Nginx的add_header在internal重定向中不继承，仅对当前location生效；同名header默认覆盖而非叠加；需在终点location显式配置或加always参数确保生效。
Nginx 的 add_header 指令在 internal 重定向（即 internal; location 或使用 rewrite ... last; / try_files 触发的内部跳转）中**不会自动继承或叠加**，其行为取决于 header 是否已在上游响应中存在，且受指令作用域和执行阶段影响。这不是“缓存表现”，而是 Nginx 响应头合并机制与请求处理流程共同决定的结果。
add_header 的作用域与执行时机
add_header 只在当前 location 的 响应发送阶段（post-read 阶段之后，filter 阶段） 生效，且仅对当前 location 生成的响应起作用。当发生 internal 重定向时：
- 原 location 的
add_header不会传递给目标 location； - 目标 location 若未显式配置
add_header，则不会添加对应 header； - 若多个 location 都设置了同名 header（如
add_header X-Foo "a";和add_header X-Foo "b";），Nginx 默认只保留最后一个生效的值（非追加）； - 该行为与 proxy_cache、fastcgi_cache 等缓存无关——即使响应被缓存，header 也是按上述规则在首次生成响应时确定的。
Internal 重定向中 header 的实际表现
以常见场景为例：
-
try_files $uri @fallback;→ 进入location @fallback { internal; add_header X-Source "backend"; }：最终响应包含X-Source: backend，但主 location 中的add_header不生效； -
rewrite ^/api/(.*)$ /backend/$1 break;（非 last）：不触发 internal 重定向，仍在同一 location，原有add_header有效； -
rewrite ^/api/(.*)$ /backend/$1 last;：触发 internal 跳转到location /backend/，此时只有该 location 的add_header生效； - 若后端（如 FastCGI 或 proxy）本身返回了
X-Frame-Options，而 location 中又用add_header X-Frame-Options "DENY"，Nginx 默认不会覆盖**已存在的 header（除非启用always参数）。
如何确保 header 在 internal 流程中可靠出现
关键方法是统一在最终处理 location 中声明，或使用 always 显式控制覆盖逻辑：
- 在所有可能作为终点的 internal location 中，重复写明所需
add_header； - 对必须强制设置的 header（如安全头），加上
always参数：add_header X-Content-Type-Options "nosniff" always;，使其在 2xx/3xx/4xx/5xx 响应中均生效； - 避免依赖“继承”，Nginx 无 header 继承机制；
- 调试时可用
curl -I或查看 access_log 中$sent_http_*变量验证实际发出的 header。
与缓存相关的常见误解澄清
有人观察到“加了 add_header 后缓存失效”或“header 没进缓存”，其实本质是：
- proxy_cache_key 默认不含 response header，所以 header 变化本身不影响缓存命中；
- 但若 header 设置导致后端响应内容变化（例如通过
add_header触发不同业务逻辑——这不属于 Nginx 行为），才间接影响缓存； - 真正影响缓存的是
Cache-Control、Expires、Vary等由后端或 Nginx 显式设置的响应头，而非任意add_header； - 如果用
expires或add_header Cache-Control控制缓存，需确保它们写在最终 location 中，否则不生效。
