换主机商：网站由我们免费搬

迁移的真实顺序

迁移很少败在技术上，多半败在顺序上。切换之后才去调低 TTL，邮箱还没建好就改了 MX，日志还没看过就退掉了旧合同——每一次这样的次序颠倒，都要花掉半天。下面是完整的顺序，从第一次盘点到最后的退订。

这里按天标注的节点，适用于一个普通的网站或服务器。旺季中的网店，或者几十个邮箱的规模，需要把这些步骤拉长，而不是跳过其中任何一步。

1. D-7 — 盘点真正在跑的东西。有哪些站点和域名，正在用的 PHP 版本，数据库及其引擎，邮箱及其体积，计划任务，证书及到期日期，以及所有知道您当前 IP 地址的第三方（支付网关、SMTP 中继、webhook）。最后收尾核对时依据的是这张清单，不是您的记忆。
2. D-7 — 按真实用量选目标配置，而不是照着您今天在付钱的那个套餐。量一下实际占用的磁盘空间、数据库大小、真正吃掉的内存。一个 6 GB 就装得下的网站，不需要 200 GB 的套餐，只因为旧套餐标的是这个数。
3. D-5 — 开通新托管并把副本建起来。文件和数据库先完整搬一遍，对外什么都不变。这份副本不必精确到秒：它的作用是证明程序能跑起来。
4. D-3 — 冻结旧服务器上的改动。在切换之前不再发文章、不再更新插件、不再改主题。在这个时间点之后写进去的东西，都得手工再同步一次。
5. D-2 — 把要变更的记录的 TTL 调低到 300 秒。这一步要在切换至少 48 小时之前做，原因见下面的 DNS 一节。这是最常被拖晚的一步，也是唯一补不回来的一步。
6. D-1 — 用真实域名测试这份副本，同时不碰公开 DNS：改一下自己电脑上的 hosts 文件，把域名指向新的 IP 地址。您这时看到的，正是访客将会看到的，包括绝对链接和各种跳转。
7. D-1 — 把目标 DNS 区域准备好但不发布。把要设置的 A、AAAA、MX、SPF、DKIM、DMARC 和 CAA 记录的准确取值写下来。提前写好，就不必在切换当天现编——那时网站已经搬到一半了。
8. 切换日 — 同步增量。第二遍复制只搬 D-5 之后有变化的部分，再用一份新导出的数据库替换之前那份。真正的不可用窗口，就由这短短的第二遍决定。
9. 切换日 — 发布新的 DNS 记录。由于两天前就把 TTL 设成了 300 秒，对大多数访客而言切换在几分钟内生效，而不是二十四小时。
10. 切换日 — 按下面给出的顺序逐条检查。不要凭记忆打勾：把清单打开，真的去测。
11. D+1 — 把 TTL 调回平时的取值；多数情况下 3600 秒合适。长期把 TTL 设得很短，只会白白增加对您域名服务器的查询量。
12. D+7 — 退掉旧合同，不要更早。先等到新邮箱收到过邮件、在新主机商这边恢复过一次备份、并且把错误日志看过一遍。退订往往当天就把数据删掉。

要搬哪些东西，各用什么方式

一份托管不是一个整块，而是一堆各自需要不同工具搬运的部件。把它们分开处理，可以避开最常见的那个错误：只复制文件，然后指望其余部分自己跟上。

