linux 服务器网络问题排查

网络问题排查，会用工具和能够抓日志，能定位问题。问题基本就解决了！（那么具体是哪些工具要熟悉的？汇总一下大概就这些）

初_xue_者

442人浏览 · 2026-05-09 08:17:27

初_xue_者 · 2026-05-09 08:17:27 发布

网络问题排查，会用工具和能够抓日志，能定位问题。问题基本就解决了！（那么具体是哪些工具要熟悉的？汇总一下大概就这些）

在硬件链路就绪后，软件层面的配置决定了业务能否跑通。本手册通过四步法，带你从互联网接入排查到容器内部。

必备工具箱： nslookup (DNS)、iproute2 (路由)、mtr (路径)、ss (端口)、iptables (防火墙)、nsenter (容器穿透)、netshoot (K8S 调试)

1. 初始配置：DNS——连接世界的“译员”

服务器连上网后的第一件事是配置 DNS，否则无法通过域名访问业务。

配置文件：/etc/resolv.conf
配置内容：添加 nameserver 114.114.114.114 或 8.8.8.8。
验证工具：nslookup baidu.com
- 正常输出：返回百度对应的公网 IP。
- 故障逻辑：若解析失败，所有基于域名的访问（如 K8S 中的 Service 名称）都会瘫痪。在 K8S 环境下，首要确认容器内的 /etc/resolv.conf 是否正确指向了集群内部的 CoreDNS 地址。

2. 状态验证：我“通”了吗？

建立网络“基准线”，确认基础出口是否可用。

连通性测试：ping baidu.com。
本地地址查询：ip addr。
- 观察点：网卡状态是否为 UP？IP 是否符合预期？
应用层验证：curl -I baidu.com。
- 深度价值：Ping 通只能证明网络层通了。curl 能验证 HTTP 协议 是否能正常响应（解决“网络通但打不开网页”的问题）。

3. 深度排查：为什么能上外网，却连不上内网？

场景： 设备 A 能上百度，但访问内网服务器 B (172.16.10.20) 失败。内网环境由于多路由器和多服务商并存，路径极其复杂。

排查步骤：对比与定位

网段对比（确定是否跨网段）：
- 将设备 A 和 B 的 IP/掩码发给 AI 助手，判断是否处于同一二层网络。
- 逻辑：若不在同一网段（如 A 是 192.168.1.10/24），流量必须经过网关。
路由决策检查：
- 执行 ip route get 172.16.10.20。
- 看什么：看内核打算把包发给哪个网关。
- 诊断：如果显示走了外网默认网关，而内网 B 应该走另一个专用路由器，说明路由表缺失，包“走错了门”。
路径追踪与断点定位：
- 执行 mtr -rw 172.16.10.20。
- 看什么：对比访问百度和访问 B 的路径快照。
- AI 协作：将 mtr 的结果直接发给 AI。若在某一跳出现 100% Loss，AI 会告诉你该节点是回程路由丢失还是防火墙拦截。

4. 容器进阶：如何访问容器内的应用？

Docker 单机容器排查

访问容器应用需要穿透宿主机映射和容器防火墙的双重屏障。

访问逻辑与排查步骤：

端口映射 (Port Mapping)：
- 执行 docker ps。确认是否有 -p 8080:80。若无映射，局域网机器无法通过宿主机 IP 访问容器。
宿主机监听状态：
- 执行 ss -tunlp | grep 8080。
- 重点：必须监听在 0.0.0.0（所有 IP）。若只在 127.0.0.1，外网无法接入。
穿透容器空间 (Debug 核心：nsenter)：
- 原理：nsenter 绕过 Docker 抽象层，直接进入容器的网络命名空间。
```
PID=$(docker inspect -f '{{.State.Pid}}' <container_id>)
nsenter -t $PID -n ss -tunlp  # 在容器内看端口是否真正启动
```
- 价值：不依赖 docker exec。即便容器内没有工具（如 alpine 镜像），也能利用宿主机的工具排查容器内部。

容器集群进阶：kubectl debug (免侵入排查)

不要试图在业务镜像里安装 mtr 或 tcpdump，那不安全也不专业。

操作命令：

kubectl debug -it <故障Pod名称> --image=nicolaka/netshoot --target=<业务容器名>

为什么用 netshoot？

