HSTS本身无性能开销，仅依赖健壮的HTTPS基础设施；需配置always参数、静态响应头、TLS 1.3、OCSP Stapling、会话复用及连接资源调优，并谨慎使用preload以防子域中断。
HSTS（HTTP Strict Transport Security）本身不参与连接建立或请求处理，它只是一个响应头，对高并发无直接性能开销。真正影响平稳运行的是它所依赖的 HTTPS 基础设施是否健壮——只要 TLS 层和 Nginx 连接处理稳了，HSTS 就自然稳。
确保 HSTS 头不成为瓶颈
HSTS 通过 Strict-Transport-Security 响应头下发，Nginx 配置通常为：
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;
关键点在于：
-
用
always参数：避免只在 2xx 响应中添加，防止重定向链路中漏发（如 301→302→200 场景）； - 不依赖 Lua 或变量动态生成：静态字符串写死，零计算开销；
-
避免在 if 块中设置：Nginx 的
if在 location 中有隐式限制，可能被跳过或重复执行，导致策略不一致。
HTTPS 底层稳，HSTS 才真稳
HSTS 生效前提是请求已走 HTTPS，而高并发下 HTTPS 的稳定性取决于三件事：
-
TLS 握手不拖慢：启用 TLS 1.3（
ssl_protocols TLSv1.3;），关闭老旧协议；开启 OCSP Stapling（ssl_stapling on;）避免客户端直连 CA 查验证书； -
会话复用率高：配置
ssl_session_cache shared:SSL:10m;和ssl_session_timeout 10m;，让 90%+ 的连接跳过完整握手； -
连接资源不耗尽：系统级
fs.file-max、用户级nofile、Nginx 的worker_rlimit_nofile和worker_connections必须协同调优，否则连接都建不起来，HSTS 根本没机会发出去。
避免 HSTS 预加载引发的意外中断
若已提交到浏览器 HSTS Preload List（含 preload 参数），则所有子域强制走 HTTPS，且无法临时降级。高流量下需特别注意：
-
确保所有子域 HTTPS 可用：包括
www、api、static等，任一不可用将导致整个子域访问失败； -
灰度发布时绕开 preload 影响：新子域上线前先不加
preload，观察一周 HTTPS 稳定性后再申请加入列表； - 不要靠清除浏览器缓存“回退”：HSTS 预加载是硬编码在浏览器中的，一旦收录，本地清除无效，只能等官方移除（极难）。
监控与兜底建议
HSTS 本身不可监控状态，但可间接验证其生效与风险：
-
用 curl 检查响应头：
curl -I https://example.com | grep Strict，确认每次响应都稳定携带； -
日志中采样分析 HTTPS 协议版本：在
log_format加入$ssl_protocol，确认 TLS 1.3 占比是否 ≥ 85%； -
对关键子域做独立健康检查：比如
health.example.com和api.example.com分别探测 443 端口 + 有效证书 + HSTS 头，避免单点故障扩散。
