Nginx企业级HSTS加固需闭环生效：HTTP server块仅配301跳转，HTTPS server块（listen 443 ssl）中用add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always，确保首次访问即HTTPS、全站证书有效、协议仅TLSv1.2+，并验证响应头与证书链完整。
企业级 Nginx HSTS 安全加固不是加一行头就完事，关键在“生效闭环”——必须确保浏览器首次访问即走 HTTPS、且后续所有请求强制加密，否则 HSTS 形同虚设。
必须配置 HTTPS 重定向 + HSTS 响应头
HSTS 只在 HTTPS 响应中被浏览器接受。如果用户用 http://example.com 首次打开，Nginx 返回 301 跳转到 HTTPS，但该 HTTP 响应本身不能带 HSTS 头（浏览器直接忽略）。所以：
- HTTP server 块只做 301 强制跳转：
return 301 https://$host$request_uri; - HTTPS server 块中必须配置 HSTS，并加
always参数：add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always; -
preload表示申请加入浏览器预加载列表，需确保全站 HTTPS 稳定运行至少 48 小时再启用
避免常见失效场景
很多线上环境 HSTS 不生效，问题不在语法，而在上下文逻辑：
- 没在 HTTPS server 块里配，而是写在 HTTP 块或 location 块里 —— 无效
- 证书不完整（缺中间 CA）导致 TLS 握手失败，浏览器收不到响应，自然也收不到 HSTS 头
- 使用了自签名或内网 CA 证书 —— 浏览器不信任，连接中断，HSTS 无从谈起
- 配置了
add_header但没加always，当 Nginx 返回 304 或错误页时，该头会被丢弃
基线核查要点（可直接用于安全审计）
以下为可落地的检查项，每项都对应明确的配置位置和验证方式：
- 检查
nginx -T | grep -A2 "Strict-Transport-Security"是否仅出现在server { listen 443 ssl; ... }块中 - 用 curl 验证 HTTPS 响应头：
curl -I https://example.com，确认返回含Strict-Transport-Security且max-age ≥ 31536000 - 检查 HTTP 响应是否 301 跳转：
curl -I http://example.com，状态码必须是301，Location 必须为https:// - 确认证书链完整：
openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -text | grep "CA Issuers"，应能解析出有效中间证书 URL
进阶加固：与整体 TLS 策略协同
HSTS 是传输层安全的“开关”，但真正防护靠整套 TLS 配置：
- 协议仅启用
TLSv1.2 TLSv1.3，禁用 TLSv1.0/1.1 - 加密套件优先 ECDHE + AES-GCM 或 ChaCha20，禁用 RSA 密钥交换、MD5、SHA1
- 开启 OCSP Stapling：
ssl_stapling on; ssl_stapling_verify on;，降低证书吊销验证延迟 - 会话复用启用：
ssl_session_cache shared:SSL:50m; ssl_session_timeout 1d;，兼顾性能与前向保密
