proxy_set_header本身不传递会话，但通过透传cookie、x-forwarded-for、x-forwarded-proto等头部，并配合后端信任配置，才能保障会话正常识别与安全校验。
在 Nginx 中，proxy_set_header 本身不直接“传递会话信息”，但它能将客户端请求中的关键字段（如 Cookie、Host、X-Forwarded-For 等）正确转发给上游服务，从而让后端应用能正常识别用户会话。真正起作用的是你选择传递哪些头，以及后端是否信任并解析这些头。
确保 Cookie 正确透传
会话通常依赖 Cookie 头（如 sessionid=abc123）。默认情况下，Nginx 会原样转发客户端的 Cookie，但若配置了 proxy_set_header Cookie "" 或类似覆盖操作，就会清空它——这是常见误操作。
- 除非有特殊需求（比如脱敏或重写），不要主动设置
Cookie头 - 保持默认行为即可：Nginx 自动将客户端的
Cookie转发给上游 - 如需修改（例如添加前缀、过滤敏感字段），可用
map指令配合proxy_set_header Cookie $new_cookie
设置可信的 X-Forwarded-* 头辅助识别
当 Nginx 作为反向代理时，后端看到的源 IP 和 Host 是 Nginx 的，而非真实客户端。通过设置 X-Forwarded-For、X-Forwarded-Proto 等头，帮助后端还原原始请求上下文，这对基于 IP 或协议判断会话安全性的场景很关键。
FastAPI Flask Proxy
下载
FastAPI + Flask 混合部署最佳实践，解决路由定义、API 代理等常见问题，适用于同时运行 FastAPI API 与 Flask 前端的场景。
-
proxy_set_header X-Forwarded-For $remote_addr;—— 记录原始客户端 IP（注意：若有多层代理，应使用$proxy_add_x_forwarded_for追加） -
proxy_set_header X-Forwarded-Proto $scheme;—— 告知后端是 http 还是 https，避免混合内容或跳转错误 -
proxy_set_header X-Forwarded-Host $host;—— 保留原始 Host，便于多租户或虚拟主机路由
避免覆盖关键头导致会话丢失
某些框架（如 Django、Flask、Spring Security）依赖特定请求头做会话校验。若 Nginx 错误覆盖了 Host、Referer 或自定义认证头（如 Authorization），可能导致会话验证失败或 CSRF 检查不通过。
- 慎用
proxy_set_header Host $host;：应改为proxy_set_header Host $http_host;，以保留端口和原始 Host 值 - 若后端需要
Authorization（如 JWT Bearer Token），确保未被 Nginx 清除：proxy_pass_request_headers on;（默认开启，但检查是否被显式关闭） - 不要无故设置空值，例如
proxy_set_header Referer ""，可能影响后端 referer 校验逻辑
配合后端信任代理 IP 才真正生效
仅设置 X-Forwarded-* 头还不够。后端必须明确配置为“信任来自 Nginx 的转发头”，否则会忽略它们，导致取到错误的 IP 或协议，进而影响会话绑定、HTTPS 重定向、CSRF token 验证等。
- Django：设置
SECURE_PROXY_SSL_HEADER = ('HTTP_X_FORWARDED_PROTO', 'https')并配置USE_X_FORWARDED_HOST和TRUSTED_PROXIES - Spring Boot：通过
server.forward-headers-strategy=framework启用，并设server.tomcat.remote-ip-header=x-forwarded-for - Node.js（Express）：使用
app.set('trust proxy', '127.0.0.1')显式声明可信代理 IP
