宕机排查流程
如何检查网站是否宕机
用清晰流程区分真正的网站故障、DNS 问题、SSL 失败、端口关闭，以及技术上有响应但仍无法正常使用的页面。
网站停止加载时，第一个问题通常太宽泛：“是不是宕机了？”实际排查时，你需要先回答更具体的问题：请求是在 DNS 完成前失败、连接阶段失败、TLS 阶段失败，还是服务器返回 HTTP 响应后才出问题？这正是有效诊断和模糊可用性猜测之间的区别。
先看完整请求路径
网站检查会在一次运行中覆盖 DNS、TCP、TLS、重定向和最终 HTTP 响应，是最快的高层判断入口。
不要把所有失败都叫宕机
403、429 或 503 仍然表示服务器有响应。这和 DNS 失败、连接被拒绝或 TLS 握手错误完全不同。
用后续工具缩小层级
只有当第一次检查告诉你请求路径从哪里开始出问题后，DNS、SSL、端口、Ping 和 traceroute 才更有价值。
01
什么时候适合使用这篇指南
这套流程适合排障的前十分钟，在你开始改记录或归因到主机服务商之前使用。
你自己打不开网站
你需要判断这个失败是否也能从公开服务器看到，还是可能只限于你的浏览器、办公网络、VPN 或网络服务商。
客户说网站宕机了
升级处理前，你需要一个快速且站得住脚的答案。一份能区分 HTTP、DNS、SSL 和网络错误的报告，比简单的“可用/不可用”更有价值。
监控提示有问题
你需要用公开诊断页面做第二视角，判断问题更像应用故障、路由异常，还是信任问题。
02
实用的第一轮排查流程
目标是从宽泛症状收窄到具体层级，而不是一开始就跳到低层工具。
用失败的准确 URL 运行网站检查
尽量使用真实主机名和协议。你需要在同一次检查中看到重定向链、最终 URL、耗时拆分和可见的 HTTP 结果。
阅读失败点，而不只看标题
DNS 错误、TLS 警告、超时和 HTTP 503 可能都像“网站宕机”，但它们指向不同负责人和下一步操作。
用专门工具确认具体层级
如果第一份结果指向证书，打开 SSL 检查；如果指向名称解析，打开 DNS 检查；如果连接无法建立，先用端口检查，再根据路径是否可疑选择 Ping 或 traceroute。
判断结果是否能证明全球问题
单个公开服务器可以证明某个位置看到了失败，但不能证明每个地区、网络服务商或浏览器都看到了同样情况。
03
常见结果通常意味着什么
当有人问网站是否真的不可用时，这些解读最关键。
带状态码的 HTTP 响应
请求到达了应用或边缘服务。网站可能仍不可用，但主机名已解析，并且确实有服务通过 HTTP 响应。
DNS 失败或没有有用记录
问题发生在任何 Web 服务器响应之前。先检查 A、AAAA、CNAME、NS 和解析器行为，再处理 SSL 或应用代码。
TLS 或证书错误
主机已经可达到足以开始 HTTPS，但信任或协议协商失败。即使服务器技术上在线，用户也可能先看到安全拦截。
连接关闭、拒绝或超时
从当前探测节点看，Web 服务没有接受可用连接。这通常指向防火墙策略、监听进程停止、源站问题或上游过滤。
04
下一步该打开哪个工具
根据第一个明确线索选择专门页面，而不是从一串模糊错误里猜。
05
会浪费时间的常见误区
这些捷径会把不同层级压成一个模糊结论，让宕机排查变慢。
- 把每个非 200 响应都当成整个网站宕机的证据。
- 只测试首页，但真实失败发生在重定向后的登录页、结账页或 API 路径。
- 还没确认网站是否响应 HTTP 或监听预期端口，就直接跳进 traceroute。
- 假设一个或两个服务器端失败就能证明所有地区和浏览器都有全球性问题。