如何通过命令行工具深度排查网络故障？-硬件测评-PHP中文网

命令行工具是网络故障排查的核心手段，通过系统性使用ping、traceroute、ip、netstat、tcpdump等工具，可从连通性、路径、配置、端口、DNS到流量层面逐步定位问题。ping用于检测可达性与延迟丢包，traceroute揭示路径中瓶颈跳点，结合二者可快速判断故障位置；ip addr和ip route检查本地IP与路由配置，避免基础错误；netstat与ss分析端口监听与连接状态，识别占用进程及异常连接；telnet或nc测试端口连通性，确认传输层可达；dig或nslookup排查DNS解析异常；当上述工具无法定位时，tcpdump抓包深入分析TCP握手、应用层交互等细节，结合过滤表达式和Wireshark可精准诊断协议级问题。整个流程体现由表及里的排查思维，实现对网络问题的全面掌控。

如何通过命令行工具深度排查网络故障？

命令行工具，对我来说，是网络故障排查的真正利器。它们能让你剥开层层抽象，直抵网络通信的本质，看到那些图形界面工具往往选择性忽略的细节。很多时候，一个看似复杂的网络问题，在几条简单的命令行指令下就能露出马脚，那种拨云见日的感觉，是作为技术人最享受的瞬间之一。

在排查网络故障时，我们往往需要一系列系统性的操作来逐步缩小范围，从宏观到微观，最终定位问题所在。这不仅仅是敲几条命令那么简单，更是一种思维流程的体现。

解决方案

当网络出现问题时，我通常会遵循以下步骤，结合不同的命令行工具进行深度排查：

确认基础连通性与路径：
- ping： 这是最基本的，用来检查目标主机是否可达以及响应时间。我通常会加上 -c 参数限制次数，或者 -i 设定间隔，比如 ping -c 5 google.com。如果 ping 不通，或者延迟很高、丢包严重，这本身就是个重要的线索。
- traceroute (Linux/macOS) / tracert (Windows)： 这个工具能显示数据包从源到目的地的路径，以及每个跳点的延迟。这对于判断问题是出在本地网络、ISP、还是目标服务器端非常关键。我经常会用它来找出路径中的瓶颈或者中断点。比如，traceroute google.com，看到某个跳点突然不响应或者延迟骤增，那问题可能就在那个区域。
检查本地网络配置与接口状态：
- ip addr (Linux) / ifconfig (macOS) / ipconfig (Windows)： 确认本地IP地址、子网掩码、网关是否正确。一个常见的错误就是IP地址冲突或者配置错误。
- ip route (Linux) / netstat -rn (macOS/Windows)： 检查路由表。确保有到达目标网络的正确路由，特别是默认网关是否指向正确。我遇到过几次，因为路由表里多了一条不该有的静态路由，导致部分流量去了“黑洞”。
分析端口与服务状态：
- netstat / ss (Linux)： 这些工具能显示所有活动的网络连接、监听端口以及相关的进程。netstat -tulnpa 或 ss -tulnp 是我的常用命令，它能告诉我哪些端口正在被监听，哪些连接是建立的，以及是哪个进程在使用这些端口。这对于排查服务无法启动、端口冲突或者是否有异常连接非常有效。
- telnet / nc (netcat)： 如果怀疑某个服务端口不通，可以用 telnet IP_ADDRESS PORT 或 nc -vz IP_ADDRESS PORT 来测试端口的可达性。这比 ping 更进一步，直接测试应用层端口。如果 telnet 能连上，说明网络层和传输层基本没问题，问题可能在应用层配置。
排查DNS解析问题：
- nslookup / dig： 当访问域名不通但IP地址正常时，DNS问题是首要怀疑对象。dig google.com @8.8.8.8 可以指定DNS服务器进行查询，这能帮助判断是本地DNS服务器的问题，还是域名本身解析的问题。
深入流量抓包分析：
- tcpdump： 这是终极武器。当上述工具都无法明确指出问题时，抓取实际的网络流量包进行分析，往往能揭示真相。tcpdump -i eth0 host 192.168.1.1 and port 80 可以抓取特定接口、特定主机和端口的流量。通过分析TCP三次握手是否完成、HTTP请求响应是否正常，甚至可以看到应用层的数据内容，这对于定位协议层面的问题是不可或缺的。

如何利用`ping`和`traceroute`快速定位网络延迟与丢包源头？

ping 和 traceroute 简直是网络诊断的“瑞士军刀”，看似简单，但用好了能解决大部分基础问题。

