云主机无法访问域名，先排查这几个常见问题

做网站运维时，云主机无法访问域名几乎是绕不过去的问题。表面现象通常很像：网站打不开、浏览器一直转圈、ping 域名没结果，或者只有 HTTPS 失败。但问题不一定出在同一层。DNS 解析、云平台安全组、系统防火墙、Web 服务监听、证书绑定，甚至本地网络缓存，都可能让用户感觉“域名不通”。

这类故障里，最容易耽误时间的做法就是一上来重启服务器。服务本身如果没问题，重启解决不了解析错误，也放不开被拦截的端口，还可能把原本正常的连接一起打断。排查时更实用的思路，是先把现象说清楚，再沿着访问链路一层层确认。

先分清：到底是哪一种“打不开”

同样是云主机无法访问域名，实际情况可能完全不同，常见的有几种：

• 浏览器输入域名打不开，但直接访问 IP 可以打开；
• 在云主机里请求域名失败，提示无法解析；
• 域名能解析出 IP，但连接超时；
• HTTP 正常，HTTPS 失败；
• 有些地区能访问，有些地区不行；
• 服务器本机测试正常，外部用户访问失败。

这一步别省。比如“IP 能开、域名打不开”，很多人会直接怀疑程序，更常见的情况还是站点配置没匹配域名，或者证书、跳转规则有问题。再比如“能解析但超时”，重点通常就在网络入口、端口或服务监听。

常见问题，大多集中在四个地方

域名解析有误，或者还没生效

域名没有正确解析到云主机公网 IP，是最常见的一类。也有一些情况是记录已经改了，但客户端仍在走旧缓存，所以你在控制台看到的是新 IP，用户访问的还是旧地址。

• A 记录或 CNAME 记录填错；
• 域名还指向旧服务器；
• TTL 没过，本地或运营商缓存未刷新；
• 线路解析配置异常；
• 域名状态本身有问题，比如过期、未完成相应状态要求、被锁定。

这里有个常见误判：看到域名能返回一个 IP，就以为解析没问题。排查时要对的是目标 IP 是否正确，不能只看“有没有结果”。

云平台网络策略没放通

解析正确，只能说明请求找到了目标地址，不代表请求一定能进到服务。很多故障就卡在入口层：安全组没放 80/443，系统防火墙拦截了外部访问，或者只允许特定来源 IP。

• 80、443 端口未在安全组开放；
• Linux 防火墙仍在拦截；
• 限制了来源网段，导致外网普通用户无法访问；
• 公网 IP、网卡绑定有误；
• 服务在内网机器，域名却指向了不对应的公网入口。

这类问题很容易出现在新服务器上线、站点迁移、临时加固策略之后。服务器里看着服务都正常，但从公网就是进不来。

Web 服务配置不匹配域名

运维现场里，不少“云主机无法访问域名”是 Web 服务配置没对上。Nginx 的 server_name 没写对，Apache 虚拟主机规则不匹配，或者服务压根没启动，都会让域名访问异常。

比较典型的表现是：直接访问 IP 有响应，访问域名却返回 404、403，或者跳到默认站点。这个时候，端口可能是通的，服务也在运行，只是请求没有落到正确的站点配置上。

HTTPS 和证书配置有问题

现在很多站点默认走 HTTPS。证书过期、证书域名不匹配、证书链不完整，或者 443 根本没有监听，用户看到的往往就是“网站打不开”。服务未必挂了，只是安全连接建立失败。

如果 HTTP 能开、HTTPS 不能开，范围就可以收窄很多：先查 443，再看证书部署和跳转规则，不用再从 DNS 全盘重查一遍。

一个很典型的场景：解析对了，网站还是超时

有些故障特别容易让人绕路。比如网站刚迁移到新的云服务器，运维同事确认 A 记录已经改到新的公网 IP，外部访问却一直超时。再用 IP 测试，页面能打开，于是应用服务先被排除。

继续往下查，结果通常会像这样：

1. 域名解析结果正确，已经指向目标公网 IP；
2. Nginx 运行正常，80 端口在本机已监听；
3. 系统防火墙没有拦截；
4. 最后发现云平台安全组没开放 80 端口的公网访问。

