HSTS本身不触发重定向，而是在HTTPS响应中通过Strict-Transport-Security头被浏览器接收并持久化，弱网下只要一次成功HTTPS访问即可生效；真正受弱网影响的是HTTP→HTTPS的初始跳转链路及CDN缓存行为。
直接测试 HSTS 在弱网、丢包环境下的表现，不能靠“模拟重定向”或“只看响应头”，因为 HSTS 本身不触发重定向，它是在 HTTPS 响应中生效的安全策略；真正受影响的是 HTTP→HTTPS 的跳转过程，以及 CDN 或浏览器对跳转响应的缓存行为。关键要分清两个层次：HSTS 策略是否被正确接收并持久化（浏览器端），以及跳转链路（HTTP→HTTPS）在弱网下是否可靠完成。
先确认 HSTS 是否已生效且不依赖跳转
HSTS 不靠重定向生效——它由服务器在每次 HTTPS 响应中通过 Strict-Transport-Security 响应头下发，浏览器收到后即强制后续请求走 HTTPS，不再发起 HTTP 请求。因此：
- 弱网下只要有一次成功 HTTPS 访问（哪怕耗时长、有重传），HSTS 就可能写入浏览器策略库
- 用
curl -I https://example.com验证响应头是否存在且值正确，这是基础前提 - 在 Chrome 中访问
chrome://net-internals/#hsts，手动查询域名，确认 includeSubDomains 和 max-age 已加载，且状态为 “loaded” - 禁用网络后再次访问
http://example.com，观察是否自动跳转到https://—— 若跳转发生，说明 HSTS 已本地生效，不依赖实时网络判断
专门压测 HTTP→HTTPS 跳转在弱网下的稳定性
这才是弱网场景的真实瓶颈点：用户首次访问 http:// 时，Nginx 返回 301 跳转，客户端需完成两次请求（HTTP→HTTPS）。丢包会显著放大失败率：
- 用
tc（Traffic Control）在测试机注入弱网条件，例如：tc qdisc add dev eth0 root netem loss 5% delay 200ms - 用
wrk或自定义脚本批量发起http://请求，统计 301 响应成功率、平均延迟、超时比例 - 重点检查：第二次请求（HTTPS）是否因 TLS 握手重传失败而卡住；可配合
tcpdump抓包分析 FIN/RST 出现频率 - 避免 Nginx 在 443 server 块内再做一次 301（如
return 301 https://$host$request_uri），这会造成 A→B→A 循环或 CDN 缓存键错乱
验证 CDN 缓存对跳转响应的影响
CDN 会缓存 301 响应，默认 TTL 可能长达 1 小时以上。弱网下若用户拿到的是过期/错误的跳转地址（比如含内部端口 :8080），就无法恢复：
- 在 Nginx 的跳转配置中显式控制缓存：
add_header Cache-Control "public, max-age=300";（301 用 5 分钟，便于快速回滚） - 确保 CDN 控制台关闭对
Location头的自动改写，并启用“透传源站响应头” - 用不同 IP（或清除 CDN 缓存后）发起请求，对比
curl -v http://example.com返回的Location是否始终为https://example.com/...，不含端口、协议错误或 $host 解析异常 - 禁用 HSTS 后（
max-age=0）再测试跳转，排除浏览器策略干扰，专注链路本身
检查真实 IP 和代理头是否在跳转中保持一致
弱网常伴随连接中断重试，Nginx 若未正确传递 X-Forwarded-Proto 和 X-Real-IP，后端生成的跳转 URL 可能降级为 http://，形成死循环：
- 在 HTTP server 块中确保：
proxy_set_header X-Forwarded-Proto $scheme;<br>proxy_set_header X-Real-IP $remote_addr;
- 在 HTTPS server 块中加：
absolute_redirect off;<br>server_name_in_redirect off;
（防止 Nginx 自动拼接错误 host） - 用
curl -H "X-Forwarded-Proto: https" -I http://example.com模拟 CDN 回源请求，验证返回的Location是否仍为 HTTPS
