logo
GeekFormat

Yönlendirme Denetleyici

Yönlendirme Zinciri Kontrolü

301/302/307/308'i atlama atlama kontrol edin, döngüleri, çapraz alan yönlendirmelerini ve HTTPS düşme sorunlarını tespit edin.

Tarayıcıya bir web adresi girdiğinizde, perde arkasında görünmeyen bir yönlendirme zinciri meydana gelebilir: HTTP→HTTPS, www'suz→www'lu, eski etki alanı→yeni etki alanı, kısa bağlantı→uzun bağlantı… Her yönlendirme atlaması zaman harcar, SEO sıralamasını etkiler ve hatta HTTPS'yi fark edilmeden HTTP'ye düşürebilir. Yönlendirme Zinciri Denetleyici, URL'lerin tam yönlendirme yolunu sunucu perspektifinden atlama başına izler, her atlama için durum kodunu (301/302/303/307/308), Location başlığını ve hedef adresi gösterir, yönlendirme döngülerini, etki alanları arası yönlendirmeleri, HTTPS düşüşünü ve zincir kopmalarını otomatik olarak algılar, etki alanı geçişi, HTTPS dağıtımı ve SEO optimizasyonunda gizli yönlendirme sorunlarını belirlemeye yardımcı olur.

İlgili Öneriler

Kullanım senaryoları

  • 域名迁移验证:网站从旧域名切换到新域名后,逐跳确认旧URL是否正确301永久重定向到新地址,避免链式跳转和错误状态码导致流量损失
  • HTTPS部署检查:确认HTTP→HTTPS跳转链路是否为单跳301,检查是否存在HTTP→HTTPS→HTTP的降级回环,验证HSTS配置是否生效
  • 短链接落地页检测:追踪短链接(t.cn/bit.ly等)、营销UTM链接或社交分享链接的完整跳转路径,确认最终落地页是否为预期地址,排查中间跳转是否插入追踪参数或恶意跳转
  • www与非www规范化:检查www域名和根域名是否正确互相301跳转到规范化版本,避免双轨运行导致的重复内容SEO问题
  • 循环重定向排查:浏览器报ERR_TOO_MANY_REDIRECTS错误时,用工具精确定位循环发生的节点,区分是Nginx/Apache配置错误、CDN规则冲突还是WordPress插件导致的循环
  • CDN与反向代理调试:排查Cloudflare、阿里云CDN、Nginx反向代理等多层架构中的重定向冲突,识别CDN规则与源站规则互相跳转的问题
  • SEO健康度审计:定期检查网站核心页面的重定向链长度,评估多跳跳转对PageRank传递效率的影响,优化过长的跳转链路
  • 跨域跳转风险评估:检测登录跳转、OAuth回调、支付跳转等涉及跨域重定向的场景,确认Cookie和Session是否在跨域过程中正确传递
  • 负载均衡与多活验证:检查多活数据中心、GSLB全局负载均衡场景下的重定向策略,确认不同地区用户被正确跳转到最近的可用节点
  • 重定向缓存调试:验证301永久重定向和302临时重定向的Cache-Control和Expires头设置,排查浏览器缓存旧重定向规则导致的异常访问

