strict-transport-security 响应头必须严格全小写拼写、首字母大写、连字符为英文短横且无空格，任何偏差都会导致浏览器忽略；需用 curl -i 验证原始响应头，排查 nginx 多级配置、第三方模块、cdn/waf 篡改及中间设备干扰。
浏览器对 Strict-Transport-Security 响应头的名称极其敏感——必须**全小写、完全拼对、不能多空格或换行**，任何大小写偏差（如 strict-transport-security 或 Strict-transport-security）或拼写错误（如 Strict-Transport-Secruity）都会导致该头被直接忽略，HSTS 策略完全不生效。
确认响应头名称是否准确
别依赖配置文件里的写法，要验证 Nginx 实际返回的响应头：
- 用
curl -I https://your-domain.com获取原始响应头，注意观察输出中是否出现 Strict-Transport-Security（首字母大写，中间全小写，连字符为英文短横，无空格） - 若看到的是
strict-transport-security、STRICT-TRANSPORT-SECURITY或Strict_Transport_Security，说明名称已被改写或由其他组件（如 CDN、WAF、反向代理层）覆盖 - 特别注意：Nginx 的
add_header指令本身不校验 header 名合法性，但若你启用了underscores_in_headers on，它只影响请求头，不影响响应头；而某些 WAF 或云服务会自动标准化 header 名，把大写转小写
检查 Nginx 配置中是否被覆盖或重写
HSTS 头可能在多个层级被意外覆盖：
- 检查是否有多个
add_header出现在不同作用域（http、server、location），Nginx 只保留最后一级生效的那条，且大小写必须一致 - 确认未启用
more_set_headers（来自 headers-more 模块）等第三方模块，它们可能用不同大小写重写了该头 - 若使用了 Nginx Proxy Manager（NPM）或 Kubernetes Ingress Controller，它们常内置 header 注入逻辑——例如 NPM 默认注入的 HSTS 头是标准写法，但自定义注解可能拼错；Ingress 中
nginx.ingress.kubernetes.io/configuration-snippet若手写 header，极易出现大小写/拼写错误
排查中间件或 CDN 干扰
即使 Nginx 返回正确，上游设备也可能篡改：
- 在服务器本地直连测试：
curl -I --resolve your-domain.com:443:127.0.0.1 https://your-domain.com，绕过 DNS 和公网链路，确认原始响应 - 对比 CDN（如 Cloudflare、阿里云全站加速）后台是否开启了“HSTS 自动启用”功能，该功能通常强制使用标准名称，但若你同时在源站也发 HSTS，可能因重复或冲突导致行为异常
- 某些安全网关或 WAF 会删除或重写非标准 header 名——若发现本地 curl 正确、公网 curl 错误，大概率是中间设备所为
快速验证与修复建议
最稳妥的验证方式是组合检查：
- 先用
curl -I看响应头原始字符串，复制整行粘贴到文本编辑器，逐字符比对是否为 Strict-Transport-Security - 在 Chrome 开发者工具 Network 标签页中，点击 HTTPS 请求 → Headers → Response Headers，展开查看，注意区分大小写渲染（Chrome 会统一显示为小写，但实际发送值以 curl 为准）
- 修复时统一采用官方推荐写法：
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;，不要手动修改大小写或缩写 - 修改后执行
nginx -t && nginx -s reload，并立即用 curl 验证，避免缓存干扰
