管理 10,000+ 个 301 重定向：哪些会失效，哪些能扩展

一万条重定向来得比大多数团队预期得更快：一次电商平台迁移、两次品牌重塑、几年活动 URL 的积累。重定向本身很简单。真正发生变化的是规模、修改权限，以及是否还有人能分辨哪些重定向真正重要。

超过 10,000 条重定向后会出什么问题#

• 速度。规则列表会按从上到下的顺序检查。包括那些根本不会重定向的页面请求在内，每次请求都会读取并测试 .htaccess 中一万行 RewriteRule。
• 链式重定向。每次迁移都会在上一次的基础上增加重定向，因此旧 URL 会经过两跳或三跳。Google 的爬虫默认最多会跟随 10 次重定向跳转^[1]，但对于访问者来说，每一跳都是一次完整的往返。
• 所有权。当重定向存放在服务器文件中时，只有工程师可以修改它们，而市场或 SEO 团队则需要等待部署。
• 审计。没有人记得某个重定向为什么存在、它是否仍在带来流量，或者最后一次是谁修改的。

选项对比#

Cloudflare 的批量重定向允许每个账户在 Free 套餐下通过列表实现 10,000 个 URL 重定向，Pro 为 25,000，Business 为 50,000，Enterprise 默认 1,000,000^[2]。单个重定向规则是单独计算的，且每个区域的额度要小得多。

Nginx map 示例#

nginx# /etc/nginx/redirects.map  （每个重定向一行）
# /old-path  /new-path;

map $uri $redirect_to {
    default "";
    include /etc/nginx/redirects.map;
}

server {
    server_name www.example.com;
    if ($redirect_to) {
        return 301 $redirect_to;
    }
}

Apache RewriteMap 示例#

apache# 在虚拟主机配置中，而不是 .htaccess
RewriteEngine On
RewriteMap redirects "dbm:/etc/apache2/redirects.map"
RewriteCond ${redirects:%{REQUEST_URI}} !=""
RewriteRule ^ ${redirects:%{REQUEST_URI}} [R=301,L]

# 从包含“旧 新”配对的文本文件构建 DBM 文件：
# httxt2dbm -i redirects.txt -o redirects.map

选择哪一个#

维护一份大型重定向列表的健康状态#

1. 每次迁移后都要展平链式重定向。 让每个旧 URL 直接指向最终 URL，而不是指向上一个重定向。参见 修复重定向链和循环。
2. 优先使用精确匹配。 对整个已按相同方式迁移的文件夹使用模式规则，其余内容使用精确条目。精确查找速度更快，也更易于阅读。
3. 为每个重定向标记其所属项目。 “2024 年平台迁移”或“春季活动”能告诉下一个接手的人它为何存在。
4. 审查那些无人访问的重定向。 对已迁移页面的重定向至少保留一年。之后，在删除之前，先查看没有访问记录且没有外部链接的重定向；删除仍有链接的重定向会让它变成 404。
5. 记录是谁改了什么。 映射文件的 Git 历史，或重定向工具中的变更历史。它能把一个损坏的重定向从谜团变成两分钟就能修好的问题。
6. 每次导入后测试一个样本。 从列表中检查 50 个旧 URL：每个都应返回一个 301，指向一个返回 200 的页面。

RedirHub 如何处理大型重定向列表#

RedirHub 通过 130 个全球 PoP 响应重定向，因此查找发生在边缘，您的服务器不会参与其中。对于大型列表：

• 从 CSV 导入，并在写入任何内容之前预览将要添加、更新或跳过的项目。重新导入已编辑的导出文件时，只会统计新增链接。
• 容量：Core 包含 2,500 个托管链接，Pro 为 10,000 个，Enterprise 则按合同为百万级规模运营设定。整域重定向不占用托管链接。
• 在 Pro 中，每个链接都会显示是谁在何时更改了它，以及旧值和新值，包括来自 CSV 导入和 API 的更改。
• 可从仪表板或 API 通过预览一次性更改多个目标，或者使用 Terraform 提供程序将列表保存在 Git 中。