Alibaba cloud international server special offer

腾讯云服务器网络抓包与诊断：tcpdump、mtr、iperf3 怎么用才有效

一个客户说服务器"偶尔会卡顿一下"，可监控里 CPU 和磁盘全都很平，ping 延迟也正常。我上手抓了一小段包才发现，是到某台下游服务的流量在偶发重传——问题藏在网络里，不体现在任何资源曲线上。网络诊断的难点就在这：它不像 CPU 打满那样一眼可见。腾讯云服务器网络抓包不是一上来就开 tcpdump，而是先分层定位、再选对工具、最后控制好抓包范围。这篇把 tcpdump、mtr、iperf3 各自解决哪一段问题讲清楚，也说说抓包本身会带来什么代价。

抓包之前：先把问题分层定位

新手最容易犯的错，是出问题先来个 tcpdump -i eth0 抓全量，结果几个 G 的包看半天找不到重点。正确的顺序是先分层，把范围缩小到某一层再抓。

一次网络请求大致经过四层：DNS 解析 → TCP 三次握手 → TLS 握手（如果是 HTTPS）→ 应用层请求响应。逐层判断的抓手其实很简单：

• DNS 层：dig api.example.com 或 nslookup，看解析耗时与返回的 IP 对不对。解析慢或返回了错误 IP，后面全线受影响。

• 传输层：ping 看连通与延迟，ss -s、ss -tnp 看连接状态和队列，重点关注 SYN-SENT 堆积和 Send-Q 不降。

• TLS 层：openssl s_client -connect host:443 看握手是否成功、证书链和协议版本。

• 应用层：curl -v -w "@fmt.txt" 分阶段打印建连、TLS、首字节、总耗时，一眼看出卡在哪一段。

我一般习惯先用 curl -w 拿到一张分阶段耗时表，再决定要不要抓包。能靠一次 curl 定位的问题，就别动用 tcpdump，这是省时间的经验。

在动手抓包之前，还有几个几乎零成本的检查值得先敲一遍：ss -s 看全局套接字统计，netstat -s | grep -i retrans 看系统级的重传计数，ss -tn state established '( dport = :3306 )' 看某个端口的连接数是否符合预期。这几个命令花不了几秒钟，很多问题看一眼计数就能定方向，连抓包都省了。

tcpdump：过滤表达式与环形写盘

确定要在传输层动手，tcpdump 才是主力。它的价值不在"抓得多"，而在"过滤得准"。几个必须会的表达式写法：

• 按主机和端口：tcpdump -i eth0 -nn -s0 -w cap.pcap 'host 10.0.0.5 and port 3306'，只抓这一条业务流。-nn 不解析域名和端口名，避免抓包时的 DNS 反向解析拖慢速度。

• 组合条件：and、or、not 拼装，net 10.0.0.0/24、src host、dst port 都很常用。

• 直击握手异常：tcpdump -nn 'tcp[tcpflags] & (tcp-syn|tcp-fin) != 0' 只看建连和断开，快速判断有没有大量失败的连接尝试。

生产环境抓包，磁盘一定要控住。用 -C 100 -W 10 -w cap.pcap 做环形写盘：单文件到 100MB 就切下一个，最多保留 10 个，老的自动被覆盖，不至于把系统盘写满。再加 -c 2000 限制抓包数量，用 -Z 指定低权限用户运行，别用 root 一直挂着。抓包文件可能包含敏感的业务数据，用完就该删，别长期留在服务器上。

判断问题该抓在哪个网卡也很关键。云服务器 CVM（行业里常叫 ECS）上通常只有内网网卡 eth0，公网 IP 是通过映射进来的，公网方向的包在 eth0 上照样能看到。如果实例接了多块网卡或做了弹性网卡绑定，抓错网卡会让你误以为"根本没流量"。

还有个实用技巧：先 -w 抓到文件，再用 tcpdump -r cap.pcap -A 'port 80' 或 Wireshark 慢慢看，别在生产上为了看内容就上 -X 直接打印原始十六进制，输出又长又乱，还容易把终端卡死。

从三次握手与重传读问题

