网站打不开了怎么检查？常见原因与完整排查方法

网站突然打不开，很多人的第一反应都是服务器是不是挂了，接着就开始重启服务器、重启 Nginx，甚至直接修改 CDN 配置。但实际做网站故障排查时，服务器宕机只是其中一种情况。DNS 解析异常、CDN 节点故障、运营商线路波动、SSL 证书错误、本地网络缓存，甚至防火墙策略配置不当，都可能让网站表现出“打不开”的现象。

尤其是遇到“自己打不开，别人正常”“电信能访问，移动打不开”“国内异常，海外正常”这类问题时，只看浏览器报错基本很难直接判断原因。所以网站打不开以后，最重要的不是马上改配置，而是先确认故障范围，再从网络、DNS、HTTP、CDN 和源站几个层面逐步排查。下面就按照实际运维中比较常用的顺序，介绍网站打不开以后应该怎么检查。

一、网站打不开，先确认到底是谁打不开

发现网站无法访问后，第一件事不是登录服务器，而是先判断故障范围，因为“网站打不开”其实可能对应完全不同的问题。

如果没有先弄清楚故障范围，很容易排错方向：比如网站只是在广东移动网络下访问异常，你却一直重启服务器，这类操作基本不会解决问题。比较合理的做法，是先从不同地区、不同运营商重新测试一次网站。

二、先用多节点测速确认网站是否真的无法访问

自己电脑上的访问结果只能代表当前这一条网络线路：比如你办公室用的是电信网络，即使网站访问完全正常，也不能证明联通、移动或者其他地区用户访问时没有问题。

排查网站打不开时，最简单有效的方法是先使用 Chahu 网站测速工具进行多节点检测。通过不同地区和运营商节点同时访问网站，可以快速看到网站当前的整体连通情况。实际测试时，不需要一开始就研究特别复杂的数据，先重点观察下面几个结果：

• 哪些节点可以正常访问

• 哪些地区出现超时

• 是否集中在某一个运营商

• 响应时间是否明显异常

• 国内和海外节点结果是否存在明显差异

例如测试结果中，电信、联通节点基本正常，但大量移动节点访问失败，这种情况下就不太像服务器整体宕机，更应该继续检查移动线路、DNS调度或者CDN节点。

如果所有地区几乎全部超时，则应该优先检查源站、CDN、Web服务和服务器网络。

还有一种情况也很常见：Chahu 多节点测试全部正常，只有你自己的电脑打不开。这种问题通常应该先检查本地 DNS、浏览器缓存、代理设置或者当前网络，而不是直接去动线上服务器。

三、继续用 Ping 判断网络连通性有没有异常

确定故障范围以后，第二步可以检查 Ping。Ping 最适合用来快速判断网络基本连通情况，以及不同节点之间是否存在明显延迟和丢包差异。如果只在自己电脑上运行 Ping，依然只能看到当前网络到目标服务器的结果，所以更适合结合 Chahu 在线 Ping 做多地区测试。

在 Ping 结果中，主要看三个方面。

1. 大部分节点能不能收到响应

如果全国多个节点同时出现超时，需要继续确认：

• 服务器 IP 是否在线

• CDN 节点是否异常

• 防火墙是否限制 ICMP

• 网络线路是否中断

• 服务器是否出现大面积网络故障

不过这里需要注意，Ping 不通并不一定代表网站已经挂了。

部分服务器、云厂商或者 CDN 节点会主动屏蔽 ICMP，因此不能只根据 Ping 结果判断网站状态。

2. 是否出现明显丢包

如果测试结果中，大部分地区都没有问题，只有少数地区出现持续丢包，就需要进一步检查对应地区的网络线路。

比如：上海电信正常，北京联通正常，但广东移动出现大量丢包。

这种情况下，服务器本身往往并没有完全失联，更可能是某段网络路径或者运营商线路出现波动。

3. 延迟有没有突然升高

