如何监控网站是否宕机？网站在线状态与实时告警方法

网站宕机真正麻烦的地方，往往不是服务器恢复需要多长时间，而是故障发生以后多久才有人发现。一个企业官网凌晨出现连接超时，如果没有持续监控，很可能第二天上班以后才被发现；电商网站的订单接口返回 500，首页却还能正常打开，运营人员看到流量下降时才意识到下单流程已经中断；还有一些故障更加隐蔽，比如：上海电信访问正常，广州移动却一直超时，技术人员自己测试没有问题，用户端却已经连续反馈打不开。所以，“服务器还在运行”并不能说明网站一定正常。

DNS 解析错误、CDN 节点异常、SSL 证书问题、运营商线路故障、应用接口报错，都可能让用户看到和服务器宕机非常相似的结果。想要尽早发现这些问题，不能等用户反馈，也不能偶尔手动打开网站看一眼，而应该建立一套持续的网站在线状态监控和实时告警机制。下面就从实际运维的角度，看看网站宕机应该怎么判断、如何监控，以及出现异常以后应该按照什么顺序排查。

一、什么情况才算网站宕机？

很多人听到“网站宕机”，第一反应就是服务器关机或者机房断网。实际上，真实的网站故障要复杂得多。从用户体验来看，只要用户无法正常完成访问或者关键操作，就已经属于网站可用性异常，只是严重程度不同。

1. 整站完全无法访问

这是最典型的宕机场景。例如监控请求网 站时连续出现：

Connection Timeout
Connection Refused
502 Bad Gateway
503 Service Unavailable
504 Gateway Timeout

而且不同地区、不同运营商的检测节点都出现相同问题，就要重点检查源站服务器、负载均衡、CDN、机房网络以及应用服务。这种故障通常比较容易发现，因为影响范围大，用户反馈也会非常集中。

2. 只有部分地区无法访问

这种问题反而更难查。例如同一个网站，在同一时间出现下面的结果：

从上海办公室访问网站完全正常，但广州移动用户已经打不开。这种情况可能与运营商线路、DNS 调度、CDN 区域节点、BGP 路由甚至特定 IP 的网络可达性有关，并不能简单归结为“服务器宕机”。因此，网站在线状态监控不能只有一个检测位置。

3. 首页在线，但核心业务已经不可用

还有一种容易被忽略的情况，就是网站看上去没有宕机。

例如：

首页                  200 OK
商品详情页            200 OK
/api/login            200 OK
/api/order            500
/checkout             Timeout

如果监控系统只检查首页，它会一直显示网站处于正常状态。但对于电商网站来说，用户已经无法下单；对于 SaaS 平台来说，如果登录或者核心 API 失效，实际上同样属于严重故障。所以判断网站是否宕机，不能只问“首页能不能打开”，还应该问：用户最重要的业务流程还能不能正常完成？

二、网站宕机是怎么被监控到的？

网站在线监控的原理并不复杂。简单来说，就是让位于外部网络中的探测节点按照固定时间间隔主动访问网站，然后记录每一次访问结果。

例如每隔一分钟请求一次：

https://example.com/

正常情况下可能得到：

HTTP/1.1 200 OK
Response Time: 183ms

如果网站出现问题，则可能返回：

HTTP/1.1 503 Service Unavailable

或者直接出现：

Connection Timeout

监控系统会持续记录这些结果，一旦达到设定的异常条件，就触发告警。

实际监控中通常会关注几个基本信号：

• 网站能否建立连接；

• HTTP/HTTPS 是否正常返回；

• HTTP 状态码是否异常；

• 响应时间是否突然升高；

• DNS 是否能够正常解析；

• SSL/TLS 握手是否正常；

• 页面是否返回预期内容；

• 核心 API 是否正常响应。

这里有一个很重要的区别：一次访问失败，不一定代表网站真的宕机。公网本身就存在短暂丢包、路由抖动和节点异常，如果某个监控节点偶尔超时一次就立即发送宕机通知，很容易产生大量误报。比较稳妥的方式是连续检测并进行二次确认，例如：

第一次检测失败
        ↓
30秒后再次检测
        ↓
仍然失败
        ↓
其他节点同步验证
        ↓
确认异常范围
        ↓
触发告警

这样既能尽快发现故障，也能减少偶发网络抖动带来的干扰。

三、为什么不能只用一个节点监控网站？

网站服务器只有一台，不代表用户访问网站只有一条路径。一个北京用户访问部署在中国香港的网站，可能经过联通骨干网；广州移动用户访问同一个网站，则会经过完全不同的运营商网络和出口。使用 CDN 以后，请求甚至可能被调度到不同边缘节点。

