作者： FreeWebTools Editorial Team 更新于

🔀

重定向检查器：查看任意网址或链接跳转到哪里

重定向检查器会顺着网址一跳一跳地跟踪下去，报告每一跳的 HTTP 状态，直到重定向链结束。例如输入 http://github.com，它会记录两跳：第 1 跳返回 301 Moved Permanently 并指向 https://github.com/，后者返回 200 OK。这是一次重定向，完全正常；每多一次重定向，就会多一次网络往返。本检查器会跟踪 301、302、303、307 和 308 响应以及 HTML 中的 meta refresh 标签，标出循环和过长的重定向链，还可以模拟 Googlebot 或手机发送请求。

每行一个网址，最多 10 个。每个网址单独追踪，之后可以导出整批结果。

嵌入此工具

× px 

                        

                            
                        

                    

                

                
                
                

                    
💡 集成提示

                    
复制嵌入代码并粘贴到您网站的HTML中。响应式版本会自动适应所有屏幕尺寸。

                

            

        

    

    
    
    

        


    
    

        
        

        
        

        2 个评分
    

    
    
    

    
    
    
    
    
    

        
    

    
    
    ✓

        
        






    

    






        

    

    




    
    
    

        
热门工具

    

    
    
    

        
        
        
        
        
        
        

            
        

        
        
        

            没有更多工具
        

    

    
    
    
        探索所有工具
        
            
        
    
    










        

        
301、302、303、307 和 308 分别是什么意思？

        
这五个状态码都是 RFC 9110 第 15.4 节定义的 3xx 响应。它们在浏览器关心的两个方面有所不同：请求方法在重定向后是否保留，以及响应能否被缓存和重复使用。“搜索引擎信号”一列说明 Google 搜索如何看待这一信号。

        

            

                HTTP 重定向状态码对比：请求方法的处理、缓存以及搜索引擎的对待方式。
                
                    

                        状态码
                        名称
                        重定向后的请求方法
                        默认可缓存
                        搜索引擎信号
                        适用场景
                    

                
                
                                        

                        301
                        Moved Permanently
                        POST 可能被改写为 GET
                        是
                        强烈的规范化信号；新网址取代旧网址
                        永久迁移、HTTP 转 HTTPS、不带 www 转带 www
                    

                                        

                        302
                        Found（临时）
                        POST 可能被改写为 GET
                        否，除非响应头允许
                        旧网址通常仍保留在索引中
                        A/B 测试、维护页面、按地区分流
                    

                                        

                        303
                        See Other
                        始终改为 GET
                        否
                        视为临时
                        表单提交后的 Post/Redirect/Get
                    

                                        

                        307
                        Temporary Redirect
                        保留，包括请求体
                        否
                        视为临时
                        需保留请求方法和请求体的 API 及表单端点临时迁移
                    

                                        

                        308
                        Permanent Redirect
                        保留，包括请求体
                        是
                        与 301 权重相同
                        需保留 POST、PUT 和 DELETE 的永久迁移
                    

                                    
            

        

        
有两个状态码常被误认为重定向，但其实不是：304 Not Modified 是缓存验证的响应，不带 Location 响应头；300 Multiple Choices 提供的是一组选项，而不是单一目标。meta refresh 标签也不是 HTTP 重定向，但浏览器会跟随它，因此检查器会将其显示为单独的一跳，并标记为 meta refresh 刷新；而 JavaScript 修改 location 造成的跳转永远不会出现，因为页面上的任何内容都不会被执行。Chrome 在 HSTS 把 http:// 升级为 https:// 时显示的“307 Internal Redirect”同样不会出现：这一行是浏览器在任何请求离开本机之前自己生成的，因此没有哪台服务器能发送它，服务器端追踪也永远看不到它。

    

    
        

        
如何检查重定向是否生效？

        
输入旧地址而不是新地址，并从访客实际使用的协议开始：在大多数服务器上，http:// 和 https:// 对应不同的规则。生效的重定向会在第 1 跳返回带 Location 响应头的 3xx，在最后一跳返回 200，且路径和查询字符串完好无损。如果最后一跳是 404、403 或 405，说明规则触发了，但指向的地址毫无用处；如果第 1 跳就已返回 200，说明重定向根本没有触发。

        
    
            
  • 第 1 跳返回 301、302、307 或 308，而不是 200。
    • 
            
  • 最后一跳返回 200，而不是 404、403 或 500。
    • 
            
  • 最终网址就是确切的目标地址，包括路径、末尾斜杠以及你发送的所有查询字符串。
    • 
            
  • 重定向链中只有一次重定向：第 1 跳返回 3xx，第 2 跳返回 200。如果重定向次数更多，说明规则在层层叠加。
    • 
        

        
        
