多域名与重定向：把几个域名收成一个入口
手里有两三个域名是常态：一个主域，一个旧域，可能还有个 xxx.net 防抢注。它们最终都要指向同一个入口，否则用户会看到两个内容相同但地址不同的站，搜索引擎也会当成重复内容。读完这篇，你能决定哪个当主域、其余用什么状态码、以及在 Cloudflare 上用什么工具落地。
域名的基本接入见 49-add-domain-to-cloudflare.md；批量 URL 转发的细节见 75-redirects-bulk.md。
1. 先决定域名之间的关系
| 关系 | 例子 | 做法 |
|---|---|---|
| 主域 + 别名 | example.com 与 www.example.com | 选一个当规范域，另一个 301 |
| 品牌保护 | example.com、example.net、example.org | 全部 301 到主域 |
| 业务分域 | shop.example.com 与 blog.example.com | 各自独立，不做互跳 |
| 过渡期旧域 | 改名前的 old-brand.com | 301 到新域对应路径，保留至少一年 |
关键决策只有一个：哪个是规范域（canonical）。所有 SEO 信号、外链、证书、统计都该往它身上集中，其余域名只做搬运。
www 与根域的选择没有对错，选完保持一致就行。Cloudflare 的 Universal SSL 同时覆盖两者，证书不是决策因素。
2. 状态码怎么选
| 状态码 | 语义 | 适用 |
|---|---|---|
| 301 | 永久 | 域名迁移、www 归一、换主域 |
| 302 | 临时 | 活动页、短期维护、A/B 测试 |
| 307 | 临时，保留方法 | 临时跳转且要保留 POST |
| 308 | 永久，保留方法 | 永久迁移且要保留 POST |
差别不只在语义。301 会被浏览器长期缓存，改错了用户端可能几个月都跳不回来；302 不缓存，灵活但每次都要多一次请求。API 场景用 307/308，避免客户端把 POST 降级成 GET。
本机对 github.com 的实测：
https://www.github.com -> 301, Location: https://github.com/
http://github.com -> 301, Location: https://github.com/两条都收敛到同一个规范地址，并且 www 的响应带 HSTS 头：
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload这是"http 到 https、www 到根域"两级归一的标准形态：一次跳转到位，不产生链。
3. Cloudflare 上的三条路径
| 方式 | 适合 | 限制 |
|---|---|---|
| Redirect Rules（单条） | 按 Host、路径、国家等条件跳转 | 规则数量按计划有上限，面板显示当前配额 |
| Bulk Redirects（列表） | 成百上千条 URL 对 URL 的映射 | 用 CSV 维护，适合迁移旧站 |
| Worker | 需要读请求头、算签名、动态拼接目标 | 要写代码，消耗 Workers 额度 |
多数场景用 Redirect Rules 就够：一条规则匹配 www.example.com/*，目标写 https://example.com/$1，状态码 301。Bulk Redirects 适合旧站迁移，把几千条旧路径逐条映射到新路径。
下面这些配置动作本机未执行，没有该域的 Zone 权限。
4. 避免重定向链
链是指 a -> b -> c。每多一跳就多一次往返，移动端感知明显，搜索引擎也会浪费抓取预算。正确做法是让所有非规范地址直接跳到最终地址。
| 错误 | 表现 | 修正 |
|---|---|---|
| 链式跳转 | http://www.a.com 先跳 https://www.a.com 再跳 https://a.com | 一条规则同时处理协议与主机名 |
| 跳到 http | Location: http://... | 目标一律写 https |
| 丢路径 | /old/post-1 跳到首页 | 用 $1 捕获路径 |
| 循环 | a -> b、b -> a | 用 curl -sIL 跟一遍 |
curl -sIL 会跟随跳转并打印每一跳的响应头，是查链最快的手段。
5. 证书与 HSTS 的两个注意点
每个参与跳转的域名都要有能用的证书，否则用户在跳转发生之前就先看到证书警告。多个域接进同一个 Cloudflare 账号后，每个 Zone 各自签发证书，不用单独买。
HSTS 的 preload 一旦提交，浏览器会强制这些域走 https，且无法通过普通方式撤销。给还在调试的域名加 preload 会把自己锁死，先只加 max-age，稳定后再考虑 preload 列表。安全头的完整配置见 83-security-headers-hsts.md。
6. 验收清单
curl.exe -sIL "http://www.example.com/any/path" --max-time 20看三件事：跳了几次、每跳的状态码、最终的 Location 是否保留了路径。理想结果是两次以内、全部 301、最终地址是 https://example.com/any/path。
再检查一遍：主域的证书是否有效、www 是否有独立证书、旧域的跳转是否带路径、有没有哪个域名还返回 200 的重复内容。
查询串也要看。跳转目标里的 $1 通常只捕获路径，原始 ?utm_source=... 这类参数会丢，投放链接的统计因此失真。需要保留参数时，在目标里显式拼上查询串，或者用 Worker 把 url.search 一并带到 Location。
常见问题
301 被浏览器缓存了，改错怎么办？
清浏览器缓存只能救自己，救不了访客。可靠的补救是改回 302 过度一段时间，或者直接把旧地址做成能用的页面。这也是上线前要先用 302 验证的原因。
多个域名都要单独接进 Cloudflare 吗？
要。一个 Zone 对应一个域，重定向规则在各自的 Zone 里配。也可以把别名域整域委派到主域账号下统一管理，但仍是一个域一个 Zone。
重定向会不会影响 SEO？
301 会把权重传给目标地址，是标准做法。真正伤排名的是链式跳转、跳到 404、以及两个域同时返回 200 的重复内容。
小结
多域名管理的核心是"一个规范域 + 其余全部 301"，状态码选对、路径带上、一次跳到位，三件事做到就没有遗留问题。
工具选择上不必纠结：规则数量少用 Redirect Rules，成批的旧路径用 Bulk Redirects，需要逻辑判断才上 Worker。真正的风险在 301 的不可撤销性，先用 302 跑通再改 301 是稳妥顺序。DNS 侧的排错方法见 95-dns-troubleshooting-dig.md。
数据来源与检索时间
检索时间 2026-11-10。跳转响应头为本机 curl 实跑。
| 来源 | URL | 对应数据 |
|---|---|---|
| Cloudflare Redirects 概览 | https://developers.cloudflare.com/rules/url-forwarding/ | Single Redirects 与 Bulk Redirects 的能力划分 |
| Single Redirects 设置项 | https://developers.cloudflare.com/rules/url-forwarding/single-redirects/settings/ | 301/302/307/308 状态码、表达式与目标写法 |
| Bulk Redirects | https://developers.cloudflare.com/rules/url-forwarding/bulk-redirects/ | 列表与 CSV 维护方式 |
| RFC 7231 | https://www.rfc-editor.org/rfc/rfc7231 | 301/302/307 的语义与方法保留规则 |
核验说明
- 实查：
https://www.github.com返回301、Location: https://github.com/，并带Strict-Transport-Security: max-age=31536000; includeSubDomains; preload；http://github.com返回301且Location相同。两条均为本机 curl 实测。 - 依据文档：Redirect Rules 与 Bulk Redirects 的能力边界、状态码语义、规则数量上限按计划区分（未逐项核对具体配额数字）。
- 未执行：创建重定向规则、配置 Bulk Redirects 列表、提交 HSTS preload、给多个域签发证书，全部未在账号内操作。文中"链式跳转"的例子是常见形态描述，不是实测到的某个站点。