Özellikler

  • 逐跳完整追踪:以服务器视角跟随每一跳重定向,依次展示原始URL、每跳状态码、状态文本、Location响应头和完整跳转路径,不遗漏任何中间节点
  • 全状态码支持:覆盖301 Moved Permanently、302 Found、303 See Other、307 Temporary Redirect、308 Permanent Redirect五种标准重定向状态码,并标注各状态码的语义差异
  • 重定向循环检测:自动识别A→B→A等闭环跳转模式,标记循环发生的具体节点位置和循环长度,精准定位ERR_TOO_MANY_REDIRECTS错误根源
  • 跨域跳转识别:逐跳检测Host/Domain变化,标记跨域跳转节点,提示Cookie丢失风险和CORS预检问题
  • HTTPS降级告警:统计重定向链中HTTP(非HTTPS)节点数量,标记HTTPS→HTTP降级跳转,提示安全风险和SEO负面影响
  • 链路截断保护:设置最大跳转深度限制(20跳),当链路过长时自动截断并标记,避免无限追踪导致的请求超时
  • 跳转统计摘要:提供总跳转次数、最终落地URL、是否检测到循环、是否跨域、HTTP节点数、链路是否截断等关键指标一览
  • SEO影响评估:根据跳转次数、状态码类型、HTTPS覆盖情况自动评估对PageRank传递和Core Web Vitals的影响等级
  • 预设测试URL:内置geekformat.com、github.com、httpbin.org/redirect、短链接服务等常用测试地址,一键填充快速体验
  • 最近查询历史:自动保存最近8条查询记录(存储在浏览器本地),支持一键重复检测,方便对比修复前后效果
  • 诊断建议卡片:针对检测到的循环跳转、跨域跳转、HTTP降级、链路过长等问题,给出具体的修复建议和最佳实践指引
  • 详情与摘要双视图:默认展示链路摘要卡片,展开可查看每一跳的完整请求URL、响应状态、Location目标和HTTPS标记

Nasıl Kullanılır

  1. 在输入框中填入需要检测的URL(必须包含http://或https://协议前缀),或点击预设URL按钮(geekformat.com/github.com/httpbin.org/redirect等)快速填充测试地址
  2. 点击「追踪重定向链」按钮,工具将从服务器端发起请求,逐跳跟随Location响应头记录每一跳的完整信息
  3. 查看顶部跳转摘要卡片:总跳转次数、最终落地URL、是否检测到循环、是否存在跨域跳转、HTTP节点数量、链路是否因跳数过多而截断
  4. 在链路可视化区域查看每一跳的详细信息:序号、请求URL、响应状态码及描述文本、Location响应头中的目标URL、HTTPS安全标记
  5. 关注诊断警告卡片:如果检测到循环跳转(红色)、HTTPS降级(橙色)、跨域跳转(黄色)或链路过长(黄色),工具会在对应位置高亮标注并提供问题说明
  6. 使用SEO影响评估区域查看当前重定向链对PageRank传递效率、页面加载速度和Core Web Vitals的影响等级及优化建议
  7. 检测完成后可从最近查询历史中点击任意记录快速重复检测,对比修复前后的跳转链路变化;也可以将检测结果截图或复制文本用于团队沟通和工单记录

Sık Sorulan Sorular

重定向链超过多少跳算太多?对SEO有什么影响?

Google官方建议重定向链控制在单跳,最多不超过3跳。根据Google Search Central文档,Googlebot通常遵循最多5个重定向跳数后停止追踪,但这并不意味着5跳是安全的。每跳重定向都会增加页面加载延迟(100-300ms/跳)、浪费爬取预算、并可能导致PageRank传递衰减。1跳几乎无SEO影响;2跳可接受但建议优化;3跳以上开始影响LCP和爬取效率;5跳以上存在页面不被收录的风险。使用本工具检测你的核心页面跳转链,确保关键URL(首页、核心产品页、高流量内页)都是单跳直达。

301重定向会伤害SEO吗?PageRank能完整传递吗?

正确使用的301永久重定向不会伤害SEO。Google的Gary Illyes和John Mueller多次确认,301重定向从HTTP域名迁移到HTTPS域名,以及在同一域名内的页面永久迁移,PageRank传递是100%的,没有损失。但需要注意:1) 302临时重定向不传递PageRank(或传递效率极低);2) 重定向链中如果出现noindex、robots.txt屏蔽、4xx/5xx错误,权重传递会中断;3) 跨域301迁移后,需要在Google Search Console提交域名变更通知加速索引迁移;4) 301会被浏览器长期缓存,测试阶段建议先用302验证再改为301。

为什么我的网站自动跳转到HTTP而不是HTTPS?如何修复?

