阅读约 12 分钟
如何检测 URL 重定向(网址跳转)并读懂重定向链
用 TrueURL、curl 和浏览器开发者工具(DevTools)逐步检测 URL 重定向,读懂重定向链的每一跳,并修复重定向循环、过长的重定向链以及 301 与 302 混用等问题。
阅读全文免费重定向工具
并非所有重定向都通过 HTTP 状态码实现。TrueURL 会读取重定向链中每个页面的 HTML,找出 meta refresh 标签和 JavaScript 重定向,以及它们的目标 URL 和延迟时间。
按 Enter 开始检测
Cloudflare 边缘网络始终会验证证书,因此该选项无法跳过证书验证。证书问题会在检测结果中报告。
随第一个请求发送,最大 16 KB。除非设置了 Content-Type 请求头,否则 JSON 请求体以 application/json 发送,其他内容以表单形式发送。
可设为 1~50。浏览器会在 20 跳后停止。
网站可能会把手机、搜索引擎爬虫和链接预览爬虫重定向到不同的地址。
随重定向链中的每个请求一起发送。
未添加自定义请求头。
填写值后才会发送此请求头。请求头的值不会保存。
跟踪 HTML 页面中的 <meta http-equiv="refresh"> 标签和 Refresh 响应头。
跟踪页面脚本中简单、无条件的重定向,例如 location.href = "…"。
设置会保存在此浏览器中,但 Cookie、请求头的值和 POST 请求体始终不会保存。
meta refresh(HTML 页面自动刷新)是一种 HTML 标签,它会让浏览器在延迟若干秒后加载另一个 URL:
<meta http-equiv="refresh" content="0; url=https://example.com/new-page">
延迟为 0 时,它的效果与普通重定向相同。延迟更长时,访问者会先看到页面本身,就像过去常见的“正在跳转,请稍候”页面那样。JavaScript 重定向则通过 location.href = '...' 或 location.replace('...') 之类的代码完成同样的工作。两者都属于客户端重定向:服务器返回 200 OK,由浏览器执行重定向。
对于每个状态码为 2xx 的 HTML 响应,TrueURL 会扫描页面的前 256 KB,查找 meta refresh 标签以及简单、无条件的 JavaScript 重定向。作用与 meta refresh 相同的 Refresh HTTP 响应头也能被检测到。找到后,它会显示相应的标签或脚本片段、解析后的目标 URL 和延迟时间,把这一跳标记为 meta refresh 或 JavaScript,并从目标地址继续跟踪重定向链。只是重新加载同一页面的刷新不属于重定向,会被忽略。
可以在高级设置中关闭对任一类型的跟踪,以便查看页面本身。TrueURL 不会执行 JavaScript:它读取页面中的脚本,识别那些在页面加载时必定执行、指向固定 URL 的重定向,无论是立即执行,还是位于顶层 setTimeout 中。依赖某种条件(例如点击、同意选择或屏幕尺寸)的重定向,或者在代码中拼接目标 URL 的重定向,都无法被检测到。请使用 GET 而不是 HEAD,因为 HEAD 响应没有可供扫描的响应体。
Google 建议,只要能配置服务器端重定向就尽量使用,把 meta refresh 作为后备方案,例如用于无法发送 301 的静态托管。
定时重定向会带来无障碍问题:使用屏幕阅读器的用户,或者只是阅读速度较慢的用户,会在页面意外切换时找不到自己读到了哪里。WCAG 将定时 meta refresh 列为一种失败情形(F40),而延迟为 0 的即时重定向则是一种公认的技术(H76)。
如果必须在 HTML 中进行重定向,请把延迟设为 0,添加指向新 URL 的 canonical 标签,并在页面中放一个指向新 URL 的可见链接,供浏览器不跟随刷新的访问者使用。
阅读约 12 分钟
用 TrueURL、curl 和浏览器开发者工具(DevTools)逐步检测 URL 重定向,读懂重定向链的每一跳,并修复重定向循环、过长的重定向链以及 301 与 302 混用等问题。
阅读全文阅读约 13 分钟
详解每个 3xx 状态码的含义:从是否永久、是否保留请求方法、缓存和 SEO 影响 4 个方面对比 301、302、303、307 和 308 跳转,并附 nginx、Apache 和 PHP 配置示例。
阅读全文Google 将即时 meta refresh(延迟为 0)视为永久重定向,因此实际效果与 301 非常接近。延时刷新则被视为临时重定向。其他爬虫对 meta refresh 的处理可能不那么可靠,所以只要主机托管允许,就请使用服务器端 301。
重定向发生在页面的 HTML 或 JavaScript 中,而不是在 HTTP 响应中。只跟随状态码的工具(例如 curl -L)会停在返回 200 的页面上。TrueURL 会扫描页面内容,并把客户端重定向显示为单独的一跳。
如果目的是重定向,就用 0。任何延迟都会让 Google 将其视为临时重定向,让访问者等待,还会造成无障碍问题。只有当页面必须先显示一条消息时,设置延迟才有意义,而且该页面还应提供一个清晰的“继续”链接。
不能,只能检测页面 HTML 中简单、无条件、目标 URL 固定的重定向,例如 location.href = '...'、window.location = '...' 或 location.replace('...'),包括位于顶层 setTimeout 中的情况。位于外部脚本文件中、带有条件、由用户操作触发或目标 URL 经过计算的重定向,需要真正的浏览器来执行。如果重定向链停在一个您确定会重定向的页面上,原因很可能就在这里。
通常是因为它无法发送 HTTP 重定向,例如使用了不支持重定向规则的静态托管、页面搭建工具或老旧的 CMS。一些短链接服务和点击跟踪工具也会使用 HTML 重定向,以便先运行统计分析脚本,或者控制目标网站看到的来源页(referrer)。
不能。HEAD 响应只有响应头,没有响应体,因此没有可供扫描的 HTML。使用 HEAD 检测时,TrueURL 会发出警告;使用本工具时请选择 GET。