2026 年重定向软件：按使用场景对比 10 款工具

当域名更换在周五正式生效时，故障往往不会等着工单。到周一，旧的定价页已经返回 404，某条活动链接仍带着上个季度的路径，而印刷传单上的二维码仍指向一个已退役的主机。公开 URL 并没有随着网站一起迁移。有人选了为另一种工作场景构建的重定向软件。

这种混淆很容易发生。品牌短链工具很擅长在链接已经散播到外部之后，替换活动落地页目标。但它并不适合处理退役域名上的每一个被索引 URL。WordPress 插件可以在单个安装中捕捉固定链接的修改，但它无法为你已经不再托管的主机名提供 DNS 响应。边缘规则可以在一次跳转中把整个域名导向新位置，但它无法让营销人员在传单印好之后还继续编辑二维码。

这份清单的划分正是关键。下面十个选项按它们最初为之构建的工作类型分组：活动链接、整站迁移、WordPress 内规则，或自托管控制。对于不适合全站重定向工作的品牌链接平台，我们会特别标注。状态码仍然决定客户端和爬虫接下来会做什么。永久状态码表示长期迁移；临时状态码则不是。只要路径中涉及表单、结账和 API，保留请求方法的那一对状态码就很重要，因为如果一个 POST 在无人察觉的情况下变成了 GET，那就是一次损坏的请求，而不是一个整洁的重定向。

1. RedirHub#

RedirHub 是一种试图把活动链接和迁移映射统一放在你已拥有的域名上的工具。你把 DNS 指向该服务，创建一个从 URL 和一个到 URL，公开主机名仍然归你所有。之后目标地址还可以更改，包括在 301 和 302 之间切换，而无需再次修改 DNS。

这种组合正是大多数综述容易混淆的地方。短链工具拥有营销链接，CDN 拥有基础设施规则，插件拥有 CMS。这里，品牌链接、动态二维码、域名重定向和网站迁移映射共享同一个 Links 页面，并配有自动 HTTPS、管理 API，以及一个供助手驱动检查使用的 MCP 服务器。

在实际迁移中能站得住脚的要点#

在迁移工作中保持路径和查询参数转发开启，这样 old-brand.com/pricing?utm_source=x 就能连同标签一起落到新主机上对应的路径。链路检测会标记本应永久重定向却会隐藏第二跳的情况，因为那样会泄漏权重并增加延迟。随后持续监控会盯住线上重定向，因为上线后才开始返回 404 的目标页，往往是没人提交工单的那种故障。

通过来自 130 个全球 PoP 的 HTTPS 返回重定向结果。无需维护服务器，也没有任何东西需要在请求获得响应前先启动。Pro 方案可添加专用集群附加组件。

方案、限制和细则#

Core 包含 25 个域名 和 2,500 个托管链接，Pro 包含 250 个域名 和 10,000 个托管链接，外加高级分析、监控和告警、高级路由与控制，以及带筛选器的工作区审计日志、五周活动热力图和 CSV 导出。Pro 附带 14 天免费试用；Core 可立即开始。框架重定向会在地址栏保留你的域名的同时，在 iframe 中加载目标页面。根域名及其自动包含的 www 只占用一个域名槽位，而基础的整域重定向不消耗托管链接容量，因此停放域名会占用一个域名槽位，但不占用托管链接容量。企业版容量按合同确定。

实用规则： 如果公开 URL 会被打印、发送邮件或被索引，就把它放在你可控的主机名上，然后只更改目标地址。

迁移完成后，请保留永久重定向。外部反向链接、书签和已索引的 URL 可能会持续引流多年，过早移除重定向会让一次干净的迁移逐渐退化成 404。启动前确实需要域名和 DNS 访问权限。如果任务只是一次性的社交媒体帖子，使用供应商的短域名，那么这比该任务所需的基础设施多得多。

2. redirect.pizza#

