浏览器转了半天，能访最后给你甩出一句“无法访问此网站”。地址你顺手打开命令行，问该网站ping 一下那个域名对应的能访 IP，四个包发出去，地址四个包回来，问该网站延迟 23ms，能访丢包率 0%。地址

这就很气人了。问该网站网络明明是能访通的，机器明明活着，地址可网站就是问该网站打不开。

我上周就碰到这么一回。能访同事说公司内网的地址 OA 系统挂了，我让他 ping 一下服务器 IP，问该网站他说通得很。我过去一看，浏览器地址栏里输的是 http://192.168.1.88:8080，ping 的也是 192.168.1.88，确实通。但页面就是白的。后来查了半天，是 Tomcat 服务挂了，操作系统还在正常运行，网卡还在响应 ICMP 请求，但那个 8080 端口后面根本没有程序在监听。

这就是最典型的一种情况：ping 通只代表网络层通了，不代表应用层活着。

ping 用的是 ICMP 协议，它工作在 IP 层之上，但跟 TCP/UDP 是平级的。你 ping 一个 IP，相当于对着那台机器喊了一嗓子“你在吗”，对方操作系统内核回了一句“我在”。这个回应是网卡和内核干的活，跟上面跑着什么网站、什么服务，半毛钱关系都没有。

换个比喻。你往一栋楼里打电话，电话通了，有人接了，说“喂”。但这不代表你要找的那个公司还在营业。可能公司早搬走了，可能今天没上班，可能前台接了电话但经理不在。ping 通就是这个“喂”。

那网站打不开，到底卡在哪了？

DNS 是第一个要排查的。你 ping 的是 IP，但浏览器地址栏里敲的是域名。如果 DNS 解析出了问题，浏览器根本找不到该往哪台机器发请求。这时候你 ping 域名可能直接报“找不到主机”，但 ping IP 是通的。反过来，如果你直接 ping 域名能通，说明 DNS 没问题，那问题就不在这。

端口是第二个。网站服务监听的是 80 或 443 端口，如果服务器防火墙把这两个端口封了，或者服务根本没启动，那 ping 通也没用。你可以用 telnet 或者 curl -v 试一下端口通不通。我习惯用 nc -zv 1.2.3.4 80，一秒钟出结果。端口不通，ping 再通也是白搭。

还有一层容易被忽略：代理。你本机可能配了 HTTP 代理，浏览器走代理出去，代理服务器挂了或者规则配错了，但 ping 命令默认不走代理，直接走系统网络栈。结果就是 ping 通、浏览器不通。这种情况在办公网络里特别常见，尤其是用 PAC 脚本自动代理的环境。

另外，有些服务器会禁 ping。管理员在防火墙里把 ICMP 全 drop 了，你 ping 它永远超时。但这不代表它不能访问。反过来也一样，能 ping 通不代表它愿意让你访问网站。ICMP 和 TCP 是两套独立的规则，防火墙可以只放行 ICMP 而封掉 80 端口。

我自己的排查顺序是这样的：先 ping IP，通的话再 ping 域名，看 DNS 有没有问题。然后 telnet 目标端口，不通就查防火墙和服务状态。端口通但浏览器还打不开，就检查本机代理设置和 hosts 文件。最后再看浏览器本身，有没有装什么插件把请求拦了。

说到底，ping 只是一个最基础的连通性测试。它像一把螺丝刀，能拧螺丝，但你不能拿它当锤子用。网络排障得一层一层往上剥，从物理层、网络层、传输层到应用层，每一层都有自己独立的“通”与“不通”。ping 通只说明第三层没问题，上面还有第四层、第七层等着你。

下次再遇到 ping 通但网站打不开，别急着重启路由器。先想想，你 ping 的到底是什么，浏览器又到底在请求什么。这两件事，中间隔着的可不止一个端口。