关键在于用proxy_set_header主动声明并标准化请求头：必须设置Host、X-Real-IP、X-Forwarded-For三项基础头；补充X-Forwarded-Proto/Host/Port实现协议与上下文感知；传递编码相关头解决乱码问题；显式透传Authorization等自定义头，未配置则默认丢弃。
要让后端服务稳定、可预期地接收请求头，关键不是“转发原始头”，而是用 proxy_set_header 主动声明并统一标准化——Nginx 默认不透传多数头，未显式配置的都会被丢弃，包括 Host、X-Forwarded-*、Authorization 等。标准化的核心是：明确意图、覆盖默认行为、适配后端真实需求。
必须显式设置的三项基础头
这三项是几乎所有反向代理场景的底线配置，缺一不可：
-
Host：用
proxy_set_header Host $http_host;—— 直接取客户端原始 Host 头（含端口与大小写），比$host更稳妥，避免 HTTPS 跳转丢失端口或签名校验失败； -
X-Real-IP：用
proxy_set_header X-Real-IP $remote_addr;—— 提供最可信的客户端 IP，不依赖可能被伪造的X-Forwarded-For； -
X-Forwarded-For：用
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;—— 自动追加真实 IP 到已有链中，兼容多层代理（如 CDN → Nginx → 应用），比直接写$remote_addr更安全。
协议与上下文感知头
当 Nginx 终止 HTTPS 或做域名路由时，后端需要知道“用户真正怎么访问的”：
-
X-Forwarded-Proto：设为
proxy_set_header X-Forwarded-Proto $scheme;，让后端准确判断是 http 还是 https，避免重定向循环或 Secure Cookie 无效； -
X-Forwarded-Host：用
proxy_set_header X-Forwarded-Host $http_host;，尤其在泛解析或多租户场景下，帮助后端还原原始访问域名； -
X-Forwarded-Port：配合
proxy_set_header X-Forwarded-Port $server_port;，对非标准端口（如 8443）部署很有必要。
编码与内容协商头
解决中文乱码、文件名解析异常等常见问题，需主动传递编码意图：
-
Content-Type charset：对表单类请求，可设
proxy_set_header Content-Type "application/x-www-form-urlencoded; charset=utf-8";，但注意避免覆盖 JSON 等类型，建议结合map按原始$content_type条件设置； -
Accept-Charset：推荐写两行，先继承再兜底：
proxy_set_header Accept-Charset "$http_accept_charset";和proxy_set_header Accept-Charset "utf-8";； -
X-Request-Charset：添加自定义头
proxy_set_header X-Request-Charset "UTF-8";，后端可无歧义读取，比依赖容器默认更可靠。
透传自定义头与禁用自动清除
Nginx 默认会丢弃 Connection、Upgrade、Authorization 等头，必须显式声明才能保留：
- 变量命名规则：全部小写，横线变下划线，例如
Authorization对应$http_authorization，X-Request-ID对应$http_x_request_id； - 示例：
proxy_set_header Authorization $http_authorization;、proxy_set_header X-Request-ID $request_id;（需确保$request_id已定义）； - 不要假设“没配就是透传”——未显式写的头一律不发，这是设计使然，不是 bug。