网站以前访问延迟只有几十毫秒，突然大量节点变成 150ms、200ms 甚至更高，也值得关注。

常见原因包括：

• 路由绕路

• 跨运营商网络拥堵

• CDN调度到距离较远的节点

• 服务器出口网络异常

• 部分骨干线路出现波动

所以 Ping 更适合用来确定“网络是不是有问题”，而不是直接判断网站页面本身是否正常。

四、Ping没问题，再检查DNS解析是否正常

很多网站打不开的问题，实际上不是服务器挂了，而是域名没有解析到正确的位置。用户访问网站时，并不是直接连接服务器，而是先通过 DNS 把域名解析成 IP 地址，再访问对应服务器或者 CDN 节点。

如果 DNS 这一层出现异常，即使服务器本身完全正常，用户依然可能打不开网站。

这时候可以通过在线DNS 查询工具检查当前域名的解析情况。

重点可以查看：

• A记录

• AAAA记录

• CNAME记录

• NS记录

• 不同地区返回的IP

• 不同运营商解析结果是否一致

1. 域名完全解析不到IP

如果查询不到正常的 A、AAAA 或 CNAME 记录，可以检查：

• 域名DNS记录是否被删除

• DNS服务商是否异常

• 域名状态是否正常

• NS配置有没有修改

• DNSSEC配置是否存在问题

2. 域名仍然解析到旧IP

这种情况经常发生在刚迁移服务器或者更换 CDN 后。

例如网站已经从旧服务器切换到了新服务器，但部分地区 Local DNS 仍然缓存着旧记录，在 TTL 过期之前，部分用户访问的依然是旧 IP。

于是就会出现：

有些人已经能打开网站，有些人仍然打不开。

3. 不同地区解析结果差异很大

如果同一个域名在不同地区解析到了明显异常的 IP，就需要继续判断：

• CDN智能调度是否正常

• 是否存在DNS缓存异常

• Local DNS是否出现问题

• 域名是否存在DNS污染或者劫持

如果网站表现为“IP可以直接访问，域名打不开”，DNS就是非常值得优先检查的一层。

五、DNS正常，网站还是打不开怎么办

如果域名解析没有明显问题，Ping结果也比较正常，但网页依然无法打开，就应该把排查重点从“网络有没有通”转移到“网站服务有没有正常响应”。重点检查 HTTP、HTTPS、端口以及 Web 服务。

检查80和443端口

普通网站最常见的访问端口是：

• HTTP：80

• HTTPS：443

服务器可以 Ping 通，并不代表 Web 服务一定正常。

例如下面这些情况都会导致网站打不开：

• Nginx停止运行

• Apache服务异常

• 443端口未开放

• 云服务器安全组修改

• 系统防火墙误封端口

• CDN无法连接源站

• 源站端口配置错误

所以如果网络正常，但浏览器访问持续超时，就需要确认网站实际监听端口是否正常。

六、通过HTTP状态码判断网站故障方向

网站并不一定完全打不开。有时候浏览器还能收到服务器响应，只是返回了 403、502、503 或 504 等错误。不同状态码对应的排查方向也不同：

网站出现 502 时，通常就不需要把主要精力放在 DNS 上，而应该继续检查 Nginx、PHP、应用服务或者 CDN 回源；如果大量出现 504，则需要重点确认源站响应时间、服务器负载、数据库以及 CDN 回源链路。HTTP状态码虽然不能直接告诉你最终原因，但可以快速帮助缩小故障范围。

七、只有部分地区打不开，要继续查路由

网站整体没有宕机，DNS解析也正常，但是某些地区或者运营商持续访问失败，这时候网络路径就比较值得检查。

例如：

上海电信正常
北京联通正常
广州移动持续超时

并且这些地区解析出来的 CDN IP 又基本一致。

这种情况下，问题可能并不在 DNS，而是在用户到服务器或者 CDN 节点之间的网络路径。

可以利用 Chahu 的路由相关检测继续观察数据包经过的线路。

