换机时「网站打不开」的原因，多半不是新机没配好，而是 DNS 还指着旧机，或者 TTL 太长，改完迟迟不生效。这篇把时间线讲清楚：什么时候改 TTL、什么时候切记录、切完怎么验、怎么留退路。
一、先理解 TTL 在做什么
TTL（Time To Live）是 DNS 记录的缓存时间，单位秒。RFC 1035 对它的定义是：资源记录可以被缓存多久，超过这个时间解析器要重新向权威服务器查询。
关键点：
- TTL 决定的是别人缓存你记录的时间，不是你改记录的速度；
- 你把 TTL 从 86400 改成 300，已经在缓存里的旧记录仍要等原来的 86400 秒过期；
- 所以「降 TTL」必须提前做，而不是切换当天做。
二、时间线：提前 48 小时降 TTL
以一次计划内的迁移为例：
| 时间 | 动作 |
|---|---|
| T-48h | 把所有要迁移的记录 TTL 调到 300 秒（或 60 秒） |
| T-24h | 确认新机服务、证书、数据都就绪，用 hosts 或临时域名验证 |
| T-0 | 逐条切换 A/AAAA/CNAME 记录到新机 |
| T+0~2h | 观察新旧机日志、抽查访问 |
| T+72h | 确认稳定后，再考虑把 TTL 调回较长值 |
提前量取决于原来的 TTL。原来是 1 小时，提前 2 小时就够；原来是 24 小时，至少要提前 24 小时。
三、Cloudflare 的 TTL 限制
官方说明：
- 代理记录（橙色云）：TTL 固定为 Auto = 300 秒，不能编辑；
- 仅 DNS 记录（灰色云）：可以自定义 TTL，非 Enterprise 最低 60 秒，最长 1 天；
- TTL 越长，记录变更生效越慢。
所以如果你开了代理，TTL 已经是 300 秒，不需要再调；要调的是灰色云的记录。
另外，官方提醒：即使 TTL 很短，你本地 DNS 缓存也可能让「实际感受到变化」的时间晚于 5 分钟。
四、迁移前先列全记录
只改主域名是最常见的漏项。迁移前把所有记录过一遍：
dig +short A example.com
dig +short AAAA example.com
dig +short MX example.com
dig +short TXT example.com
dig +short NS example.com在 DNS 面板里逐条核对：
- 主域
@、www； - 子域：
api、static、img、blog等； - 邮件相关：
MX、SPF、DKIM、DMARC的 TXT； - 验证类 TXT（搜索平台、支付、第三方服务）；
- 如果用了 CNAME 接入（如 CDN、对象存储），确认它指到哪。
把这些列成表，切换时一条一条勾，不要凭记忆。
五、切换当天的顺序
- 先切低风险子域（如
static），验证新机没问题； - 再切主域和
www； - 最后处理邮件相关记录（改错会影响收信）；
- 每切一条，等 1–5 分钟就查一次：
dig +short A example.com @1.1.1.1
dig +short A example.com @8.8.8.8两个公共解析器都指向新 IP，才说明权威记录已更新。
六、切换后验证
curl -I https://example.com
curl -I https://www.example.com检查：
- 返回 200/301，不是 502/523；
- 证书域名正确、未过期；
- 页面内容是新机版本（可以改一个临时标记确认）；
- 表单、登录、上传可用；
- 新机访问日志有真实流量，旧机日志在下降。
如果用了 Cloudflare 代理，切换源站后要清一次缓存，否则边缘可能还返回旧内容。官方支持按 URL 或整站清除。
七、回滚预案
TTL 已经降到 300 秒，回滚成本很低：
- 把记录改回旧机 IP；
- 等 5 分钟左右；
- 用
dig与curl确认流量回到旧机； - 旧机服务保持运行，不要提前释放。
这就是「提前降 TTL」的真正价值：给自己留一条几分钟内能走通的退路。
八、常见坑
| 坑 | 后果 | 避免方式 |
|---|---|---|
| 切换当天才降 TTL | 旧缓存未过期，改了也不生效 | 提前 48 小时 |
| 只改主域，漏了 www/子域 | 部分页面打不开 | 先列全记录 |
| 开了代理还去改 TTL | 改不了，白折腾 | 橙色云固定 300 秒 |
| 切完不清缓存 | 页面还是旧内容 | 按 URL 或整站清缓存 |
| 证书续期在切换前做 | HTTP-01 验证打到旧机，失败 | 切完再 certbot renew --dry-run |
| 本地缓存当成「没生效」 | 误判回滚 | 用公共解析器直接查 |
| 邮件记录跟着一起改错 | 收不到验证码/邮件 | 邮件记录最后改，单独验证 |
九、验证清单
- 所有记录已列全并逐条勾选；
- TTL 提前降到位，且已过一个原 TTL 周期；
- 主域、www、关键子域都解析到新 IP；
- HTTPS 正常、证书正确；
- 页面内容为新版本；
- 邮件收发正常；
- 旧机保留且可随时切回；
- 稳定 72 小时后再恢复 TTL。
一句话总结
TTL 要提前降，记录要列全，切换要逐条，验证要用公共解析器，旧机要留着。 迁移的停机时间取决于准备，而不是切换那一下的手速。