排查hsts与http/3混用安全头漏配，需确保strict-transport-security头在启用quic的server块中显式配置、alt-svc指向443 tls端口、tls仅启用1.3并验证alpn h3握手成功，且add_header置于server顶层避免覆盖。
排查 HSTS 与 HTTP/3（QUIC）混用时的安全头漏配，核心在于：HSTS 只在 HTTPS 响应中生效，而 HTTP/3 本身不改变响应头逻辑，但 QUIC 的 UDP 特性、连接复用机制和部分客户端行为会放大配置疏漏——比如 HSTS 头未随 HTTP/3 响应一并发出、Alt-Svc 头缺失或冲突、TLS 版本不匹配导致 HSTS 不被识别等。
确认 HSTS 是否实际下发到 HTTP/3 连接
HSTS 不是协议层能力，而是由 Nginx 在每个 HTTPS 响应中通过 Strict-Transport-Security 响应头显式传递的。HTTP/3 并不自动继承或补全该头，必须确保它出现在所有支持 HTTP/3 的 server 块中。
- 执行
curl -I -v https://example.com --http3（需 curl 8.0+ 且编译支持 HTTP/3），检查响应头是否含Strict-Transport-Security - 对比
--http1.1和--http3两种模式下的响应头输出，若仅前者有 HSTS，说明配置只写在了非 QUIC 的 server 块里，或被 location 级别的 add_header 覆盖/遗漏 - Nginx 中 HSTS 必须写在启用
quic的server块内，不能只放在纯 TCP 的 443 server 块中
检查 Alt-Svc 与 HSTS 的语义协同
Alt-Svc 是告知客户端“可用 HTTP/3”的关键头，但它与 HSTS 共存时存在隐含依赖：浏览器只有在已信任该域名（例如通过 HSTS 或预加载）的前提下，才会主动尝试 Alt-Svc 提供的 HTTP/3 端点；反之，若 HSTS 缺失，客户端可能降级走 HTTP/1.1，绕过 QUIC 安全加固路径。
- 确认
add_header Alt-Svc 'h3=":443"; ma=86400';已配置，且值中端口与listen 443 quic一致 - 避免
Alt-Svc指向非 TLS 端口（如h3=":8080"），否则违反 HSTS 策略，现代浏览器直接忽略 - 若站点已提交至 hstspreload.org，Alt-Svc 必须严格绑定到同一域名+443 TLS 端口，否则预加载策略可能拒绝协商 HTTP/3
验证 TLS 协议与密钥交换是否满足 HSTS+HTTP/3 联动要求
HTTP/3 强制要求 TLS 1.3，而 HSTS 的长期有效性依赖于 TLS 握手成功且可信。若 TLS 配置松散（如仍允许 TLS 1.2 或弱密钥交换），部分客户端在 HTTP/3 协商阶段失败后回落，可能导致 HSTS 头未被接收或缓存。
- 检查
ssl_protocols TLSv1.3;—— 必须独占配置，禁用 TLS 1.2 及以下 - 确认
ssl_ciphers仅包含 TLS 1.3 密码套件（如ECDHE-ECDSA-AES128-GCM-SHA256），避免混合旧套件引发协商歧义 - 运行
openssl s_client -connect example.com:443 -alpn h3 -tls1_3，验证能否完成 TLS 1.3 + ALPN h3 握手；若失败，HSTS 将无法随 HTTP/3 响应送达
排查 Nginx 配置层级与覆盖陷阱
HSTS 和 Alt-Svc 都依赖 add_header，但在 HTTP/3 场景下易因配置作用域错误而漏发。尤其注意：Nginx 的 add_header 默认不继承，且 location 块中的定义会覆盖 server 级设置。
- 确保 HSTS 和 Alt-Svc 都写在
server块顶层，而非嵌套在location /或其他子块中 - 若使用
always参数（如add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;），可避免 304 响应丢失该头——这对 HTTP/3 的缓存协商尤为重要 - 禁止在同一个 server 块中重复
add_header同一头字段（如两次写 HSTS），Nginx 会静默覆盖，仅保留最后一条
