proxy_set_header 不提升性能但保障上下文准确传递，关键在精准控制必要头、剔除冗余项；应禁用无用头、动态设host、慎用x-forwarded-for、用add_header分担后端响应头压力。
proxy_set_header 本身不直接提升代理性能，它的核心价值在于确保请求上下文准确传递，避免因头信息错误引发重试、鉴权失败或后端逻辑误判——这些隐性问题才是拖慢整体响应的真实瓶颈。优化的关键不是“加更多头”，而是精准控制必要头、剔除干扰项、减少冗余转发。
只传必需的请求头
默认情况下 Nginx 会转发大部分客户端请求头，但很多对后端无用（如 Accept-Encoding、Sec-Fetch-* 等），反而增加网络开销和后端解析负担。应显式覆盖或清空非必要头：
- 用 proxy_set_header Accept-Encoding "" 禁用客户端压缩声明，由 Nginx 统一处理 gzip（配合 gzip on）更高效
- 用 proxy_set_header User-Agent "$http_user_agent" 或 proxy_set_header User-Agent "" 控制是否透传设备信息，避免后端做无效 UA 分析
- 避免无差别写 proxy_set_header * $http_*，这会把所有原始头都带过去，包括浏览器私有头、调试头等
用变量替代静态值，减少硬编码
静态值（如 proxy_set_header Host 'b.winfun.com'）无法适配多域名或多环境场景，容易导致 Host 不匹配、SSL SNI 错误或虚拟主机路由失败。应优先使用内置变量动态生成：
- proxy_set_header Host $host —— 保留原始 Host，适合单域名或多租户场景
- proxy_set_header X-Forwarded-Proto $scheme —— 正确标识 http/https，避免后端误判协议导致跳转循环
- proxy_set_header X-Real-IP $remote_addr —— 直接传递真实 IP，比解析 X-Forwarded-For 更快更可靠
慎用 $proxy_add_x_forwarded_for，避免 IP 链膨胀
在单层代理中，$proxy_add_x_forwarded_for 是安全的；但在 CDN + Nginx + 后端多级架构下，它可能重复追加 IP，造成头过长甚至被后端截断或拒绝。更稳妥的做法是：
- 若只有一层 Nginx 代理：proxy_set_header X-Forwarded-For $remote_addr
- 若明确知道上游已设好 X-Forwarded-For：proxy_set_header X-Forwarded-For $http_x_forwarded_for
- 禁用该头（后端直接读 X-Real-IP）可彻底规避链路污染风险
配合 add_header 减少后端响应头压力
有些响应头（如 Cache-Control、Strict-Transport-Security）无需后端生成，Nginx 可统一注入。这样既能降低后端 CPU 开销，又能保证策略一致性：
- add_header Cache-Control "public, max-age=3600" —— 静态资源缓存由 Nginx 控制，后端不用再设
- add_header X-Content-Type-Options "nosniff" —— 安全头由边缘统一加，避免每个服务重复实现
- 注意：add_header 不继承，需在对应 location 块中重复配置；如需全局，放在 server 块
