HSTS 是强化 HTTPS 安全的机制，需部署在 443 端口 HTTPS server 块中，关键参数含 max-age=31536000、includeSubDomains 和 always；必须先完成 HTTP→HTTPS 301 跳转及全站 HTTPS 可用，preload 需谨慎评估并满足严格前提。
Strict-Transport-Security（HSTS）不是“开启 HTTPS 传输”的开关，而是让浏览器记住：这个域名以后只允许走 HTTPS，连 HTTP 请求都不发——它解决的是首次访问时被劫持的风险，必须配合已部署的 HTTPS 才能生效。
必须放在 443 端口的 HTTPS server 块里
HSTS 头只在 HTTPS 响应中被浏览器识别。如果写在 80 端口的 HTTP server 块里，或放在 http {} 全局块中，浏览器直接忽略。
- 正确位置示例：
server { listen 443 ssl; ... }内部 - 错误做法：在
server { listen 80; }里加 HSTS，完全无效 - 避免和后端应用（如 Spring Boot、Node.js）重复返回 HSTS，否则可能冲突；建议在 Nginx 层统一控制，后端禁用该头
关键参数不能少：max-age、includeSubDomains、always
基础策略要明确时效、作用范围，并确保所有响应都携带。
- max-age=31536000：推荐设为 1 年（31536000 秒），时间越长，浏览器强制 HTTPS 的周期越久
- includeSubDomains：启用后，所有子域名（如 api.example.com、blog.example.com）也必须支持 HTTPS，否则会访问失败
- always 参数必须加上：保证 404、500、304 等非 2xx 响应也带 HSTS 头，防止策略中断
preload 不是可选项，上线前要谨慎评估
加上 preload 意味着申请加入浏览器内置的 HSTS 预加载列表，一旦收录，即使用户从未访问过你的网站，浏览器也会强制走 HTTPS。
- 前提条件严格：全站 HTTPS、所有子域可用 HTTPS、max-age ≥ 1 年、必须含 includeSubDomains
- 不可逆：提交到预加载列表后，撤回需数月，且部分浏览器仍长期保留
- 建议流程：先上线不含 preload 的版本 → 观察 1–2 周无异常 → 再添加 preload 并提交至 hstspreload.org
必须前置完成：HTTP → HTTPS 301 跳转 + 全站 HTTPS 可用
HSTS 是“加固”，不是“替代”。没有可靠的 HTTPS 基础，HSTS 只会让用户彻底无法访问。
- 80 端口 server 块中必须配置 301 跳转：
return 301 https://$host$request_uri; - 确保所有资源（CSS/JS/图片/接口）都通过 HTTPS 加载，避免混合内容警告
- 检查证书有效性、域名匹配、TLS 协议版本（建议禁用 TLS 1.0/1.1，仅启用 1.2+）