HTTPS→HTTP降级跳转通常由以下原因导致:1) 反向代理/CDN以HTTP回源,源站Nginx/Apache使用$scheme变量获取协议时得到的是http而非https;2) 应用层代码中硬编码了http://前缀的URL;3) WordPress等CMS的Home URL或Site URL设置为http;4) .htaccess中存在旧的HTTP规则残留;5) 第三方服务(CDN/WAF)的SSL/TLS设置为「灵活」模式而非「严格」模式。修复步骤:首先用本工具确定降级发生在哪一跳;CDN设置SSL为「Full (strict)」模式;Nginx中正确处理X-Forwarded-Proto头;WordPress在wp-config.php中添加$_SERVER['HTTPS']='on'; 部署HSTS响应头防止浏览器层面降级;检查所有重定向规则确保目标为https://。

如何修复Nginx中的重定向循环(ERR_TOO_MANY_REDIRECTS)?

Nginx重定向循环90%以上是反向代理/CDN场景下X-Forwarded-Proto头未正确处理导致的。修复方法:1) 确保CDN/负载均衡向后端发送X-Forwarded-Proto头:proxy_set_header X-Forwarded-Proto $scheme; 2) Nginx判断时使用X-Forwarded-Proto而非$scheme来决定是否跳转HTTPS。推荐使用map块:map $http_x_forwarded_proto $is_https { default 0; "https" 1; } server { listen 80; if ($is_https = 0) { return 301 https://$host$request_uri; } } 3) 避免在server块中写rewrite规则无限匹配自身;4) www和非www重定向只在一个server块中配置单向跳转,不要双向配置。

如何修复Apache .htaccess中的重定向循环?

Apache .htaccess循环通常由RewriteRule规则冲突导致。修复步骤:1) 确保RewriteEngine On只出现一次;2) HTTP→HTTPS跳转规则放在所有规则最前面,使用:RewriteCond %{HTTPS} off RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301];3) www/非www规则放在HTTPS跳转之后,且只做单向跳转(非www→www或反之);4) 注意[L]标志的含义是「last」但如果规则修改了URL会重新从第一条开始匹配,可能导致循环,复杂规则考虑使用[END]标志(Apache 2.3.9+);5) 检查是否有多个.htaccess文件(子目录中的.htaccess也会生效);6) 临时将R=301改为R=302测试,避免浏览器缓存干扰。

如何修复Cloudflare导致的重定向循环?

Cloudflare循环最常见的原因是SSL/TLS加密模式设置错误或页面规则冲突:1) 将Cloudflare SSL/TLS模式从「Flexible」改为「Full」或「Full (strict)」——Flexible模式下Cloudflare到源站用HTTP,源站如果配置了HTTPS强制跳转就会循环;2) 检查Cloudflare的「Edge Certificates」中的「Always Use HTTPS」是否开启,不要同时在源站和Cloudflare重复配置HTTPS跳转;3) 检查Page Rules中是否有互相冲突的转发规则;4) 如果使用了Cloudflare WordPress插件,不要同时在插件和Cloudflare中配置HTTPS重定向;5) 检查Forwarding URL规则是否指向了又被Cloudflare重定向的地址。

301、302、307、308重定向有什么区别?应该选哪个?

核心区别在「是否永久」和「是否保留请求方法」两个维度。快速选择指南:对于普通网页GET请求(用户访问页面)——永久迁移用301(域名迁移、HTTPS切换、URL永久变更),临时跳转用302(A/B测试、临时维护、登录跳转);对于POST/PUT/DELETE请求(API调用、表单提交)——永久迁移用308,临时跳转用307,确保请求方法和请求体不丢失;303专门用于POST表单提交后跳转到结果页(强制GET,防止重复提交)。简单记忆:301=永久GET安全,302=临时GET安全,307=临时全方法,308=永久全方法,303=POST后跳结果页。

浏览器会永久缓存301重定向吗?如何清除301缓存?

