当网站宕机时，故障常常让人感觉像一个黑箱。访问者会看到加载中的转圈、难以理解的错误代码或一片空白。对于负责保持该网站在线的人来说，第一个问题总是相同的：什么坏了？
事实是，网站“宕机”没有单一的方式。相反，浏览器发出的请求会经过多个步骤——DNS 解析、TCP 连接、TLS 协商和 HTTP 响应。每个步骤都依赖于之前的步骤。而在每个步骤中，不同的事情都可能出错。
这就是为什么智能的可用性监控不仅仅告诉你站点“宕机”。它会告诉你故障发生在链条的哪里。DNS 错误指向一种情况，TCP 错误指向另一种。TLS/SSL 错误表明的根本原因与 HTTP 5xx 不同。如果你知道是哪个层出现了问题，就知道应联系哪个团队或供应商，从而可以大幅缩短解决时间。
本文按照浏览器实际加载站点的顺序逐项讲解每种错误类型：DNS、TCP、TLS 和 HTTP。对于每一项，我们将解释该步骤的作用、可能出错的情况，以及监控如何在客户发现问题之前捕捉到这些问题。
DNS 错误
DNS 是每个 Web 请求的起点。当用户在浏览器中输入你的域名时，首先发生的是将该域名解析为 IP 地址的查询。如果这一步失败，其他一切都无关紧要——无法建立连接，无法检查证书，也永远不会收到 HTTP 响应。这就是为什么 DNS 错误通常是中断的最早且最关键的信号。
常见的 DNS 错误
下面是一些常见的 DNS 故障：
- NXDOMAIN — 这意味着域名根本不存在。在实际情况中，这通常来自于注册到期、区域（zone）配置错误或记录条目的输入错误。域名到期可以瞬间让整个站点离线，而错误输入的记录可能只影响单个子域或服务。
- SERVFAIL — 一种服务器错误，表示权威 DNS 服务器无法处理请求。它通常指向损坏的区域文件、缺失的 glue 记录或 DNSSEC 校验问题。SERVFAIL 往往在配置更改后突然出现，因此是判断错误部署的有用预警信号。
- 超时（Timeouts） — 当在预期时间内没有响应返回时，客户端最终会放弃。超时通常由名称服务器过载、网络故障或使解析器饱和的 DDoS 攻击引起。由于 DNS 查询发生在缓存生效之前，即使这里出现小幅延迟峰值也会波及到用户端变慢的页面加载。
如何监控 DNS
监控 DNS 健康不仅仅是检查你的域名是否能被解析一次。它需要以真实用户体验的方式测试解析路径：
- 全球检查：合成监控代理应从多个地理位置和网络运行 DNS 查询。某条记录可能在你的办公室能正常解析，但在亚洲或南美因 anycast 路由问题或供应商的区域性故障而失败。
- 关注 TTL：每条记录都有一个生存时间（TTL）值来控制缓存。较长的 TTL 会加速正常浏览，但在变更后可能延缓传播。监控应该验证新值是否在实时查询中真实反映，并确认不存在陈旧缓存残留。
- 异常告警：最具可操作性的信号来自于趋势。NXDOMAIN 或 SERVFAIL 响应的突然激增，或解析延迟的峰值，通常是系统出现问题的首个线索——甚至在客户开始抱怨之前。
当 DNS 监控失败时，它也能让你确认什么不是问题。如果查询不被解析，那么 TCP、TLS 和 HTTP 检查根本就不会被尝试。这可以迅速缩小排查范围。在大多数情况下，修复措施涉及你的 DNS 托管提供商、注册商或负责区域文件管理的人。成熟的团队会与这些供应商建立合作关系和升级路径，以便快速上报并解决问题。
TCP 连接失败
一旦 DNS 解析出 IP 地址，下一步就是 TCP 握手。这相当于数字世界的握手：客户端发送 SYN，服务器以 SYN-ACK 响应，客户端再以 ACK 确认。只有在这个交换完成后，通信通道才建立起来。
如果 TCP 失败，浏览器知道服务器应该在哪里，但无法与之通信。结果就像一个黑洞——页面挂起、套接字无法打开，用户看到无尽的加载转圈。与通常快速明显的 DNS 错误不同，TCP 故障往往会造成一些用户可访问而另一些不可访问的混合性故障，令人困惑。
常见的 TCP 错误
- 连接被拒绝（Connection refused） — 客户端到达了主机，但在期望的端口上没有任何进程在监听。这通常发生在服务崩溃、容器退出或负载均衡器配置错误时。即便机器本身正常，如果 Web 服务器忘记绑定到 443 端口，也会变得不可见。
- 连接超时（Connection timed out） — 数据包在传输路径的某处被丢弃。可能是防火墙静默地阻止了流量、路由配置错误或上游拥塞。超时尤其令人沮丧，因为它们没有反馈——只有沉默直到客户端放弃。
- 连接重置（Connection reset） — 在这里握手完成但几乎立即被拆除。重置通常指向过载的代理、过于激进的空闲超时，或像 WAF 这样的中间盒将某些会话视为可疑并终止它们。
如何监控 TCP
基本的可用性检查在这里并不够。ICMP ping 可能成功而 TCP 握手失败，从而给出错误的健康感。适当的 TCP 监控应关注连接行为：
- 握手验证：工具应在实际服务端口上明确尝试 SYN/SYN-ACK/ACK 交换。这能确保监听者既可达又会响应。
- 路径分析：来自不同区域的 traceroute 或 MTR 可以揭示连接停滞的位置——是在你的数据中心内部、CDN 边缘还是上游 ISP。
- 协议对等监控：如果你同时支持 IPv4 和 IPv6，应监控两者。许多实际故障仅影响其中一种，如果只测试另一种，可能会漏检导致用户可见的问题。
TCP 监控能让你确信服务器不仅是存活的，而且准备好接受流量。它也能缩小排查范围：若 TCP 失败，则 DNS 已经正常工作，问题出在主机或网络路径上。这样的清晰度能防止团队在应用层追逐错误线索，而真正的问题可能是防火墙规则或某个负载池悄然丢失了最后一个健康节点。
TLS/SSL 错误
如今，几乎每个站点都运行在 HTTPS 上（相比十年前或二十年前，使用 SSL 的网站并不那么普遍）。这意味着在 TCP 握手之后，浏览器和服务器需要就 TLS（传输层安全性）会话进行协商。TLS 同时承担两项任务：加密传输中的数据，并通过数字证书证明服务器的身份。
这种信任带来了复杂性。如果证书过期、不匹配主机名或无法验证，用户会看到浏览器警告——或者页面完全拒绝加载。在实践中，TLS 错误是网站可能遭遇的最明显且最尴尬的事故之一，因为它们会在入口处阻止用户，显示无法安全绕过的警告。
常见的 TLS/SSL 错误：
- 证书过期 — 证书的有效期已过。这是最常见的中断之一，因为可能没有自动化，或续期没有传播到所有节点。
- 主机名不匹配 — 证书是为 www.example.com 签发的，但用户访问了 api.example.com。通常发生在添加新子域或将服务迁移到 CDN 之后。
- 不受信任的证书颁发机构（CA） — 浏览器不识别签发 CA，通常是因为证书为自签名或链到一个未安装在客户端设备上的私有根。
- 握手失败 — 加密协商本身失败。原因包括不被支持的密码套件、被弃用的协议版本或损坏的证书链。
如何监控 TLS：
TLS 监控需要主动且持续进行。证书不会渐进式地失效——某天还可用，第二天就可能阻止访问。良好的监控应当：
- 跟踪证书有效期并在到期前提前报警——理想情况下设置多个阈值（30 天、7 天、1 天）。
- 从多个地区验证完整证书链，因为缺失的中间证书或区域性 CA 问题可能在全球不同地方以不同方式破坏信任。
- 检查协议与密码套件支持，确保随着浏览器逐步弃用旧版（如 TLS 1.0 和 1.1），站点仍然兼容。
- 关注握手错误峰值，这些通常与负载均衡器配置错误或 CDN 上线有关。
当 TLS 故障在监控中出现时，它们也提供了上下文：DNS 解析成功，TCP 连接正常，但无法建立安全通道。这会立即收窄故障排查范围。修复通常涉及证书续期、负载均衡器配置或边缘终止，而不是应用代码。
对许多团队来说，运维教训很简单：把证书当成代码来对待。自动化颁发与续期，把证书到期的监控做得和磁盘空间一样积极，并演练替换流程，以避免到期证书演变为严重的公开中断。
HTTP 错误
最后，在 DNS、TCP 和 TLS 成功之后，浏览器发送 HTTP 请求。服务器以 HTTP 状态代码响应——一切正常时为 200，否则返回错误代码。
HTTP 监控是大多数人想到“可用性监控”时所指的那部分。但如果没有来自前几步的上下文，HTTP 错误只说明了部分情况。
常见的 HTTP 错误：
- 404 Not Found – 资源不存在。这可能是断链、页面被删除或请求路由错误。
- 500 Internal Server Error – 服务器遇到了意外情况。通常是代码缺陷或配置错误。
- 502 Bad Gateway – 代理或负载均衡器无法从上游服务器获得有效响应。
- 503 Service Unavailable – 服务器过载或正在维护。
- 504 Gateway Timeout – 上游服务响应超时。
如何监控 HTTP：
- 从全球代理运行合成 GET 请求以验证响应。
- 捕获响应代码并对 200–299 范围之外的任何响应触发告警。
- 监控事务工作流，而不仅仅是单页（登录，然后加入购物车，然后结账）。
- 为响应时间设置阈值，而不仅仅监测可用性。
HTTP 监控告诉你应用层出现了问题。与 DNS/TCP/TLS 问题不同，HTTP 错误通常由开发或运维团队负责，而非外部提供商。
将它们组合起来：分层错误监控策略
将错误按类型拆分的价值在于清晰。每次故障都是按序发生的。如果 DNS 失败，其他步骤不会发生。如果 TCP 失败，DNS 已经正常。如果 TLS 失败，DNS 和 TCP 已经通过。如果 HTTP 失败，则之前的所有步骤都已成功。
分层监控方法模拟了这一顺序：
- 从 DNS 检查开始。
- 增加 TCP 连接监控。
- 叠加 TLS 证书监控。
- 最后加入 HTTP 响应监控。
这种分层模型让你能够快速定位根本原因：
- DNS 错误？联系你的 DNS 提供商。
- TCP 错误？联系你的主机或 ISP。
- TLS 错误？修复证书或边缘配置。
- HTTP 错误？与你的网站团队沟通。
与其收到模糊的“网站宕机”警报，不如得到一张精确的故障地图，明确是什么坏了以及谁该修复它。这能降低平均修复时间（MTTR），并避免团队之间的相互推诿。
结论
网站不会以单一方式故障——它们是在不同层面上故障的。DNS、TCP、TLS 和 HTTP 各自带来不同的风险和错误特征。按错误类型进行监控能将这种复杂性转化为清晰的洞察。
配合正确的监控策略（以及像 Dotcom-Monitor 这样的工具），你不仅知道站点宕机了：你知道为什么宕机。你知道是否应当向 DNS 托管方、网络提供商、安全团队或开发人员升级工单。并且你能迅速获得这些可见性，而无需等待支持单或客户投诉。
归根结底，按错误类型监控不仅关乎可用性。它关乎问责与速度。下一次当你的网站出现故障时，不要满足于“出了点问题”。要确切知道哪一层出现了故障、这意味着什么以及如何修复。