ping 的核心是发送 ICMP Echo Request 包，然后等待 Echo Reply。我通常会观察三个指标：响应时间（延迟）、丢包率和TTL（Time To Live）。

高延迟： 如果 ping 目标地址的延迟很高，比如几百毫秒甚至上秒，那可能意味着网络拥堵、链路质量差，或者目标服务器负载过高。我会尝试 ping 一些公共的、地理位置相对近的服务器（比如本地ISP的DNS服务器），如果延迟正常，那么问题可能出在我的网络到目标服务器之间的路径上。
丢包： 丢包率高是一个严重信号，它直接影响数据传输的可靠性。这可能是物理链路故障、路由器负载过高、防火墙拦截或者无线信号干扰造成的。ping -c 100 google.com 这样的命令能帮你长时间观察丢包情况。
TTL： TTL 值表示数据包在网络中可以“存活”的跳数。每次经过一个路由器，TTL就会减1。通过观察 ping 返回的 TTL 值，可以大致判断目标服务器的操作系统（Windows通常是128，Linux/Unix通常是64或255）以及数据包经过的跳数。如果 TTL 值异常低，可能表示数据包在到达目的地之前被太多设备处理了。

traceroute 则是在 ping 之后，更进一步地描绘出数据包的旅程。它通过发送一系列带有递增 TTL 值的包，来探测路径上的每一个路由器。

解读输出： traceroute 的每一行代表一个跳点（路由器）。它会显示跳点的IP地址（如果能解析会显示域名）以及到达该跳点的三次探测时间。
定位问题： 如果某个跳点的响应时间突然飙升，或者连续几个跳点都显示 * * *（表示超时），那么问题很可能就出在那个跳点或者它之后。例如，我曾经遇到一个问题，traceroute 在第三跳之后就全部超时，后来发现是公司防火墙的配置问题，它阻止了外部的 ICMP 包通过。
选项： traceroute -I 强制使用 ICMP 探测，这在某些网络环境下可能更准确，因为有些路由器会优先处理 ICMP 而非 UDP（默认）。traceroute -T 可以使用 TCP SYN 包进行探测，这对于测试特定端口的路径非常有用，尤其是在防火墙可能拦截 ICMP 的情况下。

结合使用这两个工具，你就能快速判断是“通不通”、“通了慢不慢”以及“慢在哪里”的问题。

深入解析`netstat`与`ss`：如何识别异常连接和端口占用？

netstat 和 ss 是检查本地系统网络连接和端口状态的强大工具。它们能让你对系统当前的“网络脉搏”一清二楚。

netstat (Network Statistics)

netstat 是一个历史悠久的工具，几乎所有操作系统都有。我最常用的组合是 netstat -tulnpa：

-t: 显示 TCP 连接。
-u: 显示 UDP 连接。
-l: 仅显示监听（Listening）状态的套接字。
-n: 以数字形式显示地址和端口号，不进行域名解析，这样速度更快，也避免了DNS解析可能带来的干扰。
-p: 显示拥有该套接字的进程ID（PID）和进程名称。这对于找出哪个程序占用了某个端口至关重要。
-a: 显示所有连接和监听端口。

例子： netstat -tulnpa | grep 80 可以快速找出监听在 80 端口的服务进程。

解读连接状态：

LISTEN： 表示该端口正在等待传入连接。例如，一个Web服务器会在 80 端口上处于 LISTEN 状态。
ESTABLISHED： 表示一个活动的、已建立的连接。这是正常通信的状态。
TIME_WAIT： 表示连接已关闭，但系统仍在等待，以确保所有数据包都已到达。大量的 TIME_WAIT 状态可能导致端口耗尽，影响新连接的建立。
CLOSE_WAIT： 表示远程主机已关闭连接，但本地应用程序尚未关闭。这通常意味着应用程序代码存在问题，没有正确关闭套接字。

识别异常：

端口冲突： 如果你尝试启动一个服务，但它报错说端口已被占用，netstat -tulnpa | grep PORT_NUMBER 就能告诉你哪个进程正在使用它。
未知连接： 如果发现有大量到奇怪IP地址的 ESTABLISHED 连接，或者有不应该存在的 LISTEN 端口，这可能就是系统被入侵或恶意软件活动的迹象。

ss (Socket Statistics)

简篇AI排版

AI排版工具，上传图文素材，秒出专业效果！

554

查看详情

ss 是 netstat 的继任者，在 Linux 系统上它更快、更强大，因为它直接从内核空间获取信息，而 netstat 依赖 /proc 文件系统。对于大型系统或需要频繁查询时，ss 的优势非常明显。

我常用的 ss 命令是 ss -tulnpa，参数含义与 netstat 类似。

