如何诊断“无法访问此网站”错误

“无法访问此网站”（或您的浏览器中的类似提示）有意写得很含糊，它涵盖了从 URL 拼写错误，到服务器完全宕机，再到您自己网络中断的各种情况。要高效地排查，就应当先检查最便宜、最快的那些项目。

先做一次单纯的 DNS 查询

在断定服务器宕机之前，先脱离浏览器，单独解析一下这个域名。如果返回了一个正常的 IP 地址，说明问题不在 DNS，您可以接着检查连接本身（端口是否开放、TLS 是否协商成功、服务器是否真的在响应）。如果返回的是 NXDOMAIN、超时，或者一个看起来属于私有或不可达的地址，那就说明问题被锁定在 DNS 上，这立刻排除了一大类其他的排查方向。

每种结果说明什么

这也是为什么一个快速、无需注册的查询工具在故障处理期间格外有用：它能在几秒钟内给出 DNS 层的答案，无需打开终端或记住 dig/nslookup 的语法，让您可以立刻判断自己面对的是不是 DNS 问题，然后再决定把时间花在别处。

DNS 之后：接下来按顺序要检查的事项

1. 到已解析 IP 的预期端口（通常是 443）的 TCP 连通性：即使 DNS 完全正常，防火墙或完全宕机的服务器也会在这一步拒绝连接或一直挂起。
2. TLS 证书有效性：证书过期或与域名不匹配会让浏览器弹出看起来很吓人的安全警告，但这与 DNS 或服务器是否可达毫无关系。
3. HTTP 层的响应：如果服务器接受了连接，却返回 5xx 错误，说明它已启动且可达，只是在应用层出了问题，这离 DNS 能造成的任何问题已经相差好几步了。

按顺序逐一排查，即 DNS，然后是传输层，然后是 TLS，最后是应用层，每排除一步，剩下的可能性就会明显缩小，而不是一下子对整个技术栈盲目猜测。

为什么偏偏是这个顺序

这个序列中的每一层都完全依赖于前一层的成功，所以按顺序检查（而不是直接跳到看起来最可能的那一层）才是高效的做法。如果 TCP 连接根本就没有建立，检查 TLS 证书就毫无意义；如果 TLS 协商失败，检查 HTTP 响应码同样没有意义。从 DNS 开始（它是其他一切得以进行之前必须先发生的第一件事），然后一层一层向外推进，您就永远不会白白去调查一个症状，而它其实一直是由更早、更简单的某一层的问题造成的。