• 文件。两边都允许时走 SSH 上的 rsync，否则用 SFTP。两遍胜过一遍：第一遍在网站照常运行时完整复制，第二遍紧挨着切换之前只取差异。之后要确认权限、归属和符号链接都还在——FTP 设置不当会在无声中把它们抹平。
• 数据库。MySQL 和 MariaDB 用 mysqldump --single-transaction --quick，PostgreSQL 用 pg_dump -Fc。记下源库的字符集和排序规则，并用同样的设置创建目标库：正是这个细节，会让导入后的重音字母变成乱码。
• 面板备份。如果您现在的托管由控制面板管理，它自带的导出——文件、数据库、邮箱和设置都在一个压缩包里——往往是最稳妥的路。我们的网站托管套餐随附 Plesk 面板，它有自己的备份与恢复工具。
• 整机时的磁盘镜像。在 VPS 或独立服务器上有两条路：原样复制磁盘（raw 或 qcow2 镜像，或者从救援系统按块复制），或者从一个干净系统重新开始、把应用重新部署上去。如果您现在的主机商不给磁盘镜像的访问权，第二条路就是唯一选择——而对于用了好几年的系统，我们本来也建议走第二条。
• 证书。不要搬它们：域名指过来之后，Let's Encrypt 证书在新服务器上几秒钟就重新签发好了。如果您买的是扩展验证证书，退订之前先把私钥导出来，否则只能再买一次。
• 邮箱。一次 IMAP 同步会把邮件、文件夹结构以及已读未读状态从一台服务器复制到另一台。像文件一样做两遍：切换前一遍，切换后一遍，把中间到达的邮件补上。
• 计划任务和服务。cron、systemd 定时器、消息队列和常驻进程，任何网站备份里都不会有。手工照搬一份，然后确认它们在切换后真的在跑，而不是只确认它们被声明了。
• 各种密钥。已授权的 SSH 公钥、API 令牌、应用加密密钥、各服务的凭据：它们常常不在网站目录里，因此会无声无息地丢掉。程序能启动却再也解不开自己的数据，几乎总是因为某个密钥留在了旧服务器上。

DNS：哪些提前准备，哪些在切换日变更

DNS 是迁移里您一个人管不了的部分。在您的区域和访客之间，有一批解析器会把旧答案缓存起来，时长正好是您告诉它们的那个数。这个时长叫 TTL，也是您手上唯一能缩短切换时间的杠杆。

所以规则是：TTL 要提前调低，不能在切换当中调。如果今天您的 TTL 是 86400 秒，而您在切换当天早上才改成 300，那些已经拿到旧值的解析器还会照旧值再守二十四小时。提前 48 小时调低，旧值自己就到期了，切换也就成了几分钟的事。

1. 提前 48 小时：把 TTL 调低到 300 秒，凡是要改动的记录都要调——至少 A 和 AAAA，如果邮件也搬，还要加上 MX 及其相关的 CNAME。TTL 在 DNS 区域里设置，也就是在托管这个区域的一方：多数情况下是您的域名注册商。
2. 动手之前先把当前区域记录下来。一条 dig 您的域名 ANY 查询，或者从界面导出一份区域文件，就给了您起始状态。把它留着：万一出问题，这就是您的退路。
3. A 和 AAAA。A 记录填新托管的 IPv4 地址，AAAA 填它的 IPv6 地址（如果有）。不要漏掉 www，也不要漏掉真正在用的子域名：某个 webmail、某个 api、某个预发布环境。被漏掉的，往往正是自己从来不去访问的那些。
4. MX：最容易被漏掉的记录。它指向接收您邮件的服务器，和托管网站的那台无关。如果您的邮件服务留在原处，就不要动它：这正是「把区域里所有 IP 一起换掉」这种切换方式的经典错误，会把邮件引到一台根本不认识它的服务器上。如果邮件服务也要搬，那就等邮箱建好并同步完之后再改 MX。
5. SPF。这是一条唯一的 TXT 记录，列出获准以您的名义发信的服务器。如果它还指向旧托管，从新服务器发出的邮件会被归入垃圾邮件或者直接被拒。切换前把新服务器加进去，等迁移确认无误后再把旧的去掉——并且只保留一条SPF 记录：两条会互相抵消。
6. DKIM。签名由发信服务器生成，凭您区域里以选择器（selector）发布的公钥来验证。切换前先把新服务器的选择器发布出去，旧的再留几天：两个选择器可以并存互不干扰，SPF 则不行。
7. DMARC。它告诉收件方，对没通过上述检查的邮件该怎么处理。迁移期间保持 p=none 并留一个接收报告的地址：既能观察又不会弄坏什么，等 SPF 和 DKIM 两边都干净了，再把策略收紧。
8. CAA，如果有的话。这条记录列出允许为您的域名签发证书的机构。如果里面没有您新主机商用的那一家，签发会无声失败，网站就停在 HTTPS 无效的状态上，而且哪里都不会有一条明确的错误提示。
9. 反向 DNS（PTR）。它不在您的区域里设置，而是设在 IP 地址上，也就是在持有这个地址的主机商那里。一旦您的服务器自己发信，它就重要了：如果 PTR 与服务器声明的主机名不一致，一部分收件方会拒收。在我们这边，反向 DNS 可按需定制。