ss 的一些高级用法：

过滤： ss -s 可以显示套接字统计信息。ss -o state established '( dport = :http or sport = :http )' 可以查看所有与 HTTP 端口相关的已建立连接。
进程信息： ss -p 也能显示进程信息。
TCP 状态： ss -nt state established 可以只显示 TCP 的已建立连接。
内存使用： ss -m 可以显示套接字的内存使用情况。

选择： 在 Linux 环境下，我个人更倾向于使用 ss，尤其是在排查性能问题时，它的速度和提供的额外信息（比如 TCP 窗口大小、拥塞控制算法等）非常有帮助。但 netstat 仍然是跨平台和快速检查的可靠选择。

通过这两个工具，你可以像医生给病人听诊一样，感知到系统网络的“心跳”，及时发现异常。

何时需要`tcpdump`进行抓包分析，以及如何解读复杂的网络流量？

tcpdump 是我排查网络故障的“杀手锏”，它能让你看到网络中流动的每一个数据包，这对于定位那些深层次、协议层面的问题是不可或缺的。通常，当 ping、traceroute、netstat 等工具都无法给出明确答案时，就该请出 tcpdump 了。

何时使用 tcpdump？

应用层通信问题： 比如，Web服务器返回 500 错误，客户端与服务器握手失败，或者某个自定义协议无法正常工作。tcpdump 可以捕获实际的请求和响应，帮助你看到应用层数据。
防火墙或安全组误配置： 怀疑是防火墙拦截了特定流量，但日志没有明确记录。通过 tcpdump 在服务器内外侧同时抓包，可以判断数据包是在哪里被丢弃的。
性能瓶颈分析： 观察 TCP 窗口大小、重传、乱序等情况，判断是网络拥堵、服务器处理慢还是客户端发送慢。
DDoS 攻击或异常流量： 识别大量异常的连接请求、特定端口的扫描等。
DNS 解析异常： 抓取 DNS 请求和响应包，看解析过程是否正常，是否有缓存污染等。

tcpdump 的基本用法和解读：

tcpdump 的命令格式通常是 tcpdump [options] [expression]。

-i interface： 指定要监听的网络接口，比如 eth0、en0。
-n： 不将IP地址解析为主机名，不将端口号解析为服务名，这能加快显示速度。
-vvv： 详细输出，显示更多协议信息。
-s 0： 捕获完整的数据包内容（默认只捕获前96字节）。
-w filename.pcap： 将捕获到的数据包保存到文件，以便后续使用 Wireshark 等工具进行图形化分析。

过滤表达式： 这是 tcpdump 最强大的部分，可以让你只捕获你关心的流量。

host IP_ADDRESS： 捕获与指定IP地址相关的所有流量。
port PORT_NUMBER： 捕获与指定端口相关的所有流量。
src host IP_ADDRESS / dst host IP_ADDRESS： 捕获源IP或目的IP为指定地址的流量。
tcp / udp / icmp / arp： 捕获指定协议的流量。
and / or / not： 组合过滤条件。

示例：

tcpdump -i eth0 -n host 192.168.1.1 and port 80：抓取 eth0 接口上，源或目的为 192.168.1.1 且端口为 80 的所有 TCP 流量。
tcpdump -i any -n icmp：在所有接口上抓取所有 ICMP 流量。

解读复杂流量：

这需要一定的网络协议知识，但一些常见模式可以帮助你快速定位：

TCP 三次握手：
- [SYN]：客户端发送同步序列号请求。
- [SYN, ACK]：服务器响应同步和确认。
- [ACK]：客户端发送确认。
- 如果只看到 SYN，没有 SYN, ACK，可能服务器没启动服务，或者防火墙拦截。
- 如果看到 SYN, ACK，但没有 ACK，可能客户端防火墙拦截了，或者客户端有问题。
HTTP/HTTPS 流量：
- 看到 GET /index.html HTTP/1.1 这样的请求，然后看到 HTTP/1.1 200 OK 这样的响应，说明通信正常。
- 如果看到请求，但响应是 404 Not Found 或 500 Internal Server Error，那问题出在应用层。
- 对于 HTTPS，抓包内容是加密的，你只能看到 TCP/IP 层面的交互，但仍然可以判断握手是否成功、是否有重传等。
DNS 查询：
- DNS Standard query A www.example.com：客户端查询 www.example.com 的 A 记录。
- DNS Standard query response A 1.2.3.4：DNS 服务器响应 IP 地址。
- 如果查询发出后没有响应，或者响应是 NXDOMAIN（域名不存在），那说明 DNS 有问题。