重定向循环是怎么发生的：服务器检测不到时浏览器会报什么

先给有条件的答案：当一次请求经过的重定向路径，再次回到之前已经走过的地址时，循环就形成了。按 MDN 重定向文档的表述，当后续的重定向路径重复之前的路径的时候，重定向循环就产生了，也就是陷入无限循环，不会有一个最终的页面返回。

这句话里有两个关键词：路径、重复。判断是不是循环，不看状态码是 301 还是 302，也不看跳转了几次，只看新地址是不是之前已经访问过的那个。

一个自建示例（练习场景，不是对某个真实站点的记录）：假设你在练习目录里维护两个自建页面，A 页面配置成跳转到 B，B 页面又配置成跳转到 A。用户请求 A，服务器返回指向 B 的重定向；浏览器请求 B，服务器返回指向 A 的重定向。路径 A→B→A→B 开始重复，循环成立。

这里要分清：单次重定向是正常功能，路径重复才是问题。文档也提醒，每一次重定向都会带来性能开销，所以应尽量避免内部链接的重定向映射。

本文只讲重定向路径重复导致的死循环，以及服务器端和浏览器端分别怎么检测。不讲 301 与 302 的区别，也不讲 meta 与 JavaScript 重定向的优先级。

服务器端能不能检测到循环，取决于它有没有完整的跳转路径视图。

按 MDN 文档的说明，大多数情况下重定向循环属于服务器端错误。如果服务器检测不到，就会返回 500 Internal Server Error。文档还给了一个实用线索：假如你在修改了服务器配置不久就出现了这个问题，八成是遇到了重定向循环。

这句话可以拆成两层。第一层：服务器如果能在自己的配置里发现“这个地址最终又指回自己”，它可以直接判定为错误，返回 500。第二层：如果服务器检测不到，它就不会返回 500，而是继续按配置发出重定向响应。

为什么会有检测不到的情况？文档写得很直接：有时候服务器端无法对其进行检测，因为重定向循环发生于多台服务器之间，对于每一台服务器来说，都无法获得一个全景图。

一个自建示例（练习场景）：假设你在练习目录里用两个自建服务分别配置跳转，服务一收到 /a 就跳转到服务二的 /b，服务二收到 /b 又跳回服务一的 /a。对服务一来说，它只知道自己把 /a 指向了 /b；对服务二来说，它只知道自己把 /b 指向了 /a。任何一台单独看，都看不出这是一条闭环路径。

所以服务器端的检测能力是有边界的：单台服务器、单份配置里能看出来的循环，它可能返回 500；跨服务器、跨配置的循环，它往往看不到，这时检测责任就落到浏览器身上。

当服务器端无法检测时，浏览器会负责进行检测，然后返回错误信息。这是 MDN 文档对循环检测分工的明确表述。

浏览器为什么能检测到？因为它站在客户端这一侧，能看到这次请求实际走过的完整跳转序列。服务器各自只看到自己发出的那一次重定向，浏览器则连续收到多次重定向响应，能够发现地址在重复。

这里要划清一个边界：浏览器检测到循环后，给出的是错误提示，不是替你修复。文档也说明，无论哪个场景，用户对此都无能为力，除非客户端发生突变，比如说缓存或者 Cookie 不匹配。也就是说，普通用户看到提示后，能做的通常只是停止访问或联系站点方，而不是在浏览器里点几下就解决。

一个自建示例（练习场景）：你在练习目录里用自建页面模拟 A 跳 B、B 跳 A。浏览器连续跟随重定向，走到一定次数后不再继续，转而显示错误页。这个错误页是浏览器给出的，不是服务器返回的。

需要说明的是：本文不给出浏览器具体在多少次重定向后停止的数值，资料没有提供这个数字，本文也不补。

服务器检测不到、浏览器接手拦截之后，不同浏览器给出的提示文字不一样。按 MDN 文档列出的两条：

Firefox 会呈现：Firefox 检测到该服务器正在将指向此网址的请求无限循环重定向。

Chrome 则会呈现：该网页将你重定向的次数过多。

把这两句并排看，差异在措辞的落点上。Firefox 的提示把原因说成“无限循环重定向”，指向的是循环这个性质；Chrome 的提示说成“重定向的次数过多”，指向的是次数这个表现。

对排查的人来说，这个差异有实际影响：看到 Firefox 的提示，可以直接往“路径是不是绕回来了”这个方向查；看到 Chrome 的提示，容易先怀疑“是不是跳转层数太多”，但底层原因同样可能是路径重复。

一个自建示例（练习场景）：你在练习目录里用自建页面制造 A→B→A 的循环，分别用两款浏览器打开同一个地址，记录各自显示的提示文字。这一步只用来观察提示差异，不据此推断浏览器的内部实现。

本文只对照这两条提示文字，不评价哪款浏览器更好，也不涉及其他浏览器的提示写法。

如果你怀疑遇到了重定向循环，可以按下面这个顺序核对。以下顺序是编辑整理的排查方向，不是官方规定的流程。

第一步，记录实际跳转路径。用浏览器开发者工具的 Network 面板，看这次请求依次经过了哪些地址。重点不是数跳转了几次，而是看有没有地址重复出现。

第二步，判断重复发生在哪一层。如果重复的地址都在同一台服务器、同一份配置里，服务器端有可能自己检测到并返回 500。如果重复的地址分属不同服务器或不同配置，按 MDN 文档的说明，每一台服务器都拿不到全景图，服务器端往往检测不到，这时由浏览器拦截。

第三步，对照浏览器提示判断方向。看到 Firefox 的“无限循环重定向”，直接查路径闭环；看到 Chrome 的“重定向次数过多”，不要只盯着次数，也要回到路径上找重复。

第四步，回想最近改过什么。文档给的线索是：假如你在修改了服务器配置不久就出现了这个问题，八成是遇到了重定向循环。所以先回看最近动过的跳转配置，比漫无目的地翻找更有效。

一个自建示例（练习场景）：在练习目录里维护一份自建的跳转记录表，两列分别写“请求地址”和“响应指向的地址”，逐行填。填完看第二列有没有哪一行回到了第一列已经出现过的地址。有，就是路径重复。

本文只讲这套核对顺序，不涉及具体服务器配置文件的写法。

本文的事实依据是 MDN 的 HTTP 重定向文档，适用范围限定在重定向路径重复导致的死循环。

覆盖的内容有三项：循环的成因是后续重定向路径重复之前的路径；服务器端能检测时返回 500，检测不到时由浏览器负责检测；Firefox 与 Chrome 给出的提示文字差异。

不覆盖的内容也有三项，需要明确划出：不讲 301 与 302 的区别，不讲 meta 重定向与 JavaScript 重定向的优先级，也不给出浏览器在多少次重定向后停止的具体数值，因为资料没有提供这个数字。

另外要说明：本文所有场景都是编辑设计的自建练习情境，不是对某个真实站点的测试记录，也没有对任何真实服务器做过操作。涉及浏览器开发者工具的部分，只用于查看你自己访问的请求记录，不修改任何系统设置。

如果你在实际站点上遇到循环，能做的通常是记录跳转路径、回看最近的配置改动，并把记录交给负责该站点的人。用户端本身通常无法直接消除循环。