记录一下那天晚上的排查过程。在 CDN 开了强制 HTTPS，源站又配了一条 http 跳 https 的规则没判断转发头，结果 https 请求到源站被当成 http 再跳一次，浏览器报重定向次数过多，蜘蛛直接放弃。
刚开始盯着「CDN 的强制 HTTPS 与源站规则叠加，形成闭环」，折腾了半个多小时，排掉了。
排查方向其实有限，先把可能性排一排。CDN 终止 TLS 后回源用 http，源站按 http 再跳 https。另一种情况是跳转规则没有读 X-Forwarded-Proto，无法识别真实协议。
还有一种情况，301 被缓存后，连修正配置都要等缓存过期。
数一下跳转次数
curl -sIL -o /dev/null -w "%{num_redirects} %{url_effective}\n" http://www.example.com/接着看请求带没带转发头
curl -sI https://www.example.com/ | grep -i 'x-forwarded-proto'源站按转发头判断
if ($http_x_forwarded_proto = 'http') { return 301 https://$host$request_uri; }末了清掉 CDN 的 301 缓存
curl -X PURGE https://www.example.com/报错是间歇性的，我蹲守了半小时才抓到一次完整现场。
改完先别撤，确认这几项。跳转次数回到 1 次，最终落地 200，CDN 边缘的 301 缓存清空后循环消失。
容易忽略的是，强制 HTTPS 只在一层做，两层各做一次又没有转发头，就一定循环，改完记得清 301 缓存。拖得越久，排查成本越高，因为现场状态会被后续操作覆盖。