真正的不可用时间，以及怎样把它压到几乎为零

大多数人担心的那种中断——「DNS 扩散期间我的网站会打不开」——只要两边托管同时在响应，就不存在。扩散期间一部分访客落到旧服务器，另一部分落到新服务器，两边都能显示网站。没人会看到错误。

真正的窗口在别处：那是数据库已经导出、而网站还在一侧继续接受写入的那段时间。在这个窗口里下的订单，记录在旧服务器上，在新服务器上永远不会存在。所以，减少不可用时间就是减少这个写入窗口——而不是去和 DNS 较劲。

• 展示型或纯静态网站：完全不中断。服务器端不写任何东西，副本可以前一天就做好，切换也不需要什么特别的防备。
• 带数据库的网站：几分钟。把网站切到只读或维护状态，导出数据库，导入，切换。在普通网站上整套动作五到十五分钟就够，安排在访问量低的时段。
• 网店：窗口一样，但要提前通知。先跟团队打招呼，挑一个真正冷清的时段——常常是清晨——事后再把两边的最后几笔订单对一遍，然后才把旧服务器当成可丢弃的。
• 邮件：不中断，但有一段重叠期。只要 MX 还没到处生效，就仍会有邮件落到旧服务器上。保留那边的访问权几天，切换之后再做一次 IMAP 同步：这正是避免邮件丢失的办法。
• 带队列或延迟任务的应用：先把队列排空。导出时正在执行的任务会丢掉，或者被跑两遍。先停掉消费端，等队列排空，再导出。

切换之后：按顺序逐条检查

这份清单在切换当天自上而下走一遍。顺序不是装饰：每一项都以前一项通过为前提，第 2 项没过，后面所有项的结果都无从判断。

1. DNS 解析。分别向一个公共解析器和您宽带运营商的解析器查询：两边都必须返回新地址。在此之前，您在浏览器里看到的什么都说明不了。
2. 网站在响应，而且来自正确的机器。curl -I https://您的域名 应返回 200；如有疑问，curl --resolve 可以强制指定地址，把两台服务器并排比对。
3. 证书。有效、域名正确，并且也覆盖 www。自动签发在扩散之后要等几分钟；超过一小时，就去看看 CAA 记录。
4. 各种跳转。HTTP 跳 HTTPS，以及 www 跳裸域名或者反过来——但只能一个方向，用 301 而不是 302，也不要出现两级连续跳转。
5. 深层页面。首页几乎总是正常的。随便打开五六个站内网址：丢掉的重写规则、以及仍然指向旧域名的绝对链接，都在这里露出来。
6. 表单。用联系表单发一条测试消息，确认它真的到了。表单显示「感谢」却什么都没发出去，是迁移后最常见的毛病。
7. 支付，如果有的话。在沙箱模式下走一笔测试订单，一直走到确认页和对应邮件。顺便看看支付网关是不是还有一份 IP 白名单需要更新。
8. 外发邮件。从网站往一个外部地址发一封，打开收到那封的邮件头，读 SPF 和 DKIM 的结果。两项都要是「pass」；否则回到 DNS 那一节。
9. 入站邮件。从外部往已迁移的某个地址写一封，并且再盯着旧邮箱几天。
10. 计划任务。等到有一次真的执行过之后去看它留下的痕迹，而不是只看任务表里那一行在不在。
11. 错误日志。头 48 小时里都要读。缺少的扩展、或者写死在代码里的绝对路径，会立刻显形，常常比任何人来抱怨都早。
12. 在新主机商这边做第一份备份。做出来，再恢复一次，确认它真的能用。这是退掉旧合同之前必须满足的条件。

