proxy_set_header 是安全策略落地的关键控制点，需精准传递可信头（如Host、X-Real-IP、X-Forwarded-Proto）、主动清理高危头（如User-Agent、X-Debug）、动态控制Origin/Referer，并配合server_tokens和add_header实现请求-响应闭环防护。
proxy_set_header 不只是转发头的工具，更是安全策略落地的关键控制点。它直接影响后端服务能否正确识别请求来源、是否暴露敏感信息、以及能否抵御常见攻击链。优化它的核心思路是：该传的精准传，不该传的坚决不传，可疑的主动清理。
精准传递关键信任头，避免伪造风险
后端依赖某些头做身份和环境判断，但默认传递可能被客户端篡改。必须用可信变量重建：
- Host 头必须重置为 $host 或 $http_host：防止攻击者伪造 Host 触发虚拟主机路由错误或 SSRF
-
X-Real-IP 和 X-Forwarded-For 要区分使用：单层代理用
proxy_set_header X-Real-IP $remote_addr;；多层代理用proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;，避免覆盖原始链路 - X-Forwarded-Proto 必须设为 $scheme：确保后端知道原始是 HTTP 还是 HTTPS，防止混合内容或强制跳转失效
主动清理或屏蔽高危/冗余请求头
客户端可随意构造任意请求头，其中部分头对后端无用却可能被滥用来探测或绕过防护：
FastAPI Flask Proxy
下载
FastAPI + Flask 混合部署最佳实践，解决路由定义、API 代理等常见问题，适用于同时运行 FastAPI API 与 Flask 前端的场景。
-
清空 User-Agent：
proxy_set_header User-Agent "";减少指纹暴露，尤其在反爬或合规场景下 -
移除可疑调试头：
proxy_set_header X-Debug "";、proxy_set_header X-Forwarded-Secret "";等非标准头，防止被用于注入或信息泄露 - 不传递 Authorization 给不需认证的路径：在不需要鉴权的静态资源 location 中省略该头，降低凭证意外泄露风险
动态控制 Origin 与 Referer，强化 CORS 安全边界
跨域场景下，Origin 和 Referer 是后端做白名单校验的重要依据，不能简单透传：
-
Origin 应有条件透传：用
proxy_set_header Origin $http_origin;，但配合 map 指令限制合法域名，例如只允许来自 *.yourdomain.com 的 Origin -
Referer 可做基础过滤：对内部 API 接口，可设置
proxy_set_header Referer $http_referer;，但若后端不依赖该头，建议置空以减少攻击面 -
禁止 Origin 为空或通配符：避免配置
proxy_set_header Origin "*"，这会破坏后端白名单机制
配合 server_tokens 和自定义响应头，统一出口安全水位
proxy_set_header 控制请求头，而安全策略还需延伸到响应侧：
-
全局关闭版本暴露：在 http 块中设
server_tokens off;，防止 Nginx 版本号随错误页或响应头泄露 -
用 add_header 补充安全响应头：如
add_header X-Content-Type-Options "nosniff";、add_header X-Frame-Options "DENY";，与 proxy_set_header 形成请求-响应闭环 - 敏感路径禁用缓存头透传：对 /admin/ 或 /api/auth/ 类路径，显式清除 Cache-Control、ETag 等头，防止中间节点缓存敏感响应
