HSTS仅在标准HTTPS端口443生效，非标端口（如8443）下浏览器直接忽略该头；应通过Nginx反代至443端口、子域名+SNI或内网替代方案解决。
HSTS 本身不支持非标准 HTTPS 端口（如 8443、8081、9443 等）——浏览器只在访问 标准端口 443 的 HTTPS 站点时，才会接收、解析并缓存 Strict-Transport-Security 响应头。若你的 Nginx 监听的是非标准 HTTPS 端口，即使配置了 HSTS 头，浏览器也会直接忽略，策略完全不生效。
为什么非标准端口下 HSTS 不起作用
这是浏览器的硬性限制，不是 Nginx 配置问题：
- 所有主流浏览器（Chrome、Firefox、Safari）仅对
https://example.com（即隐式端口 443）或显式写为https://example.com:443的请求处理 HSTS 头 - 对于
https://example.com:8443这类地址，浏览器视其为“独立协议端点”，不会将 HSTS 策略与主域名关联，也不会跨端口共享缓存 - 即使你在
listen 8443 ssl的 server 块中正确写了add_header ... always，响应头确实存在，但浏览器根本不读取它
可行的应对方案
没有“让非标端口 HSTS 生效”的绕过方式，只能通过架构调整适配浏览器规则：
-
方案一：前端统一走 443 端口，后端用非标端口代理
这是最合规的做法。Nginx 监听443 ssl，对外提供标准 HTTPS；后端服务（如 Spring Boot、Node.js）运行在:8080或:3000等非标端口，由 Nginx 反向代理。此时 HSTS 可正常配置在 443 server 块中，完全生效 -
方案二：使用 443 端口 + SNI 或多域名区分服务
若需共存多个内部系统，可为每个系统分配子域名（如sys-a.example.com、sys-b.example.com），全部走 443 端口，用 SNI 和 server_name 匹配路由。HSTS 可按需在各 server 块中独立启用 -
方案三：放弃 HSTS，强化其他防护（仅限可信内网）
若确无法改端口（如金融专网强制用 8443），且用户环境可控（如统一终端、内部浏览器策略），可：
– 强制客户端配置 HTTP→HTTPS 重写规则
– 后端启用Upgrade-Insecure-Requests+Content-Security-Policy: upgrade-insecure-requests
– 日志监控 HTTP 请求并告警
⚠️ 注意：这无法防御首次访问劫持，安全等级显著低于 HSTS
特别注意：preload 和 includeSubDomains 在非标端口下毫无意义
提交到浏览器预加载列表（hstspreload.org）有严格校验：
- 必须响应在
https://domain.com（即 443 端口） - 必须返回完整策略：
max-age≥31536000; includeSubDomains; preload - 所有子域也必须在 443 上可 HTTPS 访问并返回同等 HSTS 头
- 非标端口响应即使含
preload参数，也会被预加载检查器直接拒绝
不复杂但容易忽略的是：HSTS 的设计初衷就是绑定「域名 + 标准 HTTPS 端口」这个组合。想让它工作，就得让流量先符合这个前提——端口不是配置项，而是信任锚点。
