行到水穷处 坐看云起时

昨天下午同事过来说微信公众号后台网站 ping 不通了。我先去打开公网链接，没响应，然后打开内网链接，没响应。当时判断 Web 服务挂了。

基于这个判断，后面我们进行了验证。登录内网 Web 服务器，用 netstat 查看监听的端口，以下为示例：

Active Internet connections

Proto Recv-Q Send-Q Local Address Foreign Address (state)

tcp4 0 0 192.168.31.102.57220 .https ESTABLISHED

tcp4 0 0 192.168.31.102.57219 ti-in-f139.1e100.https SYN_SENT

tcp4 0 0 192.168.31.102.57217 221.179.183.17.http ESTABLISHED

tcp4 0 0 192.168.31.102.57213 ti-in-f139.1e100.https SYN_SENT

没有发现 nodejs 的服务端口。

接下来启动 nodejs 服务：

node server.js

公众号后台网站恢复正常。

处理的过程中有同事提议注册一个域名，用于恢复访问微信公众号 Web 服务。理由是访问百度的公网 IP 同样不能正常打开百度网站，而用百度域名就可以。我没有重现出他的描述。实际上用百度公网 IP 是可以访问百度的。

这次故障处理主要涉及到了三个网络协议：HTTP、TCP、DNS，是以上操作的理论依据。

首先说 HTTP，应用层协议，没有应用层服务，系统是不会监听 TCP 相应端口的。这是怀疑服务挂掉的第一理由。

再说 TCP，传输层协议，为应用层提供应用进程间的逻辑通信端口。依次从公网、内网、Web 服务器本机访问，是依据 TCP 服务涉及的范围，逐步定位故障点的位置。

再说 DNS，应用层协议，本质上是一种映射关系，把 IP 地址映射为域名。如果传输层的 TCP 服务不可达，那域名的访问同样也是不可达，就像指针指向了未分配的内存地址。

为什么整个过程不用 ping 命令去判断故障。因为正常的 Web 服务所用的端口一定是开放的，而 ping 命令所用的 ICMP 协议的端口不一定开放，从而无从判定。所以在能够登录 Web 服务器的情况下，直接依据特定位置的 URL 访问情况去判断是最高效的。