网站重定向次数过多怎么办？

网站开启HTTPS、接入CDN或修改域名后，浏览器可能提示：

ERR_TOO_MANY_REDIRECTS

这通常表示请求在多个地址之间反复跳转，或者不断跳转回自身，导致浏览器无法正常打开页面。

排查时，应先确认每次跳转的目标，再检查CDN、Web服务器和应用程序中的对应规则。

1. 查看网站首次跳转到哪里

在Linux终端中执行：

curl -sS -D - -o /dev/null \
  --connect-timeout 5 --max-time 15 \
  https://example.com/

将 example.com 替换成实际域名。如果只有某个页面报错，应使用该页面的完整地址。

这条命令发送GET请求，显示响应头并丢弃响应正文，不会自动跟随跳转。

重点查看状态码和 Location：

HTTP/1.1 301 Moved Permanently
Location: http://example.com/

这表示当前HTTPS地址要求客户端转到HTTP地址。接下来需要检查HTTP地址是否又要求返回HTTPS。

301、302、303、307、308都可能用于重定向。出现一次跳转不一定异常，关键是请求能否最终到达正确页面。

使用curl查看网站重定向状态码和Location目标

2. 查看连续跳转是否形成循环

执行：

curl -sS -L --max-redirs 5 \
  --connect-timeout 5 --max-time 20 \
  -D - -o /dev/null https://example.com/

其中：

-L：跟随HTTP重定向。
--max-redirs 5：最多跟随5次跳转。
-D -：显示各次请求的响应头。

如果出现：

curl: (47) Maximum (5) redirects followed

说明跳转次数超过了本次测试上限。还需要查看前面的地址变化，区分真正的循环和过长但能够结束的跳转链。

常见现象与排查方向如下：

跳转现象	优先检查
HTTP与HTTPS反复切换	CDN回源协议、强制HTTPS规则
带www与不带www来回切换	CDN、Nginx和应用的主域名设置
同一个HTTPS地址反复跳向自身	应用未识别原始HTTPS请求、规则自循环
登录页与业务页来回跳转	Cookie、会话状态、登录回调及站点地址
两个路径互相跳转	路径重写、末尾斜杠规则或应用路由

这些现象用于缩小范围，不能仅凭某个响应头就确定是哪个组件产生了跳转。

使用curl排查HTTP与HTTPS循环重定向

3. 检查CDN回源协议

网站接入CDN后，浏览器使用HTTPS，并不代表CDN也使用HTTPS连接源站。

常见循环过程是：

用户通过HTTPS访问CDN。
CDN通过HTTP连接源站。
源站要求跳转到HTTPS。
用户再次访问同一个HTTPS地址。
CDN继续通过HTTP回源，重复以上过程。

应核对CDN的回源协议，以及源站的HTTP、HTTPS监听和跳转设置。

如果准备使用HTTPS回源，先确认源站HTTPS能够正常响应，证书有效且域名匹配，再调整CDN配置。

以Cloudflare为例，Flexible模式通过HTTP连接源站，可能与源站强制HTTPS规则产生循环。满足源站HTTPS和证书要求后，可使用Full (strict)模式。该模式会验证源站证书，需要证书未过期、主机名匹配，且由其认可的证书机构签发。

其他CDN的设置名称可能不同，应按对应产品的回源配置核对。

如果架构本身设计为代理终止HTTPS、内部通过HTTP转发，则需要让后端正确识别可信代理传递的原始协议，具体见第5节。

4. 统一Nginx与CDN的跳转方向

先确定网站最终使用的规范地址，例如：

https://example.com/

随后检查各层配置，避免出现：

CDN把不带www跳转到www，源站又反向跳回。
Nginx要求使用HTTPS，应用却生成HTTP地址。
已经处于目标地址的请求，仍被规则跳回自身。

对于Nginx直接处理公网HTTP、HTTPS，或CDN已正确使用HTTPS回源的场景，可以在对应HTTP站点中设置单向跳转。例如：