抓到的包怎么读？传输层最值得看的是三次握手和重传。正常流程是一条 SYN、一条 SYN-ACK、一条 ACK。异常迹象对应着不同病因：

• 反复出现 SYN 却等不到 SYN-ACK：对端没监听、被安全组或防火墙拦了、或者对端负载太高。

• 大量重传（Wireshark 里标成 tcp.analysis.retransmission）：链路丢包、对端处理慢、或本地拥塞窗口被压。结合 RTT 一起看，重传集中在某一条目标上，说明问题在下游而不在本地。

• 出现 RST：连接被强制复位，常见于对端进程重启、连接被中间设备重置、或半开连接超时。

• 出现 Dup ACK 一堆：对端在催你重发，通常是丢包引起的。

用 Wireshark 打开抓包文件后，先看"专家信息"（Expert Information），它会把重传、乱序、零窗口这些异常自动标出来，比肉眼扫快得多。定位到具体流后，再统计这条流的 RTT、重传率、窗口大小，基本能判断是网络质量差还是对端应用慢。

还有两个细节值得单独拎出来。一个是接收窗口掉到 0，也就是零窗口：它说明对端不是收不到，而是应用层读得太慢，缓冲被塞满，发送方只能干等——这时瓶颈在对端应用，不在网络，抓包能看到 ZeroWindow 标记，顺着去查对端那个服务的处理逻辑即可。另一个是 MTU 与分片：隧道、VPN 或过度封装会让实际可用 MSS 变小，表现为握手正常、一传大报文就卡住或丢，用 ping -M do -s 1472 逐步试探能找出合适的 MTU。这两类问题都不是靠"加大带宽"解决的，靠的是读懂报文里的字段。

mtr、traceroute 与 ping 通端口不通

链路质量要靠 mtr 和 traceroute，但两者定位不同：

• traceroute（云上常用 traceroute -n -T -p 443）是"一次性"探测，列出到目标经过的每一跳，适合看路径对不对、在哪一跳断掉。

• mtr（mtr -n -T -p 443 host）是"持续"探测，对每一跳反复发包并统计丢包率和延迟，适合判断是"偶发丢包"还是"稳定不通"。

这里有个很多人踩的坑：中间某一跳显示丢包，不等于真的丢包。路由器对 ICMP 探测做了限速，会出现"中间跳丢包、最后一跳却不丢"的假象，这种情况下业务往往是好的。真正要看的，是从某一跳开始后续每一跳都持续丢包，那才是链路问题。

再说"ping 通但端口不通"这个高频场景。ping 走的是 ICMP，端口通不通走的是 TCP。ping 通说明网络可达，但端口不通通常是三个原因：目标服务根本没在监听这个端口（ss -tlnp 一查便知）、安全组没放行这个端口、或者系统内防火墙（iptables/firewalld）把包丢了。这三者要按"服务 → 安全组 → 系统防火墙"的顺序排查，别一上来就怀疑腾讯云网络有问题——十次里有八次是自己的配置。

想快速确认端口连通，nc -vz <ip> <port> 或 telnet 一发就知道，比反复抓包直接得多。排查时还有个高效组合：先 nc -vz 确认端口连通，再用 curl -v 看应用层往返，最后才在服务端和客户端同时抓包对比。两端同时抓的价值在于，你能确认包到底是去程丢了、回程丢了，还是压根没发出去——单端抓包只能看到"我发了、我没收到"，看不到中间发生了什么。

iperf3 与带宽验证：突发带宽不等于计费带宽

带宽够不够，猜没用，得测。iperf3 是标配：一端 iperf3 -s 起服务端，另一端 iperf3 -c <内网IP> -t 30 -P 4 用 4 条并发流测 30 秒，看最终带宽。同地域内网之间测，能验证实例内网带宽的实际能力；测试产生的内网流量，同地域下不额外计费，这也是很多人愿意在内网跑压测的原因。

