hsts防降级效果验证需三步：一查浏览器是否缓存策略（chrome://net-internals/#hsts），二测http访问是否被自动跳转且无明文请求，三用无痕窗口模拟首次访问并结合curl与开发者工具交叉确认响应头。
测试 HSTS 头是否真正起到防中间人降级（SSL stripping）的效果，核心不是看它“有没有发出去”，而是验证浏览器是否已记住策略、是否主动跳过 HTTP 尝试、是否拒绝明文连接。这需要分三步走：查策略状态、模拟降级场景、观察拦截行为。下面直接说怎么操作。
一、确认浏览器已加载并缓存 HSTS 策略
这是前提——如果浏览器根本没记住，就谈不上“防降级”。在 Chrome 或 Edge 中打开：
chrome://net-internals/#hsts
在 “Query domain” 输入你的测试域名（如 test.example.com），点击 Query。若显示 Found，且 max-age > 0，说明策略已生效；若为 Not found，后续所有测试都无意义，先回 Nginx 检查响应头是否发出。
Firefox 和 Safari 不提供内置界面查询，但它们同步 Chromium 的 HSTS 预加载列表，且对已接收过 HSTS 响应的域名行为一致。可先用 Chrome 确认策略存在，再换 Firefox/Safari 验证实际拦截效果。
二、手动触发 HTTP 访问，观察是否被拦截
HSTS 防降级的关键表现是：用户输入 http://test.example.com 或点击一个 HTTP 链接时，浏览器根本不发请求，地址栏自动变成 HTTPS 并直连 —— 这才是成功。
操作方式：
- 关闭所有该域名的标签页，清空 DNS 缓存（
ipconfig /flushdns或sudo dscacheutil -flushcache） - 在地址栏完整输入 http://test.example.com（注意是 http://，不是只输域名）
- 按回车后观察：
✅ 正确表现：地址栏瞬间变为 https://test.example.com，页面正常加载，开发者工具 Network 面板里看不到任何 HTTP 请求（只有 HTTPS）
❌ 错误表现：出现“不安全”提示、重定向循环、或 Network 中能看到 301 → HTTPS 的明文跳转 —— 说明 HSTS 未生效或被绕过
三、用无痕/隐私窗口复现首次访问场景
无痕模式不继承历史 HSTS 缓存，能模拟真实用户“第一次访问”的情况，特别适合验证 preload 或刚上线的策略：
- 新开 Chrome 无痕窗口，访问 http://test.example.com
- 若配置了 preload 且域名已在 hstspreload.org 列表中，会直接走 HTTPS（无需先访问一次 HTTPS）
- 若未预加载，首次访问 http:// 仍会失败（因为还没收到 HSTS 头），此时需先访问一次 https://，让浏览器记下策略，再关掉窗口重试 http:// —— 这才完成闭环验证
四、辅助验证：curl + 浏览器开发者工具交叉比对
仅靠肉眼容易误判，建议组合验证：
- 执行
curl -I https://test.example.com，确认响应头含 Strict-Transport-Security，且值符合预期（如max-age=300; includeSubDomains） - 在 Chrome 开发者工具 → Network → 点开任意一个 HTTPS 请求 → Headers → Response Headers，查找该字段是否存在
- 注意：如果用了 CDN（如 Cloudflare），需确认其未过滤 HSTS 头；Nginx 后端若也输出 HSTS，需用
proxy_hide_header Strict-Transport-Security避免冲突