301永久重定向默认会被浏览器缓存,但缓存时间取决于响应头中的Cache-Control和Expires设置。如果没有显式指定缓存头,不同浏览器的默认缓存行为不同:Chrome通常缓存301重定向数周到数月(甚至直到浏览器重启后仍可能缓存);Firefox默认缓存301但在浏览器重启后可能重新验证;Safari的缓存策略相对保守。清除301缓存的方法:1) Chrome:设置→隐私和安全→清除浏览数据→时间范围选「所有时间」→勾选「缓存的图片和文件」→清除数据;2) 开发者工具(F12)打开时勾选Network面板的「Disable cache」;3) 在URL后添加无意义查询参数(?nocache=1)绕过缓存;4) Chrome开发者可以在chrome://net-internals/#sockets中Flush sockets,或在chrome://net-internals/#dns中Clear host cache;5) 测试阶段使用302临时重定向代替301,确认无误后再改为301。

Meta Refresh和HTTP重定向有什么区别?哪个更好?

Meta Refresh是HTML文档中的<meta>标签实现的重定向(如<meta http-equiv="refresh" content="0;url=https://example.com/new">),在浏览器端解析HTML后执行跳转,而HTTP重定向通过3xx状态码在HTTP协议层面由服务器直接指示跳转。区别对比:1) 速度:HTTP重定向在收到响应头时就开始跳转,Meta Refresh需要等待HTML下载并解析后才跳转,速度更慢;2) SEO:Google通常能识别Meta Refresh并传递权重(如果delay=0),但官方推荐使用HTTP 301/302重定向,因为Meta Refresh是客户端跳转,信号不如服务端重定向明确;3) 延迟:Meta Refresh可以设置延迟时间(如content="5;url=..."表示5秒后跳转),但HTTP重定向没有这个功能;4) 可访问性:W3C不推荐使用Meta Refresh,因为屏幕阅读器等辅助技术处理不佳,也可能使用户困惑;5) 后退按钮:Meta Refresh在某些浏览器中可能破坏后退按钮行为。结论:始终优先使用HTTP 301/302/307/308重定向,避免使用Meta Refresh,除非你无法控制服务器配置(如托管在静态页面平台无法配置服务端规则)。

重定向会影响Core Web Vitals中的LCP吗?

会,且影响非常大。重定向发生在浏览器获取HTML文档之前,这意味着每跳重定向都会推迟HTML文档的开始下载时间。LCP(Largest Contentful Paint,最大内容绘制)的计算起点是导航开始时间,而浏览器必须在获得最终HTML后才能开始解析DOM、加载CSS和渲染LCP元素。假设每跳重定向增加150ms网络延迟(DNS+TCP+TLS+请求响应),3跳重定向就会让LCP至少增加450ms,这足以将LCP从「良好」(≤2.5s)推到「需要改进」(2.5-4s)区间。Google的Core Web Vitals文档明确将「避免多次重定向」作为优化LCP的关键建议之一。最佳实践:确保核心页面零重定向(直接链接最终URL),HTTP→HTTPS和www规范化这类必要重定向控制在单跳。

如何检查一个短链接最终跳转到哪里?

短链接(t.cn、bit.ly、dwz.cn、url.cn等)通常通过1-3跳重定向到达最终URL,中间可能包含UTM追踪参数、设备检测跳转、地域跳转等。使用本工具可以:1) 输入短链接URL(包含http://或https://);2) 点击追踪查看每一跳的完整路径;3) 查看最终落地URL、跳转次数、状态码类型;4) 检查中间跳转是否有HTTP降级或异常跨域。注意:部分短链接根据User-Agent或IP地域返回不同的最终目标,本工具使用服务器IP请求,可能与你浏览器直接访问看到的结果略有差异(尤其是海外短链接服务)。对于微信/QQ的url.cn短链接,可能需要在微信环境内才能正确跳转到目标页。

HTTPS强制跳转用301还是302?需要加HSTS吗?

HTTPS强制跳转应该使用301永久重定向,因为从HTTP到HTTPS是永久性的变更,不是临时跳转。配置301后还应该部署HSTS响应头。完整的HTTPS强制方案分三个阶段:1) 第一阶段(测试期):先配置HTTP→HTTPS 301重定向,不启用HSTS,观察1-2周确认所有资源和子域名都正常工作;2) 第二阶段(稳定期):添加Strict-Transport-Security响应头,初始max-age设为较短时间(如max-age=300即5分钟),逐步增加到max-age=31536000(1年);3) 第三阶段(Preload):确认所有子域名都支持HTTPS后,添加includeSubDomains和preload指令,然后提交到HSTS Preload List(hstspreload.org),使浏览器内置你的域名HSTS策略,消除首次访问的HTTP窗口。注意HSTS一旦在浏览器中缓存,在max-age到期前无法通过服务器端撤销,所以务必充分测试。