如需查看某一跳返回的全部响应头，例如 Location、Cache-Control 和 Strict-Transport-Security，请用 HTTP头检查器查看该网址。

        
某一跳报证书错误而不是返回状态码时，浏览器同样会在此止步：用 SSL证书检查器查看该主机的证书。

    

    
        

        
如何修复重定向链或重定向循环？

        
当两条规则相互矛盾时，就会出现循环：CDN 强制使用 https://example.com，而源站强制使用 http://www.example.com，于是每一跳都在抵消另一跳，浏览器最终报 ERR_TOO_MANY_REDIRECTS 错误并停止。本检查器会在 10 跳后停止；当某个网址再次出现时，它会指出把请求重新导回链中的那一跳；如果只是链条过长，它会指出最后到达的网址。修复方法是：确定一种规范形式（协议、主机名和末尾斜杠），只在一个层级中实施，并改写其他规则，让它们直接指向最终网址，而不是互相指向。

        
    
            
  1. 选定一种规范形式：https、一个主机名、一种末尾斜杠约定。
    2. 
            
  2. 只在一处强制执行，通常是 CDN 或 Web 服务器；切勿两者同时设置，更不要再在应用程序中重复一遍。
    3. 
            
  3. 合并重定向链：修改第一条规则，让它指向最终网址，使 A 直接跳到 C，而不是 A 到 B 再到 C。
    4. 
            
  4. 用检查器重新检测旧网址，确认只有一次重定向，并以 200 结束。
    5. 
        

        
要在 Apache 上修复？.htaccess生成器可以帮你编写 301 规则，包括 http 到 https 和 www 的重定向，让每个旧网址只需一跳。

    

    
        

        
使用重定向检查器安全吗？

        
比你亲自点击链接更安全。追踪在我们的服务器上运行，而不是在你的浏览器中：不会发送你浏览器中的任何 Cookie，不会运行 JavaScript，对于普通页面也只读取前 64 KB，用来查找 meta refresh 标签。你在决定是否访问之前就能看到目标主机，面对 t.co、bit.ly 或 lnkd.in 这类包装链接时，这正是你需要的。发往 localhost、私有地址段（如 192.168.0.0/16）和云元数据端点的请求会被拒绝，试图跳转到这些地址段的重定向会在发起跳转的那一跳被拦截，每次检测在达到 10 跳或 20 秒后结束。

    

    





    
网络与诊断

    

                
        
            

                📋
            

            

                
HTTP头检查器

                
分析任何网站的HTTP响应头。检查安全头、缓存策略、服务器信息并获得安全评分。

            

        
                
        
            

                📡
            

            

                
网站状态检查器

                
检查网站是否在线。响应时间、HTTP状态码、服务器头信息。支持批量检查。

            

        
                
        
            

                🔍
            

            

                
HTTP头部检查器

                
检查任何网站的HTTP响应头和安全评分。分析HSTS、CSP、X-Frame-Options等安全头。

            

        
                
        
            

                🔒
            

            

                
SSL证书检查器

                
检查SSL/TLS证书详情。颁发者、有效期、证书等级和安全状态。

            

        
            







    

    
        

        

            关于重定向检查器
        

        

                        
