换服务器后部分用户访问旧站

服务器迁移完成、解析也切了过去，第二天还是有用户打电话说看到旧页面。这不是解析没生效，而是各级缓存的正常滞后，处理思路要提前到迁移之前。 ## 根因：TTL 与递归缓存 DNS 应答会被运营商递归服务器按 TTL（记录的缓存存活时间，单位秒）缓存。TTL 设了 3600，理论上切换后一小时内全网更新完毕，但个别节点超时持有旧记录的情况确实存在，延迟一两天也有人遇到。用户侧还叠着浏览器缓存和页面缓存，看到的"旧站"可能根本没发起过 DNS 查询。 dig 应答里自带的 TTL 数值会随缓存时间递减，看它还剩多少秒，就能估计各节点的缓存何时过期，判断"再等等"还是"有异常"。 ## 迁移前把 TTL 调低 规范做法是提前一两天把 A 记录的 TTL 从 3600 调到 300 甚至更低，让全网旧缓存提前老化，等真正切换 IP 时缓存窗口已缩到几分钟。这个动作必须在切换前做，切换后才调就晚了——旧的 3600 秒缓存已经发出去了。 切换前顺手把新站压测预热一遍也值得：切换后流量一次性涌入，新机器没热身容易触发并发告警，和缓存滞后搅在一起更难分辨。 ## 切换期间与切换后的动作 正式切换选流量低谷时段，改完解析立刻用多地拨测或 dig 各公共 DNS 确认扩散进度。旧服务器建议保留几天兜底：要么整个站点 301 跳转到新地址，要么至少关键页面可访问，把迷路用户引到新站。对必须立刻看到新内容的用户，引导其强刷（Ctrl+F5）或清浏览器缓存，并说明这是网络缓存滞后、不是数据丢失。 有 CDN 的站点同步在控制台提交缓存刷新，把旧页面的 URL 刷一遍，DNS 与 CDN 两层一起收敛，用户侧恢复更快。 迁移类操作的关键在预案：TTL 提前降压、旧站保留过渡、多地验证到位，用户基本无感。反复临时改解析，反而让缓存状况更乱。切换完成后保留监控一周，确认旧站访问量归零再下线旧机器，收尾才算干净。