JavaScript的window.location跳转和HTTP重定向有什么区别?

JavaScript跳转(如window.location.href='https://example.com')与HTTP 3xx重定向有本质区别:1) 执行层级:HTTP重定向在协议层由服务器返回状态码,浏览器在收到响应头时立即跳转;JS跳转需要HTML下载、JS解析执行后才跳转,速度更慢;2) SEO:搜索引擎爬虫能正确识别并跟踪HTTP 301/302重定向传递权重,但JS跳转的SEO效果取决于爬虫是否执行JS以及执行时机,信号弱且不稳定;3) 中间环节:JS跳转前页面已经开始加载(可能出现白屏或部分内容闪烁),HTTP重定向用户直接到达目标页,体验更流畅;4) 可靠性:JS可能被浏览器、插件或Content Security Policy阻止,HTTP重定向由浏览器核心处理,可靠性最高。结论:需要永久/临时跳转URL时,始终使用服务端HTTP 301/302重定向,JS跳转仅用于交互逻辑中的页面导航(如表单验证后跳转、按钮点击跳转等)。

重定向链会导致A/B测试结果不准确吗?

会的,重定向链对A/B测试有多方面影响:1) 如果A/B测试通过重定向实现(50%用户302到版本A,50%到版本B),重定向延迟会让两个版本的页面加载速度不同,速度本身可能影响转化率(速度快的版本天然转化率高),导致测试偏差;2) 重定向过程中可能丢失UTM参数或来源标记,导致归因数据不准确;3) 302重定向如果持续时间过长,Google可能自行判断为301传递权重,影响测试页面的SEO;4) 多跳重定向中如果某跳设置了Cookie,可能影响用户分组逻辑。建议A/B测试使用服务端渲染分流或客户端JS分流(如Google Optimize、Optimizely),避免使用重定向分流。如果必须用重定向(如测试完全不同的URL路径),使用302(非301)并确保单跳直达,测试结束后及时移除重定向。

如何批量检查整个网站的重定向链?

批量检查网站重定向链需要结合爬虫工具:1) 使用Screaming Frog SEO Spider等爬虫工具爬取整个网站,在Redirect Chains报告中查看所有重定向URL和链长度;2) 使用Ahrefs、Semrush或Sitebulb等SEO工具的站点审计功能,它们会自动检测重定向链和循环;3) 对于核心页面列表,可以编写脚本调用本工具的后端API批量检测;4) 在Google Search Console的「页面索引」报告中查看「重定向错误」和「重定向链过长」的提示;5) 使用Chrome DevTools的Lighthouse审计,Performance部分会标记重定向问题。建议优先检查:首页、主要导航页、高流量着陆页、最近迁移/改版的页面、HTTPS切换后所有HTTP URL、旧域名下的所有URL。

术语表

