解决由于前端启用 HSTS 导致的老旧 HTTP 监控接口无法正常访问的业务隔离重构-Nginx-PHP中文网

hsts问题本质是服务端下发策略被浏览器缓存，导致http请求未发出即被拦截；验证需查chrome://net-internals及curl测试；最优解为监控接口域名隔离，次选服务端路径级豁免或客户端适配。

解决由于前端启用 hsts 导致的老旧 http 监控接口无法正常访问的业务隔离重构

这个问题核心不是“前端启用HSTS”，而是HSTS策略已由服务端（如Nginx、ESA、Ingress或IIS）下发并被浏览器持久化记录，导致所有对该域名的HTTP请求（包括监控探针、脚本curl、旧版健康检查接口）被浏览器或客户端主动拦截——它根本没发出去，自然无法到达后端服务。

确认是否真由HSTS引发

老旧监控接口若通过浏览器访问才报错（如“您目前无法访问，因为此网站使用了 HSTS”），而用curl -I http://xxx 或Postman直连HTTP仍能通，则说明问题出在浏览器端HSTS缓存；若curl也失败（返回空响应、连接重置或直接跳转失败），需排查服务端是否配置了强制HTTP→HTTPS重定向，而非HSTS本身。

快速验证步骤：

在Chrome中访问 chrome://net-internals/#hsts → “Query domain”输入监控域名 → 若显示Found，即已生效
用 curl -I http://monitor.example.com 观察是否301跳转到HTTPS；若有，说明服务端重定向仍在运行
用 curl -I https://monitor.example.com 查看响应头是否含 Strict-Transport-Security

业务隔离：为监控接口分配独立域名或路径

HSTS作用域基于域名（+ includeSubDomains），不按路径区分。因此最稳妥的解法是让监控接口脱离主站域名体系：

Jan

Jan是一款AI大模型工具，本地运行大模型并进行AI对话的工具，免费开源。

下载

新增专用子域，如 health.example.com 或 probe.example.com，该域名不启用HSTS，也不配置HTTPS重定向
Nginx中为该子域单独配置server块，禁用add_header Strict-Transport-Security，并关闭return 301 https://…
若受限于DNS或运维规范，可改用路径前缀（如 /api/health），但需配合反向代理做路由剥离，并确保该路径不被HSTS策略覆盖（注意：HSTS不识别路径，仅靠域名隔离）

服务端精准关闭HSTS（非全局停用）

不必停掉整个站点的HSTS，只需对监控相关入口点“豁免”：

Nginx中，针对监控location块，用 add_header Strict-Transport-Security "" always; 清空该路径的HSTS头
Kubernetes Ingress中，若使用Nginx Ingress Controller，可通过注解 nginx.ingress.kubernetes.io/configuration-snippet 注入 header清除逻辑
ESA边缘平台可在“规则引擎”中设置条件策略：当请求路径匹配 /healthz 或 /ping 时，不插入HSTS头

客户端侧兼容处理（临时兜底）

对无法立即改造的第三方监控系统（如Zabbix、Prometheus黑盒探针），可做如下适配：

将HTTP探针目标改为HTTPS，并配置跳过证书校验（如curl -k）——仅限内网可信环境
若探针支持自定义User-Agent，可添加特殊标识，在Nginx中识别后返回200 + 空内容，绕过HSTS逻辑（因HSTS只影响浏览器，不影响curl等工具行为）
对必须走HTTP的老系统，部署轻量级反向代理（如Caddy），监听HTTP端口，转发至HTTPS后端，自身不发HSTS头

重构重点不在“怎么关HSTS”，而在“让监控流量不进HSTS作用域”。域名隔离是最干净、可审计、易回滚的方式；服务端路径级豁免适合灰度过渡；客户端适配仅作短期缓冲。三者可组合使用，但避免依赖浏览器手动清理HSTS记录——它不可控、不一致、无法批量管理。