网站迁移到新服务器以后，有一种情况特别让人头疼。

自己测试一切正常，网站首页可以打开，后台也能登录。但客户却反馈，有的人访问正常，有的人一直打不开，还有人说页面显示的还是旧内容。

遇到这种情况，很多站长会先怀疑新服务器不稳定，甚至考虑重新迁移一次。

其实，网站换服务器以后，部分用户能访问、部分用户无法访问，并不一定是新服务器本身出了问题。域名解析、CDN配置、IPv4和IPv6、服务器防火墙以及网站运行环境，都可能造成类似现象。

尤其是迁移过程中，如果旧服务器和新服务器同时保留一段时间，不同用户访问到不同的服务器，也是一种需要重点排查的情况。

那么，遇到这种问题，应该从哪里开始检查？

一、最常见的原因：不同用户获取到的DNS解析结果不一样

正常情况下，用户在浏览器中输入域名，电脑需要先通过DNS查询这个域名对应的IP地址，然后才能向目标服务器发起连接。

例如，网站原来使用的服务器IP是 192.0.2.10，迁移后更换为 192.0.2.20。

当域名解析记录修改以后，并不是所有用户的电脑都会立即使用新IP。

原因在于，DNS查询结果可能被本地系统、路由器或者递归DNS服务器缓存。只要缓存仍然有效，部分用户就可能继续使用之前的解析结果。

这时就会出现两种情况：

• 已经获取新解析结果的用户，访问新服务器；

• 仍然使用旧缓存的用户，继续访问旧服务器。

如果旧服务器还在正常运行，这两类用户可能都能打开网站，只是看到的内容不同。

但如果旧服务器已经关闭，或者旧IP不再提供网站服务，那么仍然访问旧地址的用户就可能遇到连接超时、拒绝连接或网站无法访问等问题。

这也是网站迁移后，部分用户访问异常的常见原因之一。

需要注意，DNS解析变更并不是简单地等待一个固定时间就一定能在全球同步完成。实际生效时间会受到原有TTL、递归DNS缓存、解析服务商行为等因素影响。

因此，迁移完成后，不应该只用自己的电脑测试一次，就认定所有用户都已经切换到新服务器。

二、为什么同一个域名，不同地区访问结果却不一样？

有些站长会发现，自己在办公室访问正常，客户在家里或者其他城市访问却不正常。

这不一定意味着服务器存在地区性故障。

首先，不同地区、不同网络运营商使用的递归DNS服务器可能不同，缓存状态也可能不一样。

其次，如果域名使用了智能DNS、分线路解析或者CDN服务，不同地区的用户本来就可能获得不同的解析结果。

例如，一个网站可能根据用户所在地区返回不同的IP，或者把访问请求交给不同的CDN节点处理。

如果迁移服务器时只修改了部分解析记录，或者某些线路的解析规则没有同步调整，就可能导致部分用户仍然访问旧节点。

因此，遇到地区性访问异常时，应该同时检查：

1. 不同地区的DNS解析结果是否一致；

2. 不同运营商返回的IP是否符合预期；

3. 域名是否启用了智能解析或CDN；

4. 旧服务器是否仍然接收访问请求；

5. 新服务器是否允许对应来源的网络连接。

同一个域名，不代表所有用户一定会连接到同一个IP地址。 这是排查网站迁移问题时很重要的一点。

三、别忘了检查IPv6：IPv4正常，网站仍然可能打不开

这是网站迁移时比较容易忽略的问题。

域名除了可以配置IPv4地址记录，也可以配置IPv6地址记录。

IPv4对应的DNS记录是A记录，IPv6对应的DNS记录是AAAA记录。

假设网站迁移以后，A记录已经更新到新服务器，但AAAA记录仍然指向旧服务器。

那么，部分优先使用IPv6的用户，可能继续连接旧地址。

如果旧服务器已经关闭，或者新服务器没有正确配置IPv6访问，就可能出现一种看起来很奇怪的现象：

有些网络访问完全正常，另一些网络却始终打不开。

这种情况不能只检查A记录，还应该检查AAAA记录。

可以在电脑上分别查询：

