最慢的 URL 重定向排名：你的在名单上吗？

第一个字节到达前用了 823 毫秒。这是我们从东京测试的 Cuttly 链接的中位数；在法兰克福为 129 毫秒，在华盛顿特区为 212 毫秒。没人会看到这个数字，但每位访客在真正页面开始加载前都得先等待它。

所以我们进行了测量。使用我们免费的重定向速度测试，我们在 2026 年 10 月 16 日对 11 家服务的 12 个重定向链接进行了计时。下面先是排名，然后逐个介绍每个链接，从最慢到最快，最后说明这一切意味着什么。

Average of the three regional medians, first response only. RedirHub test, Oct 16, 2026.

排名一览#

时间单位为毫秒（1,000 毫秒等于 1 秒），表示访客继续前往之前，重定向完成响应所需的时间；技术名称是首字节时间，即 TTFB。越低越好。redirect.pizza 出现了两次，因为我们测试了它的两个链接；只有第一个参与排名。

下面每个链接下方都有其在速度测试中自己页面的截图，因此你可以打开它并再次运行。我们对每个页面都从三个地区重新运行了一遍，平均值与表格使用的相同。实时数值会在每次运行之间变化，所以每个说明都同时给出重跑结果和排名轮次的数值。对于有多个跳转的链，我们只计时了第一个跳转；额外的跳转会在此基础上进一步增加访客的耗时。

1. Cuttly：388 毫秒#

一个公开的 Cuttly 短链接，指向一个 Google Colab 笔记本。它在三个地区都只返回了一个 301，因此设置本身没有问题。成本在于距离：法兰克福 129 毫秒，华盛顿特区 212 毫秒，东京 823 毫秒，同一个链接的差距达到 6 倍。

One short link, three regions. Median of 5 runs each.

Speed test page for cutt.ly/rgdfBIa, re-run from all three regions on October 16, 2026: 378 ms (ranking round: 388 ms).

打开此测试： cutt.ly/rgdfBIa

2. redirect.pizza：360 毫秒和 51 毫秒#

这是最令人惊讶的结果。我们在同一轮中测试了两个 redirect.pizza 链接。两者都返回了一个带有效证书的 301。URL A，test.redirect.pizza，平均为 360.3 毫秒，东京耗时 735 毫秒。URL B，即官方示例域名，平均为 51.0 毫秒。

Speed test page for test.redirect.pizza, re-run from all three regions on October 16, 2026: 351 ms (ranking round: 360.3 ms).

打开此测试： test.redirect.pizza

Speed test page for redirect-pizza-example.com, re-run from all three regions on October 16, 2026: 50 ms (ranking round: 51 ms).

打开此测试： redirect-pizza-example.com

只选择其中一个会对这项服务讲述错误的故事，因此两者都保留在排名中。

3. urllo（EasyRedir）：302 毫秒#

urllo 自己的旧域名 easyredir.com，会重定向到新品牌。这是网站迁移重定向，而不是客户链接：从华盛顿特区为 179 毫秒、从法兰克福为 428 毫秒、从东京为 298 毫秒。它在到达最终页面前也会经历两次重定向（easyredir.com，然后是 www.easyredir.com，最后是 www.urllo.com），而我们只计时了第一个。

Speed test page for easyredir.com, re-run from all three regions on October 16, 2026: 307 ms (ranking round: 301.7 ms).

The chain behind it: two redirects before the final page.

打开此测试： easyredir.com

4. Rebrandly：264 毫秒#

一个公开的 Rebrandly 短链接。从华盛顿特区很快（29 毫秒），但从法兰克福（298 毫秒）和东京（466 毫秒）要慢得多。它也是测试中最长的链路：经过两个带点击 ID 的免费试用 URL，共三次重定向，最后落到定价页面。

Speed test page for rbnd.ly/booked, re-run from all three regions on October 16, 2026: 258 ms (ranking round: 264.3 ms).

