清理旧域名时"断错了一根线"：托管面板里的显示名，和它实际承载的网站不是一回事
公司早年换过几拨外包开发商，账上积攒了一批来历各异的域名和托管套餐。这天做的是一件很正常的事：清理这些遗留资产，把确认废弃的域名和套餐停掉，省下续费。
然后官网就下线了。
显示名骗了人
追查发现，托管商账户里那个被停掉的 cPanel Hosting Gold 套餐，显示名挂的是一个早就不用的旧域名——从名字看，它属于”可以放心停”的那一类。但实际打开看，这个 cPanel 实例里装的是现役官网的全部站点文件：主域名的流量一直重定向到这个套餐承载的站点上。
套餐过期 → 托管商自动停用 → 官网 404，顺带这个 cPanel 上的企业邮箱账号也被一并停用。向托管商开了加急工单请求生成续费账单、恢复套餐，但恢复要走流程，官网不能就这么裸奔着等。
没有源站，怎么让域名先”活”起来
这时的处境是：源站彻底没了（托管被停用），但域名的 DNS 在 Cloudflare 上。这就够了——Cloudflare 的 Redirect Rules 在边缘节点上执行，根本不需要一个能正常响应的源站。
临时方案：把主域名的流量 302 重定向到海外分部的官网，至少让客户搜到公司时看到的不是错误页。
第一步：确保 DNS 记录是 Proxied（橙色云）。 重定向规则只对经过 Cloudflare 网络的流量生效。给根域名（@）和 www 各建一条 A 记录，指向 192.0.2.1——这是一个专门保留给文档用途的假 IP（TEST-NET-1 段），它不需要真的能连通，作用只是让 Cloudflare 有一条”可代理”的记录，把流量收进自己的边缘网络。
第二步：建 Redirect Rule。 Rules → Redirect Rules → Create rule，匹配条件用 Hostname equals 根域名 OR www，动作是 Static URL 重定向到分部网站。
第三步（关键）：状态码选 302，不要选 301。 301 是永久重定向，会被访客的浏览器狠狠缓存——等源站恢复、规则删掉之后，老访客的浏览器还会继续往分部网站跳，而且这个缓存你没有任何办法从远端清除。302 是临时重定向，浏览器不缓存，源站一恢复、规则一删，流量立刻回来。
规则部署后约 30 秒全球生效，用无痕窗口验证（避开本地缓存）
规则 Deploy 之后差不多半分钟就全球生效。用无痕窗口验证两个域名都正常跳转，官网从”错误页”变成”临时指向分部站点”，为托管恢复争取到了时间。
教训
- 托管面板里的”显示名”只是个标签，不代表这个套餐实际在服务什么——清理任何订阅之前，先回答”停掉它，到底哪些东西会消失”：进 cPanel 看站点文件、查 DNS 上有哪些记录指向它、确认有没有邮箱账号挂在上面；
- Cloudflare 的边缘重定向不需要源站，是官网全挂时的标准急救包——假 IP 192.0.2.1 + Proxied + Redirect Rule，几分钟就能把域名从错误页救成”指向别处”；
- 应急重定向永远用 302——301 会被浏览器永久缓存，事后收不回来；
- 续费日历要自己维护，不能全指望托管商的提醒邮件——尤其是显示名和实际用途对不上的老套餐，它们的续费提醒最容易被当成”废弃资产的噪音”忽略掉。