搜索全站
网站迁移 9 分钟阅读

换服务器时 DNS 切换时机与 TTL 预调:零中断迁移方案

换服务器最怕切换那一刻的访问中断和"部分用户看到新站、部分看到旧站"。本文讲清 TTL 的作用,给出提前降 TTL、双写同步、灰度切换的完整时间表和验证方法。

U
UFO_PF 2020-06-15 · 阅读 9 分钟
换服 网站迁移
阅读提示
本文约 3,441 字,预计阅读 9 分钟。文中命令与配置均经过实测,可直接参考执行。

引言:切换后一半人看到旧站

迁移服务器的经典翻车现场:

  • 改完 DNS,自己访问是新站,用户访问还是旧站;
  • 一部分用户在新站下单,一部分在旧站注册,数据分裂;
  • 等了 48 小时解析才完全生效,期间评论区两边都有人发言;
  • 旧站数据库还在被写入,新站数据永远是旧的。

根源是 DNS 缓存。理解并控制它,才能实现真正平滑的迁移。

原理分析:TTL 是什么,为什么会”有的生效有的没生效”

DNS 记录的 TTL(Time To Live) 告诉递归 DNS 服务器”这条记录可以缓存多久”:

mimangfei.com  A  1.2.3.4  TTL=3600

流程:

  1. 用户访问 → 本地 DNS(运营商/8.8.8.8)查询;
  2. 本地 DNS 缓存这条记录 3600 秒;
  3. 这 1 小时内,经过这个 DNS 的用户都拿到旧 IP;
  4. 你改了解析,但缓存没过期,用户仍走旧服务器。

为什么各地生效时间不同:每个运营商、每个公共 DNS 的缓存独立计算,且有些 DNS 会强制覆盖 TTL(部分运营商无视短 TTL,固定缓存数小时甚至一天)。

因此:TTL 必须在切换前提前降低,提前的时间要 ≥ 原 TTL 值。

保姆级实操:迁移时间表

假设原 TTL 是 3600 秒,建议节奏:

时间点 动作
T-48h 把 TTL 改成 300 秒;确认生效
T-24h 新服务器部署完成,全量同步数据;hosts 绑定验证
T-2h 停止旧站写入(或开启双向同步);做最后一次增量同步
T-0 修改 DNS 指向新 IP
T+5min 各地验证生效情况
T+24h 确认全部生效后,TTL 改回 3600
T+72h 旧服务器下线(先关机观察,别急着删)

第一步:提前降低 TTL

在域名解析控制台(阿里云云解析 / 腾讯云 DNSPod / Cloudflare)把 A 记录 TTL 改成 300 或 600。

验证:

# 查权威 DNS 的 TTL
dig mimangfei.com @ns1.alidns.com +noall +answer
# 查公共 DNS(反映实际缓存)
dig mimangfei.com @8.8.8.8 +noall +answer
dig mimangfei.com @114.114.114.114 +noall +answer

注意:改 TTL 后要等原 TTL 时间过去,全网缓存才会换成新 TTL。所以 T-48h 改,T-24h 再确认。

第二步:新服务器部署并本地验证

不切换 DNS 先验证新站。用 hosts 绑定:

# Windows: C:\Windows\System32\drivers\etc\hosts
# Linux/macOS: /etc/hosts
新服务器IP  mimangfei.com
新服务器IP  www.mimangfei.com

刷新缓存后访问:

ipconfig /flushdns                       # Windows
sudo dscacheutil -flushcache             # macOS
sudo systemd-resolve --flush-caches      # Linux

用无痕窗口检查:首页/文章页/分类页、图片加载、SSL 证书、后台登录、表单/评论/搜索。

关键检查:siteurl / home。域名没变就不需要改;域名变了参考WP-CLI search-replace 批量替换域名。

第三步:数据同步策略

方案 A:停机维护切换(最简单,适合小站)

  1. 旧站挂 503 维护页(见WordPress 临时关闭的正确做法);
  2. 导出数据库、打包文件;
  3. 导入新服务器;
  4. 改 DNS;
  5. 生效后取消维护页。

