Nginx怎么排查HSTS配置导致后端健康检查(Health Check)发起的HTTP请求异常-Nginx-PHP中文网

hsts本身不影响健康检查，异常主因是服务端强制跳转或响应头干扰；应排除http跳转、清空hsts头或用独立子域隔离健康检查。

nginx怎么排查hsts配置导致后端健康检查(health check)发起的http请求异常

这个问题核心在于：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）也命中了该规则：

Nginx Config Linter

对 Nginx 配置文件进行语法检查、验证和安全、性能审计。

下载

用 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;