必须添加always参数，否则Nginx仅在2xx/3xx响应中输出头，302、4xx、5xx等响应缺失CORS、HSTS等关键头，导致跨域失败或安全策略失效。
直接加 always 是最有效的方式。Nginx 默认只在特定状态码（如 200、301、304 等）下注入 add_header，而 302 不在默认生效列表中（除非你用的是较新版本且明确支持），导致重定向响应里缺失 HSTS、CORS 或 Referrer-Policy 这类关键头。
为什么 302 响应里 header 会丢失
Nginx 的 add_header 指令有严格的状态码限制：它默认仅对 200、201、204、206、301、303、304、307、308 等少数状态码生效；302 被排除在外（尤其在 1.12.x 及更早版本中）。即使你在 server 或 location 块里写了安全头，只要响应是 302，这些头就不会出现在实际返回中。
- 浏览器收到无
Strict-Transport-Security的 302，不会启用 HSTS，后续请求仍可能走 HTTP - 前端发起 CORS 请求后被 302 重定向，若跳转目标没带
Access-Control-Allow-Origin，跨域校验失败 -
Referrer-Policy缺失时，重定向携带的 referer 可能泄露敏感路径
使用 always 参数强制注入所有响应
加上 always 后，Nginx 会无视状态码，把头字段加到所有响应中，包括 302、401、403、500 等异常或重定向响应。
- 确保 Nginx 版本 ≥ 1.7.5（2014 年发布，当前主流版本均满足）
- 语法必须完整：
add_header Header-Name "value" always;，漏掉分号或拼错always会报配置错误 - 常见安全头示例：
add_header Access-Control-Allow-Origin "*" always;
add_header Referrer-Policy "no-referrer-when-downgrade" always;
add_header X-Content-Type-Options "nosniff" always;
注意继承规则和 location 冲突
add_header 不会跨层级自动叠加——如果父级（如 server）和子级（如 location /api）都定义了 add_header，子级会完全覆盖父级，而不是合并。这意味着：
- 若你在
location中只写了一条add_header Access-Control-Allow-Origin "*"，但没加always，那该 location 下的 302 依然不带这个头 - 若你希望全站统一加安全头，建议统一放在
server块，并显式带上always - 避免在多个嵌套
location中重复定义相同 header，否则容易遗漏always导致部分路径失效
验证是否生效
重启 Nginx 后，用 curl 模拟 302 响应测试：
curl -I -X GET http://your-domain.com/some-redirect-path检查响应头中是否包含你配置的字段，特别确认状态行是 HTTP/1.1 302 Moved Temporarily 时头仍在。
浏览器开发者工具的 Network 面板中，筛选出 302 请求，点开 Response Headers 标签页，逐项核对。
