全站的响应头本来都有，给下载目录单独加了一条Cache-Control后，原来的头却消失了。先看子路径的配置层级，再区分继承中断与状态码不匹配。
确认是哪个响应缺了头
对正常页面和子路径各执行一次curl -sS -D - -o /dev/null https://example.com/download/sample.txt，记录状态码和头部。用sudo nginx -T确认实际匹配的server、location及包含文件。该命令会打印完整配置，不要直接贴到公开工单。若经过CDN，也要确认它是否改写了响应。
区分继承和状态码规则
默认模式下，当前层只要定义一条add_header，就不再继承上一层的add_header。不是只有同名头才被覆盖。另外，未加always的头只在文档列明的状态码下添加；只有404缺头时，要先考虑状态码规则。always不会恢复已断开的继承。
根据版本选择配置
先用nginx -v确认版本。旧版可将共同头放进单独的include片段，在需要自定义头的location中显式引用；Nginx 1.29.3起可在需要的层级设置add_header_inherit merge;追加父级配置。检查同名头是否重复，尤其不要让CDN、源站和网关各生成互相冲突的策略。
确认最终落在哪个location
错误页或内部重定向可能让请求落到另一个location。对照nginx -T中的error_page和实际响应，不要为了补头给所有子路径设置同一套缓存规则。
复测正常页和错误页
在萤光云或LightNode的独立实例先比较改动前后。运行sudo nginx -t成功后再重载；对目标子路径、普通路径与预期404各检查一次。验收既要确认应有的头出现，也要确认没有多余的同名值。
FAQ
子级只加一条也会失去父级配置吗？ 默认继承模式下会。
always能解决继承吗？ 不能，它控制添加响应头的状态码范围。
旧版能用merge吗？ 1.29.3之前没有此指令。
merge会替换同名头吗？ 它追加父级配置，需检查重复值。
只看200就可以吗？ 最好同时核对重定向和错误路径。
温馨提示
变更前保留旧配置。不要把下载目录的缓存策略复制给登录或个性化内容路径。
