Linux 网络连通性排查实战：从 ping 到 tcpdump 的分层定位法

服务部署完，浏览器转圈、接口超时，很多人第一反应是重启服务，再不行就重启机器。其实网络故障最忌讳乱猜：从物理链路到应用层一共没几层，每层用一个命令验一下，十分钟就能把故障圈定在具体一层。本文按从下往上的顺序，给出一套在云服务器上最常用的排查流程。

第一层：网卡和 IP 本身

先确认机器的网络身份是对的。执行 ip addr，看网卡状态是不是 UP、IP 地址和你预期的是否一致；ip link 里网卡若是 DOWN，先 ip link set eth0 up 拉起来。云服务器重装系统或改过配置后 IP 对不上，是最常见也最低级的故障。多网卡机器还要看默认路由在谁身上：ip route 里 default via 那一行，指错网关时整台机器都出不去。

第二层：网关通不通

ping 默认网关的 IP。通，说明局域网这一段没问题；不通，再看 arp -n，网关的 MAC 地址学没学到。连网关都不通，问题基本在本机配置或云平台的虚拟网络层，去控制台看子网和路由表配置，别在系统里瞎折腾。注意 ping 不通公网但能通网关，和连网关都不通，是两个完全不同的故障域，先分清再动手。

第三层：路由断在哪一段

ping 一个公网 IP（比如运营商的 DNS 服务器地址），不要先 ping 域名，避免把 DNS 问题混进来。公网 IP 不通，用 traceroute 或 mtr 一路看过去：星号从哪一跳开始出现，断点就在哪一段。云服务器的出方向还受安全组和 ACL 影响，系统里看着都正常、包就是出不去时，去控制台查出方向规则，这是云上特有的坑。

第四层：DNS 单独验

IP 能 ping 通、域名打不开，十有八九是 DNS。用 dig 或 nslookup 查域名，看返回的解析结果对不对、耗时长不长；再看 /etc/resolv.conf 里配的 DNS 服务器是不是还活着。临时把 nameserver 换成一个公共 DNS 对照测试，能立刻区分是本地配置问题还是上游解析问题。还有一种隐蔽情况：解析返回了一个错误 IP，服务其实好端端在另一台机器上。

第五层：端口和服务监听

网络通了，服务连不上，查监听：ss -tlnp 看目标端口有没有进程在听、听在 0.0.0.0 还是只听了 127.0.0.1——只听本机回环是新手最常踩的坑，服务在服务器上自己 curl 能通，外面死活进不来。再从另一台机器用 nc -vz 服务器IP 端口测连通性。别忘了云安全组的入方向：本机防火墙放行了、安全组没加规则，端口照样不通，两层都要查。

第六层：应用层用抓包一锤定音

前五层都正常还连不上，上 tcpdump。在服务器上抓目标端口的包：tcpdump -i any port 你的端口，然后从客户端发起一次连接。抓不到包，说明请求根本没到服务器，问题在上游网络或安全组；抓到 SYN 没有 SYN-ACK，是服务或本机防火墙的问题；三次握手正常但后续无数据，是应用本身卡住。配合 curl -v 看 TLS 握手和 HTTP 状态码，应用层的问题基本无所遁形。

总结成一张清单：ip addr 看身份，ping 网关分故障域，mtr 找断点，dig 验 DNS，ss 看监听，tcpdump 一锤定音。排查的顺序永远是从下往上、从近到远，每层留一个明确结论再往上走。网络故障看起来玄学，其实九成都是某一层的一个小配置，流程对了，定位只是时间问题。