逐跳检查 301/302/307/308，识别循环、跨域跳转与 HTTPS 降级问题。
当你在浏览器中输入一个网址时，幕后可能发生了一连串你看不见的跳转：HTTP→HTTPS、非www→www、旧域名→新域名、短链接→长链接……每一跳重定向都在消耗时间、影响SEO排名、甚至可能悄悄将HTTPS降级为HTTP。重定向链检查器以服务器视角逐跳追踪URL的完整跳转路径，展示每一跳的状态码（301/302/303/307/308）、Location头和目标地址，自动检测循环跳转、跨域跳转、HTTPS降级和链路截断等问题，帮助你在域名迁移、HTTPS部署和SEO优化中发现隐藏的重定向隐患。
Google官方建议重定向链控制在单跳，最多不超过3跳。根据Google Search Central文档，Googlebot通常遵循最多5个重定向跳数后停止追踪，但这并不意味着5跳是安全的。每跳重定向都会增加页面加载延迟（100-300ms/跳）、浪费爬取预算、并可能导致PageRank传递衰减。1跳几乎无SEO影响；2跳可接受但建议优化；3跳以上开始影响LCP和爬取效率；5跳以上存在页面不被收录的风险。使用本工具检测你的核心页面跳转链，确保关键URL（首页、核心产品页、高流量内页）都是单跳直达。
正确使用的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。
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重定向循环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循环通常由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循环最常见的原因是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重定向的地址。
核心区别在「是否永久」和「是否保留请求方法」两个维度。快速选择指南：对于普通网页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永久重定向默认会被浏览器缓存，但缓存时间取决于响应头中的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是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，除非你无法控制服务器配置（如托管在静态页面平台无法配置服务端规则）。
会，且影响非常大。重定向发生在浏览器获取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永久重定向，因为从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.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测试有多方面影响：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。
301 | Moved Permanently | 是（永久） | 可能改变（POST→GET） | 域名迁移、HTTPS切换、www/非www规范化、URL永久变更 |
302 | Found | 否（临时） | 可能改变（POST→GET） | 临时维护页、登录跳转、A/B测试、短期活动页 |
303 | See Other | 否（临时） | 是（强制GET） | POST表单提交后跳转到结果页，防止重复提交 |
307 | Temporary Redirect | 否（临时） | 否（严格保留原方法） | API临时重定向、需要保留POST数据的临时跳转 |
308 | Permanent Redirect | 是（永久） | 否（严格保留原方法） | RESTful API永久迁移、需要保留PUT/DELETE方法的永久重定向 |
| 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头，始终重定向到HTTPS | Nginx配置中添加：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后直接请求 |
