nginx本身不诱发hsts告警，该告警由浏览器触发，根源是https证书异常，mitm是典型成因；需通过curl检查hsts头、chrome://net-internals验证缓存、排查tls解密代理或恶意根证书，并结合nginx日志中高频ssl握手失败及异常ua等指标识别mitm痕迹。
Nginx 本身不会“诱发”HSTS 告警，HSTS 告警完全由浏览器触发，根源是客户端访问了 HTTPS 站点但遭遇了证书异常——而中间人攻击（MITM）正是造成这类异常的典型原因。排查重点不是“Nginx 配置错了”，而是：为什么浏览器在收到合法 HSTS 头后，仍反复弹出红色证书警告？这往往说明客户端已被劫持，或本地环境存在干扰。
确认 HSTS 是否已正确生效
先排除配置问题，避免误判为 MITM：
- 用 curl -I https://your-domain.com 检查响应头是否含 Strict-Transport-Security，且值符合预期（如 max-age=31536000; includeSubDomains; preload）
- 打开 Chrome，访问 chrome://net-internals/#hsts，输入域名点击 Query domain，确认状态为 Found 且 includeSubdomains 为 true
- 若查询结果为空，说明 HSTS 尚未写入浏览器缓存——此时出现的证书警告与 HSTS 无关，只是普通 HTTPS 证书校验失败
区分真实 MITM 与常见干扰源
HSTS 启用后，浏览器会强制跳过 HTTP → HTTPS 重定向，直接发 HTTPS 请求。一旦此时证书不可信，就会立即拦截。需快速判断是攻击还是误报：
- 公司/学校网络：IT 部门可能部署了 TLS 解密代理（如 Zscaler、Palo Alto），它会用自己的 CA 签发伪造证书。用户需手动安装该机构根证书，否则所有 HTTPS 站点都会报错
- 本地安全软件：某些国产杀毒软件（如 360、腾讯电脑管家）或抓包工具（Fiddler、Charles）会启用 HTTPS 抓包，原理相同——需在系统信任其根证书
- 恶意证书注入：设备被植入未知根证书（如通过钓鱼 APK、恶意驱动），导致浏览器信任了攻击者控制的 CA。可在系统证书管理器中检查“受信任的根证书颁发机构”列表是否有异常条目
从 Nginx 日志反向验证异常流量模式
虽然 Nginx 不知道 HSTS，但它能记录 TLS 握手失败和请求特征，这些是 MITM 的间接证据：
- 开启增强日志，确保 log_format 包含 $ssl_protocol、$ssl_cipher、$status 和 $http_user_agent
- 重点筛查 error_log 中高频出现的错误：SSL routines::sslv3 alert bad certificate、no suitable signature algorithm，尤其集中在同一 IP 或特定 UA（如 “mitmproxy”、“Evilginx”）
- access_log 中若发现大量 400 错误，且请求路径覆盖多个子域登录页（/login、/sso、/auth），但无 CSS/JS 请求，高度提示自动化中间代理在试探
快速验证与临时绕过（仅用于诊断）
注意：这不是修复，而是定位手段：
- 换设备/网络（如手机开热点）访问同一域名，若告警消失，说明原网络存在 TLS 中间设备
- 在 Chrome 地址栏输入 chrome://net-internals/#hsts → Delete domain 清除该域名 HSTS 缓存，再用 HTTP 访问（需服务端未禁用 HTTP）。若跳转 HTTPS 后不再报错，说明原问题是证书在 HSTS 强制下暴露了信任链缺陷
- 使用 OpenSSL 手动测试证书链：openssl s_client -connect your-domain.com:443 -servername your-domain.com，观察 Verify return code 是否为 0；非 0 值需结合 depth=N 信息排查中间 CA 是否缺失或过期