Three redirects before the final page, each one a round trip.

打开此测试：rbnd.ly/booked

5. Bitly：117 毫秒#

Bitly 自己的公开示例链接。第一跳从华盛顿特区很快（26 毫秒），但从法兰克福（119 毫秒）和东京（205 毫秒）要慢一些。这个链路有一个薄弱点：该链接会把访问者发送到一个 http:// 的 YouTube 地址，然后还需要再次重定向到 https://。

Speed test page for bit.ly/bitly, re-run from all three regions on October 16, 2026: 126 ms (ranking round: 116.7 ms).

A hop over plain HTTP: slower, and one step is unencrypted.

打开此测试：bit.ly/bitly

6. Vercel：77 毫秒#

我们在 Vercel 上自己设置的重定向规则，指向我们自己的网站。各地区表现非常均匀（70、73 和 89 毫秒），但每次响应都比下面那些基于边缘网络的服务稍慢一点。

Speed test page for vercel.urlredirectservice.com, re-run from all three regions on October 16, 2026: 42 ms (ranking round: 77.3 ms).

打开此测试：vercel.urlredirectservice.com

7. Short.io：46 毫秒#

一个供哥伦比亚政府机构使用的公开 Short.io 链接。从华盛顿特区和法兰克福看速度非常快（各 15 毫秒），从东京则较慢（109 毫秒）。它使用 302，这是用于临时重定向的；如果迁移是永久性的，速度测试会标记出来。

Speed test page for e436.short.gy/descarga-geoportal-ideam, re-run from all three regions on October 16, 2026: 46 ms (ranking round: 46.3 ms).

A 302 is temporary. For a permanent link, a 301 or 308 passes ranking signals on.

打开此测试： e436.short.gy/descarga-geoportal-ideam

8. Dub：38 毫秒#

Dub 指向其 GitHub 仓库的官方短链接。无论在哪个地点都几乎完全一致（39、35 和 40 毫秒），这就是边缘节点提供的重定向应有的样子。和 Short.io 一样，它返回 302。

Speed test page for d.to/github, re-run from all three regions on October 16, 2026: 42 ms (ranking round: 38 ms).

One hop, but a temporary 302.

打开此测试： d.to/github

9. TinyURL：34 毫秒#

一个指向 YouTube 视频的公开 TinyURL 链接：从华盛顿特区和法兰克福看为 29 毫秒，从东京看为 44 毫秒。一个干净的 301，没有额外跳转。

Speed test page for tinyurl.com/zs9flrt, re-run from all three regions on October 16, 2026: 34 ms (ranking round: 34 ms).

打开此测试： tinyurl.com/zs9flrt

10. Cloudflare：30 毫秒#

我们在 Cloudflare 上设置的一个重定向规则，指向我们自己的网站：30、35 和 25 毫秒。测试中结果最为均衡之一，东京的速度是三者中最快的。

Speed test page for cloudflare.urlredirectservice.com, re-run from all three regions on October 16, 2026: 34 ms (ranking round: 30 ms).

打开此测试：cloudflare.urlredirectservice.com

11. RedirHub：17 毫秒#

我们自己的网站将 redirhub.com 重定向到 www.redirhub.com：15、17 和 18 毫秒。公平地说：这是我们自己的网站，不是客户的域名，而且测试是我们自己运行的。请把它当作一个数据点，并用你自己的链接去验证。

Speed test page for redirhub.com, re-run from all three regions on October 16, 2026: 16 ms (ranking round: 16.7 ms).

打开此测试：redirhub.com

我们学到了什么#

• 访客所在的位置很重要。最快的链接在一个地区表现良好，在另一个地区却很慢：Cuttly 从 129 毫秒变成 823 毫秒，Rebrandly 从 29 毫秒变成 466 毫秒。请从受众所在的地区进行测试，而不只是坐在你的办公桌前测试。

Darker cells are slower. Gap compares each link's slowest region with its fastest.