这就导致一种非常常见的现象：网站不是整体故障，而是某一条访问路径出了问题。比如某次网站异常：

上海电信     82ms      正常
北京联通     103ms     正常
成都电信     97ms      正常
广州移动     Timeout   异常
深圳移动     Timeout   异常
香港         71ms      正常

如果你的监控服务器刚好部署在上海，那么整个故障期间监控后台可能始终显示“Online”。

但对于广州和深圳的一部分移动用户来说，网站实际上已经处于不可用状态。

因此，网站监控最好覆盖真实用户所在的主要地区，并尽量包含不同运营商。

国内业务尤其应该关注：中国电信、中国联通、中国移动 + 主要省市节点。

如果同时做跨境业务，再加入中国香港、新加坡、日本、美国或其他主要市场节点，得到的结果会更接近真实用户访问情况。

四、如何通过多节点判断网站是否真正宕机？

收到“网站打不开”的反馈以后，第一件事不应该急着重启服务器，而是先确认故障范围。

这一步可以通过Chahu多节点检测快速完成。使用 Chahu 网站监控 从不同地区和运营商观察网站状态。Chahu 当前的网络检测体系支持按中国电信、中国联通、中国移动以及港澳台、海外节点进行查看。拿到多节点结果以后，一般可以按照下面几种情况判断。

情况一：绝大多数节点同时失败

如果电信、联通、移动以及海外节点都出现连接超时或 5xx，网站整体故障的可能性就比较高。

这时应该重点检查：服务器是否正常运行、Web 服务是否启动、CDN 是否正常回源、防火墙策略是否误封、域名是否正常解析，以及机房网络有没有异常。

情况二：只有某个运营商异常

这时千万别急着给服务器升级配置，根本不是性能的事儿。重点去看移动的线路、DNS 调度以及移动方向的路由走得对不对。

情况三：只有某个地区异常

大概率是区域性的网络链路问题，或者这几个节点被 CDN 异常调度到了同一台出故障的边缘节点上。

情况四：网站能够访问，但响应时间明显异常

时跑 100 毫秒的页面，突然连续十几分钟要两三秒才出得来，这就是宕机前的预警信号了。赶在彻底瘫痪前，赶紧去排查数据库压力、源站 CPU 负载还有网络带宽。

五、网站实时告警应该怎么设置？

监控要是只记日志不发通知，那充其量就是一份冷冰冰的统计报表。真正管用的在线监控，得在问题露头时主动拍拍运维的肩膀，抢在用户大面积吐槽之前把故障扑灭。要让告警真正发挥作用，这几点很关键：

1. 不建议一次失败立即报警

如果只要偶尔来个 Timeout 就狂发短信，久而久之运维耳朵都会听出茧子，最后干脆把通知静音。合理的做法是设一个“缓冲机制”：根据业务重要程度来定连续失败次数。比如普通官网可以设为连续失败 2 到 3 次再报警；核心业务则可以把检测间隔拉频，同时用多个地区的节点交叉校验，确认真的出了问题再发通知。

2. 不要只设置“网站离线”告警

实际运维里，网站彻底打不开只是故障的终极形态，很多隐患在崩塌前就已经有征兆了。除了基础的通断，这些指标同样值得盯紧：

这里要特别提一句：响应时间阈值千万别搞一刀切。一个平时只要 150 毫秒的 API，突然飙到 1.5 秒，哪怕还没超时也绝对有问题；但换成一个需要复杂计算的报表页面，耗时 2 秒可能完全正常。最稳妥的方法是先让监控跑几天，摸清各个接口的正常底细，再据此设定合理的警告线。

3. 告警必须按严重程度分级

并不是所有鸡毛蒜皮的小事都值得大半夜把人叫醒。

比如 SSL 证书还有 15 天到期，发个邮件或者钉钉群消息打个招呼就行；某个边缘节点短暂波动，记录下来留作观察即可；但要是多个核心节点同时连不上，就必须立刻触发电话轰炸或短信的高优先级报警。

团队内部也得把分工明确好，谁负责处理什么级别的故障。不然哪天真正致命的问题夹在一堆日常杂音里被无视了，那才是最大的灾难。

六、网站宕机后，应该按照什么顺序排查？

确认网站真的出了故障，最忌讳的就是像无头苍蝇一样瞎撞，手忙脚乱地到处改配置。搞不好原本只是个小网络波动，结果自己一番乱操作把现场全破坏了。

最省心也最高效的排查思路，其实就是“由外向内”一层层剥洋葱，逐步缩小嫌疑范围。

第一步：先看受灾范围到底有多大 

收到打不开的反馈，第一件事是用 Chahu 抓几个不同地区和运营商的节点测一轮。先搞清楚：到底是整个网站死透了，还是只有一部分用户访问受阻？