这款重定向检查器会追踪从你输入的网址到最终加载的页面之间实际发生的一切。它从我们的服务器为每一跳发送一个不带 Cookie 的 GET 请求，记录状态码、Location 响应头和每一跳的耗时，然后继续请求下一个网址，直到收到非重定向的响应为止；或者在 10 跳后停止。10 跳已经是 Google 抓取工具跟踪的最大深度，也大约是浏览器上限的一半：浏览器约允许 20 跳，超过后就会报 ERR_TOO_MANY_REDIRECTS 错误并放弃。如果某一跳返回 200 和一个 HTML 页面，检查器最多读取前 64 KB 来查找 meta refresh 标签，因为这类重定向写在页面里，而不在响应头里。页面上的任何内容都不会被执行，这也是 JavaScript 重定向无法检测的原因：它们只有在浏览器运行页面脚本之后才会存在。

                        
输出结果刻意保持原样，不做任何加工。第 1 跳就是你输入的网址，之后的每一行都是上一跳实际指向的确切网址，包括协议的变化、添加或去掉的 www、末尾斜杠和查询字符串；通过 meta refresh 到达的跳会如实标明，并注明延迟。正因如此，这个工具在网站迁移时很有用：在 nginx 配置中看似正确的规则，一旦 HSTS、CDN 边缘规则和应用层的规范化重定向同时起作用，实际表现往往会不同，而唯一能如实看到结果的办法，就是从外部把它跟踪一遍。由于有些网站会把手机、爬虫和桌面浏览器导向不同的地方，请求可以用我们自己的爬虫、Windows 上的 Chrome、iPhone 上的 Safari、Googlebot（智能手机版或桌面版）或 Bingbot 的身份发出。

                        
批量模式一次最多接受 10 个网址，逐一追踪，并生成一张表格，列出重定向次数、最终状态、最终网址和总耗时，可以导出为 CSV，也可以直接粘贴到电子表格或工单中。变体按钮会为你输入的地址生成 http 与 https、带 www 与不带 www 的四种组合，并一次性全部追踪，这是确认所有入口都汇聚到同一个规范网址的最快方法。它能在几秒钟内解答的典型问题包括：旧的产品网址是否仍通过一次 301 到达新网址？HTTP 到 HTTPS 的规则在上次部署后是否依然有效？联盟推广链接的查询字符串是否一路保留？短链接最终究竟落在哪里？私有地址、localhost 和云元数据端点会被拒绝，每次检测在 20 秒后停止，因此无法利用本检查器探测内部网络。

                    

    

        
    
        

        

            使用场景
        

        

                        

                
                    
                
                验证网站迁移：把流量最高的 10 个旧网址粘贴到批量模式中，确认每一个都通过一次 301 直接到达新地址，而不是返回 302 或绕道首页。
            

                        

                
                    
                
                审查 HTTP 到 HTTPS 的切换：http://github.com 应当返回 301，并通过一次重定向到达 https://github.com/。如果出现三次重定向，通常意味着 HSTS 规则、www 规则和应用程序在依次各自重定向。
            

                        

                
                    
                
                点击之前先还原短链接：t.co、bit.ly 和 lnkd.in 包装的链接会在服务器端展开，你无需在浏览器中加载页面或运行其脚本，就能看到目标主机。
            

                        

                
                    
                
                排查营销活动跟踪问题：检查 ?utm_source 和 ?gclid 是否在每一跳中都得以保留，因为丢掉查询字符串的重定向会悄无声息地破坏这次点击的归因。
            

                        

                
                    
                
                诊断客户报告的 ERR_TOO_MANY_REDIRECTS：当某个网址第二次出现时，追踪会立即停止，并指出把请求重新导回链中的那一跳——几乎总是 CDN 强制使用 HTTPS，而源站强制使用 HTTP；如果链条从不重复却一直延续，追踪则会在 10 跳上限处停止，并指出最后到达的网址。
            

                    

    

        
    
            

    

        如何检查网址重定向到了哪里
    

    
    

                

            

                1
            

            

                
粘贴要测试的网址或链接，例如 http://github.com，或者点击输入框下方的某个示例标签。

            

        

                

            

                2
            

            

                
如有需要，可选择请求以谁的身份发出：我们的默认爬虫、Chrome、iPhone、Googlebot 或 Bingbot。对手机或爬虫区别对待的网站会显示不同的重定向链。

            

        

                

            

                3
            

            

                
按 Enter 键或点击“检测重定向”。我们的服务器会逐跳发出请求，并沿着 301、302、303、307、308 响应和 meta refresh 标签继续跟踪，最多 10 跳。

            

        

                

            

                4
            

            

                
查看摘要：发现的重定向次数、最终 HTTP 状态、总耗时和最终网址。如果网址出现循环，或经过不止一次重定向，会显示警告。

            

        

                

            

                5
            

            

                
顺着编号的重定向链查看每一跳：它的网址、状态标记（例如 301 Moved Permanently）、是否为 meta refresh 刷新，以及该跳的耗时。

            

        

                

            

                6
            

            

                