redirect.pizza^[1] 是面向主机名的托管重定向层，不是活动工作室。你把源主机名的 DNS 指向该服务，然后在仪表板中编辑规则。没有需要打补丁的重定向服务器。这种形态非常适合域名整合、品牌主机名，以及路径必须保持可用的迁移场景。

状态菜单与网络的实际行为一致。301（“永久移动”）和 302（“找到”）是较早的一对。308（“永久重定向”）于 2015 年 4 月由 RFC 7538^[2] 标准化，因此永久迁移可以保留原始方法，包括 POST。307 对临时迁移也采用相同方式。URL 永久失效时使用 301 或 308。用于测试、维护窗口或短期活动时使用 302 或 307。修改 API 或结账表单的请求方法，就是“简单”重定向出错的原因。

同时支持按路径的规则和整主机名规则，并提供路径和查询参数转发。API、批量导入导出以及 Terraform 提供程序可满足不想靠点击操作的团队。符合条件的方案提供分析和目标监控。还提供有限的免费层级。

硬性限制在于主机名本身。一旦 DNS 指向这里，这个名称就不能再同时承载现有网站的其余部分。正则表达式和监控取决于方案，而且你需要 DNS 控制权。对于已退役域名的完全切换，这一类别很适合；对于可编辑二维码和团队链接工作区，则不适合。

3. Cloudflare 重定向规则#

如果域名已经通过代理，Cloudflare^[3] 可以在源站被唤醒之前就响应重定向。这才是性能层面的理由，而不是品牌层面的理由。每一次重定向都会带来额外的 HTTP 请求。当它跨越不同源站时，DNS、TCP、TLS，以及往返时间可能会增加 数百到数千毫秒，这就是为什么 迁移性能指南^[4] 会把重定向视为加载时间成本，而不是免费的别名。一个只需一跳即可完成的边缘规则，胜过一个先启动、再认证、再查询数据库的应用规则。

规则，而不是链接产品#

单个重定向支持静态目标和动态模式，包括通配符。批量重定向可处理源 URL 和目标 URL 列表。你可以保留路径后缀和查询字符串。免费套餐包含重定向功能，文档中提到的批量重定向列表容量从 10,000 个 URL 起。更高级的套餐会提高配额。你仍然需要自己管理匹配顺序和这些配额。

这是一套基础设施，而不是品牌短链台面。这里没有活动工作区，没有动态二维码资产，也没有“编辑海报跳转目的地”的工作流。要运行这些产品，域名必须开启代理。如果 Cloudflare 不是你现有的 DNS 和 CDN，仅为了重定向而采用它会是一次很大的变更。想要免费边缘路径、又不想重建其余技术栈的团队，可以按照 如何将 Cloudflare 域名重定向到另一个 URL 操作，并将其与专用重定向主机名进行比较。

把 HTTP 到 HTTPS 以及尾部斜杠的行为统一到这一次跳转中。HTTP、HTTPS、www，再到最终路径的链式跳转，就是你本不想发送出去的三次额外请求。

4. Rebrandly#

Rebrandly^[5]是为人们分享的链接而构建的，而不是为站点地图而构建的。你绑定一个组织域名，发布一个短链接，之后还能更改跳转目标，并查看点击分析。二维码、API、团队工作区和 Webhook 都围绕这个核心展开。企业版套餐增加 SSO 和更严格的控制。免费套餐足以试用品牌链接和二维码。当创建流程需要程序化处理时，也有高流量 API 选项。

当任务变成“处理每一个旧 URL”时，限制就会立刻显现。链接、域名、编辑和分析权限会随套餐等级变化，而这个产品并不是用于网站的通用重定向映射。你不能导入一份已被索引路径的爬取清单，然后就宣称迁移完成。

可编辑链接需要一个所有者#

目的地编辑是营销想要的功能，也是安全团队应该审查的功能。APWG 的 2025 年第二季度趋势报告^[6]记录了二维码滥用传播的速度。Mimecast 在 2025 年第二季度检测到 635,672 个独特的恶意二维码，随后在第三季度达到 716,306 个；截至第三季度的 12 个月内，独特恶意二维码总数超过 300 万 个。APWG 记录到有 1,642 个品牌成为二维码攻击的目标。印刷出来的二维码可以在流通过程中存在多年。你无法召回纸张。

