在 Nginx 中配置 HSTS 强制 HTTPS，正确指令是在监听 443 端口的 HTTPS server 块内使用 add_header Strict-Transport-Security 并带上 always 参数，HTTP 端口块中配置无效。
先说结论：Nginx 启用 HSTS 只能用 add_header 指令，且必须放在 443 端口的 server 块中，加 always 参数确保非 200 响应也携带该头。
- 先判断：确认你的 Nginx 已正确配置 SSL 证书且 443 端口可正常访问 HTTPS
- 优先做：在 listen 443 ssl 的 server 块内添加带 always 参数的 add_header 指令
- 再验证：用 curl 或浏览器开发者工具检查响应头是否包含 Strict-Transport-Security
命令速用版
直接可用的配置片段如下，放入你的 HTTPS server 块中：
server {listen 443 ssl;server_name example.com;# SSL 证书配置（已有则跳过）ssl_certificate /path/to/cert.crt;ssl_certificate_key /path/to/key.key;# HSTS 配置核心指令add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;
}HTTP 强制跳转单独在 80 端口 server 块处理：
server {listen 80;server_name example.com;return 301 https://$host$request_uri;
}为什么会这样
HSTS（HTTP Strict Transport Security）是浏览器原生支持的安全策略，通过响应头告诉浏览器在未来一段时间内只允许通过 HTTPS 访问该域名。关键限制有两条：
第一，HSTS 头只能在 HTTPS 响应中被浏览器接受。RFC 6797 明确规定，HTTP 响应中的 Strict-Transport-Security 头会被浏览器完全忽略。所以即使你在 80 端口配了 add_header，浏览器也不会认。
第二，Nginx 没有 Header set 指令。这是 Apache 的语法，在 Nginx 配置里写 Header always set 会导致 nginx -t 直接报错 unknown directive。Nginx 唯一可用的指令是 add_header，属于 ngx_http_headers_module 模块，默认内置无需额外加载。
分步处理
步骤一：确认 HTTPS 已正常工作
先确保 443 端口的 server 块能正常响应 HTTPS 请求，证书有效且域名匹配。用 curl 测试：
curl -I https://example.com
如果返回 200 或 301 且能看到证书信息，说明 HTTPS 基础配置没问题。
步骤二：在 HTTPS server 块添加 HSTS 头
打开 Nginx 配置文件（通常位于/etc/nginx/nginx.conf 或/etc/nginx/conf.d/ 目录下），找到监听 443 的 server 块，添加：
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;
参数说明：max-age 单位是秒，决定浏览器记住策略的时长；includeSubDomains 表示策略适用于所有一级子域；preload 表示愿意提交到浏览器预加载列表（需额外满足条件）；always 确保 404、500 等非 200 响应也携带该头。
步骤三：检查配置语法并重新加载
nginx -t nginx -s reload
如果 nginx -t 报错，检查是否有拼写错误或指令放错了位置。
步骤四：灰度验证
建议先用较短的 max-age 值（如 300 秒）测试，确认无误后再延长。避免配置错误导致子域名无法访问或测试环境被浏览器拦截。
怎么验证是否生效
方法一：curl 检查响应头
curl -I https://example.com
在输出中查找 Strict-Transport-Security 行，确认值与配置一致。
方法二：浏览器开发者工具
打开浏览器按 F12，切换到 Network 标签，刷新页面后点击主文档请求，在 Response Headers 部分查看是否有 Strict-Transport-Security 头。
方法三：在线检测工具
使用 SSL Labs 等在线工具扫描域名，会显示 HSTS 是否启用及参数详情。
常见坑
坑一：add_header 不继承到 location 块
如果在 server 级配置了 HSTS，但某些 location 块里又定义了其他 add_header，server 级的头会被完全覆盖。解决方法是在每个 location 块中也添加相同的 add_header，或把 HSTS 配置移到更内层。
坑二：在 HTTP 块配置 HSTS
在 listen 80 的 server 块里加 add_header 无效，浏览器会直接忽略。还可能暴露你启用了 HSTS 的意图，增加安全风险。
坑三：忘记加 always 参数
没有 always 参数时，404、500、304 等非 2xx 响应不会携带 HSTS 头，可能导致策略在某些场景下失效。
坑四：includeSubDomains 启用前未验证子域
开启 includeSubDomains 前需确认所有子域名都已支持 HTTPS，否则会导致子域无法访问。
坑五：后端应用也返回 HSTS 头
如果后端（如 Spring Boot、Node.js）自己返回了 HSTS，而 Nginx 又配置了，可能出现策略冲突。建议在 Nginx 中统一清理后端返回的 HSTS 头。
坑六：CDN 剥离或覆盖 header
如果用了 CDN（如 Cloudflare），需确认它未剥离或覆盖该 header，部分 CDN 要在控制台单独开启 HSTS 开关。
参考来源
- Nginx 官方文档 - ngx_http_headers_module 模块说明
- RFC 6797 - HTTP Strict Transport Security 协议规范
- HSTS Preload 官方提交页面 - hstspreload.org
原文链接：https://www.zjcp.cc/ask/11736.html