• 一个链接并不代表整个服务。同一轮测试中，两个 redirect.pizza 链接分别为 360 毫秒和 51 毫秒。这里的每个数字都描述了某个时刻的某一个链接；请测试你自己的链接。
• 跳转次数会累积。Rebrandly 经过了三次重定向，urllo 和 Bitly 经过了两次，而且 Bitly 的跳转还经过了普通 HTTP。请让每个链接直接指向最终的 https:// 页面。
• 使用正确的状态码。Short.io 和 Dub 返回了 302，这适用于临时跳转。对于永远不会改变的链接，301 是更明确的信号。
• 最快的看起来在各地都一样。TinyURL、Cloudflare、Dub 和 RedirHub 在所有三个地区都只相差几毫秒。

有关这对用户和 SEO 为什么重要，请参见重定向速度为何重要。关于重定向链和失效重定向，请参见301 重定向不工作？6 个常见原因及修复方法。

我们如何测试#

The number in every chart is time to first byte of the redirect response.

• 日期：2026 年 10 月 16 日。主要样本在 UTC 09:18 到 09:22 之间测试，RedirHub 在 UTC 09:31 测试，redirect.pizza 的成对 URL 则在 UTC 09:33 一起测试。
• 地区：华盛顿特区、法兰克福和东京。每个地区进行 5 次运行，每次使用新的连接；我们报告中位数。
• 指标：仅统计第一个响应的首字节时间。目标页面不计时，因此目标页面缓慢不算重定向的问题。
• 排名：三个地区中位数的简单平均值，因此每个地区权重相同。
• URL：公开来源中找到的短链接、官方示例、我们自己在 Cloudflare 和 Vercel 上设置的两条重定向规则，以及 redirhub.com。不同服务的目标地址、套餐和设置并不相同。
• 遗漏项：一个 redirection.io 客户部署，在三个区域中的两个返回了 403（被阻止的响应并不比重定向更快），以及自托管方案，例如 NGINX、Apache、Caddy 和 WordPress 插件，其速度取决于所运行的服务器。我们尚未测试注册商域名转发。
• 执行者：RedirHub。这只是特定 URL 的一个简短快照，不是任何品牌的长期性能排名，本身也不能说明 SEO 或转化情况。

30 秒内检查你自己的重定向#

步骤 1. 打开 重定向速度测试并粘贴你的重定向或短链接。

Paste a link, pick a region (or all three) and press Test speed.

步骤 2. 选择全部三个区域，这样你看到的是洲际之间的差距，而不只是离你最近的那个。

步骤 3. 添加第二个 URL 进行比较，例如把你当前的服务商与一个测试重定向进行对比。两者都会以相同次数、交替地、从同一地点运行。

步骤 4. 阅读结果卡片和“需要修复的内容”列表，就像上面的截图那样：多余的跳转、应为 301 却用了 302、经过明文 HTTP 的跳转，或损坏的目标。

步骤 5. 分享结果页面或下载其图片，或者复制 curl 命令，在你自己的机器上重复测试。

更喜欢终端？下面会输出某个 URL 10 次运行的中位数，包含 DNS、连接、TLS 和首字节时间。你的结果会与我们的不同，因为它们取决于你运行命令的位置。

bashfor u in 'https://your-redirect.example/'; do
  for i in $(seq 10); do
    curl -s -o /dev/null --max-redirs 0 --max-time 10 \
      -w '%{time_namelookup} %{time_connect} %{time_appconnect} %{time_starttransfer} %{http_code}\n' "$u"
  done | sort -n -k4 | awk -v u="$u" '{r[NR]=$0} END{split(r[int((NR+1)/2)],m," ");
    printf "%-28s %s  DNS %4.0f  connect %4.0f  TLS %4.0f  first byte %4.0f ms\n", u, m[5], m[1]*1000, (m[2]-m[1])*1000, (m[3]>0?m[3]-m[2]:0)*1000, m[4]*1000}'
done