先判断问题是不是只和域名有关
线上排障时，经常会遇到一种很迷惑的情况：直接访问服务器 IP 能通，甚至 curl IP 也能返回内容，但换成域名就打不开、超时，或者返回了完全不对的页面。这个现象说明服务器本身不一定挂了，问题更可能出在 DNS 解析、虚拟主机匹配、HTTPS 证书、反向代理转发或缓存链路上。
第一步不要急着重启 Nginx、PHP 或数据库，而是先把“IP 是否可达”和“域名是否正确指向这台服务器”拆开。可以在本地执行 ping 域名、dig 域名 或 nslookup 域名，再和服务器公网 IP 对比。如果解析出来的地址不是当前服务器，后续再查 Web 服务就容易跑偏。
用 dig 看清 DNS 解析链路
DNS 问题最常见的原因有三个：解析记录填错、DNS 缓存还没刷新、不同地区递归 DNS 返回结果不一致。排查时建议直接看 A 记录或 CNAME 记录，例如：
dig example.com A +short
dig www.example.com CNAME +short
dig @8.8.8.8 example.com A +short
如果不同 DNS 服务器返回的结果不同，通常是 TTL 缓存或权威解析配置还没完全生效。刚修改解析时，不要只看自己电脑的结果，也要用公共 DNS 或在线工具交叉验证。对于刚迁移到新云服务器的网站，建议在切换前提前降低 TTL，切换后再逐步恢复，避免用户长时间访问旧地址。
用 curl 指定 Host 头验证站点匹配
很多 Web 服务器上不止一个站点，Nginx 或 Apache 会根据 Host 头决定把请求交给哪个虚拟主机。直接 curl IP 正常，并不代表域名访问一定正常，因为 curl IP 时 Host 头是 IP，而浏览器访问域名时 Host 头是域名。
可以用下面的命令模拟域名访问，但请求仍然打到指定 IP：
curl -I -H "Host: example.com" http://服务器IP/
如果这条命令返回 404、默认站点、证书错误或跳转到其他域名，就要检查 Nginx 的 server_name、站点配置文件是否启用、是否加载了正确配置，以及反向代理后端是否依赖 Host 头。修改配置后，先执行 nginx -t 检查语法，再用 systemctl reload nginx 平滑重载。
HTTPS 场景要同时检查证书和 SNI
如果 HTTP 可以访问，HTTPS 不行，排查重点要转向证书、443 端口和 SNI。一个常见误区是只用 IP 测试 HTTPS。实际上 HTTPS 证书是按域名签发的，浏览器还会通过 SNI 告诉服务器自己要访问哪个域名，所以 IP 正常不代表域名 HTTPS 正常。
可以使用：
curl -Iv https://example.com/
openssl s_client -connect example.com:443 -servername example.com
重点看证书域名是否匹配、证书链是否完整、是否过期、服务器是否监听 443，以及 CDN 或反向代理是否把 HTTPS 请求正确转发到源站。如果证书刚签发或刚续期，还要确认 Web 服务实际加载的是新证书文件，而不是旧路径。
别忽略 CDN、缓存和安全组
域名访问通常不一定直接到源站，中间可能还有 CDN、WAF、负载均衡或云厂商安全组。IP 能访问而域名不行时，要确认域名是否接入了 CDN，CDN 回源地址是否仍是旧 IP，源站是否限制了 CDN 节点 IP，安全组是否放行 80 和 443 端口。
如果业务部署在云服务器上，建议把 DNS、CDN、源站和安全组画成一条链路逐段验证。像 速维云 这类云服务器或建站环境，迁移网站、切换域名解析、配置 HTTPS 时，也应先确认线路、端口、安全组和站点配置都对齐，再判断是不是应用程序本身的问题。
推荐的排查顺序
实际处理时，可以按这个顺序走：先查域名解析是否指向正确 IP；再查本机和公共 DNS 返回是否一致；然后用 curl 指定 Host 头验证虚拟主机；接着检查 80/443 端口、安全组、防火墙和 Nginx 配置；最后再看 CDN 回源、HTTPS 证书、应用日志和后端服务。
这样做的好处是每一步都能缩小范围，而不是在 DNS、Nginx、证书和程序之间来回猜。只要能区分“网络到没到服务器”“请求有没有进入正确站点”“站点有没有正确转发到后端”，大多数“IP 能访问但域名打不开”的问题都能很快定位。