重定向(Redirect)
服务器通过返回3xx状态码和Location响应头,指示客户端自动访问另一个URL的机制。重定向对用户通常透明,浏览器会自动跟随跳转。
301 Moved Permanently
永久重定向状态码。表示资源已永久移动到新位置,搜索引擎会将旧URL的PageRank传递给新URL,浏览器会长期缓存此重定向。GET请求场景下推荐用于域名迁移、HTTPS切换等永久变更。
302 Found
临时重定向状态码(原称Moved Temporarily)。表示资源暂时位于其他位置,搜索引擎不会转移权重,浏览器不长期缓存。注意:POST请求收到302后多数浏览器会转为GET请求重定向,可能丢失请求体。
303 See Other
查看其他位置状态码。通常用于POST表单提交后的结果页面跳转,明确要求客户端以GET方式请求新URL,防止表单重复提交。303响应不应该被缓存。
307 Temporary Redirect
临时重定向状态码(HTTP/1.1引入)。语义与302相同,但严格要求保留请求方法和请求体——POST请求收到307后必须仍然以POST方式请求新URL,不会丢失表单数据。适用于API和表单场景的临时跳转。
308 Permanent Redirect
永久重定向状态码(RFC 7538定义)。语义与301相同,但严格要求保留请求方法和请求体——POST请求收到308后仍然以POST方式重定向。是301的「方法安全」版本,现代浏览器已完全支持。
Location头
HTTP响应头字段,用于在3xx重定向响应中指定目标URL。可以是绝对URL(推荐)或相对URL,客户端收到后自动向该URL发起新请求。Location头中的非ASCII字符必须进行URL编码。
重定向链(Redirect Chain)
从初始URL到最终落地URL之间经过的一系列连续重定向。例如A→B→C→D形成一条3跳的重定向链。过长的重定向链会拖慢加载速度、损耗SEO权重,建议控制在单跳、最多不超过3跳。
重定向循环(Redirect Loop)
重定向链中某个URL重复出现,形成无限跳转闭环(如A→B→A)。浏览器在达到最大跳转次数(通常20次)后会显示ERR_TOO_MANY_REDIRECTS错误。常见原因包括HTTP↔HTTPS互跳、www↔非www互跳和反向代理协议丢失。
域名迁移(Domain Migration)
网站从一个域名永久切换到另一个域名的过程,如品牌更换域名、公司收购合并。迁移时需要将旧域名的所有URL通过301永久重定向到新域名对应页面,并在Google Search Console中提交域名变更通知。
URL规范化(URL Canonicalization)
将同一内容的多个URL变体(www/非www、带/不带尾部斜杠、HTTP/HTTPS、大小写差异)统一到唯一标准URL的过程,通常通过301重定向实现。规范化避免重复内容问题,集中SEO权重。
HTTPS强制跳转
将所有HTTP(80端口)请求通过301重定向到HTTPS(443端口)的配置,是部署SSL/TLS证书后的必要步骤。通常配合HSTS响应头使用,消除首次访问的HTTP明文窗口。
HSTS
HTTP Strict Transport Security(严格传输安全),通过Strict-Transport-Security响应头告诉浏览器在指定时间内只能通过HTTPS访问该域名,浏览器内部自动将HTTP升级为HTTPS,无需服务器重定向。有效防御SSL剥离攻击。
短链接(Short URL)
将长URL转换为短URL的服务(如bit.ly、t.cn),访问时通过301/302重定向跳转到原始URL。短链接背后经常隐藏多跳跳转链,可能包含追踪参数或在特定条件下跳转到不同目标。
PageRank
Google创始人Larry Page和Sergey Brin发明的网页排名算法,通过链接关系评估页面权威性。301永久重定向会将旧URL的PageRank传递给新URL,而302临时重定向通常不传递或极少传递。
Core Web Vitals
Google定义的核心网页体验指标,包括LCP(最大内容绘制,衡量加载性能,良好标准≤2.5s)、FID/INP(交互响应性,良好标准≤100ms/200ms)和CLS(视觉稳定性,良好标准≤0.1)。重定向链会延迟HTML下载,直接恶化LCP指标。
跨域重定向(Cross-origin Redirect)
重定向目标URL与原始URL的域名不同(包括完全不同域名或不同子域名)。跨域重定向受同源策略限制,可能导致Cookie不发送、第三方Cookie被拦截、CORS预检失败等问题。
链路截断(Chain Truncation)
当重定向链的跳数超过工具或浏览器设置的最大深度限制(本工具为20跳,Chrome为20跳)时,追踪器停止跟随后续重定向并标记链路被截断。链路截断通常暗示存在无限循环或异常复杂的重定向配置。

HTTP重定向状态码完整对照表

