nginx反向代理需显式配置proxy_pass_header strict-transport-security以透传hsts头，且仅在https server块中启用，避免http下发送或重复添加。
在 Nginx 反向代理中，HSTS（HTTP Strict Transport Security）头默认不会被后端应用自动透传，尤其当使用 proxy_pass 时，Nginx 默认会清除或忽略部分响应头（包括 Strict-Transport-Security），除非显式配置允许。要让 HSTS 正确生效，关键不是“添加”头，而是确保它不被丢弃、不被覆盖，并且只在 HTTPS 上发送。
确认后端是否已返回 HSTS 头
先检查上游服务（如 Node.js、Django、Spring Boot 等）是否已在响应中设置了 Strict-Transport-Security。可用 curl 验证：
若响应中已有该头（例如 Strict-Transport-Security: max-age=31536000; includeSubDomains; preload），说明后端已配置；否则应优先在后端设置，Nginx 仅作透传或兜底。
启用 proxy\_pass 对 HSTS 头的透传
Nginx 默认会过滤掉某些“危险”响应头，HSTS 正是其中之一。需用 proxy_pass_header 显式放行：
- 在
location或server块中添加：
proxy_pass_header Strict-Transport-Security; - 注意：该指令必须写在
proxy_pass之后才生效（顺序敏感） - 若使用了
proxy_hide_header，务必确保未将其列入隐藏列表（例如不要写proxy_hide_header Strict-Transport-Security）
避免重复添加或错误覆盖
如果既让后端发 HSTS，又在 Nginx 中用 add_header 强制加，可能导致多个 HSTS 头（违反规范），或因缓存/条件逻辑导致非 HTTPS 下误发（浏览器将拒绝接受）。安全做法是：
- 只在
https的 server 块中用add_header设置 HSTS（利用 Nginx 的上下文隔离） - 若依赖后端透传，就不要在 Nginx 中重复
add_header - 推荐统一策略：后端负责生成 HSTS 值，Nginx 负责透传 + 保证仅 HTTPS 下可见
HTTPS 上下文与安全边界
HSTS 必须仅通过 HTTPS 响应发送，明文 HTTP 响应中包含该头会被浏览器直接忽略。因此：
- 确保你的
server { listen 443 ssl; ... }块中启用了 HSTS 透传或添加 - HTTP server 块（
listen 80）中绝对不要add_header Strict-Transport-Security，也不应尝试透传（后端本就不该在 HTTP 下返回它） - 可配合
ssl_trusted_certificate和 HSTS preload list 提交要求，但那是后续步骤
