命令行工具是网络故障排查的核心手段，通过系统性使用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)
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 有问题。
tcpdump 的输出可能非常庞大，所以精准的过滤表达式至关重要。对于更复杂的分析，我会将 tcpdump 捕获到的 .pcap 文件导入到 Wireshark 中，利用其图形界面和强大的协议解析能力进行深度挖掘。这两种工具结合使用，能让你在网络故障面前变得无往不利。
以上就是如何通过命令行工具深度排查网络故障？的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/70443.html
微信扫一扫 
支付宝扫一扫 
