通配符重定向：它们如何工作以及如何设置

通配符重定向是一条单独的规则，它按模式匹配许多 URL，并将它们发送到其他位置。你无需逐一列出 4000 个旧地址，只要写类似“/blog/ 下的所有内容都跳转到新域名上的相同路径”这样的规则，然后让服务器完成其余工作即可。本指南涵盖人们常混淆的两种含义（DNS 通配符和 HTTP 重定向）、Apache 和 NGINX 的可用模式、会影响排名的 SEO 失误，以及何时使用托管重定向层是更好的选择。

通配符重定向到底是什么#

“通配符”这个词涵盖三种不同的事物，而搜索结果常常把它们混在一起。

通配符（模式）重定向。 带有占位符的规则。这个占位符可以代表“此位置之后的任意字符”（前缀匹配）、“此位置之前的任意字符”（后缀匹配），或在目标中重复使用的捕获片段。典型示例：/old-blog/* 到 /blog/*，或 *.olddomain.com 到 newdomain.com。

通配符 DNS 记录。 左侧标签中带星号的记录，例如 *.example.com，会响应那些没有自己记录的子域查询。AWS 说明了记录名称中星号的工作方式^[1]，而与本文主题相关的关键点是，DNS 只决定由哪台服务器应答。重定向本身是 DNS 解析之后发生的 HTTP 操作，由接收请求的服务器执行。

注册局层面的通配符禁令。 第三种用法涉及顶级域注册局：运营方被禁止为不存在的域名合成响应。这是针对注册局的规则，不是你在自己网站上可以配置的内容。

因此，子域名的完整通配符配置通常需要两层：一条通配符 DNS 记录，让每个子域名都能到达你的服务器；以及一条服务器端规则，决定每个请求应去向何处。

你实际会用到的模式#

大多数现实需求都可归纳为六种模式。

前两行之间的区别才是最重要的。保留路径可以维持一对一的相关性，这正是当新网站与旧网站结构一致时你所需要的。只有在不存在对应页面时，才应该删除路径。

Apache 上的通配符重定向（.htaccess）#

一个常见问题是如何通过 .htaccess 将某个路径之后的所有内容重定向。在 Apache 中，这正是 mod_rewrite 的职责。Apache mod_rewrite 文档^[2] 说明了 RewriteRule 以及与之配合使用的标志，包括用于重定向的 R。

一个保留其余路径的前缀重定向：

<code class="language-apache">RewriteEngine On
RewriteRule ^old-section/(.*)$ /new-section/$1 [R=301,L]
</code>

括号会捕获 old-section/ 之后的所有内容，而 $1 会将其插入目标地址。L 会停止后续规则处理，从而避免意外的重复匹配。

一个保留路径和查询字符串的整站域名重定向：

<code class="language-apache">RewriteEngine On
RewriteCond %{HTTP_HOST} ^(www\.)?old-domain\.com$ [NC]
RewriteRule ^(.*)$ https://new-domain.com/$1 [R=301,L]
</code>

有几件事经常让人困惑：

• 顺序很重要。 规则按从上到下执行。把具体规则放在通用规则之上，否则兜底规则会把所有内容都截获。
• 要转义点号。 正则表达式中未转义的 . 会匹配任意字符。
• 先用 302 测试。 浏览器会积极缓存 301。测试时使用 R=302，等规则正常后再切换为 301。
• 注意服务器。 .htaccess 仅适用于 Apache。如果你的主机运行的是 NGINX，这个文件会被忽略。

NGINX 上的通配符重定向#

NGINX 通过 server_name 处理主机名。NGINX web server guide^[3] 解释说，服务器名称可以是精确名称、开头或结尾带星号的通配符，或者正则表达式；并且在多个匹配时，精确名称会优先于通配符。

将旧域名的所有子域重定向到新域名：

<code class="language-nginx">server {
    listen 80;
    server_name .old-domain.com;
    return 301 https://new-domain.com$request_uri;
}
</code>

前导点既匹配 old-domain.com，也匹配任何子域。$request_uri 会保留原始路径和查询字符串，因此深层链接仍然有效。

对于站点内的路径前缀：

<code class="language-nginx">location ~ ^/old-section/(.*)$ {
    return 301 /new-section/$1;
}
</code>

对于简单重定向，优先使用 return 而不是 rewrite。这样更清晰，执行成本也更低。

选择状态码#

你返回的代码会告诉浏览器和搜索引擎如何处理重定向。

• 301（永久移动）和308（永久重定向）表示资源有了新的永久地址。301 的 MDN 参考^[4]说明了浏览器会自动跟随Location头。
• 302 和 307是临时性的。可将它们用于 A/B 测试、短期促销或维护页面。

Google 的指导意见是，永久重定向有助于整合重复 URL，并表明新 URL 应该被编入索引^[5]，而临时重定向会保留源页面的索引优先级。如果变更是长期的，请使用永久代码。迁移后仍保留在 302 的通配符规则，是一种安静而常见的错误。

RedirHub 流量对永久和临时代码的显示情况#

在 RedirHub 边缘于 2026 年 10 月 22 日提供的重定向请求中，抽取了一个六小时样本，其中 42.2% 来自机器人。在来自用户的请求中，82.3% 收到 301 或 308，1.3% 收到 302 或 307，少于 0.03% 为错误（4xx 或 5xx）。

永久代码占主导地位，因此迁移后通配符规则仍停留在临时代码上的情况，会成为需要审计的异常。这里的占比只统计用户（不含机器人），数据来自重定向访问日志而非调查，并排除了最大型的账户，以避免单一客户造成偏差。在 RedirHub 上，Core、Pro 和 Enterprise 套餐包含使用 301、302、307 和 308 的域名重定向，而通配符子域名重定向仅包含在Pro 和 Enterprise中。

通配符规则容易导致的 SEO 错误#

因为一条规则会影响成千上万的 URL，一条错误的规则会一次性损坏成千上万的页面。

把所有内容都指向首页#

那个偷懒的全匹配规则，/* 到 /，看起来整洁，却会丢失相关性。点击了某个具体指南链接的访客，最终却落到一个通用首页并离开。搜索引擎也可能把大量重定向到无关页面的做法视为软 404。请重定向到最接近的等价页面；只有在不存在等价页面时，才使用更宽泛的上级分类页。

创建重定向链#

比如 http://old.com/page 重定向到 https://old.com/page，后者又重定向到 https://www.old.com/page，再重定向到 https://new.com/page。这就是三次跳转。Google 的文档指出，Googlebot 可以跟随有限次数的跳转，而且更推荐直接重定向^[5]，因为重定向链会增加延迟并减慢索引速度。应当把规则写成第一次响应就直接指向最终 URL，同时一次性修正协议、主机和路径。

忘记查询字符串和片段#

像 UTM 这样的活动参数经常会随旧链接一起出现。请检查你的规则在需要时是否保留了查询字符串。Apache 文档说明，如果重定向到绝对 URL，除非你另行指定，否则会带上原始查询字符串。在 NGINX 中，$request_uri 包含查询字符串，而 $uri 不包含。

混淆 www 和非 www#

选择一个规范主机，并将另一个重定向到它。Google 关于合并重复 URL 的指南^[6]把重定向列为表明你首选版本的强信号，只要保持一致，哪种选择都可以。如果你需要一步步说明，我们关于将非 www 重定向到 www的说明可以帮到你。

过早移除规则#

Google 说，重定向可能会被视为规范化信号，而不是绝对指令；正如其规范化文档^[7]所解释的那样，它仍可能基于其他因素选择不同的规范 URL。实际操作中，在迁移后至少保留永久重定向一年；对于仍然获得外部链接的 URL，则保留更久。

通配符迁移的安全流程#

1. 盘点旧 URL。 从站点地图、服务器日志、分析数据和抓取结果中提取它们。Google 的站点迁移文档^[8]强调，要将每个旧 URL 映射到新的对应位置。
2. 按模式分组。 大多数网站最终都会收敛成少量通配符规则，加上一小部分例外情况。
3. 先写例外。 具体映射应放在通配符规则之上，这样它们才能优先生效。
4. 使用真实 URL 测试。 选取几百个旧 URL 进行抽样，包括最奇怪的那些，并检查状态码、最终目的地和跳转次数。重定向检查工具可以显示单个 URL 的每一次跳转和状态码。
5. 使用永久状态码上线。 测试通过后，从 302 切换为 301。
6. 监控。 在接下来的数周里，关注各部分的抓取错误、404 和流量。用新规则修补缺口，不要匆忙修改旧规则。

Google 还指出，大型网站可以分批迁移，以测试效果；而较小的网站通常一次性整体迁移效果更好。关于域名层面的规划，我们的SEO 域名变更指南涵盖了切换前后需要检查的内容。

服务器文件不再实用的时候#

编辑 .htaccess 或 NGINX 配置，对于你自己控制的一个网站来说还算可以。但在以下情况下就会变得很麻烦：

• 你拥有几十个域名，有些是停放域名，有些是遗留域名，还有些是为某个活动买的。
• 市场团队需要更改跳转目标，但每次修改都需要开发人员和一次部署。
• 你的网站运行在一个无法访问服务器配置的平台上。
• 重定向规则散落在四个地方（CMS、CDN、服务器、注册商），没人知道到底哪一个会生效。

顺序也很重要。正如 MDN 解释的那样^[9]，重定向是由服务器发送带有 Location 标头的 3xx 响应触发的，因此它发生在发送任何页面内容之前。当你无法接触服务器层时，像 JavaScript 或 meta refresh 这样的客户端技巧只能作为最后手段。专门的重定向层可以让你停留在正确的层级，而无需服务器访问权限。

离开服务器层带来的另一个成本是速度，而且这个成本很小：RedirHub 的首字节时间中位数为 18 毫秒，而 26 家服务商中最快的为 11 毫秒，这一测量是在华盛顿特区、法兰克福和东京完成的（RedirHub 重定向速度基准测试，2026 年 10 月 18 日至 25 日^[10]）。

我们的观点#

我们看到的大多数重定向问题并不是语法问题，而是所有权问题。规则通常由当时参与项目的人写下，之后一直留在配置文件里，几年后没人记得为什么 /promo/* 会指向那个地方。然后某个域名过期了，印刷手册或二维码还在把人送到失效页面，而修复它需要开工单。

我们围绕这样一个理念构建了 RedirHub：链接和重定向应该放在你自己的域名上，并由你自己掌控，同时由我们替你处理 SSL，而不是依赖共享短链接服务或一堆服务器文件。我们对通配符规则的建议无论使用哪种工具都一样：写出最窄、能完成任务的匹配模式，直接指向最终 URL，保留一份例外列表，并按计划定期检查这些规则。把重定向视为长期资产，因为互联网上流通的链接会比你当前的网站设计存在更久。

在没有配置文件的情况下管理通配符和域名重定向#

RedirHub 让你在自己的域名上管理域名重定向和品牌链接，并提供 SSL 和分析功能，还可以在不更改印刷材料的情况下修改跳转目标。如果你正在迁移网站，我们的网站迁移服务和用于 SEO 迁移的 301 重定向服务就是为这项工作而设计的。套餐信息公布在定价页面：Core 为每月 49 美元，Pro 为每月 119 美元。Enterprise 采用合同定价。通配符子域名重定向（兜底子域名重定向）仅包含在 Pro 和 Enterprise 中，而域名重定向、路径转发和查询参数转发则包含在 Core、Pro 和 Enterprise 中。

快速参考：通配符 DNS 与通配符重定向#

关于多域名设置，还有一个 DNS 细节：CNAME 不能位于区域顶点（裸域 example.com），而某些提供商提供可在顶点使用的 alias 风格记录。AWS 在其 别名记录与非别名记录的比较^[11] 中对此进行了说明。如果你将裸域指向重定向服务，请检查你的 DNS 提供商在顶点支持哪种记录类型。

示例：带有三个子域名的品牌重塑#

设想一家公司从 acme-tools.com 迁移到 acme.com。它有一个博客、一个位于 help.acme-tools.com 的支持站点，以及几个地区性子域名，例如 uk.acme-tools.com。

一个清晰的方案如下：

1. 在旧域名上添加一条通配 DNS 记录，这样任何子域名，包括没人记得的，也都能到达重定向层。
2. 先创建明确规则：help.acme-tools.com/* 到 support.acme.com/*，以及 uk.acme-tools.com/* 到 acme.com/uk/*。
3. 添加一条通用规则：*.acme-tools.com/* 到 acme.com/*，作为兜底。
4. 添加根域规则：acme-tools.com/* 到 acme.com/*。
5. 所有规则都返回 301，并在目标中使用 HTTPS，这样就只有一次跳转。
6. 从站点地图和分析数据中测试 200 个旧 URL，然后在一周后再次检查。

这些明确规则保护了结构不同的各个部分，而兜底规则会捕获漏网之鱼。如果没有顺序，兜底规则会把支持站点扁平化到主域名的路径下，而那里没有任何内容能匹配。