nslookup example.com

在支持 dig 的系统中，也可以使用：

dig example.com A +short
dig example.com AAAA +short

请把 example.com 替换成自己的网站域名。

第一条 dig 命令用于查看IPv4解析结果，第二条用于查看IPv6解析结果。

如果AAAA记录仍然指向旧地址，需要进一步确认新服务器是否已经具备IPv6服务能力。

如果业务不准备使用IPv6，也应先确认相关记录确实不再需要，再决定是否删除。不要因为某个用户访问异常，就未经检查直接修改所有DNS记录。

四、如果网站使用了CDN，排查方法就不一样了

现在很多网站会通过CDN提供访问加速和安全防护。

这种情况下，域名解析结果可能指向CDN节点，而不是实际的源站IP。

例如，用户访问网站时，连接的是CDN边缘节点，CDN再根据配置向源站请求内容。

如果网站迁移时只修改了域名解析，却没有更新CDN的源站配置，那么就可能出现以下问题：

• 部分请求仍然回源到旧服务器；

• CDN回源失败，出现502或504；

• HTTPS回源证书校验失败；

• 新服务器拒绝CDN节点的回源请求；

• 部分缓存仍然返回旧页面。

这里需要区分两个问题。

DNS负责把用户引导到对应的访问入口，CDN源站配置决定CDN从哪里获取网站内容。

如果域名一直使用CDN，通常不应该直接把域名解析修改为新服务器IP，而是根据实际架构更新CDN中的源站地址，再确认回源协议、回源端口、Host设置和证书配置是否正确。

如果只改了DNS，没有检查CDN配置，问题就可能一直存在。

另外，CDN缓存也可能让用户看到旧内容，但这和无法连接服务器并不是同一种故障。前者需要检查缓存规则和刷新策略，后者则应该重点排查网络连接与回源状态。

五、新服务器的防火墙和安全组也可能拦截用户

还有一种情况：域名已经解析到新服务器，但部分用户仍然打不开网站。

这时就需要检查新服务器的网络访问规则。

云服务器的网络访问可能同时受到多个层面的控制，例如：

• 云平台安全组；

• 系统防火墙；

• 上游网络访问策略；

• Web服务监听地址；

• CDN回源白名单；

• 网站程序自身的访问限制。

这些环节中，任何一处配置不正确，都可能导致访问失败。

例如，新服务器上的Nginx已经正常启动，但只监听了本地回环地址，而没有监听外部网络接口，那么外部用户就无法正常连接。

又或者，服务器安全组只开放了SSH端口，却没有放行网站需要的80和443端口。

还有一些情况是，服务商或管理员为了限制访问，设置了特定的IP白名单，导致部分来源可以访问，其他来源则被拒绝。

如果网站使用CDN，源站还可能只允许CDN节点访问。此时从普通公网直接测试源站IP失败，并不一定说明网站故障，需要结合预期的访问架构判断。

排查时，建议先确认Web服务是否正常监听，再检查云平台安全组和系统防火墙，最后结合访问日志判断请求有没有到达服务器。

不要一看到外网无法访问，就直接关闭所有防火墙。正确的做法是找到具体被拦截的规则，再有针对性地调整。

六、新服务器能打开首页，不代表迁移已经完成

还有一种容易被忽略的情况：网站首页可以访问，但部分页面、登录功能或接口无法正常使用。

这可能是因为新服务器只完成了基础部署，其他运行环境还没有完全恢复。

例如：

• 数据库没有完整迁移；

• PHP版本与旧服务器不一致；

• 网站目录权限不正确；

• 伪静态规则没有配置；

• SSL证书没有正确安装；

• 定时任务没有恢复；

• API回调地址仍然指向旧服务器；

• 网站程序仍然连接旧数据库。

这些问题不一定会导致整个网站完全无法访问，却可能造成不同用户、不同页面出现不同结果。

如果网站迁移后只有部分功能异常，就不应该一味检查DNS。

更合理的方式是先区分故障类型：

如果整个域名无法连接，优先检查DNS、网络和Web服务。

