nginx配置hsts本身不兼容旧版浏览器，因ie6–11等根本不识别strict-transport-security头，既不解析也不执行；真正风险在于hsts启用后暴露的http监控失效、ie缓存异常及混合内容问题，需通过域名隔离、路径豁免和缓存头组合策略分层应对。
Nginx 配置 HSTS 本身不涉及旧版浏览器兼容性问题，因为 HSTS 是现代浏览器（Chrome、Firefox、Safari、Edge 等）原生支持的安全机制，IE 6–11、老旧 Android WebView 或极早期移动浏览器根本不识别 Strict-Transport-Security 响应头——它们既不会解析，也不会执行强制 HTTPS 重写。
所以，所谓“旧版本浏览器对 HSTS 头的兼容表现”，实际是不存在兼容问题，而是完全不生效。重点不是“如何让旧浏览器支持 HSTS”，而是：
✅ HSTS 对旧浏览器无影响（它们照常走 HTTP 或按原有逻辑处理）；
⚠️ 真正需要关注的，是旧浏览器在启用 HSTS 后可能暴露的其他兼容风险，比如缓存、跳转、证书或混合内容行为。
HSTS 不影响旧浏览器，但间接暴露三类典型风险
旧浏览器虽无视 HSTS 头，却仍受同一套 HTTPS 基础设施约束。HSTS 上线后若未同步适配，容易触发以下问题：
-
HTTP 监控/健康检查接口失效
很多运维脚本（如 Zabbix、curl 脚本、Shell 健康探针）仍用http://请求/healthz或/ping。
→ 若服务端同时配置了 80 端口 301 跳转 + 全站 HTTPS，这些请求会 301 到 HTTPS；而旧客户端（如 curl 7.29 或某些嵌入式 HTTP 库）可能不自动跟随跳转，或无法校验证书，导致检测失败。
✅ 解法：为监控路径单独豁免跳转，例如：location = /healthz { add_header Strict-Transport-Security "" always; return 200 "OK"; add_header Content-Type text/plain; } -
IE6–IE8 缓存策略与 HTTPS 冲突
这些浏览器不支持Cache-Control: max-age，但能读Expires；又因 HTTPS 下默认禁用缓存，若静态资源（JS/CSS）没显式加Cache-Control: public或max-age=0，会导致反复加载、白屏或 404。
✅ 解法：对静态资源显式控制缓存，避免依赖 HSTS 带来的 HTTPS 环境“默认行为”：location ~* \.(js|css|png|gif|jpg)$ { expires 1h; add_header Cache-Control "public, max-age=3600" always; # 注意：不要只设 expires，IE6–8 需 Cache-Control 显式兜底 } HSTS 启用后暴露混合内容（Mixed Content）问题
旧浏览器（尤其 IE）对混合内容拦截更宽松，可能默默加载 HTTP 资源；而现代浏览器开启 HSTS 后，会严格阻止所有非 HTTPS 资源（如<img src="http://...?x-oss-process=image/resize,p_40">），导致页面功能异常。
→ 表面看是旧浏览器“兼容好”，实则是安全隐患被掩盖。
✅ 解法：全站扫描并替换所有http://资源引用为协议相对（//xxx）或绝对 HTTPS 地址，不依赖浏览器容错。
关键提醒：别试图“让旧浏览器支持 HSTS”
- HSTS 是 HTTP 响应头，由浏览器主动实现策略，服务端无法“降级适配”；
- 没有 polyfill、没有 JS 模拟、没有 Nginx 指令可绕过浏览器能力限制；
- 所有“兼容旧浏览器”的动作，本质都是规避 HSTS 引发的连带影响，而非增强其对 HSTS 的理解。
真正要做的，是分层治理：
? 对用户浏览器：靠 HSTS 保护现代终端；
? 对运维工具/旧客户端：用域名隔离（如 probe.example.com 不启 HSTS）、路径豁免或协议白名单；
? 对静态资源：用 expires + add_header Cache-Control 组合覆盖新旧缓存逻辑。
不复杂但容易忽略。
