Linux网络连通性排障实战

Linux网络连通性排障实战

网络连通性问题是 Linux 运维中最常见的故障类型之一。表面现象通常只是“访问不了”，但真正的问题可能出在本地网卡、路由、DNS、防火墙、远端服务甚至链路中的某个中间节点。中级阶段的关键，不是会执行几个网络命令，而是能够建立分层排查路径。

一、先区分是哪一层不通

排查网络问题时，第一步不是马上抓包，而是先判断问题大概发生在哪一层。常见情况包括：本机没有地址、默认路由异常、DNS 解析失败、端口不通、服务未监听。先把问题分类，后续动作才会更高效。

二、检查本地地址与网卡状态

先确认网卡是否正常启用、地址是否正确。

ip addr

如果某块网卡没有拿到预期地址，或者状态不是 UP，那么问题很可能还停留在本机侧。进一步看链路状态：

ip link

三、查看路由是否正确

即使本地地址正常，路由错误也会导致流量走不出去。

ip route

重点关注默认路由是否存在，以及访问目标网段时是否有明确路由项。如果是多网卡主机，还要特别小心流量是否从错误出口发出。

四、先测 IP 再测域名

为了快速排除 DNS 干扰，先直接测试目标 IP：

ping -c 4 8.8.8.8

如果 IP 可达但域名不可达，再测试 DNS：

ping -c 4 www.example.com

这一步能迅速把问题分成“网络链路问题”和“名称解析问题”两类。

五、检查 DNS 配置

如果怀疑是解析异常，可以查看解析配置：

cat /etc/resolv.conf

也可以直接验证解析结果：

getent hosts www.example.com

如果解析超时、返回空结果，或者指向了错误地址，就要回到 DNS 配置、上游解析器或网络策略继续排查。

六、看端口是否真的通

能 ping 通不代表服务一定可用，很多问题发生在传输层。可以使用以下方式测试端口：

nc -vz 192.168.1.10 443

或者：

telnet 192.168.1.10 443

如果端口不通，而主机可达，说明问题更可能出在防火墙、服务监听或中间设备策略上。

七、确认服务端是否监听

如果你能登录到目标机器，就直接确认对应端口是否在监听：

ss -lntp

定位某个具体端口：

ss -lntp | grep 8080

很多“网络不通”其实不是链路问题，而是服务根本没起来，或者监听在了错误地址上。

八、防火墙经常是关键变量

主机防火墙或云安全组都可能导致端口不可达。先看本机规则，再结合环境判断外围策略。

iptables -L -n

如果系统使用 firewalld：

firewall-cmd --list-all

中级排查时不能只盯着某一端，还要有“链路中每一层都可能阻断”的意识。

九、必要时进入抓包阶段

如果前面都看不出问题，就需要抓包确认数据包是否发出、是否到达、是否返回。

tcpdump -i eth0 port 443

抓包的价值在于用事实回答三个问题：包有没有发出去、对端有没有回、回来的包有没有被本机接收。很多模糊问题，抓包后会立刻清晰。

十、形成固定排障顺序

一个更稳妥的排查顺序通常是：先看本地地址，再看路由，再测 IP，再测域名，再测端口，最后结合防火墙和抓包深入。这样可以避免一开始就陷入细节，提升排障效率。

Linux 网络连通性排障的关键，在于建立由浅入深、由本地到远端的结构化路径。只要顺序正确，大部分网络问题都能较快缩小范围。