排查时重点关注：

• 哪一跳开始延迟明显升高

• 是否出现连续丢包

• 是否存在明显路由绕路

• 是否集中在某个运营商

• CDN调度线路是否合理

例如原本广州用户访问香港节点，正常情况下路径比较短，但实际路由却绕到其他地区甚至海外再返回，这时候即使服务器本身没有任何故障，访问体验也可能明显变差。

因此，如果网站只在某些地区打不开，路由检测通常比反复重启服务器更有价值。

八、检查CDN和WAF

现在很多网站前面都部署了 CDN 或高防 CDN，所以用户访问的往往不是源站，而是 CDN 边缘节点。这种情况下网站打不开，不一定是源站的问题。

如果多节点测试显示部分地区异常，可以继续检查 CDN：

• CNAME是否配置正确

• CDN节点是否出现故障

• 回源地址有没有修改

• 回源端口是否正确

• 源站防火墙是否允许CDN回源IP

• HTTPS证书是否已经同步

• 缓存或者重定向规则是否配置错误

如果开启了 WAF，还要检查安全策略有没有误伤正常用户。

比较常见的问题包括：

• IP黑名单误封

• 地区访问限制

• CC防护规则设置过严

• Bot策略误判

• User-Agent过滤规则异常

• 请求频率限制配置错误

有时候网站只有部分用户打不开，并不是线路出了问题，而是安全策略把他们拦截了。

九、HTTPS网站打不开，还要检查SSL证书

现在绝大部分正式网站都已经使用 HTTPS，因此证书异常也是比较常见的一类问题。

常见表现包括：

• 浏览器提示连接不安全

• NET::ERR_CERT_DATE_INVALID

• 证书域名不匹配

• TLS握手失败

• HTTPS页面完全打不开

这时候需要检查：

• SSL证书是否过期

• 证书绑定域名是否正确

• 中间证书是否完整

• CDN证书是否已经更新

• 源站证书是否正常

• TLS协议和加密套件配置是否兼容

尤其是在更换服务器、CDN或者重新签发证书后，比较容易出现源站已经更新，但 CDN 仍然使用旧证书的情况。如果网站 HTTP 可以打开，但 HTTPS 无法访问，通常就应该优先从这一层排查。

十、不同网站故障现象，应该先检查什么

实际排查时，没有必要每一次都把所有项目全部查一遍。可以先根据现象确定优先级。

这样排查最大的好处，就是不用每次都从服务器开始查。

先根据故障表现判断可能发生在哪一层，效率会高很多。

十一、网站偶尔打不开，最好开启持续监控

还有一种故障比“完全打不开”更麻烦，就是网站偶发异常。比如：每天凌晨偶尔超时几分钟，白天又完全正常；或者服务器高负载时偶尔出现 502，但过一会儿自己恢复。这种问题靠人工打开网页测试，很难抓到真正的故障现场。等你发现用户反馈再去检查时，网站可能早就恢复了。

这种情况下就需要使用 Chahu 网站监控持续观察网站状态。

除了普通 HTTP(S) 访问以外，还可以根据实际需求监控 Ping、TCP、DNS、SSL 等项目。

例如：

• HTTP突然无法访问

• DNS解析异常

• Ping延迟明显升高

• TCP端口失联

• SSL证书出现问题

• 网站响应时间持续增加

通过历史监控记录，可以看到故障发生时间、持续时间以及恢复情况。

对于经常出现“用户说打不开，但自己一测又正常”的网站来说，这类历史数据往往比临时测试更有价值。

十二、网站打不开的总体排查顺序

如果不确定从哪里开始，可以直接按照下面这套顺序检查：

网站打不开
    ↓
Chahu 多节点网站测速
    ↓
判断是全国异常还是局部异常
    ↓
Ping 检查网络连通性
    ↓
DNS 查询确认解析 IP
    ↓
Traceroute 检查网络路径
    ↓
检查 HTTP 状态码 / 80 / 443 端口
    ↓
