网站迁移时，最容易误判的是“改完解析就立刻生效”。递归DNS解析器会按记录的TTL缓存答案，用户何时转到新服务器，取决于缓存何时过期，也取决于本地网络等因素。做好外贸企业网站迁移前的DNS TTL与回滚准备，应先确认谁管理解析、哪些记录要改，以及旧环境能否继续接流量。
先盘点解析记录与管理权限
登录实际托管DNS区域的控制台，导出或截图保存当前记录；不要只检查域名注册商，因为域名注册和DNS托管可能由不同服务商负责。重点核对网站主机名对应的A记录、AAAA记录或CNAME，以及邮件使用的MX记录和相关验证记录。
迁移网站通常只需调整网站入口记录。不要顺手改动邮件配置：MX负责邮件投递，SPF、DKIM和DMARC用于邮件发送授权或验证，错误变更可能造成邮件退信、进入垃圾邮件或验证失败。记录每项的名称、类型、值、TTL和用途，并确认修改权限及紧急联系账号可用。
TTL什么时候调，调到多少
TTL以秒计，表示解析结果可缓存的时间，不是保证切换完成的倒计时。比如原记录TTL为86400秒，缓存中已有的旧答案可能在一天左右仍被使用；降低新TTL通常不能立即清除此前形成的缓存。
若计划窗口允许，可在迁移前至少提前一个原TTL周期降低网站记录的TTL；实际安排要给递归解析器和运维验证留余量。常见做法是临时设为300至600秒，适合变更窗口较短、希望缩短切换或回切等待的场景。若服务商不接受较低值、解析负载较高，或迁移日期尚未确定，则应先确认其限制，不必长期维持低TTL。切换稳定后，可再恢复为适合日常运营的值，例如3600秒或更长，具体按变更频率与服务商建议决定。
把回滚准备变成可执行步骤
- 留存基线：保存迁移前的记录快照，标清旧服务器地址、计划修改项、操作者和变更时间。
- 验证新环境：在公开切换前检查首页、登录、表单、后台及关键业务流程；确认HTTPS证书、主机名和应用配置有效。
- 保留旧环境：切换后不要马上关闭旧服务器。旧环境至少应覆盖观察期，并继续具备处理尚未更新解析用户请求的能力。
- 明确回滚触发条件：预先写明何种故障需要回切，例如主要页面持续无法访问、表单提交失败或关键业务功能异常；同时指定决定人和执行人。
- 执行回切并复核：将网站记录改回已保存的旧值，检查权威DNS返回结果及不同网络下的访问情况。由于缓存尚未过期，回切也不会让所有用户立即回到旧服务器。
DNS回切不等于数据回滚
解析改回旧地址，只能改变后续用户访问的目标，不能自动撤销新服务器已经写入的数据。若迁移后有订单、客户提交或内容更新，旧环境可能缺少这些变更。切换前要确定数据同步方式、暂停写入的时机，或准备将新增数据补回旧环境的流程；无法保证数据一致时，不应只凭网页能打开就判定回滚安全。
还要检查新旧环境是否同时处理动态请求。若两边数据库各自接受写入，回切可能产生数据分叉。对只读页面，回滚通常较简单；对持续产生交易或提交的网站，则应把数据核对列为回滚决策的一部分。
常见问题
降低TTL后，多久能生效？
取决于旧TTL和缓存情况。应尽量提前一个原TTL周期调整，并预留额外验证时间，不能把降低后的数值当作所有用户的即时刷新保证。
迁移时要改MX记录吗？
仅迁移网站且邮件服务不变时，通常不需要。先核对邮件托管方案，避免误改MX及邮件验证记录。
什么时候可以关闭旧服务器？
待主要网络访问稳定、关键功能通过检查，并确认没有仍指向旧环境的有效访问后再评估。等待时长应结合原TTL、业务流量和数据同步情况确定。
归纳来说，外贸企业网站迁移前的DNS TTL与回滚准备不是只把TTL调低，而是要留好旧记录、验证新环境、保留旧服务，并提前解决数据回切问题。这样即使解析缓存尚未更新，也能按既定步骤排查和处置。