可编辑链接并不会自动更安全。没有审批步骤时，原本用于省去重印成本的同一次编辑，也会成为受信任的钓鱼攻击面。

如果你使用这样的平台，请将其与角色权限限制、变更历史、到期时间和紧急停用开关配套使用。不要把它当作域名切换的权威记录系统。

5. Short.io#

Short.io^[7] 适合需要在多个客户品牌之间管理短链接的代理机构。其卖点包括按品牌设置自定义域名、通过 CSV 或电子表格批量创建、动态二维码，以及用于程序化工作的 API。目的地保持可编辑，因此当落地页发生变化时，公开短链接不会改变。团队角色、点击分析和定向功能覆盖了营销侧需求。

它有免费计划，付费层级会增加容量和控制能力。链接、域名和自动化限制会随方案变化，供应商也会经常调整层级。向客户承诺自定义域名或为大型目录编写脚本之前，请先在 Short.io 的定价页面确认当前免费层限制。免费额度可能在评估与注册之间发生变化，所以要在你确定采用的那一周检查，而不是在你入围的那一个月。

零售和 CPG 团队有理由关注二维码这一半。Hospitality Technology 对 Bitly《2023 年二维码趋势报告》的报道^[8]显示，2023 年零售和消费包装商品中的二维码创建量增长了 88%。包装上的二维码比社交帖文存活更久，而短链接服务可以在印刷后更新这些目的地。它无法保留旧的路径结构，无法转发所有查询参数变体，也无法在平台迁移期间负责主机名级重定向。在这里做活动；迁移请走别的地方。

6. Bitly#

Bitly^[9] 是大家熟悉的活动工具栈：短链接、二维码、分析和团队控制。营销团队已经熟悉这套流程；当替代方案是一张原始 URL 电子表格时，这一点就很有价值。符合条件的方案提供品牌域名。API 和企业级集成支持更高的使用量。企业版还增加了协作、SSO 和更强的安全控制。基础测试有免费计划。

链接和二维码的创建限制因层级而异，且并非所有方案都包含品牌链接。在向客户承诺自定义域名之前，请先阅读对应层级说明。这不是网站重定向映射工具，也不是域名迁移工具。这里没有认真应对“拿 40,000 个已被索引的 URL，并把每一个都指向其替代地址”这种场景的模型。

根据 Bitly 的 2023 年二维码趋势报告^[10]，在 2023 年上半年，全球二维码创建量同比 2022 年同期增长了 41%。这就是为什么这个类别感觉很拥挤。它并不会改变职责边界。就在这里衡量活动。把网站迁到别处。

如果想直接了解迁移平台与短链接服务的差异，请参见 并排的链接平台对比。如果你唯一的需求是一个熟悉的编辑器和基础点击报告，Bitly 是一个合理的默认选择。如果旧域名必须继续解析深层链接，那它就不是正确的类别。

7. Dub#

Dub^[11] 面向希望将点击与转化关联起来，而不仅仅是计数的产品和增长团队。自定义域名、链接创建和二维码是基础功能。分析和转化跟踪则建立在其上。事件 Webhook 仅在付费方案中提供。API 和开发者工具适合已经主要通过代码交付的初创公司。更高级别的方案还增加了工作区控制、权限和 SSO。

免费方案可覆盖少量链接和点击额度，这足以验证归因闭环。付费层级会提高受跟踪事件、链接创建和域名容量。有些方案包含合作伙伴管理功能，如果你只想要重定向，你永远不会用到。这在合作伙伴管理是核心工作的情况下没问题；如果不是，那就只是累赘。

Dub 不能直接替代现有网站上的重定向。你不应该把旧的营销域名指向它，并期望它能完整保留所有旧文章的路径。只要你在签名单前放入一个跳转，延迟就仍然很重要。请从你服务的地区，对公开 URL 进行 与 Dub 的重定向速度测试，并将该跳转与直接请求进行比较。单独跟踪重定向新增耗时。平均值会掩盖偏远用户糟糕的尾部表现。

