小狐狸与小道士搞网络、搞运维、搞安全的兄弟，几乎没人能绕开 tcpdump。它是 Linux 系统上最老牌、最底层的命令行抓包工具，基于 libpcap 库工作，能直接采集网卡上经过的每一个报文，并以你能看懂的方式打印出来。说白了，当你在服务器上怀疑接口超时、DNS 解析变慢、连接被重置，又没法在客户端装 wireshark 或者 fiddler 的时候，tcpdump 就是第一选择。它能让你在没有任何图形界面的生产环境里，用最短的时间定位“包到底有没有来”“包到底去了哪里”这类最基础、也最致命的问题。
这篇文章我想按照自己实战中用 tcpdump 的经验来写，从安装到常用参数，从过滤语法到长时抓包，再到真实排障场景，完整过一遍。适合刚接触 Linux 网络排查的初级运维，也适合那些已经会用几分但总在细节上卡壳的开发同学。只要照着敲一遍，再遇上网络问题，你至少能自己先看一眼报文，而不是全靠猜。
1. 上手前先搞清楚：tcpdump 为什么是绕不开的抓包工具
1.1 抓包的底层逻辑和 tcpdump 的工作原理
抓包本质上就是“旁听”网卡上的网络流量。网卡收到数据帧之后，正常情况下只会把发往本机的报文交给内核协议栈处理，而 tcpdump 这类基于 libpcap 的工具，会先把网卡设置成“混杂模式”（promiscuous mode），也就是把经过该网卡的所有报文都复制一份给抓包程序，再由 BPF（Berkeley Packet Filter）做过滤，最终只把符合条件的报文呈现给你。
这里要理解一个关键点：tcpdump 抓到的是“报文的副本”，它不会影响报文继续走正常的内核协议栈。也就是说，你抓包的时候流量是正常流转的，不存在“因为你在抓包所以应用就出错”的情况（除非你同时做了什么额外干预）。我见过有些同事一抓包就紧张，怕影响线上业务，其实对于网卡抓包来说，通常只需要担心的是抓包流量过大把磁盘写满，而不是抓包本身会打断业务连接。
BPF 是这个工具的灵魂。tcpdump 之所以效率高，是因为过滤动作发生在内核态，只有匹配到的报文才会被拷贝到用户态打印，而不是把所有流量全捞上来再慢慢挑。所以平时写抓包命令时，尽量把过滤条件写到 tcpdump 的参数里，而不是先抓全量再回去用 grep 筛，这既是效率问题，也是磁盘空间的生存问题。
1.2 和 wireshark、fiddler、charles 等工具的定位差异
总有人问：我电脑上装了 wireshark，为什么还要用 tcpdump？答案很简单：wireshark 是图形化工具，很适合人眼分析，但它不能直接抓服务器上的包，也不能在一台没有显示器的 Linux 主机上跑。fiddler、charles 这类更倾向于 HTTP/HTTPS 层面的代理抓包，它们能解开请求和响应，能篡改报文，但在“网卡层的原始包”面前，它们不是同一个维度的工具。
tcpdump 更像是一个“底层取证工具”。代理类工具看不到 TCP 重传，看不到握手过程，看不到 SYN 包有没有回应，而这些恰恰是网络排查里最关键的证据。tcpdump 抓下来的 pcap 文件，可以拿到本地用 wireshark 打开慢慢分析，这也是最经典的组合姿势：服务器端用 tcpdump 采集，本地用 wireshark 还原线索。
所以我的建议是：这几个工具不是竞争关系，而是互补。生产环境用 tcpdump 拿原始的包，本地用 wireshark 做协议解析和可视化分析，日常调试接口可以用 fiddler 或 charles 看 HTTP 层的信息。但如果你只会用 fiddler 点按钮，从来没在服务器上敲过 tcpdump，那遇到线上问题大概率会束手无策。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 从安装到第一个抓包：环境准备与快速起步
2.1 在线安装与离线安装，两条路径都给你铺好
在线安装非常直接。Debian 系用 apt，CentOS/RHEL 系用 yum，Alpine 用 apk，几乎一行命令就能搞定。
bash复制# Debian / Ubuntu
apt-get update && apt-get install -y tcpdump
# CentOS / RedHat / Rocky
yum install -y tcpdump
# Alpine
apk add tcpdump
安装完先验证一下版本和可用的网卡接口：
bash复制tcpdump --version
ip link show
离线安装就稍微有点讲究了。内网服务器没有外网权限，最常见的方式是在一台能连外网的机器上把 rpm 包拉下来，传到内网安装。这里要注意，tcpdump 依赖 libpcap，所以至少需要两个 rpm 包。用 yumdownloader 可以自动把依赖一起下载下来：
bash复制# 在外网机器上执行
yum install -y yum-utils
yumdownloader --resolve --destdir=/tmp/tcpdump_rpm tcpdump
然后把 /tmp/tcpdump_rpm 目录下的所有 rpm 包拷贝到内网服务器，按依赖顺序安装：
bash复制rpm -ivh libpcap-*.rpm
rpm -ivh tcpdump-*.rpm
如果内网还是老旧的 RHEL 6 或者 CentOS 7，也可以在官方源里找对应版本的 rpm 包手动下载。安装完运行 tcpdump --version，能看到版本信息就说明装好了。有一点值得提醒：有些精简版系统可能缺少 libpcap 的底层库模块，装完 tcpdump 后执行任意抓包命令直接报 libpcap.so: cannot open shared object file，这时候检查一下 libpcap 的 so 文件是不是真的装上去了，必要时用 ldd $(which tcpdump) 看一眼依赖。
2.2 5 分钟跑通第一个抓包命令
安装完成后，最基础的一个抓包命令长这样：
bash复制tcpdump -i any -nn
-i any 表示抓所有网卡的流量，-nn 表示不做域名解析也不把端口号解析成服务名。这里我强烈建议所有初学阶段的人都加上 -nn，不然 DNS 反查会拖慢抓包速度，而且一堆 https、ssh 之类的服务名远不如 443、22 直观。
运行之后你会发现屏幕上开始刷一行一行的数据，但你可能看不懂。不要慌，先开另一个终端，随便 ping 一个地址，比如 ping 8.8.8.8，然后回去看 tcpdump 输出，你会看到类似这样的内容：
text复制12:08:33.112344 IP 192.168.1.10 > 8.8.8.8: ICMP echo request, id 1, seq 1, length 64
12:08:33.132890 IP 8.8.8.8 > 192.168.1.10: ICMP echo reply, id 1, seq 1, length 64
到这里，你的 tcpdump 已经能用了。结合 ping 这种常用工具来验证抓包效果，是我最推荐的新手起步方式，因为你确切知道这个时刻有哪些流量在出现，对照看输出就不会茫然。要是 ping 的输出和 tcpdump 的输出对不上，问题多半出在 -i any 上，有的系统里 any 虚拟接口抓不到某些流量，换成实际网卡设备名再试。
3. 核心参数与过滤表达式：把抓包从“能用”变成“好用”
3.1 那些必须吃透的基础参数
tcpdump 的参数不算多，但每一个都很实用。我把自己在真实场景里从来不用的花哨参数去掉，按重要性从高到低列出来：
-i <interface>：指定抓包网卡，最常用，可以用-i any抓所有网卡。-nn：不解析主机名和端口名，建议新手默认带上。-c <count>：抓取指定数量的报文后自动退出，适合快速验证。-s <snaplen>：每个报文抓多长，默认 262144 字节（旧版本是 65535），如果只关心包头可以设-s 96，有效减小文件体积。-w <file>：把原始报文写入 pcap 文件，不打印到终端。-r <file>：读取 pcap 文件并解析。-e：显示数据链路层头部信息，也就是源 MAC 和目的 MAC。-XX：同时以十六进制和 ASCII 形式显示报文内容，适合做协议分析。-v / -vv / -vvv：控制输出详细程度，排障时-vv已经是上限了，太多信息反而干扰。-G <seconds>：每隔指定秒数生成一个新文件，常与-w配合做长时间抓包。-C <file_size>：每个文件写到指定大小（单位 MB）后切换新文件。-Z <user>：抓包时以指定用户运行，安全考虑用的，普通场景不必在意。
对于初学者，我建议先把 -i、-nn、-c、-w、-r 这几个练熟，这些已经能覆盖大部分日常排障需求。-XX 这种在做协议字段分析时会用到，但没有 -w 配合的话，刷屏效果也很劝退。
3.2 过滤表达式实战：host、port、tcp 与组合逻辑
tcpdump 的过滤表达式是它最强的能力之一，也是初学阶段最容易卡壳的地方。记住一个核心原则：过滤表达式不是参数，它通常是命令行里最后一段，而且需要注意表达式整体加不加引号的问题——如果表达式里有空格或者特殊字符，建议用单引号包起来。
最常用的几类过滤条件：
bash复制# 按 IP 过滤
tcpdump -i eth0 -nn host 192.168.1.100
# 按端口过滤
tcpdump -i eth0 -nn port 443
# 按方向过滤
tcpdump -i eth0 -nn src host 192.168.1.100
tcpdump -i eth0 -nn dst host 192.168.1.100
# 按协议过滤
tcpdump -i eth0 -nn tcp
tcpdump -i eth0 -nn udp
tcpdump -i eth0 -nn icmp
组合逻辑用 and、or、not 三个关键字。比如我想抓“来自 192.168.1.100 且访问 80 端口”的包：
bash复制tcpdump -i eth0 -nn src host 192.168.1.100 and tcp port 80
再比如抓“跟 10.0.0.5 的 443 端口相关的所有包，但不包括 10.0.0.6 的流量”：
bash复制tcpdump -i eth0 -nn host 10.0.0.5 and port 443 and not host 10.0.0.6
还有一类非常实用的是端口范围过滤：
bash复制tcpdump -i eth0 -nn tcp dst portrange 8000-9000
这个在排查微服务调用链路时特别好用，一个命令覆盖一整段服务端口。
另外提醒一点：and 的优先级高于 or，如果你混用两者，最好用括号把条件分组明确一下：
bash复制tcpdump -i eth0 -nn 'host 192.168.1.100 and (port 80 or port 443)'
这里括号一定要用单引号包起来，不然 shell 会先把括号解释掉，你就等着报语法错误吧。这个坑我用 tcpdump 的早期基本必踩一次。
3.3 输出内容深度解读：看懂每一段字段
tcpdump 的默认输出看似乱七八糟，实际上结构非常固定，逐段拆开看就简单了。拿一条典型的 TCP 握手包来说：
text复制12:08:33.112344 IP 192.168.1.10.58234 > 93.184.216.34.443: Flags [S], seq 2852048180, win 64240, options [mss 1460,sackOK,TS val 2738561844 ecr 0,nop,wscale 7], length 0
从左往右拆开解析：
12:08:33.112344是包捕获时的时间戳，精确到微秒级，看这个可以判断时延。IP表示网络层协议是 IPv4，如果是 IPv6 会是IP6，ARP 包的这里就写ARP。192.168.1.10.58234是源地址加源端口，中间用点隔开，注意这里因为加了-nn才能直接看到端口号，不加的话会显示成58234对应的服务名或者直接看不到。>表示方向，从源到目的。93.184.216.34.443是目的地址加端口。Flags [S]是 TCP 标志位，S是 SYN，P是 PSH，F是 FIN，R是 RST，.表示 ACK。组合如[S.]表示 SYN+ACK。seq 2852048180是 TCP 序列号。win 64240是接收窗口大小，表示本端还能接收的字节数，这个值异常变小往往意味着接收端处理不过来。options [...]是 TCP 选项，像 MSS、时间戳都是在这里。length 0表示负载长度，0 表示纯握手包或 ACK 包。
看到这里你应该明白，tcpdump 本身已经把 TCP 状态机拆得很清楚了。排障时你不需要完整看懂每个字段，只需要根据 Flags 和前几个字节判断“这个连接到底卡在哪一步”。比如一直看到 Flags [S] 发出去但没有 [S.] 回来，那就是目的主机不可达或者被防火墙拦了；如果反复出现 Flags [R]，那往往是被对端主动拒绝，通常和端口没监听有关。
4. 高阶操作：长时间抓包、文件管理与和 wireshark 联动
4.1 长时间抓包的两种正确姿势
生产环境排障经常要挂几小时甚至一整晚的抓包，不可能一直开着终端盯着屏幕。这时候有两个方向：后台运行，或者文件轮转。
后台运行最简单，配合 nohup 把抓包进程放后台，并把日志和抓包文件分开写：
bash复制nohup tcpdump -i eth0 -nn -w /data/capture/traffic.pcap 'port 8080' > /tmp/tcpdump.log 2>&1 &
但这里有个隐患：pcap 文件会一直变大，直到磁盘写满。所以我更推荐用文件轮转的方式，按时间或者按大小把抓包文件切分成多个小文件。
按时间切割，每个小时一个文件，最多保留 24 个文件：
bash复制tcpdump -i eth0 -nn -w /data/capture/traffic-%Y%m%d%H%M%S.pcap -G 3600 -W 24 'tcp port 8080'
注意 -G 配合文件名里的时间格式，tcpdump 会在指定的间隔（秒）后自动切换到新文件。-W 限制最多保留多少个文件，超过会覆盖最老的文件，防止磁盘被塞满。
按大小切割也很常见：
bash复制tcpdump -i eth0 -nn -w /data/capture/traffic.pcap -C 512 'tcp port 8080'
-C 512 表示单个文件写到 512MB 就切换下一个文件，文件名为 traffic.pcap、traffic.pcap1、traffic.pcap2 这种递增方式。
我个人在长时间抓包时倾向于按时间切割，因为排查问题的时候，按时间点去找对应时段的文件远比在几个大文件里翻来翻去方便。另外无论怎么切割，都建议先用 du -sh 看一下目录增长速度，估算能不能撑住一整晚。
4.2 分析阶段的提速套路：wireshark 和 tshark 怎么接棒
tcpdump 抓到文件之后，大头的分析工作我基本不在终端里做，而是拿回本地用 wireshark 打开。wireshark 的图形界面能直观展示 TCP 流、HTTP 请求、TLS 握手，还能通过“统计”菜单快速看到哪类报文最多、哪段链路时延最大。
但也许你已经发现，直接打开一个几百 MB 的 pcap 文件，wireshark 会卡出脾气。这时候先用 capinfos 或者 tshark 在外面预处理一下会舒服很多。比如先看看文件基本信息：
bash复制capinfos traffic.pcap
想知道文件里一共抓了多少包、多少流量、有多少 TCP 连接，可以用：
bash复制tshark -r traffic.pcap -q -z io,phs
tshark -r traffic.pcap -q -z conv,tcp
如果只想把某个 IP 相关的包单独抽出来存成小文件，再用 wireshark 打开：
bash复制tshark -r traffic.pcap -w filter.pcap -Y 'ip.addr == 192.168.1.100'
这里的 -Y 是 wireshark 显示过滤器语法，比 tcpdump 的 BPF 更灵活，可以按 HTTP 状态码、TCP 流、甚至 DNS 域名来过滤。我通常的流程是：tcpdump 采集全量，tshark 做初步统计和筛选，wireshark 对可疑流量做逐包分析，三个工具配合起来才完整。
4.3 从 pcap 里还原应用层数据：一个实测例子
抓包不只看握手，很多时候要还原应用层内容。比如排查一个 HTTP 接口返回异常，抓包时加上 -XX 会在终端直接把十六进制编码的请求内容打出来，但内容多的时候看终端太吃力，更好的方式是把 pcap 文件拿回本地，用 wireshark 的“追踪 HTTP 流”功能，一个 HTTP 请求和响应就能拼起来看，连响应体都能看到。
如果只在服务器上想快速看应用层数据，可以用 -A 参数，只把每个报文的 ASCII 内容打印出来：
bash复制tcpdump -i eth0 -nn -A -s 0 -w /tmp/http.pcap -c 100 'tcp port 8080'
然后用 strings 处理 pcap 文件里的文本内容也能应急看个大概。但这种做法只适合临时凑合，真正的结构化分析还是交给 wireshark 类工具，原因很简单：手写的 HTTP 解析很容易出边界问题，而 wireshark 已经把所有协议解析做得足够成熟了。
5. 实战场景：排障时最常用的几个抓包案例
5.1 排查 HTTP 接口超时：从三次握手到响应耗时
接口超时是最常见的网络投诉，在服务器上抓包能直接分辨出故障在哪个环节。假设服务监听在 8080 端口，客户端 IP 是 192.168.1.100，同时开两个终端，一个抓包，一个看应用日志：
bash复制tcpdump -i eth0 -nn 'tcp port 8080 and host 192.168.1.100' -w /tmp/api_timeout.pcap
抓到一定量之后 Ctrl+C 停止，然后用 tshark 统计时间戳差：
bash复制tshark -r /tmp/api_timeout.pcap -q -z io,stat,0
分析时只要看三点：TCP 握手的 SYN、SYN-ACK、ACK 三包之间时间间隔；HTTP 请求发出后到响应第一个字节的时间；响应包和中间是否有重传。
如果 SYN 包发出去很久才收到 SYN-ACK，多半是网络链路慢或者中间设备丢包；如果三次握手很快，但请求发出后迟迟没有第一个响应字节，那问题十有八九在应用本身处理慢，跟网络没啥关系。抓到这一步，运维不用背锅，开发也能拿着 pcap 去查自己代码，整个排查效率提升一个档次。
5.2 排查 DNS 解析异常：用一条命令看穿“假故障”
DNS 解析问题经常表现得非常诡异：有时能解析，有时超时，有时解析出错误 IP。用 tcpdump 抓 DNS 请求是最直接的定位方式。DNS 使用 UDP 53 端口，抓包命令：
bash复制tcpdump -i eth0 -nn 'udp port 53'
运行后触发一次解析，比如 nslookup example.com，输出大概是：
text复制12:20:31.982301 IP 192.168.1.10.51234 > 8.8.8.8.53: 3841+ A? example.com. (31)
12:20:32.013903 IP 8.8.8.8.53 > 192.168.1.10.51234: 3841 1/0/0 A 93.184.216.34 (47)
这里最有用的信息是中间那个 3841+ 和后面的 1/0/0。3841 是 DNS 事务 ID，请求和响应必须一致，对不上就说明中间有人拦截或劫持；+ 表示请求设置了递归查询标志；1/0/0 表示响应中有一个回答、零个权威记录、零个附加记录。如果你发现请求发出去后没有任何响应，那就是 DNS 服务器根本没回包，可能是防火墙把 UDP 53 给丢了，也可能是上游 DNS 挂了。这类检查看 tcpdump 一眼就能定位，比在 /etc/resolv.conf 里猜来猜去靠谱得多。
5.3 定位丢包与重传：网络质量差到底差在哪
网络质量差的典型表现是应用偶尔卡顿、文件传输中途断开、音视频通话花屏。这些现象的底层原因往往是 TCP 重传。tcpdump 抓包时，只要看到大量重复的 seq 号或者带重传标志的包，就能判定链路上存在丢包。
一个非常实用的抓法：
bash复制tcpdump -i eth0 -nn 'tcp[tcpflags] & (tcp-syn|tcp-fin|tcp-rst) != 0 or tcp[13] & 8 != 0'
这个表达式稍微复杂一点，目的是抓所有 TCP 连接建立（SYN）、释放（FIN）、重置（RST）以及带 PSH 标志的数据包，能更清晰地反映连接生命周期。不过排重传不用这么复杂，直接抓全量 TCP 流量然后用 wireshark 的 Expert Info 看重传次数也行：
bash复制tcpdump -i eth0 -nn -w /tmp/net_quality.pcap 'tcp'
tshark -r /tmp/net_quality.pcap -q -z io,stat,0
tshark -r /tmp/net_quality.pcap -Y 'tcp.analysis.retransmission'
最后一条如果输出很多，说明重传比例很高。这时再打开 -Y 'tcp.analysis.retransmission' 过滤出来的报文，看源目地址和端口，基本就能判断是哪个链路和哪个连接出了问题。是公网链路抖动，还是内网交换机丢包，再到对应链路去排查即可。
6. 常见问题与排查技巧实录
6.1 高频报错与解决方案速查表
以下这些报错，我在实际用 tcpdump 时基本都遇到过，整理成速查表供参考：
| 报错信息 | 原因 | 解决方法 |
|---|---|---|
tcpdump: eth0: You don't have permission to perform this capture |
当前用户权限不足 | 用 root 执行或加 sudo |
tcpdump: eth0: No such device exists |
网卡名写错了 | 用 ip link show 查看正确的网卡名 |
tcpdump: eth0: That device is not up |
网卡处于 down 状态 | ip link set eth0 up 先拉起网卡 |
libpcap.so: cannot open shared object file |
libpcap 没装或版本不对 | 重装匹配版本的 libpcap |
tcpdump: syntax error |
过滤表达式写错 | 检查括号引号，用 tcpdump -dd 'expression' 调试语法 |
tcpdump: tcpdump: pcap_loop: The interface went down |
网卡中途被 down 了 | 检查网络配置，避免操作网卡 |
| 抓包文件飞速增长占满磁盘 | 没加轮转或过滤条件 | 用 -C / -G 做轮转，收窄过滤条件 |
权限问题最常见，但很多人会忽略 tcpdump 在有的发行版上只允许 root 用户使用，普通用户的 sudoers 配置也可能不包含 tcpdump。所以如果你在容器或者最小化环境里跑 tcpdump，先确认当前用户身份和 sudo 权限是第一步。
6.2 为什么抓到的包和预期不一样？四个经典误区
抓包结果对不上预期，这大概是我见过最多的求助类型了。归纳下来主要有四个原因。
第一，没有开启混杂模式。默认抓包时 tcpdump 会自己尝试把网卡切到混杂模式，但某些虚拟化环境或者容器网络模式下这个设置不生效，导致你只能抓到进出本机的流量，抓不到经过网卡但目标不是本机的包。排障时先确认自己的网卡到底能不能看到物理链路全量流量，如果环境不支持，那换抓包位置是唯一出路。
第二，过滤条件本身写错。比如想抓目的端口 8080，但写成了 port 8080，这实际上把源端口或目的端口为 8080 的都抓了，当然会多出很多无关报文。新手最容易忽略方向限定，老老实实写上 dst port 或 src port，输出立刻干净许多。
第三，内核或驱动丢包。流量轻微的丢包不会影响业务，但对于抓包来说，环形缓冲区一旦被塞满，新报文会被内核直接丢弃，导致你抓到的报文本就不完整。这时可以加 -B 参数调大缓冲区，比如 -B 4096 表示 4MB 缓冲区，能有效减少用户态来不及读取导致的丢包。
第四，抓包时机不对。有人跑了个抓包命令但只抓了 3 秒，然后断言“没有流量”，这种结论显然站不住脚。确认是持续流量还是偶发流量，持续流量抓 10 秒足够，偶发流量建议把抓包时间拉长到分钟级，必要时后台挂着抓。
6.3 几条文档里不常写、但实战很顶用的经验
最后分享几条我自己的心得，这些东西不一定能在 man 手册里直接找到，但确实是踩坑踩出来的。
时间校准非常重要。tcpdump 打印的时间戳来自抓包主机，如果服务器和本地分析电脑的时间不一致，你拿回 wireshark 分析时会觉得时间轴对不上。去现场排障前先 date 看一眼服务器时间，必要时和标准时间对一下，不然分析出的“时延”可能带着时钟偏移的误差。
抓包时加上 -s 96 还是 -s 0 要看需求。如果只看包头和 IP 层信息，-s 96 足够了，能大幅压缩 pcap 文件体积；但如果要还原应用层内容，必须 -s 0 抓完整报文。我见过有人拿 -s 96 抓了半天包，回头想查 HTTP 响应体才发现全是截断的，白抓了。
一个特别有用的小技巧：用 tcpdump 抓包时配合 -c 限制数量，可以避免手动 Ctrl+C 的尴尬。比如线上一个接口异常，你只需要看前 100 个报文判断方向，直接 -c 100 跑完自动退出，省得还要盯着终端等时机手动停。
另外，抓包文件最好先落盘再分析，别在生产服务器上一个命令抓完一个命令分析，多开一个 tshark 进程就会多占一份内存。我习惯把所有 pcap 文件下载到本地工作机再统一处理，毕竟服务器上的资源是用来跑业务的，不是拿来给你做分析的。
最后再说一下 tcpdump 和代理抓包类工具的使用边界。像 fiddler、charles、reqable 这些工具在手机抓包、微信小程序抓包、App 抓包场景里很擅长，因为它们能解开 HTTPS 并直接看应用层内容；但如果你要查的是 TCP 层重传、TCP 连接被 RST、802.1x 认证报文这类底层问题，它们就完全插不上手了。学会 tcpdump 并不会让你丢掉其他工具，反而能让你在所有工具之间按需切换。我在实际工作中经常用 tcpdump 先定位到“是网络问题还是应用问题”这一步，再决定要不要掏出更上层的工具继续深挖，这个判断能力，才是排查网络故障最值钱的地方。