检查 CDN / WAF / SSL
    ↓
检查源站 Web 服务和服务器负载

这套方法的核心并不是使用多少工具，而是先判断故障属于哪一层。

网站打不开最麻烦的情况，往往不是故障本身有多复杂，而是一开始就排错了方向：明明是某个运营商的线路问题，却不停重启服务器；明明域名还解析到旧 IP，却一直修改 Nginx；明明是 SSL 证书过期，却反复检查 CDN 节点，这些操作不仅浪费时间，还可能让原本正常的配置变得更乱。

实际处理时，可以先利用 Chahu 的多节点网站测速确认故障范围，再按照 Ping、DNS、路由、HTTP/HTTPS、CDN、源站 的顺序逐层缩小范围。只要先确定问题发生在哪一层，大多数“网站突然打不开”的故障，定位起来都会简单很多。

相关问答

1. 浏览器显示"无法访问此网站"和"连接已重置"，这两种报错指向的问题有什么不同？

区别很大。"无法访问此网站"通常意味着TCP连接建立失败，比如服务器没开443端口、防火墙拦截了请求、或者IP根本不可达，问题出在连接层面。"连接已重置"则意味着TCP握手已经成功了，但服务器端主动把连接断开了，这种情况常见于防火墙拦截、WAF触发规则、或者服务器内部主动拒绝了请求。实际排查中遇到"连接已重置"，我会优先检查安全策略和WAF日志，而不是去看端口通不通。

2. 服务器CPU跑满了会导致网站打不开吗？具体现象是什么？

会，而且现象很有特点。CPU满载的时候，服务器的TCP连接栈还在正常工作，所以Ping能通、TCP握手也能成功。但Web服务（比如Nginx或PHP-FPM）已经没有CPU资源去处理请求了，浏览器会卡在"正在建立安全连接"或者"正在等待响应"的状态，然后超时返回504或者直接报连接失败。如果监控看到响应时间从几十毫秒突然飙升到几秒然后超时，同时CPU使用率接近100%，那基本就是CPU瓶颈导致的，不是网络问题。

3. 网站部署了CDN之后出现部分地区打不开，但源站直接IP访问正常，问题出在哪？

这种情况问题基本锁定在CDN这一层，源站本身是没问题的。先检查CDN控制台的节点状态，看看那个区域是不是有节点故障公告。如果没有，让打不开的用户做一下本地DNS刷新，因为CDN的调度也是基于DNS的，可能是用户本地还缓存着旧节点IP。再排查一下CDN的防盗链配置、IP黑白名单和地区访问限制，有时候配置了"仅允许中国大陆访问"之类的策略，海外的用户就打不开了。

4. 怎么区分是网站被攻击了还是单纯的流量高峰导致打不开？

被攻击和流量高峰的表现确实很像，都会导致服务器负载飙升、响应变慢甚至超时。但有几个细节能区分：被攻击的时候访问日志里会出现大量来自不同IP的异常请求，User-Agent乱七八糟或者干脆没有，而且请求的URL高度集中（比如只刷某一个接口）。正常流量高峰的话，访问日志里各页面分布相对均匀，用户行为有规律。另外如果服务器带宽被占满但CPU不高，很可能是流量型攻击；如果CPU和数据库连接数爆了但带宽正常，更可能是应用层攻击或者单纯的业务高峰。

5. 排查网站故障的时候，先看服务器日志还是先看监控数据？

顺序很重要。我的习惯是先看监控数据、再看服务器日志。监控数据（比如Chahu的多节点探测结果）能帮你快速判断故障范围和影响面，是全国挂了还是只有某个地区挂了，这是排错的第一步决策依据。有了方向之后再登录服务器看Nginx access log和error log，找具体的错误线索。如果上来就登录服务器翻日志，很容易因为信息量太大而迷失方向，而且如果问题出在CDN或者DNS层面，服务器日志里根本不会有任何异常记录，纯属浪费时间。