8. Linkly#

Linkly^[12] 仍然专注于营销人员的使用场景，并提供一些普通短链接服务所不具备的路由技巧。自定义域名、点击分析以及可编辑目标的二维码都是标准配置。在合适的方案中，你还能获得地理位置和设备路由、链接轮换器以及过期功能。API 和自动化集成可将这些链接接入更完整的营销技术栈。

免费方案适合低流量使用。付费层级会提高链接、点击和域名额度。月度上限是为上线前定价所做的权衡，包括当免费方案点击上限被触发时会发生什么，以及超额部分如何计费。轮换器或地理规则适合测试；但如果测试结束后没人负责这条规则，而一半流量仍然落到失败方案上，那它就会变成负担。

这仍然是用于活动重定向的软件。它不会盘点反向链接，不会强制执行从旧路径到最终规范 URL 的单跳映射，也不会放在必须继续提供真实网站服务的主机名前端。代理机构可以在这里为多个客户开展活动，但不应因为短链接看起来整洁，就告诉客户域名迁移已经完成。

上线后你不能再改名的重定向规则，不过是另一条等待出事的链条。

9. 重定向#

在 WordPress 里，Redirection^[13] 是实用型插件。它管理 301 重定向，监控 404，并且在文章或页面的永久链接发生变化时可以自动创建重定向。导入和导出支持 CSV、JSON、Apache 和 Nginx，因此如果你之后迁移站点，规则集也可以脱离插件继续使用。WP-CLI 支持脚本化更新。核心功能是免费的。完成基本工作不需要购买任何付费版本。

这个 404 日志物有所值。2025 年对重定向 URI 的分析——在 MDN 重定向指南^[14] 中有讨论——发现了 62,000 个自定义 404 URI，其中近一半是软 404。一个返回 200 却说“未找到”的页面，在简单检查中不会被识别为明显失败。插件的 404 监控正是你捕捉因永久链接变更而产生遗漏的方式。它不会替你在其他主机上识别软 404。

你已经有的技术栈#

这个插件只在 WordPress 运行的地方运行。它不是托管式域名路由器，不是品牌短域名，也不是动态二维码系统。速度和正常运行时间是主机的问题。把一个缓慢的 PHP 技术栈放在每次访问旧链接前面，并不是存放一个已经退役、且不再承载网站的域名的好地方。将 Redirection 用于 CMS 内的永久链接整理，以及把有限的规则列表导入 WordPress 站点。至于主机名级别的切换，请放到不需要 WordPress 启动的地方。

10. Shlink#

Shlink^[15] 是面向那些拒绝使用供应商命名空间、并愿意自行运行服务的团队的自托管短链接工具。你可以在自己拥有的域名上获得短链接，配有 REST API、CLI，以及官方网页客户端，可管理多个实例。导入和动态重定向规则都是该项目的一部分。Docker 及其他文档化安装方式都是入口。

可控性既是优点也是缺点。由你来选择主机、数据库、TLS、备份和更新窗口。公开 URL 里不会出现别人的短域名。但你也要对宕机负责。没有供应商可用性目标可追责，而漏掉补丁就是你的事故。没有已经在运行内部服务的团队，在一个月内就会感受到这一点。

Shlink 终究还是一个短链接工具。动态规则有帮助，但它并不是为多域名迁移、路径转发、证书自动化以及给营销团队共享审计轨迹而设计的一站式软件。如果需求是“我们的链接、我们的服务器、我们的 API”，它很合适。如果需求是“旧站点必须在周一就能解析，而且我们不想被告警打扰”，那就选一个托管式重定向层吧。

按主要用途、免费选项和迁移适配度比较重定向软件#