301Moved Permanently是(永久)可能改变(POST→GET)域名迁移、HTTPS切换、www/非www规范化、URL永久变更
302Found否(临时)可能改变(POST→GET)临时维护页、登录跳转、A/B测试、短期活动页
303See Other否(临时)是(强制GET)POST表单提交后跳转到结果页,防止重复提交
307Temporary Redirect否(临时)否(严格保留原方法)API临时重定向、需要保留POST数据的临时跳转
308Permanent Redirect是(永久)否(严格保留原方法)RESTful API永久迁移、需要保留PUT/DELETE方法的永久重定向

重定向链对SEO影响对照表

0跳(直接到达)无影响,最佳状态无额外延迟保持现状,内部链接直接指向最终URL
1跳PageRank正常传递,SEO影响可忽略增加约100-300ms延迟(一次往返)可接受,HTTP→HTTPS和域名规范化的常见跳数
2跳权重传递可能有轻微衰减,爬虫可正常跟踪增加约200-600ms延迟建议优化为单跳,检查内部链接是否指向了中间跳转URL
3跳权重传递效率下降,部分爬虫可能放弃追踪增加约300-900ms延迟,LCP可能受影响必须优化,合并重定向规则直接到最终URL
4-5跳PageRank明显衰减,收录可能受影响,爬取预算浪费增加500ms-1.5s延迟,LCP大概率超标紧急修复,检查CDN/源站/应用多层重定向叠加
6跳以上严重风险,搜索引擎可能停止追踪导致页面脱收录延迟超过1秒以上,用户体验极差立即排查循环或配置错误,重构重定向规则
循环(ERR_TOO_MANY_REDIRECTS)页面完全无法访问,搜索引擎将其从索引中移除页面无法加载,浏览器显示错误最高优先级修复,使用本工具定位循环节点

常见重定向配置错误及修复方案

ERR_TOO_MANY_REDIRECTS循环错误,HTTP↔HTTPS反复跳转CDN/负载均衡以HTTP回源,源站未正确处理X-Forwarded-Proto头,始终重定向到HTTPSNginx配置中添加:set $forwarded_scheme $http_x_forwarded_proto; if ($forwarded_scheme != "https") { return 301 https://$host$request_uri; } 或使用$scheme变量配合proxy_set_header X-Forwarded-Proto配置
www和非www互相跳转形成循环CDN层配置www→非www跳转,源站Nginx又配置非www→www跳转,规则冲突选择一个规范化版本(推荐非www或www,保持一致),只在一层(CDN或源站)配置重定向,删除其他层的对应规则
重定向链经过4-5跳才到达最终页面HTTP→HTTPS跳→非www→www跳→加尾斜杠跳→旧路径跳新路径,多层规则叠加合并重定向规则,直接从初始URL一步跳到最终URL。Nginx中使用return指令一次性跳转到完整最终地址
HTTPS站点重定向链中出现HTTP节点(降级)服务器配置中硬编码了http://前缀的重定向目标,或应用生成重定向URL时未识别当前为HTTPS配置应用信任反向代理,正确读取X-Forwarded-Proto;Nginx中使用https://绝对URL或$scheme变量(前提是proxy正确设置了scheme);部署HSTS
301重定向修改后浏览器仍然跳到旧地址浏览器长期缓存301永久重定向规则,F5刷新无效测试阶段使用302临时重定向确认无误后再改为301;清除浏览器缓存(Chrome:设置→隐私→清除浏览数据→缓存的图片和文件);使用DevTools的Disable cache选项
POST请求重定向后表单数据丢失使用了301或302重定向,浏览器自动将POST转为GET请求,请求体被丢弃对于POST/PUT/DELETE等非GET请求,改用307(临时)或308(永久)重定向,严格保留请求方法和请求体
重定向后URL出现%2520等双重编码字符URL参数已经过一次URL编码,服务器重定向时又对其进行了第二次编码检查重定向逻辑,确保URL只编码一次;Nginx中使用$request_uri(原始URI,未解码)而非$uri(已解码)
AJAX/fetch请求跨域重定向后报CORS错误跨域重定向的目标服务器未配置CORS响应头(Access-Control-Allow-Origin等)确保重定向链中每一跳的服务器都正确配置CORS头;或避免在AJAX请求中使用跨域重定向,改为前端获取目标URL后直接请求

Troubleshooting