“服务器循环重定向”（通常称为 重定向循环 或 Redirect Loop）是网站开发中非常常见的一种错误。
就是服务器 A 告诉浏览器去访问服务器 B，而服务器 B 又告诉浏览器回到服务器 A，如此无限循环，导致浏览器无法加载页面，最终报错（如 ERR_TOO_MANY_REDIRECTS）。
以下是导致该问题的常见原因、排查步骤和解决方案：
常见原因
-
HTTP/HTTPS 配置冲突
- 网站强制要求 HTTPS，但服务器配置错误，导致 HTTP 请求被重定向到 HTTPS，而 HTTPS 配置又错误地重定向回 HTTP。
- Nginx/Apache 配置了
if ($scheme = http) { return 301 https://... },但后端应用又做了相反的重定向。
-
WordPress 等 CMS 的站点地址设置错误
- WordPress 后台的“WordPress 地址 (URL)”和“站点地址 (URL)”设置不一致（比如一个加了
www，一个没加；或者一个用 HTTP，一个用 HTTPS）。 - 插件（如 GEO 插件、缓存插件）强制重定向设置错误。
- WordPress 后台的“WordPress 地址 (URL)”和“站点地址 (URL)”设置不一致（比如一个加了
-
CDN 或反向代理配置问题
- 使用 Cloudflare、简米云 CDN 等服务时，SSL/TLS 加密模式设置不当（如设置为“Flexible”但源站又强制 HTTPS）。
- 反向代理（如 Nginx）未正确传递
X-Forwarded-Proto头信息,导致后端应用误判协议类型。
-
代码逻辑错误
- 在 PHP、Java、Node.js 等后端代码中,路由逻辑存在死循环。
- 登录验证逻辑中，未登录用户重定向到登录页，但登录页本身又检查登录状态,形成循环。
-
Cookie 或 Session 问题
某些情况下，浏览器 Cookie 损坏或策略冲突，导致身份验证状态反复切换,引发重定向。
排查步骤
使用浏览器开发者工具（最推荐）
- 打开浏览器（Chrome/Firefox/Edge）。
- 按
F12打开开发者工具，切换到 Network（网络） 标签页。 - 刷新页面,观察请求列表。
- 你会看到一系列状态码为
301或302的请求，它们会不断重复,直到浏览器停止并报错。 - 点击其中一个重定向请求，查看 Headers（标头）：
- 查看 Location 字段：它指向了哪个 URL？
- 查看 Request URL：当前请求的是哪个 URL？
- 通过对比，找出循环的两个 URL 是什么。
使用命令行工具 curl
curl -I -L https://yourdomain.com
-I：只显示响应头。-L：跟随重定向。- 输出会显示每一步的重定向目标,帮助你定位循环点。
检查服务器配置文件
- Nginx：检查
nginx.conf或站点配置文件中是否有冲突的rewrite或return指令。 - Apache：检查
.htaccess文件中是否有重复或冲突的RewriteRule。 - IIS：检查
web.config中的
<rewrite>规则。
检查 CMS 设置（如果是 WordPress 等）
- 登录后台（如果还能登录），检查 设置 > 常规 中的两个 URL 是否一致。
- 临时禁用所有插件,看是否恢复。
- 检查
wp-config.php中是否定义了WP_HOME或WP_SITEURL。
解决方案
场景 1：HTTP/HTTPS 冲突
Nginx 示例：
确保只在一个地方强制 HTTPS,而不是两边都强制。
# 正确做法：只监听 80 端口并重定向到 443
server {
listen 80;
server_name yourdomain.com;
return 301 https://$host$request_uri;
}
# 然后只监听 443 端口处理 HTTPS 请求
server {
listen 443 ssl;
server_name yourdomain.com;
# SSL 配置...
# 不要在这里再写重定向回 HTTP 的代码
}
Apache 示例：
确保 .htaccess 中只有一个重定向规则：
RewriteEngine On
# 如果请求不是 HTTPS，则重定向到 HTTPS
RewriteCond %{HTTPS} off
RewriteRule ^(.)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
场景 2：WordPress 站点地址错误
- 登录 WordPress 后台。
- 进入 设置 > 常规。
- 确保 WordPress 地址 (URL) 和 站点地址 (URL) 完全一致（都包含
https://或都不包含，都包含www或都不包含）。 - 如果无法登录后台，可以通过数据库直接修改：
UPDATE wp_options SET option_value = 'https://yourdomain.com' WHERE option_name = 'siteurl'; UPDATE wp_options SET option_value = 'https://yourdomain.com' WHERE option_name = 'home';
场景 3：CDN 配置问题（如 Cloudflare）
- 进入 Cloudflare 控制台。
- 找到 SSL/TLS 设置。
- 如果源站已配置 SSL，建议将加密模式改为 Full (Strict)。
- 避免使用 Flexible，除非你完全确定源站没有强制 HTTPS。
场景 4：代码逻辑错误
- 检查后端路由逻辑,确保没有两个路由互相重定向。
-
// 错误示例 if (!is_logged_in()) { redirect('/login'); } // 在 login 页面中又检查： if (!is_logged_in()) { redirect('/login'); // 死循环！ } - 修复：确保重定向目标页面本身不触发相同的重定向条件。
预防措施
- 统一 URL 规范：决定使用
www还是non-www，使用HTTP还是HTTPS,并在服务器层面全局统一。 - 使用 HSTS：启用 HTTP 严格传输安全（HSTS），防止浏览器降级到 HTTP。
- 测试环境验证：在上线前，使用
curl或浏览器开发者工具测试重定向链路。 - 避免多层重定向：尽量减少重定向次数,最好一步到位。
如果你能提供具体的错误信息、服务器类型（Nginx/Apache/IIS）或 CMS 类型（WordPress/自定义开发）,我可以给出更精确的解决方案。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/%e6%9c%8d%e5%8a%a1%e5%99%a8%e4%b8%ba%e4%bd%95%e5%be%aa%e7%8e%af%e9%87%8d%e5%ae%9a%e5%90%91%ef%bc%9f%e6%9c%8d%e5%8a%a1%e5%99%a8%e5%be%aa%e7%8e%af%e9%87%8d%e5%ae%9a%e5%90%91%e6%80%8e%e4%b9%88%e8%a7%a3/