功能数量在这里具有误导性。一个品牌链接平台可能列出四十项功能，却仍然无法完成域名迁移；而一个专为重定向打造、功能列表很短的主机则能顺利完成切换。请先按主要用途阅读此表，然后再查看免费版覆盖哪些内容。

迁移列是关键区别点。这些工具中有五个是活动链接平台，在真正涉及整站迁移时就不再适用，而自托管方案则以控制权换取了厂商可靠性。对于涉及路径转发和证书处理的多域切换，可行的候选项是 RedirHub、redirect.pizza、Cloudflare 规则，或者当网站本身已经运行在 WordPress 上时使用 Redirection。

重定向本身响应有多快#

速度是这项比较中唯一一个我们能够用同一种方式衡量大多数工具的指标。RedirHub 重定向速度基准，2026 年 10 月 19 日至 26 日^[16] 会从华盛顿特区、法兰克福和东京测量各提供商重定向 URL 的首次响应时间，然后取该提供商所有 URL 的中位数；在过去 7 天内共测量了 26 个提供商。表格展示了该名单中属于该集合的提供商。Linkly、Redirection 和 Shlink 不在其中，而 Cloudflare 这一行覆盖的是该集合中由 Cloudflare 提供服务的重定向 URL，并非某一种特定规则类型。

测试从 Vercel 函数运行，而不是从 RedirHub 的网络运行，且计时仅覆盖首个响应。通过 重定向速度测试 运行你自己的链接，从相同的三个位置进行比较。

将重定向软件与团队实际要做的工作相匹配#

从你最需要防止的失败开始，再选择类别。把长长的功能列表放在错误的类别里，到了周五切换时依然会失败。

全站迁移 需要路径和查询参数转发、批量导入，以及从旧地址到最终地址的直接映射。将永久重定向长期保留；反向链接、书签和已收录的 URL 会在多年里持续带来流量。在更改 DNS 之前，导出已收录 URL、反向链接和高流量目的地的基线数据，使用 迁移重定向映射器 将旧 URL 与新 URL 配对，并在上线前通过 网站迁移测试。强制只允许一次跳转，并在新规则引入链式跳转、循环、软 404 或目的地偏移时发出警报。

糟糕的链式跳转并不是理论问题。研究人员跟踪了 1100 万个唯一重定向 URI^[17]，最长达 10 次跳转。大多数链很快就停止了：690 万 个在第一次重定向后停止，约 200 万 个在第二次后停止，而 672,306 个继续得更远，只有 0.06% 超过 10 次跳转。停止并不等于解析成功。只有 50% 的 URI 最终成功终止，在 HTTP 到 HTTPS 之类的规范重定向中，只有 48.70% 解析为 2xx 响应。一个链可能在一次跳转后就结束，但仍然落到错误页面上。301 跳转即使落在错误页面、丢失了活动跟踪参数，或对非浏览器客户端表现不同，也仍然是失败的迁移。

活动链接和二维码 需要可编辑的目标、扫码和点击分析，以及批准目标更改的负责人。Short.io、Bitly、Rebrandly、Dub 和 Linkly 都属于这一类。它们都不能替代整个站点的重定向映射。

WordPress 适合 Redirection，但要接受主机性能成本。自托管控制 适合 Shlink，但要接受补丁和备份负担。主机名切换 需要边缘规则或专用重定向服务，而插件无法覆盖这一点。

在上线前，从多个网络对一部分旧 URL 进行端到端测试。跟随多个跳转，记录每个状态码和最终 URL，并区分 DNS、TLS、超时、4xx 和 5xx 失败。确认永久重定向直接命中规范 URL，并确认临时重定向没有被缓存为永久重定向。

上线后，要关注流失的流量和转化，而不是统计已保存的规则。重定向也会随着时间变化，所以要持续监控，不要把切换当作已经结束。

如果你的工作涉及品牌链接、动态二维码，以及你拥有的域名上的迁移规则，这正是我们在 RedirHub 提供的方案。将旧 URL 映射到新 URL，保留路径和查询字符串，并在切换前检查完整的重定向链。先从周一绝不能出问题的链接开始。