但要分清两个概念：公网带宽是有计费上限的，测出来的速度不会超过你买的带宽。你买 10Mbps 公网带宽，iperf3 跑到 12Mbps 才是见鬼了。而"突发带宽"指的是短时间内允许一定程度的超出，属于时段性、有条件的，不能当成长期能力。很多客户抱怨"我买的机器跑不满带宽"，一测发现瓶颈在公网计费带宽上，而不是实例性能。

另外两个常用姿势要记住：加 -R 是反向测，让服务端往客户端发，验证的是下行方向；加 -u -b 走 UDP 模式，能观察丢包率而不只是吞吐，更适合判断链路质量而非上限。多测几组并发数（-P 1、-P 4、-P 8），你会看到带宽随并发上升后趋于平台，那个平台就是这条链路的实际能力。

工具 作用层级 关键参数/命令 适用场景 主要局限

ping 网络层 ICMP 目标地址、-c 次数 连通性与基础延迟 只能测 ICMP，测不了端口和带宽

traceroute 网络路径 -n -T -p 端口 看经过哪些跳、断在哪 一次性探测，看不到丢包率趋势

mtr 路径与质量 -n -T -p 端口持续探测 持续丢包率与稳定性判断 中间跳 ICMP 限速易误判

tcpdump 传输层以上 过滤表达式、-C/-W、-w 抓握手、重传、应用报文 有性能开销，文件敏感

iperf3 带宽吞吐 -s / -c -P 并发 -t 时长 内网带宽与带宽上限验证 需两端配合，测的是理想吞吐

ss 连接状态 -s、-tnp 看队列堆积、连接数 只看本机套接字，不涉及链路

丢包假象与抓包本身的代价

有两种"看着像网络问题、其实不是"的情况，特别耗人。

第一种是安全组和网络 ACL 造成的"丢包假象"。它们是在流量进入实例之前就把包丢弃的，所以你在实例上用 tcpdump 根本抓不到这些包——看起来像"包在网络上丢了"，其实是被云侧规则拦了。遇到"抓不到、又确实不通"，先去核对安全组入站规则和子网 ACL，别在实例里死磕。安全组是有状态的：出站放行了，返回流量会自动放行；但入站没开对应端口，连接就是建不起来。

第二种是抓包本身带来的性能代价。在高流量实例上跑无过滤的 tcpdump，既吃 CPU 又吃磁盘，还可能把本就紧张的业务拖慢，等于"诊断动作变成了新故障"。所以范围控制是纪律：先想清楚要看哪条流，用最小过滤表达式；用环形写盘限制磁盘占用；抓够证据就立刻停。别让一个排查动作演变成第二个事故。

另外，抓包文件本身是敏感数据，里面可能有请求头、账号标识、内部接口路径。生产抓包要限定范围、及时清理、按需脱敏，这不是洁癖，是基本的安全素养。做跨境业务的，我见过客户在海外区域抓包时才发现链路绕路严重，这类问题最好先按合规部署把区域选对，再谈抓包优化；国际腾讯云服务器和国内站的产品细节有差异，命令大原则相通，但控制台里的配置项要按对应站点来。

FAQ

Q：抓包前第一件事应该做什么？

A：先分层定位。用 curl -w 或 dig、ss -s 判断卡在 DNS、握手、TLS 还是应用层，确认要在传输层查再抓包，别一上来抓全量。

Q：抓到的包为什么看不懂、太多？

A：大概率是没加过滤表达式。用 host、port、net 组合条件只留目标流，再用 -c 限制数量、-C/-W 环形写盘，文件自然小而清晰。

Q：ping 通但端口连不上，是云网络问题吗？

A：多数不是。按顺序查：服务是否在监听（ss -tlnp）、安全组是否放行该端口、系统防火墙是否拦截。三个都排除了再怀疑链路。

Q：mtr 显示中间跳丢包，业务却很正常？

A：那是中间设备对 ICMP 限速造成的假象。要看从某一跳起后续每一跳是否持续丢包，只看单跳丢包容易误判。

Q：iperf3 测出来的带宽比别人低，是不是被限速了？

A：先看是不是公网计费带宽封顶，公网速度不会超过你购买的带宽；内网测试才发现实例本身能力。两者别混着比较。

结语

网络诊断的正确姿势是"先