很多网站接入CDN后，访问时浏览器突然报错 NET::ERR_TOO_MANY_REDIRECTS，提示重定向次数过多，页面完全无法打开。这个错误在Chrome、Edge等浏览器中十分常见，尤其在启用HTTPS或做了强制跳转的站点上更容易出现。问题表面上看起来像是服务器配置错误，但如果站点接入了CDN，根源往往藏在CDN回源与源站协议之间的配合上。下面就把这个问题的形成原因、排查方法和解决方案彻底梳理清楚。
重定向循环是怎么形成的
HTTP重定向是服务器告诉浏览器“资源换了位置，请重新请求另一个URL”的机制，状态码通常为301、302、307等。正常情况下，重定向链条是有限的，浏览器跟随几次后就能到达最终内容。但如果服务器A把请求重定向到服务器B，而服务器B又把请求重定向回服务器A，或者多个节点之间形成闭环，浏览器就会在同一个请求上无限跳转，直到达到内部上限（通常为20次）后报出 ERR_TOO_MANY_REDIRECTS。
在CDN接入的场景下，用户请求首先到达CDN边缘节点，CDN再向源站发起回源请求。如果源站配置了“所有HTTP请求必须跳转到HTTPS”，而CDN回源时使用的却是HTTP协议，源站就会返回301重定向到HTTPS地址。CDN收到这个重定向后，可能并不会直接跟随，而是把它当作正常响应缓存下来；或者CDN按照自己配置的回源协议再次发起请求，结果又触发源站跳转，如此反复。更常见的是CDN节点和源站之间协议不一致，导致两边的重定向逻辑互相打架。
另一个容易忽略的点是：有些源站会根据请求的 Host 头或者端口号来决定是否重定向。CDN回源时往往使用IP地址或者自定义的Host头，源站识别不出这是来自CDN的请求，误以为用户直接访问了HTTP版本，于是强制跳转到HTTPS。而CDN把HTTPS请求回源时又降级为HTTP，源头又跳，循环就出现了。
CDN环境下的常见触发场景
场景一：源站强制HTTPS跳转，但CDN回源协议为HTTP。这是最常见的原因。WordPress、Nginx、Apache等平台经常配置了全局强制HTTPS规则，例如在Nginx中写一条 return 301 https://$host$request_uri;。如果CDN控制台里回源协议选择了“HTTP”，那么回源请求永远是HTTP，源站永远返回301到HTTPS，CDN继续用HTTP回源，死循环就产生了。
场景二：回源Host配置与源站虚拟主机不匹配。很多源站服务器上配置了多个站点，根据Host头区分服务。如果CDN回源时携带的Host头不是源站虚拟主机配置的域名，源站可能会返回一个默认的重定向（例如跳转到www版本或主域名），而CDN拿到重定向后又用同样的Host回源，结果跳转目标再次触发重定向。
场景三：负载均衡或反向代理层的健康检查干扰。当源站前面还有一层Nginx或HAProxy做负载均衡时，健康检查请求可能被重定向到HTTPS，但健康检查通常使用HTTP且不会跟随跳转。如果上游健康检查被配置为跟随重定向并且目标又是CDN节点，就可能把CDN节点拉入循环。不过这种情况相对少见，更多时候是因为后端应用根据请求协议做了跳转，而CDN与源站之间的协议无法保持稳定。
场景四：CMS插件或.htaccess规则冲突。使用WordPress、Joomla等CMS时，可能同时启用了多个重定向插件（例如Really Simple SSL、Redirection），或者.htaccess里既有Apache的Rewrite规则又有插件写入的规则，导致重复跳转。加上CDN缓存了这些重定向响应，问题会被放大。
排查思路与实战命令
遇到重定向循环，第一步是用命令行工具观察重定向链。在Linux或macOS终端执行下面这条命令：
curl -I -L https://ipipp.com
参数 -I 表示只获取响应头，-L 表示跟随重定向。如果看到一连串的301/302响应并且URL在几个地址之间反复横跳，基本就能确认循环存在。把 https://ipipp.com 换成实际出问题的域名即可。输出里每一组 HTTP/1.1 301 Moved Permanently 后面的 Location 头会告诉你跳转目标，连续观察几个就能发现规律。
也可以使用浏览器开发者工具，打开Network面板，勾选“Preserve log”，刷新页面，查看请求列表里带有301/302状态码的记录，点击任意一条查看Response Headers中的Location值。通过对比多个请求的URL变化，可以快速定位是哪个环节在反复重定向。
确认循环后，登录CDN控制台检查回源配置，重点看这三项：回源协议（HTTP/HTTPS/协议跟随）、回源Host（是否为源站绑定的域名）、回源端口（默认80或443）。如果源站做了强制HTTPS，回源协议必须选择“HTTPS”或“协议跟随”，并且回源Host要正确指向源站能识别的域名。
解决方案与配置示例
最直接的解决办法是统一源站与CDN之间的协议。推荐做法是源站和CDN都启用HTTPS，回源协议设置为“协议跟随”或“HTTPS”。这样CDN会以HTTPS回源，源站不会因为协议是HTTP而触发跳转。如果必须保留HTTP回源，那么源站上要修改跳转逻辑，只对直接来自用户的HTTP请求做跳转，对来自CDN的回源请求放行。Nginx可以通过检查 X-Forwarded-Proto 请求头来区分，示例配置如下：
server {
listen 80;
server_name ipipp.com;
# 仅当请求不是来自CDN的HTTPS回源时才跳转
if ($http_x_forwarded_proto != "https") {
return 301 https://$host$request_uri;
}
}
上面的配置逻辑是：CDN回源时会带上 X-Forwarded-Proto: https 头，源站看到这个头就不再跳转。但要注意，这种判断依赖CDN正确传递该头，如果CDN不发送或可被伪造，需要配合其他方式。更稳妥的方案是让CDN直接以HTTPS回源，从根源上避免协议不一致。
如果源站因为Host头不匹配而重定向，需要在CDN回源配置里把回源Host改为源站虚拟主机对应的域名，而不是默认的加速域名。例如加速域名是 cdn.ipipp.com，但源站只认识 origin.ipipp.com，那么回源Host就要填 origin.ipipp.com。修改后源站能正确提供内容，不会再跳到其他域名。
对于CMS插件或.htaccess产生的循环，建议先禁用所有重定向插件，逐个排查。在.htaccess中只保留一套跳转规则，避免与CDN的HTTPS跳转重复。比如Apache里只保留从HTTP到HTTPS的一条RewriteRule，并且条件限定为非HTTPS请求：
RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R=301,L]
还要检查应用代码中是否有手动发送 Location 头的逻辑，特别是登录、支付等回调地址，这些地方很容易因为环境变量（如 $_SERVER['HTTPS']）在CDN下判断错误而产生循环。确保应用能正确识别经过CDN转发的HTTPS请求，常见做法是信任 X-Forwarded-Proto 头。
预防措施与最佳实践
上线前用重定向检测工具跑一遍网站的完整URL列表，包括首页、内页、静态资源等，确认没有循环后再接入CDN。可以使用 curl -I -L 对多个典型路径进行测试，观察每个请求的最终状态码和重定向次数。有条件的话，在预发环境模拟CDN回源，提前暴露协议不匹配问题。
保持域名策略单一化。避免同时使用带www和不带www的域名、HTTP和HTTPS混合跳转、多个CDN厂商嵌套加速。统一跳转规则：只在一个层面（源站或CDN）执行HTTPS强制跳转，不要在两边都配置。CDN控制台里通常也有“强制HTTPS”开关，如果源站已经做了跳转，CDN侧就不要重复开启。
监控重定向相关指标。通过日志分析工具统计301/302响应码的出现频率，当某个URL的重定向次数超过正常阈值（例如3次）就触发告警。Nginx访问日志中可以记录 $upstream_http_location 变量，方便追踪回源时的重定向目标。一旦发现循环苗头，及时回滚配置或切换回源协议，避免影响扩大。
NET::ERR_TOO_MANY_REDIRECTS 虽然看起来吓人，但只要理清请求链路，从协议、Host、回源配置三个维度逐一排查，绝大多数循环都能快速解决。关键是保证CDN与源站对“用户请求是HTTP还是HTTPS”这个事实有一致判断，并且重定向规则只在一个环节生效。
CDN重定向循环ERR_TOO_MANY_REDIRECTS修改时间：2026-09-23 11:13:31