HSTS本身不导致重定向循环，但会与服务端错误的HTTP→HTTPS重定向配置叠加，造成浏览器未发请求即强制跳转或反复跳转；需先通过chrome://net-internals/#hsts确认HSTS是否生效，再检查Nginx、CDN或反向代理是否存在多层重定向冲突。
HSTS 本身不会导致重定向循环，但它会和错误的 HTTP→HTTPS 重定向配置叠加，让浏览器在“没发请求”和“反复跳转”之间来回卡死——表面看是“打不开”，实际是两种机制在打架。排查关键在于先剥离 HSTS 干扰，再定位真循环点。
先确认是不是 HSTS 在作祟，而不是重定向本身
浏览器一旦记住 HSTS 策略，对同一域名的所有 HTTP 请求根本不会发出，直接 307 内部跳 HTTPS；此时你看到的“打不开”，其实是空连接或 ERR_CONNECTION_CLOSED，Nginx 日志里连一条访问记录都没有。
- 打开 Chrome 地址栏，输入
chrome://net-internals/#hsts - 在 “Query domain” 中输入你的域名（如
test.example.com），点击 Query - 若显示 Found，且
max-age > 0，说明 HSTS 已生效，当前问题大概率被它锁死；若显示 Not found，那重定向循环才是主因，继续往下查
检查 Nginx 是否同时存在两层强制 HTTPS 机制
常见陷阱：既在 80 端口用 return 301 做跳转，又在 443 端口配了 add_header Strict-Transport-Security，而中间还夹着 CDN 或反向代理，导致协议判断错乱。
- 运行命令：
curl -I http://test.example.com- 如果返回
301 Moved Permanently+Location: https://...，说明 80 端口跳转在工作
- 如果返回
- 再运行：
curl -I https://test.example.com- 如果响应头里有
Strict-Transport-Security: max-age=31536000; includeSubDomains，说明 HSTS 也在发 - 更危险的是：如果这个 HTTPS 响应本身又触发了二次跳转（比如后端返回 302 到另一个 HTTPS 地址，或 CDN 回源时协议不一致），就构成真实循环
- 如果响应头里有
重点盯防 CDN 和反代场景下的隐性循环
很多“重定向过多”不是 Nginx 配的，而是链路中某一层偷偷改了协议或 host。
- 如果用了 CDN（如 Cloudflare、阿里云全站加速）：
- 检查 CDN 控制台是否开启了“强制 HTTPS”
- 查看 CDN 的回源协议设置：必须设为 HTTPS，不能是 HTTP，否则 Nginx 收到的是 HTTPS 请求，但转发给后端却是 HTTP，后端可能又跳一次 HTTPS，形成闭环
- 如果用了反向代理（如 Nginx 代理另一台 Nginx 或 Node.js）：
- 确保 proxy_pass 指向
https://backend（若后端支持 HTTPS），或至少在 header 中透传协议信息：proxy_set_header X-Forwarded-Proto $scheme; proxy_set_header X-Forwarded-Host $host;
- 后端应用需识别
X-Forwarded-Proto，避免自己再做一次 HTTP→HTTPS 跳转
- 确保 proxy_pass 指向
快速验证与临时破局方法
不用等配置全改完，先用这几个动作锁定问题范围：
- 用无痕窗口访问
http://test.example.com：无痕模式不带 HSTS 缓存，如果能打开，说明 HSTS 是主因 - 用 curl 加
-v参数观察完整跳转链：curl -v http://test.example.com
看输出里是否出现连续多个
Location:行（比如https://...→https://.../login→https://.../auth）
小红书长文-谷歌浏览器下载在 Linux 上通过 Chrome 挂载/VNC 自动发布小红书长笔记。Agent 撰写标题和正文后执行 xhs_publish.sh --publish --submit，触发小红书发布。
- 临时停掉 HSTS 头：把
add_header Strict-Transport-Security ...注释掉，nginx -s reload，再测 HTTP 是否仍跳转——如果还跳，说明循环来自别处
不复杂但容易忽略