• 全国和海外节点全线沦陷： 基本上可以锁定是源站、CDN 整体服务或 DNS 出了大问题。

• 只有特定地区或某家运营商打不开： 别急着动源站，优先盯紧运营商线路、DNS 调度以及 CDN 的边缘节点。

这个问题搞清楚了，后面的排查才不会跑偏。

第二步：看看 HTTP 状态码吐出的是啥 

只要请求还能连接上服务器，就看看它返回的是什么错误代码，这能帮你直接定位到故障层级：

• 502 Bad Gateway： 前端的代理（比如 Nginx 或 CDN）找不到后面的源站了，重点去查上游源站的服务进程还在不在。

• 503 Service Unavailable： 服务器当前扛不住了，大概率是访问量暴涨过载、数据库连接池干了，或者是系统正在挂牌维护。

• 504 Gateway Timeout： 前端网关把请求发过去了，但源站卡在里面半天不回消息，通常是数据库死锁或后端逻辑处理太慢。

• 直接 Connection Timeout（连接超时）： 连状态码都拿不到，那就别看 Web 服务了，直奔防火墙策略、服务器端口监听和基础网络去查。

3. 检查 DNS 解析有没有猫腻 

DNS 是排查时极容易被漏掉的一环。用 DNS 查询工具跑一下，看看域名当前解析出来的 IP 对不对，不同地区拿到的结果是不是一致。

重点盯这几样：

• A/AAAA 记录和 CNAME 是不是被谁误改了；

• 是不是还解析在早该废弃的老服务器 IP 上；

• CDN 域名有没有正常生效；

• 是不是只有某个运营商拿到了错误的解析结果。

举个很常见的例子：网站刚刚切了 CDN，上海地区已经顺畅跑在新节点上了，而华南某些地方的 DNS 还在死扣着旧 IP 缓存，用户侧自然就会出现“有人能进、有人进不去”的怪现象。

4. 扔几个 Ping 看看基础连通性 

域名解析没毛病，接着可以用 Chahu 的在线 Ping 测一下目标 IP 的延迟和丢包。

这里有个大坑要注意：Ping 不通不等于网站挂了。很多服务器和安全防火墙为了防扫描，会直接干掉 ICMP 协议。Ping 的真正价值在于帮你观察：

• 延迟有没有突然出现几倍的飙升；

• 某些地区是不是丢包丢到了不可接受的程度；

• 是不是只有移动或者联通跑不过去。

如果 HTTP 请求超时，同时多个节点的 Ping 也出现严重丢包或延迟暴涨，那就可以打包票是网络路径出了状况。

5. 上 Traceroute 或 MTR 扒路由 

一旦基本确定是网络层出的毛病，就该看看到底卡在哪个骨干节点上了。

请求从用户端发起到源站，走的线路大体是这样的：用户→本地运营商→省级骨干网→跨网/国际出口→CDN边缘节点→回源链路→源站

沿着链路一路追踪下去，看看到底是在哪一步延迟突然飙到几百毫秒，或者哪里的节点开始大面积丢包。是运营商的跨网互联堵死了，还是 CDN 回源的链路断了，一扒便知。

相比一发现“打不开”就抓瞎去重启服务器，这种从外向内、层层剥离的排查法不仅速度快，而且绝不会因为误操作带来二次伤害。

七、为什么不能只监控网站首页？

很多刚接触运维或建站的朋友，第一次配置监控时通常只扔进去一个首页地址：https://example.com。

有监控当然比裸奔强，但对真正靠流量变现或承载业务的网站来说，只看首页完全是掩耳盗铃。

在实际运维中，下面这种情况太常见了：

https://example.com/ (首页)            --> 200 OK (跑得飞快)
https://example.com/item/123 (详情页)  --> 200 OK (完全正常)
https://example.com/user/login (登录)  --> 200 OK (毫无问题)
https://example.com/api/order (下单)   --> 500 Internal Error (后端报错)
https://example.com/checkout (结算)    --> Timeout (直接卡死)

这时候你的监控面板可能还是一片喜庆的绿灯，但真正决定公司现金流的下单和支付流程早就瘫痪了。用户买不了东西，抱怨声四起，你却还在以为网站运行得好好的。

所以，设置监控的核心原则只有一条：盯着“用户必须完成的关键动作”去测，而不是只看门面。

不同类型的网站，侧重点完全不同：

• 企业官网： 重点盯紧首页、核心落地页（Landing Page）、域名 DNS 解析以及 SSL 证书过期时间。

• 电商平台： 除了首页和商品页，登录、购物车、下单 API 以及结算页面必须全流程覆盖。