它是一个专门为 K8S 设计的“军火库”，内置了第一、二篇提到的所有工具（mtr, ss, tcpdump, dig, nmap）。通过 --target 模式，它会和业务容器共享同一个网络命名空间。

本篇总结

网络问题就看着几个工具就好，作为定位问题我们只要找到对应的怀疑，然后用对应的工具测试。再然后对着返回的结果问AI或者直接看就可以

路由不通找 route，路径丢包看 mtr；进程听没听看 ss，容器进不去靠 nsenter；拦截没拦截查 iptables，K8S 疑难杂症直接上 netshoot。 拿到返回别硬抗，直接投喂给 AI 帮。

1. `ip route`：内核里的“导航仪”

很多工程师只用 ip route 看默认网关，但它最强大的功能是预演发包。

核心命令：ip route get <IP>
作用：它不真的发包，而是去问 Linux 内核：“如果我现在要给这个 IP 发个包，你会从哪个网口发？走哪个网关？”
排查价值：
- 如果输出显示 via 192.168.1.1 dev eth0，说明路由配置正确。
- 如果输出显示 unreachable，说明你本机就找不到路，包根本没下网卡就被内核丢了。
- FAE 场景：在多网卡设备（如既连内网又连 4G/5G）中，用来确认流量是否“跑偏”到了错误的网卡上。

2. `mtr`：网络界的“核磁共振”

mtr (My Traceroute) 结合了 ping 和 traceroute 的优点。

作用：它会持续向目标发送探测包，并列出路径上每一个路由器的响应情况。
看懂数据：
- Loss%：丢包率。如果中间某一跳开始丢包率持续在 100%，那这里就是断点。
- Last/Avg/Best/Worst：延迟情况。如果延迟在某一跳突然翻倍，说明该跳的路由器处理能力遇到瓶颈。
排查价值：直接拿着 mtr 的截图发给网络管理员，告诉他：“包在 10.0.0.5 这一跳断了”，这比说“网不通”要专业 100 倍。

3. `ss`：协议栈的“体检表”

ss (socket statistics) 是 netstat 的现代替代品，速度更快，信息更全。

常用组合：ss -tunlp（tcp, udp, numeric数字显示, listening监听, process进程信息）
作用：确认系统里到底有哪些门（端口）是开着的，以及是谁（PID）开的。
排查价值：
- 看 Local Address：如果显示 127.0.0.1:80，说明服务只给本机用，外面连不上。必须是 0.0.0.0 或 *。
- 看 Send-Q / Recv-Q：如果这两个数值很大且不减少，说明程序处理不过来了，网络堵塞在应用层。

4. `nsenter`：跨空间的“任意门”

这是排查容器问题的“神技”。

底层原理：Linux 容器的本质是 Namespace (命名空间)。nsenter (NameSpace Enter) 可以让一个进程“钻进”另一个进程的命名空间。
作用：
- 场景：容器里往往为了精简，连 ip、ping 都没有。
- 方案：你在宿主机运行 nsenter -t <容器PID> -n <命令>。
- 结果：你是在用宿主机上功能强大的工具（如 tcpdump），去检查那个“空空如也”的容器网络。它像是一台手术相机，伸进了容器内部。

5. `iptables`：流量的“安检员”

Linux 内核的防火墙，Docker 和 K8S 的底层转发全部依赖它。

核心逻辑：
- INPUT：进本机的包。
- FORWARD：经过本机发往容器的包（FAE 重点）。
- OUTPUT：本机发出的包。
排查价值：
- 如果 ping 通但端口不通，且 ss 显示服务正常，那 90% 是 iptables 的 REJECT 或 DROP 规则在捣鬼。
- 使用 iptables -nvL 查看规则时，注意 pkts（包计数）。如果有规则的计数在疯涨，说明流量正在被这条规则持续拦截。

6. `netshoot`：K8S 里的“特种兵工具箱”

它不是一个简单的工具，而是一个封装了所有上述工具的 Docker 镜像。

为什么用它？

在 K8S 中，Pod 是动态的，镜像是个黑盒。netshoot 通过 kubectl debug 模式，直接强行“挂载”到故障 Pod 的网络上。
实战动作：当你发现 Pod A 连不上 Pod B，直接在 A 上启动一个 netshoot 临时容器，在里面运行 mtr 或 tcpdump，这被称为“侵入式诊断”。