会白白耗掉一天的几个坑

• 当天才调低 TTL。这样做没有意义：旧的那个很长的取值早已进了缓存。一部分访客整天都留在旧服务器上，而您在找一个根本不存在的故障。
• 顺手就把 MX 换掉。把「区域里所有 IP」一起替换，会把邮件和网站一起带走。邮箱不搬，MX 就不动。
• SPF 还留在旧服务器上。网站能开，邮件发得出去，可是没人收到——或者都进了垃圾邮件。这是事后最难诊断的毛病，因为表面上什么都没失败。
• 旧合同退得太早。退订会删数据，常常就在当天，一并带走切换之后到达的邮件，以及文件那份唯一还新鲜的副本。
• DNS 还没指过来就申请证书。验证会失败，网站带着安全警告显示，浏览器还会把这个错误记住。先等扩散完成，再申请签发。
• 把预发布环境的 robots.txt 原样搬过来。从测试环境继承的一条 Disallow: /，几天内就能让网站从索引里消失。切换之后马上把这个文件再读一遍。
• PHP 版本在没人拍板的情况下变了。新托管常常默认给一个更新的版本。先把原来的版本复现出来，等迁移收尾之后再升级。
• 忘了缓存和 CDN。如果网站前面挂着 CDN，要改的不是公开的 A 记录，而是 CDN 里声明的源站。切换后还要清一次缓存，否则您仍在把旧站发给访客。
• 第三方那边的 IP 白名单。支付网关、SMTP 中继、合作方 API、远程数据库：凡是按 IP 地址过滤的，都必须在切换之前知道新地址，而不是之后。

迁一台服务器，和迁一个网站不是一回事

这两件事名字相同，内容并不相同。迁一个网站，是把文件、一个数据库和一些邮箱搬到一份已经有人管的托管上：系统、安全更新和控制面板都是现成的。这正是我们免费承担的、迁往网站托管套餐的那种迁移。

迁一台服务器，是把一台机器重新搭起来：系统、软件包、各项服务、防火墙、用户、证书、备份。在KVM VPS 上，您会拿到一个专属 IPv4 地址、SSH 的 root 权限，以及一个提供重启、重装、快照和控制台的面板。那个控制台在切换当天很关键：万一某条防火墙规则把 SSH 的门关上了，靠它才能把控制权拿回来。

当原来那台机器已经用了好几年时，我们的建议是：不要复制磁盘，重新搭。否则您会继承一堆没人再说得清缘由的设置。每个有风险的步骤之前都拍一张快照——这不花什么时间，却能把一次失误变成简单的回退。整套基础设施要搬的话，请在报价申请里把现状描述给我们：我们会和您一起把顺序定下来，而不是在还没看过机器之前就先报一个工期。

迁移期间的搜索排名

保持同一个域名、同一批网址去换主机商，本身对排名没有任何影响：在搜索引擎看来只有 IP 地址变了，而这不是排名因素。迁移之后观察到的下滑，几乎总是别的原因。

• 网址变了却没有跳转。如果结构和托管一起改动，就在切换之前把对应关系表准备好，并且发 301 而不是 302。至少保留十二个月。
• 无意中屏蔽了收录。robots.txt、X-Robots-Tag 响应头、从测试环境带过来的 noindex 标签：当天把这三处都查一遍。
• 网站比以前更慢。应用缓存和压缩在新托管上往往需要重新开启。把响应时间前后测一遍来比，不要靠推测。
• 站点地图坏了。确认它仍然可访问、内容是最新的，然后让搜索引擎自己回来。只要网址没变，抓取节奏几天内就会恢复，没有什么需要催的。