答案是排查hsts问题需分四步：一查chrome://net-internals确认浏览器是否缓存hsts；二用curl检查nginx是否仍在返回strict-transport-security头；三通过分层抓包验证请求是否被浏览器拦截；四同步将max-age设为0并手动删除客户端hsts策略。
排查 Nginx 的 HSTS 相关问题，核心在于分清“服务端配置”和“客户端强制行为”的边界。很多看似 Nginx 在跳转、重定向或拒绝 HTTP 的现象，实际是浏览器已缓存 HSTS 策略后主动拦截——请求根本没发出去，Nginx 日志里自然查不到 301/302，也看不到任何访问痕迹。抓包也抓不到 HTTP 请求，因为 TLS 握手前就被浏览器拦下了。
一、确认 HSTS 是否已在浏览器生效
这是最常被跳过的一步，却是定位问题的起点：
- 在 Chrome 或 Edge 地址栏输入：chrome://net-internals/#hsts
- 在下方 “Query domain” 输入你的测试域名（如 test.example.com），点击 Query
- 若返回 Found，说明该域名已被记录，max-age 值即剩余强制 HTTPS 时长；若显示 Not found，问题不在 HSTS 缓存，需转向其他方向（如证书错误、Nginx 80 端口未配置跳转等）
二、检查 Nginx 是否仍在发送 HSTS 响应头
即使你认为已关闭 HSTS，也可能因配置残留或 Ingress Controller 默认启用而继续下发：
- 执行命令：curl -I https://test.example.com，观察响应头中是否含 Strict-Transport-Security
- 如果是裸 Nginx：检查 server 块是否有 add_header Strict-Transport-Security ...，注意该指令在 location 中定义时，可能被子配置覆盖
- 如果是 Nginx Proxy Manager（NPM）：进入代理主机设置 → SSL 选项卡 → 查看“HSTS”开关是否关闭
- 如果是 Kubernetes Ingress：检查 Ingress 资源注解（如 nginx.ingress.kubernetes.io/hsts: "false"）或 Ingress Controller ConfigMap 中 hsts 字段是否设为 false
三、全链路抓包验证 HSTS 干预时机
HTTPS 抓包“看不到 HTTP 请求”，不是工具失效，而是 HSTS 让浏览器压根不发起 HTTP 连接。要验证这一点，需分层抓包：
- 浏览器侧：用 Chrome DevTools → Network 标签页，刷新页面，观察地址栏是否自动变为 https://，且无 http:// 请求出现
- 本机网络层：用 tcpdump -i lo port 80（监听回环）或 tcpdump -i eth0 host test.example.com and port 80，确认无 SYN 包发出
- 对比验证：开 Chrome 无痕窗口（不继承 HSTS 缓存）访问同一域名，再抓包——此时若能看到 HTTP 请求（或 301 跳转），即可确认原问题确由 HSTS 导致
四、彻底清理与临时绕过方案
仅停掉 Nginx 的 HSTS 头不够，必须同步清除客户端策略：
- 服务端立即生效：将 HSTS max-age 设为 0，例如 add_header Strict-Transport-Security "max-age=0; includeSubDomains";，然后 reload Nginx 或更新 Ingress 配置
- 客户端强制清除：回到 chrome://net-internals/#hsts → “Delete domain security policies” → 输入域名 → Delete
- 警惕预加载风险：若域名曾提交至 hstspreload.org 并被收录，则本地清除无效，只能等待官方列表更新（通常数周）或改用新域名
不复杂但容易忽略