如需测试多个地址，可切换到批量模式（最多 10 个网址），或点击变体按钮一次性追踪 http、https、带 www 和不带 www 的版本，然后将结果导出为 CSV。

            

        

            





        
    
        

        

            专业提示
        

        

            
    
                                
  • 
                    
                        
                    
                    尽量只用一次 301 直接跳到最终网址。每多一跳都要多一次完整的网络往返，切换到 HTTPS 的跳还要多一次 TLS 握手，更换主机的跳还要在此基础上再多一次 DNS 查询——在移动网络上，这些加起来通常会在任何内容渲染之前耗去 100～300 毫秒。
                
    • 
                                
  • 
                    
                        
                    
                    如果被重定向的请求可能是 POST，请使用 308 而不是 301。301 和 302 允许客户端把请求方法改写为 GET；307 和 308 则必须保留请求方法和请求体。
                
    • 
                                
  • 
                    
                        
                    
                    除了 https:// 版本，也要测试 http:// 和 www 版本；变体按钮可以一次测完全部四个。很多网站在 HTTPS 上重定向正常，但一条过时的纯 HTTP 规则仍然指向一台已停用的主机。
                
    • 
                                
  • 
                    
                        
                    
                    不要只看重定向次数，还要看最后一跳的状态。以 404 或 405 结尾的重定向链是失效的，即使途中每一次重定向都是毫无问题的 301。
                
    • 
                                
  • 
                    
                        
                    
                    迁移完成后，把 Search Console 中的热门网址放进批量模式检测，下载 CSV，一周后再用同一份列表检测并比对差异，就能发现被某次部署悄悄还原的规则。
                
    • 
                            

        

    

        
    
            

    

        故障排除
    

    
    

                

            

                

                    
                        
                    
                    问题:
                

                
选择 Googlebot 时，检测结果为 403。

            

            

                

                    
                        
                    
                    解决方案:
                

                
许多大型网站会确认自称 Googlebot 的访问者确实来自 Google 的网络，并拒绝其他所有访问者，其中也包括本检查器。请改用默认或 Chrome 用户代理进行对比；要查看 Google 自己收到了什么，请使用 Search Console 中的网址检查工具。

            

        

                

            

                

                    
                        
                    
                    问题:
                

                
重定向链以 403、405 或 503 结束，但页面在我的浏览器里能正常打开。

            

            

                

                    
                        
                    
                    解决方案:
                

                
该网站很可能在筛选客户端：比如需要 Cookie 和 JavaScript 的机器人防护或 CDN 人机验证，或者封禁了服务器 IP 段。试试 Chrome 或 iPhone 用户代理；如果响应没有变化，说明过滤依据的是网络或行为，服务器端检测无法绕过。

            

        

                

            

                

                    
                        
                    
                    问题:
                

                
我的浏览器显示 ERR_TOO_MANY_REDIRECTS，但检查器显示的重定向链一切正常。

            

            

                

                    
                        
                    
                    解决方案:
                

                
这个循环很可能取决于本检查器不会发送的东西：某个 Cookie、已登录的会话，或者浏览器保存的 HSTS 记录。请清除该网站的 Cookie 或打开无痕窗口，然后用变体按钮对比 http:// 和 https:// 版本，找出把访客送回原处的那条规则。

            

        

                

            

                

                    
                        
                    
                    问题:
                

                
某一跳没有返回状态码，而是报 SSL 证书错误。

            

            

                

                    
                        
                    
                    解决方案:
                

                
该主机上的证书已过期、是自签名的，或是为其他域名签发的，因此在读取任何重定向之前连接就被拒绝了。浏览器也会在同一处停下。请续期或修复证书，或者让上一跳指向一台证书有效的主机。

            

        

            



        
    
            

    

        常见问题解答
    

    
    

                

            
            

                