• SaaS 平台： 重点关注/login页面、核心业务 API、/api/health健康检查、WebSocket 长连接，以及后台的任务调度队列。

• API 服务： 绝对不能只看端口通不通。必须校验接口返回的 HTTP 状态码、响应时间，甚至检查返回的 JSON 数据结构是不是预期内容。

有些服务配置了/api/health接口，它不管数据库死活，只要 Nginx 活着就固定返回200 OK。这种虚假的“健康”毫无意义，一旦底层数据库或缓存挂了，业务接口早已报错，简单的在线检测却依然以为一切正常。把这些关键链路一处处盯紧，才能在真正影响业务时第一时间收到通知。

八、网站监控多久检测一次比较合适？

频繁程度取决于这个网站掉线一分钟，你会损失多少钱。

• 个人博客、普通展示型官网： 1 到 5 分钟测一次足够了，没必要折腾。

• 电商、SaaS 平台、在线业务系统： 建议拉到 30 秒到 1 分钟测一次。

• 支付服务、核心金融 API： 需要高频外部监控，并且必须配合服务器内部的指标（CPU、内存、日志）一起盯。

不过也别盲目追求“10 秒测一次”。如果你的监控节点只有一个，频率设得再高，只要那个节点自身的网络抖一下，就会给你狂发误报。真正可靠的监控体系，永远是：合理的检测频率 + 多个节点交叉验证 + 连续失败再触发 + 按严重程度分级通知。这套组合拳打下来，比单纯在频率数字上卷高低有用得多。

监控网站是否宕机，真正需要解决的不是“偶尔打开网页看一下”，而是建立一套持续的外部检测机制，在故障真正影响大量用户之前发现异常。对于普通网站来说，HTTP 状态、响应时间和核心页面已经是最基础的监控内容；如果使用 CDN、海外服务器或者用户分布在多个地区，就不能只依赖单一节点，还应该观察不同运营商和不同地区的访问结果。

日常巡检或者发现异常时，可以通过 Chahu 网站监控 从不同地区观察网站在线状态。如果发现只有部分节点异常，再结合 DNS、Ping 和路由信息继续往下排查，通常能够更快区分到底是服务器故障、CDN 调度问题，还是某条运营商线路出现异常。网站监控的目的从来不是多看几个数字，而是尽可能把“用户反馈网站打不开”变成“用户还没发现，我们已经开始处理”。这才是持续监控真正能带来的价值。

相关问答

1. 网站在本地访问正常，但监控提示 502 Bad Gateway 是什么原因？

这通常是 Nginx、反向代理或 CDN 与源站服务器通讯失败导致的。本地访问正常可能是因为你连接的是特定节点或走的是内部网络，而外部监控请求到了异常的反向代理节点。遇到这种情况，优先排查源站应用进程（如 PHP-FPM、Node.js 实例）是否在瞬时高并发下挂掉，或者网关层设置的proxy_read_timeout超时时间过短。

2. 为什么有时公网只有某个特定运营商打不开网站？

这种情况多半不是服务器关机，而是网络传输链路发生了故障。常见原因包括：DNS 智能解析向该运营商分配了失效的 IP；特定运营商的跨网骨干网出口发生拥堵或路由绕行；或者 CDN 在该运营商部署的边缘节点宕机。可以用Chahu单独筛选该运营商的节点进行 Ping 和 MTR 跟踪，找出报文丢失的具体骨干网路由段。

3. SSL 证书故障会导致监控系统判定网站宕机吗？

会。大部分严谨的 HTTP(S) 监控节点在遇到 SSL/TLS 握手失败、证书过期、域名与证书不匹配或中间证书链缺失时，会直接终止 TCP 连接并标记为错误（如SSL Handshake Failed）。为了防止因为证书过期导致网站突发无法访问，建议将 SSL 证书剩余有效天数（如小于 15 天）单独列为中风险预警项目。

4. 收到网站宕机通知后，排查故障的第一步应该做什么？

不要盲目重启服务器。第一步是确认故障影响范围：使用多节点监测工具看一下是全国大面积宕机，还是单地区/单运营商故障。第二步看错误状态码：如果是502/504找反向代理与源站通讯；如果是DNS Lookup Failed检查域名解析与域名商；如果是Connection Timeout则优先排查源站防火墙、安全组策略或机房网络断连。

5. 既然已经有服务器内部监控（如 CPU、内存监控），为什么还需要外部网站监控？

因为内部监控存在“视角盲区”。服务器 CPU 占用率 10% 只能说明硬件资源充裕，但如果公网 DNS 解析被篡改、CDN 节点故障、SSL 证书过期或者运营商骨干网路由中断，内部监控完全感知不到。外部监控是以真实用户访问路径为视角进行探测，能直接反映最终的用户体验。