uwsgi_param 和 proxy_set_header 之间的区别

Question

当使用 Nginx 作为 uWSGI/Django 的反向代理时， Nginx 配置中uwsgi_param和之间有什么区别？proxy_set_headeruWSGI 参数是否像 HTTP 标头，或者完全不同，如果是，其目的是什么？

---

背景：我正在 Django 中对与安全相关的 HTTP 标头进行一些修改。我有一个使用 Nginx 作为反向代理的设置，uWSGI 为 Django 应用程序提供服务并作为代理服务器：

                           _____________________________________
                           |                                    |
            http or https* |           uwsgi                    |
   browser --------------> | nginx --------------> uWSGI/Django |
                           |____________________________________|

* http 301-redirects to https equivalent;
  https response returns Strict-Transport-Security header

这里有两种机制可以让 http 请求“变成”https 请求：

1. Nginx将端口80请求重定向到443，例如请求历史链有301重定向
2. HTTPs 响应包含Strict-Transport-Security: max-age=31536000; includeSubDomains; preload响应标头；在这种情况下，永远不会有 302 重定向；浏览器接受客户端 http 请求并立即强制其转换为等效的 https。

也就是说，相关的 Django 设置如下所示：

# tail -n4 project/settings.py
SECURE_HSTS_SECONDS = 31536000  # Seconds; *USE A SMALLER VALUE FOR TESTING FIRST!*
SECURE_HSTS_PRELOAD = True
SECURE_HSTS_INCLUDE_SUBDOMAINS = True
SECURE_PROXY_SSL_HEADER = ("HTTP_X_FORWARDED_PROTO", "https")

和 Nginx 配置：

server {
    server_name .mydomain.com;
    listen 80;
    return 301 https://$host$request_uri;
}

server {
    location / {
        uwsgi_pass localhost:8000;
        include uwsgi_params;
        uwsgi_param X-Forwarded-Proto "https";
        proxy_set_header X-Forwarded-Proto "https";
    }
    listen 443 ssl; # managed by Certbot
    ssl_certificate /etc/letsencrypt/live/mydomain.com/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/mydomain.com/privkey.pem; # managed by Certbot
    include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot
}

那么，当 Django 应用程序收到原始连接是 HTTPs via 的消息时SECURE_PROXY_SSL_HEADER，它是否有uwsgi_param或proxy_set_header值得感谢？仍然proxy_set_header实际使用，因为协议是 uwsgi 而不是proxy_pass: http://localhost:8000？a 有什么uwsgi_param作用？我在协议描述中看到的很少。它的行为是否类似于 HTTP 标头，还是完全不同？

Answer 1

是的，感谢uwsgi_param或proxy_set_header HTTP_X_Forwarded_Proto设置了标头（否则它不会出现）并且 django 应用程序（通过 https 代理后面的 http 工作）可以知道，原始请求是安全的（通过 https）。

Nginx 将初始 http 请求转发到底层上游服务器。为此，它可以使用不同的协议 -如果设置了指令，则使用uwsgi ；如果设置了指令，则使用http 。只需要在块中设置其中之一即可。uwsgi_passproxy_pass

默认情况下，nginx 将所有原始请求标头转发到上游，这是由proxy_pass_request_headers和uwsgi_pass_request_headers选项控制的。使用proxy_set_header或uwsgi_param标头及其值可以显式设置/添加。

With proxy_pass- 请求作为 HTTP 请求转发到上游服务器。并且proxy_set_header可以设置标头及其要传递的值。

请求uwsgi_pass通过 uwsgi 二进制协议转发。它不是 http，它没有“标头”，而是具有要传递的参数uwsgi_param（如果参数名称带有前缀HTTP_- 它可作为 wsgi 应用程序中的标头）。

Uwsgi 是 wsgi 服务器的本机（但大多数也可以通过 http 工作），并且允许通过传递参数对 wsgi 服务器处理请求的方式进行更多微调。并且通过配置可以提高性能。然而，差异可能非常微妙。

需要 http 的几种情况（主要原因是它的普遍性）：

• 直接用于服务之间的内部通信
• 你可能想使用或尝试除 nginx 之外的其他 https 代理（现在有很多），它可能不支持 uwsgi
• 使用微服务方法 - nginx 和 uwsgi 之间可能存在其他代理/边车（用于身份验证、日志记录等），并且它们仅适用于 http