停机时间 = 传输时间 + 生效时间,通常 30–60 分钟。

方案 B:主从同步(零停机,适合电商等有写入的站)

  1. 提前把 MySQL 配成主从,新服务器做从库;
  2. 切换前新库与旧库实时同步;
  3. 切换瞬间:停止旧站写入 → 等待从库追平 → 新库执行 STOP SLAVE; RESET SLAVE ALL; → 开放新站写入;
  4. 文件用 rsync 增量同步。
# 最后一次增量同步(切换前执行)
rsync -avz --delete -e ssh \
  --exclude 'wp-config.php' \
  /var/www/mimangfei/ root@新IP:/var/www/mimangfei/

注意 --exclude wp-config.php:新旧服务器数据库地址可能不同,别把配置覆盖掉。

方案 C:反向代理过渡(最平滑)

旧服务器收到请求后代理到新服务器:

location / {
    proxy_pass https://新服务器IP;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
}

无论 DNS 指向哪边,内容都由新服务器提供。写入问题依然存在,需配合从库同步。

第四步:切换 DNS

修改 A 记录指向新 IP。同时检查这些记录:

  • @(根域名)、www、其他子域(img. / cdn. / static.)
  • MX 记录(邮件,忘了会导致邮件中断)
  • TXT 记录(SPF/DKIM/站点验证)
  • AAAA(IPv6)

第五步:验证生效

for dns in 8.8.8.8 1.1.1.1 114.114.114.114 223.5.5.5 119.29.29.29; do
  echo -n "$dns -> "
  dig +short mimangfei.com @$dns
done

在线工具:dnschecker.org(全球传播)、17ce.com(国内多地 Ping)、百度站长平台”抓取诊断”。

判断标准:至少 80% 的 DNS 返回新 IP,且电信/联通/移动都生效,即可认为切换完成。

第六步:处理”尾巴用户”

切换后 24–48 小时内仍有用户走旧服务器(长缓存 DNS、企业内网 DNS)。让旧服务器继续代理到新服务器,直到确认无人访问旧 IP:

tail -f /var/log/nginx/access.log

连续几小时无真实访客后再下线旧服务器。

常见踩坑

  1. 忘了提前降 TTL:改完才发现 TTL 是 24 小时,只能干等。第一步永远是查当前 TTL:

bash
dig mimangfei.com +noall +answer

  1. 只改了 www 忘了根域名:或只改 A 忘了 AAAA。检查 dig mimangfei.com AAAA。
  2. 忘了 MX 记录:换服务商时 MX、TXT 经常漏配,邮件全断。切换前后用 dig mimangfei.com MX 对比。
  3. 案例:某电商站切换时没停写,DNS 生效的 2 小时内订单分散在两台服务器。最后手工合并数据库,耗时一天还丢了部分数据。教训:有写入的站点必须开启数据库同步或停机切换。
  4. SSL 证书问题:新服务器没配证书,或证书只签了 www 没签根域名。切换前用 hosts 绑定验证。
  5. CDN 回源地址没改:用了 CDN 的话,改的是 CDN 的回源 IP,不是域名解析——域名解析始终指向 CDN 的 CNAME。
  6. 邮件队列:旧服务器可能有未发出的邮件,切换前检查 mailq。

总结

平滑迁移的核心是提前 48 小时降 TTL + 切换前完成数据同步 + 切换后保留旧服务器做代理。小站用”维护页 + 停机切换”最省心;有订单/注册的站必须做数据库主从同步或明确停机窗口。切换后别急着删旧服务器,观察访问日志确认无人访问再下线(建议保留至少 3 天)。数据同步细节可参考rsync 增量同步迁移和mysqldump 备份参数与自动化。

U
UFO_PF作者

专注 WordPress 生态的实战作者,内容以「可复制、可验证」为第一原则。

留下你的想法

邮箱地址不会被公开。带 * 的为必填项。