它能显示一个网址实际会把访客和搜索引擎带到哪里。你会看到从输入的地址到最终作出响应的页面之间的每一跳，以及每一跳的状态码和耗时。这样一次就能回答三个问题：重定向是否生效？是否指向了正确的目标？途中浪费了多少跳？在点击短链接或联盟推广链接之前，也可以用它安全地查看链接会通向哪里。

            

        

                

            
            

                
301 表示永久迁移：浏览器会缓存它；Google 会把旧网址的排名信号合并到新地址，只将旧网址保留为备用名称，因此旧网址通常不再出现在搜索结果中，但当某个查询表明用户信任它时，仍可能出现。302 表示临时迁移，因此原网址通常仍保留在索引中，而且除非响应头允许，否则该响应不会被缓存。网站迁移和升级到 HTTPS 时请使用 301；302 只用于 A/B 测试和维护页面。

            

        

                

            
            

                
目标是一次，两次尚可容忍，三次及以上就应该合并。浏览器大约在 20 跳后中止，Google 抓取工具最多跟踪 10 跳重定向，超过后便将该网址视为错误。每多一跳都要多一次网络往返，切换协议的跳还要多一次 TLS 握手，更换主机的跳还要再多一次 DNS 查询，因此在移动网络上，一条包含三次重定向的链可能会在真正内容的第一个字节到达之前增加数百毫秒。

            

        

                

            
            

                
输入你的域名，然后点击变体按钮。它会在同一批次中追踪同一路径的 http://、https://、http://www. 和 https://www. 四个版本。配置正常时，四个版本都会落到同一个返回 200 的最终网址上：规范版本没有任何重定向，其余三个各只有一次 301 或 308。如果 http://www. 版本出现两次重定向，通常说明协议和主机名是由两条独立的规则分别修正的，可以合并为一条。

            

        

                

            
            

                
可以。在开始检测之前选择用户代理：Windows 上的 Chrome、iPhone 上的 Safari、Googlebot 智能手机版或桌面版，或者 Bingbot。如果网站会把移动端访客导向 m. 子域名，或对爬虫区别对待，那么每种用户代理都会显示不同的重定向链。需要注意一点：许多大型网站会核实自称 Googlebot 的访问者是否真的来自 Google 的网络，否则就返回 403；因此使用 Googlebot 用户代理时得到 403，往往正是这个原因。要确切了解 Google 收到了什么，请使用 Search Console 中的网址检查工具。

            

        

                

            
            

                
meta refresh 可以检测。当某一跳返回 200 和 HTML 页面时，检查器会读取页面的前 64 KB，找到带有网址的 meta refresh 标签，并将其作为下一跳继续跟踪，标记为 meta refresh 刷新，同时注明延迟秒数。JavaScript 重定向则不行：它们只有在浏览器运行页面脚本之后才会发生，而本检查器从不执行任何内容。如果最后一跳返回 200，而你的浏览器却跳到了别处，原因很可能是脚本；DevTools 的“网络”（Network）面板会将其显示为由脚本发起的导航。

            

        

                

            
            

                
通常有四个原因。一是你的浏览器在 HSTS 缓存中记录了该网站，因此在任何请求离开本机之前，就已把 http:// 升级为 https://。二是网站会根据 Cookie、语言请求头或国家/地区返回不同的响应，而在网站看来，我们的服务器和你并不一样。三是网站会把手机和桌面设备导向不同的地方，切换用户代理即可复现。四是页面加载后由 JavaScript 重定向完成了最后一段跳转，而服务器端追踪永远看不到这一步。

            

        

                

            
            

                
可以。切换到批量模式，粘贴最多 10 个网址，每行一个。每个网址都会单独追踪，结果汇总在一张表格中，列出重定向次数、最终状态、最终网址和总耗时。你可以用“下载 CSV”保存这张表格，或用“复制为表格”将其复制为制表符分隔的文本，直接粘贴到 Sheets、Excel 或 Jira 工单中，无需重新排版。变体按钮则会用同一地址的四个 http/https 与 www 版本填充这张表格。

            

        

                

            
            

                
按 F12 打开 DevTools，切换到“网络”（Network）面板，勾选“保留日志”（Preserve log），然后加载该网址。每一跳都会单独显示为一行，状态为 301 或 302；点击其中一行，在“响应标头”（Response Headers）下查看 Location 字段。问题在于，DevTools 显示的是你的浏览器实际的行为，连同你的 Cookie、HSTS 缓存和扩展程序的影响，因此同事在另一台电脑上看到的重定向链可能并不相同。

            

        

                

            
            

                
单次 301 或 308 会传递排名信号，不会造成问题。重定向链则会，原因有二：Google 抓取工具最多跟踪 10 跳重定向，更长的链会被报告为重定向错误；而且每一跳都会推迟第一个字节的到达，直接影响核心网页指标（Core Web Vitals）。循环更糟糕，因为页面永远无法访问，会被完全移出索引。请合并重定向链，让第一个网址直接指向最后一个。

            

        

            





        
    
        





    
参考资料与延伸阅读

    



    


    

    

                
            



    
    
    
    

    

    

    
            


    
    

    
    


        
        

            

                

                    
                        
                    
                

                

                    
FreeWebTools AI

                    

                

            

            

                
                
            

        


        
        

            
            

            
            

            
            
        


        
        

            

                
                
            

            

                Powered by free AI models · Full chat →