HSTS不可被CDN缓存或合并，必须由Nginx在443 server块中用always参数原样发出，并通过CDN透传配置确保从源站到浏览器全程不修改、不复用；否则将导致子域误锁、策略失效或跨域名污染。
HSTS 不能与 CDN 边缘节点“合并响应头”，这个说法本身存在概念偏差。HSTS 是浏览器端强制执行的安全指令，必须由源站（Nginx）在每次 HTTPS 响应中独立、稳定、原样发出；它不是可协商或可拼接的普通响应头，更不应被 CDN 缓存、覆盖、注入或参与任何“头合并”逻辑。
核心原则：HSTS 必须透传，不可缓存
CDN 的角色是代理通道，不是策略决策者。一旦 HSTS 被 CDN 缓存并复用于不同请求（比如不同 Host、不同证书状态、甚至 502 回源失败时返回旧响应），就可能引发严重安全后果：
- 未启用 HTTPS 的子域名被错误锁定，导致整个子域无法访问
- max-age 过期或配置错误后无法及时撤回，策略长期失效
- 多租户或泛域名场景下，HSTS 头被跨域名误继承（如 a.example.com 的响应被缓存后返回给 b.example.com）
- CDN 回源失败时若返回带 HSTS 的兜底响应，可能暴露不安全上下文
Nginx 配置要点：稳定生成 + 显式透传
确保 HSTS 在 Nginx 层正确下发，并让 CDN 知道“别动这个头”：
- 在 443 server 块中使用 always 参数添加头，避免因重定向或错误状态码被跳过：
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always; - 禁用 Nginx 中可能干扰的指令，例如
proxy_hide_header Strict-Transport-Security或fastcgi_hide_header相关配置 - 若使用 proxy_pass 回源到其他服务（如应用服务器），需确认上游也未重复设置 HSTS，避免冲突
CDN 侧关键设置：关闭自动干预，开启透传
不同 CDN 平台名称略有差异，但目标一致——让 HSTS 从 Nginx 出来什么样，到用户浏览器就是什么样：
- Cloudflare：关闭「Automatic HTTP Rewrites」和「HSTS Header」自动注入；在「Cache Rules」或「Edge Cache TTL」中启用「Include Response Headers」并显式勾选
Strict-Transport-Security - 腾讯云 EdgeOne：在缓存配置中关闭「自动添加 HSTS」，开启「透传源站响应头」并确保包含该字段
- AWS CloudFront：在缓存策略（Cache Policy）的「Headers」部分选择「Include the following headers」并添加
Strict-Transport-Security；同时确认「Origin request policy」未屏蔽该头
验证是否真正安全透传
上线后必须人工验证，不能只看首页正常：
- 用
curl -I https://example.com和curl -I https://example.com/404分别检查，确认所有状态码（包括 404、500、301）都携带且值一致 - 对比直连源站 IP 与走 CDN 的响应头，逐字比对 HSTS 字段，特别注意空格、分号、引号是否完全一致
- 检查 CDN 控制台缓存日志或命中状态头（如
X-Cache: HIT），确认 HSTS 不出现在缓存键计算中（即不参与 key 生成）
