HSTS本身不影响健康检查，异常主因是服务端强制跳转或响应头干扰；应排除HTTP跳转、清空HSTS头或用独立子域隔离健康检查。
这个问题核心在于：HSTS 是浏览器端策略，而健康检查（如 Nginx upstream check、Prometheus 黑盒探针、Zabbix HTTP 检测等）通常不走浏览器，所以 HSTS 本身不会直接影响健康检查。真正导致异常的，往往是 HSTS 配置背后连带的 服务端强制跳转逻辑 或 响应头干扰，被健康检查客户端误判为失败。
先确认是不是真被 HSTS 影响了
健康检查工具绝大多数不解析或遵守 HSTS 策略（curl、wget、Ingress 自带 check、Prometheus blackbox_exporter 默认配置均如此）。若出现异常，优先排查以下更常见原因：
- 健康检查发起的是
http://请求，但 Nginx 配置了return 301 https://$host$request_uri;—— 它会返回 301，而多数健康检查默认不跟随重定向，直接判定为失败 - 健康检查目标是 HTTPS 地址，但服务端响应头中仍含
Strict-Transport-Security，部分严格模式的探针（如某些 ESA 规则、自定义脚本）可能将该头视为“不期望响应”，触发告警 - 后端服务本身返回非 2xx 状态码（如 302、401、503），健康检查未配置
proxy_next_upstream或check_http_expect_alive，直接标记为不健康
检查 Nginx 是否对健康检查路径做了不当跳转
很多团队在 server 块统一加了 HTTP → HTTPS 跳转，却忘了健康检查接口（如 /healthz、/ping）也命中了该规则：
- 用 curl 模拟健康检查请求：
curl -I http://your-domain.com/healthz，观察是否返回 301/302 - 若返回跳转，检查 Nginx 配置中是否有类似这样的全局跳转： server { listen 80; return 301 https://$host$request_uri; }
- 正确做法是，在跳转逻辑前，用 location 精确排除健康检查路径：
location = /healthz { proxy_pass http://backend; }
location = /ping { proxy_pass http://backend; }
location / { return 301 https://$host$request_uri; }
验证健康检查是否因 HSTS 响应头被拦截（极少数情况）
虽然罕见，但部分企业级监控平台或自研探针会解析响应头并做策略校验。若你怀疑是 Strict-Transport-Security 头导致误报：
- 执行
curl -I https://your-domain.com/healthz，查看响应头是否包含Strict-Transport-Security - 若存在且不希望健康检查收到它，可在对应 location 中清空该头：
location /healthz {
proxy_pass http://backend;
add_header Strict-Transport-Security "" always;
} - Kubernetes Ingress 用户可用注解：
nginx.ingress.kubernetes.io/configuration-snippet: |
add_header Strict-Transport-Security "" always;
推荐的健康检查隔离方案
HSTS 作用域基于域名，与路径无关。最稳妥、可维护性最强的方式是彻底分离流量：
- 为健康检查分配独立子域，如
probe.example.com或health.example.com - 该子域的 Nginx server 块中：
– 不配置add_header Strict-Transport-Security
– 不启用 SSL 证书（或仅配 HTTP 监听）
– 不设置任何 301 跳转 - 监控系统直接轮询该子域，完全规避 HSTS 及其衍生问题
