HSTS引发的访问冲突本质是浏览器缓存旧策略导致TLS握手失败，用户见拦截页而Nginx无日志；需先查chrome://net-internals/#hsts确认策略状态，再同步验证响应头、证书链与配置一致性。
证书更换期间 HSTS 引发的访问冲突，本质是浏览器已缓存旧 HSTS 策略（如 max-age=31536000），而新证书尚未完全生效或配置不一致，导致部分请求因 TLS 握手失败、域名不匹配或重定向中断被拦截——用户看到“您的连接不是私密连接”或空白页，Nginx 日志却无对应记录。排查需同步验证客户端策略状态、服务端响应一致性与证书链完整性。
确认浏览器是否已锁定旧 HSTS 策略
这是最常被跳过的起点。HSTS 一旦生效，浏览器会主动拒绝 HTTP 请求，且不发包到服务端，因此 Nginx 日志里查不到 301/400 类错误。
- 在 Chrome 或 Edge 地址栏输入：chrome://net-internals/#hsts
- 在 “Query domain” 中输入你的域名（如 api.example.com），点击 Query
- 若返回 Found，并显示 max-age > 0，说明浏览器仍强制走 HTTPS，且会校验证书有效性；若为 Not found，则问题不在 HSTS
- 特别注意：若启用 includeSubDomains，主域和关键子域（如 www、api）需分别查询
检查新证书是否真正被 HSTS 响应头“背书”
HSTS 头本身不校验证书，但它让浏览器对 HTTPS 连接更严格——一旦证书异常（域名不匹配、过期、链不全），用户将直接看到浏览器拦截页，而非 Nginx 返回的错误页面。
- 用 curl 直连每个 Nginx 节点 IP（绕过 DNS 和 CDN），确认 HTTPS 响应头含 HSTS：
curl -I -k https://your-domain.com | grep -i "strict-transport-security" - 比对三项是否统一：是否存在该头、max-age 值是否非零、是否含 includeSubDomains（若启用）
- 同时用
curl -v https://your-domain.com查看 TLS 握手详情，重点关注：
– Subject CN / SAN 是否匹配当前域名
– notAfter 时间是否晚于 2026-10-02
– 是否返回完整证书链（尤其有 intermediate 时）
排查证书更新与 HSTS 配置的时间差风险
证书刚换完，但 HSTS 仍带大 max-age，此时若新证书有细微问题（如私钥不匹配、OCSP stapling 失败、CDN 缓存旧 OCSP 响应），用户就会间歇性失败——“时有时无”正是典型表现。
- 检查 Nginx 配置中 HSTS 是否写在 listen 443 ssl 的 server 块内，而非 http 或 location 块；避免因配置未加载导致部分响应缺失该头
- 确认所有节点都已重载：
nginx -s reload，且nginx -t通过；多节点环境必须逐台验证，不能只改一台 - 若使用 CDN 或 WAF（如阿里云 DDoS 高防、Cloudflare），登录控制台确认其 SSL 设置已同步新证书，并关闭“强制使用平台证书”类选项
- 临时规避：可将 HSTS max-age 设为 0（如
add_header Strict-Transport-Security "max-age=0; includeSubDomains" always;），再重载，快速解除浏览器强制策略（配合 chrome://net-internals 手动删除）
验证代理链路是否污染或剥离 HSTS
前端如有 Nginx Proxy Manager、WAF 或二级反向代理，它们可能主动清除 Strict-Transport-Security 头，或用自己的证书重新封装 TLS，导致 HSTS 头虽存在，但证书校验对象错位。
- 从客户端 curl 最外层入口（如公网 VIP 或 CDN 回源地址），对比响应头与直连 Nginx 节点的差异
- 检查中间层是否设置了
proxy_hide_header Strict-Transport-Security—— 这是 Nginx 常见误配，会静默丢弃该头 - 若用 Nginx Proxy Manager（NPM），进入对应 Proxy Host → SSL → Custom Headers，确认未禁用 HSTS 或覆盖为错误值
- 抓包验证：用 tcpdump 或 Wireshark 在 Nginx 入口网卡捕获 TLS 握手包，确认 Server Hello 后的 HTTP 响应是否含 HSTS 头