规则一调整，站点立刻恢复。这种情况很常见，也很说明问题：云主机无法访问域名时，DNS 只是排查链路中的一环。解析没错，外部也不一定能连上。

排查顺序别乱，按链路走会快很多

先确认域名当前指向谁

先看域名解析出来的 IP，是不是目标云主机的公网 IP。刚修改过解析时，要把缓存因素考虑进去，不要刚改完就认定“解析没有生效”或“服务器有问题”。

如果前面挂了 CDN、负载均衡或反向代理，这一步还要确认架构本来是不是应该直连云主机。有些站点压根不该把域名直接解析到源站。

再确认公网入口是否通

确认 80、443 这些业务端口是否真的对外开放。这里至少看两层：云平台安全组和操作系统防火墙。只在服务器里看到端口监听，不代表外部就能访问到。

一个简单判断是：本机访问正常、外部超时，通常优先怀疑入口没放通；本机和外部都不通，再去看服务本身。

再看服务是否接得住请求

检查 Nginx、Apache、Tomcat 等服务是否在运行，监听端口是否正确，站点配置里是否写了对应域名。域名访问跳默认页、返回 404、403，很多时候都是这里出了问题。

有些应用启动了，但只监听了 127.0.0.1，这在 Node.js、Python、Java 的初次部署里并不少见。进程在、端口有，本机能通，公网还是访问不到，因为服务根本没绑定到外部可访问地址。

HTTPS 单独看，不要混在一起猜

只有 HTTPS 出问题时，就重点检查证书绑定、证书有效期、证书链、443 监听，以及是否存在强制跳转导致的循环重定向。用户看到的是“打不开”，但根因和 HTTP 超时完全不是一回事。

服务器都正常，再回头查访问方环境

如果服务器侧已经确认没问题，就不要一直在主机里打转了。本地 DNS 缓存、公司网络限制、运营商侧解析异常、浏览器缓存，都可能造成“别人能打开，我这里不行”的情况。

这类问题的特征通常是：换个网络能访问，换个地区结果不同，或者同事电脑正常、自己电脑不正常。遇到这种现象，继续折腾服务器意义不大。

几个容易漏掉的隐藏点

备案和实际接入环境不一致

在一些国内业务场景里，备案信息和实际接入平台不一致，可能影响访问稳定性。不一定每次都会直接报错，但站点出现异常时，这一项值得核对，尤其是刚迁移过环境的时候。

IPv6 记录抢在前面

如果域名配了 AAAA 记录，但云主机没有正确支持 IPv6，部分网络会优先走 IPv6，结果就是访问失败或明显变慢。表面看像域名问题，实际是解析方向和主机能力没对齐。

挂了 CDN，问题却出在回源

用了 CDN 后，用户访问的是 CDN 节点。回源地址填错、源站端口不通、回源 Host 配置不对，都会让外部表现成“域名打不开”。这时候如果只盯着云主机，容易越查越偏。

想少走弯路，检查清单要固定下来

处理云主机无法访问域名，靠临场感觉很容易漏项。更稳妥的办法，是把检查顺序固定下来，遇到故障按同一套路径核对：

• 先核对域名状态、解析记录和目标 IP，确认有没有指错、有没有缓存影响。
• 再检查公网入口，包括安全组、系统防火墙、端口是否对外开放。
• 然后确认服务进程、监听地址、站点配置，尤其是域名匹配和默认站点问题。
• 如果涉及 HTTPS，再单独检查 443、证书部署、证书链和跳转规则。
• 服务器侧没问题时，补查本地缓存、运营商网络，以及 CDN、负载均衡这类中间层。

团队协作场景里，变更记录也很有用。迁移服务器、切换解析、更新证书之后，如果没有做校验，很容易出现“明明改过了，但不知道哪里没跟上”的情况。很多故障不难，难在变更后没人按步骤确认。

云主机无法访问域名不是单一故障名，更像一个结果描述。把现象拆开，再按“解析、网络、端口、服务、证书、访问环境”这条线排查，通常都能比较快地找到根因。比起出问题就重启，把流程标准化，下一次恢复速度会更快，影响也更小。