server {
    listen 80;
    server_name example.com www.example.com;

    return 301 https://example.com$request_uri;
}

这是HTTP跳转配置片段，不能直接覆盖完整站点配置。应修改已有的对应配置，避免创建重复的 server 块。

HTTPS站点需要正常提供业务内容，不应再跳回HTTP。若还要将 https://www.example.com 跳转到主域名，对应HTTPS入口也必须先具备有效证书。

如果CDN始终通过HTTP回源，不要直接套用上面的强制跳转片段，应先解决第3节中的协议识别问题。

修改前备份配置，完成后先检查：

sudo nginx -t

检查通过后，再执行：

sudo nginx -s reload

面板安装、自定义路径或容器部署环境，应使用实际运行实例对应的Nginx程序及配置。

5. 检查应用地址和代理协议识别

如果CDN与Nginx规则已经一致，但仍然跳转，应继续检查应用。

检查网站地址设置

应用中的基础地址、主域名、HTTPS设置和登录回调地址，应与实际部署一致。

例如，网站已经使用HTTPS，但应用仍将HTTP地址作为规范地址，就可能与外层强制HTTPS规则冲突。

WordPress等程序可能分别配置程序地址和站点地址。应核对协议、域名和部署路径；安装在子目录时，两项路径不一定相同。

检查反向代理请求头

如果Nginx直接接收用户的HTTPS请求，再通过HTTP转发给后端，可以在对应代理配置中传递：

proxy_set_header Host $host;
proxy_set_header X-Forwarded-Proto $scheme;

同时，后端应用需要配置为识别来自可信代理的协议信息。仅添加请求头，不代表所有应用都会自动使用它。

上述 $scheme 表示当前Nginx收到请求时使用的协议。如果它前面还有CDN，并且CDN通过HTTP回源，$scheme 仍会是 http，不能直接代表用户访问时的协议。

多层代理应按实际架构传递并验证协议信息。应用只应信任已确认的代理来源，不能无条件相信客户端自行提交的转发头。

6. 验证修复结果

修复后执行：

curl -sS -L --max-redirs 5 \
  --connect-timeout 5 --max-time 20 \
  -o /dev/null \
  -w '%{http_code} %{num_redirects} %{url_effective}\n' \
  http://example.com/

输出依次表示最终状态码、跳转次数和最终地址。例如：

200 1 https://example.com/

表示经过一次跳转后，到达HTTPS页面并返回200。

还应分别测试：

HTTP与HTTPS入口。
带www与不带www的域名。
原来出现问题的具体路径。
登录、退出和主要业务功能。

公开首页通常应最终正常返回内容；需要认证的页面则应到达预期的登录流程。不要将“所有页面必须零跳转”作为修复标准。

如果CDN缓存了旧的跳转响应，应清理对应缓存。浏览器仍显示旧结果时，可使用无痕窗口对比，必要时清理该站点缓存和Cookie后重新登录。

使用curl验证网站最终状态码和重定向次数

常见问题

清理浏览器Cookie就能解决吗？

部分登录循环与Cookie有关，但CDN回源协议或服务器规则造成的循环，需要修正配置。清理Cookie不能替代服务端排查。

把301改成302能解决吗？

状态码改变不会自动消除相互冲突的跳转规则。应先修正跳转方向和触发条件，再根据业务选择合适的状态码。

curl正常，为什么浏览器仍然报错？

浏览器可能携带已有Cookie、使用缓存，或者执行页面中的JavaScript跳转。普通curl测试不会自动复现这些行为，可结合浏览器开发者工具的网络面板继续检查。

注意事项

调整前记录原配置，每次修改一处并验证结果，便于确认原因和回退。不要通过关闭证书验证来掩盖HTTPS配置问题。

使用莱卡云服务器时，如需协助排查，可向莱卡云技术支持提供报错域名、具体路径、发生时间、是否使用CDN，以及脱敏后的跳转响应头和相关配置。提交前请隐藏Cookie、认证信息和其他敏感数据。