nginx 通过 proxy_hide_header 清除后端响应头、add_header（带 always）注入标准化头，确保跨域、安全、hsts 等头统一可控；需注意配置顺序、作用域、状态码覆盖及 options 拦截，并辅以 include 管理、ci/cd 校验和定期验证。
在 Nginx 集群架构中，后端响应头的统一规范不是靠“协调后端”实现的，而是由 Nginx 主动接管、先清后加——即屏蔽不可控头、再注入合规头，确保所有上游返回的响应对外一致、安全、可预期。
统一剥离易冲突的响应头
后端服务（尤其是多语言、多团队维护的微服务）常各自设置 Access-Control-Allow-Origin、X-Powered-By、Strict-Transport-Security 等头，叠加后易导致浏览器拒绝响应或缓存异常。必须用 proxy_hide_header 在 location 块内、proxy_pass 之后 显式清除：
- 跨域类：Access-Control-Allow-Origin、Access-Control-Allow-Methods、Access-Control-Allow-Headers
- 安全类：Strict-Transport-Security、X-Frame-Options、X-XSS-Protection、X-Content-Type-Options
- 协议/缓存类：Transfer-Encoding、Cache-Control、Expires、Server（配合 server_tokens off）
注意：该指令不继承，upstream 中不能配置，每个需代理的 location 都要单独写；头名大小写不敏感，但不能用正则匹配。
统一注入可控且合规的响应头
清掉旧头后，Nginx 必须主动补上标准化头，推荐全部加上 always 参数，确保 4xx/5xx/204 等非 200 响应也携带必要头：
- 跨域头：用
add_header Access-Control-Allow-Origin "$http_origin" always;动态回传，避免与 credentials 冲突；预检请求 OPTIONS 应由 Nginx 直接拦截并返回 204 - 安全头：如
add_header X-Content-Type-Options nosniff always;、add_header X-Frame-Options DENY always; - HSTS：仅 HTTPS 下启用，用
if ($scheme = https) { add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always; } - 版本标识：统一加
add_header X-API-Version "v2" always;，便于可观测性与问题定位
避免常见陷阱与配置盲区
看似简单，但几个细节极易出错：
- 顺序错误：proxy_hide_header 必须写在 proxy_pass 之后，否则不生效
- 作用域遗漏：server 块里设了，子 location 不自动继承；建议用 include 引入公共头清理片段，保持复用性
- 状态码限制：不加 always 的 add_header 默认只对 200/301/302 等特定状态码生效，错误响应会丢失跨域头，前端无法读取 error detail
- OPTIONS 请求穿透：未拦截的 OPTIONS 会打到后端，若后端未正确处理，可能返回 502 或无响应头；应在 location 内用 if 判断并直接 return 204
配套机制保障长期一致性
单靠配置还不够，需结合运维机制：
- 将常用 proxy_hide_header / add_header 片段拆为独立 conf 文件（如 headers-sanitize.conf），通过 include 管理，避免重复粘贴
- 在 CI/CD 流程中加入 Nginx 配置语法校验和头策略检查（例如禁止出现 Access-Control-Allow-Origin * 与 credentials 共存）
- 日志中记录 $upstream_http_x_api_version 等透传头，用于链路追踪与版本行为审计
- 定期用 curl -I 检查各 endpoint 的实际响应头，验证是否符合预期（尤其关注 401/500 等错误路径）