如果首页可以打开，但登录或提交表单失败，就应该进一步检查程序日志、数据库连接和接口配置。

如果只有HTTPS异常，则需要检查证书、域名匹配、证书链和代理配置。

先判断问题发生在哪一层，再决定检查什么，通常比反复修改配置更有效。

七、网站迁移后，怎样一步一步排查？

如果客户反馈网站无法访问，可以按照下面的顺序进行检查。

第一步：确认域名现在解析到哪里

先查询域名的A记录和AAAA记录，确认它们是否已经更新到预期地址。

如果网站使用CDN，还要先确认域名解析到CDN是否符合预期，不要误把CDN节点IP当成源站IP。

第二步：从不同网络进行测试

分别使用不同地区、不同运营商的网络访问网站。

同时记录测试时间、访问结果和网络环境。

如果自己能访问而客户无法访问，最好让客户提供报错截图或浏览器错误信息，而不是只根据“打不开”三个字判断原因。

第三步：检查新服务器的Web服务

确认Nginx、Apache或IIS等服务是否正常运行，网站是否正确监听80和443端口。

如果使用反向代理，还要确认后端应用是否正常响应。

第四步：检查安全组和系统防火墙

确认新服务器允许预期的用户流量进入。

如果网站通过CDN访问，还应确认CDN回源请求没有被错误拦截。

第五步：检查网站日志

如果请求已经到达新服务器，可以进一步查看访问日志和错误日志。

日志通常能够帮助判断请求是否到达、哪个环节返回了错误，以及是否存在程序异常。

如果日志中完全没有对应请求，则需要继续检查DNS、网络路径、CDN入口或其他前置环节。

第六步：确认旧服务器是否仍然被访问

在迁移过渡期，可以对比新旧服务器的访问日志，观察是否还有正常用户请求到达旧服务器。

如果旧服务器仍然有请求，就需要确认这些请求是来自尚未更新的DNS缓存、固定IP访问、第三方回调，还是其他未完成迁移的配置。

在确认所有必要业务已经切换以前，不建议过早关闭旧服务器。

八、怎样迁移，才能尽量避免部分用户打不开？

与其等迁移后再排查，不如在迁移前把容易遗漏的环节检查一遍。

对于正在运营的网站，可以参考下面的流程。

迁移前：

• 备份网站文件和数据库；

• 记录旧服务器的DNS、CDN和防火墙配置；

• 检查域名的A记录与AAAA记录；

• 确认新服务器的PHP、数据库和Web环境；

• 提前测试新服务器的访问能力；

• 根据实际业务降低DNS TTL，并预留缓存更新时间。

迁移时：

• 完成数据同步并检查数据库；

• 确认新服务器上的网站能够正常运行；

• 更新实际需要变更的DNS或CDN源站配置；

• 检查HTTPS、接口和网站核心功能；

• 通过不同网络验证访问结果。

迁移后：

• 持续观察访问日志和错误日志；

• 检查旧服务器是否还有正常业务请求；

• 监控网站可用性和数据库状态；

• 确认DNS、CDN和第三方接口均已完成切换；

• 验证备份可以正常恢复。

需要注意，降低DNS TTL并不能保证所有缓存立即更新，因此仍然应该保留合理的过渡期。

如果旧服务器已经没有必要继续运行，也应先确认没有重要业务依赖旧地址，再安排下线。

写在最后

网站换了服务器以后，有些人能打开，有些人却打不开，并不是一种单一故障。

它可能是DNS缓存尚未更新，也可能是IPv6记录遗留、CDN源站配置错误、防火墙拦截，或者新服务器上的程序环境还没有完全恢复。

真正有效的排查方式，是把访问过程分成几个环节：域名解析、网络连接、服务器接入、Web服务和网站程序。

先确认用户访问到了哪里，再判断请求在哪个环节出现问题，往往就能缩小排查范围。

对于长期运营的网站来说，服务器迁移不只是把文件复制到新机器上。DNS、证书、数据库、网络规则和第三方接口都可能影响最终访问结果。

迁移完成的标准，不是站长自己的电脑能打开网站，而是目标用户能够通过正常的访问路径稳定使用网站。