Linux网络延迟排查：从ping到tcpdump的完整定位思路

Linux服务器出现访问慢、SSH卡顿或接口超时时，先别急着重启网卡。
网络延迟排查的核心思路是：先确认延迟是持续存在还是偶发，再判断问题出在本机、中间链路还是目标端，最后用工具逐段验证。
本文按这个顺序展开，命令可直接复制使用，适合零基础运维和建站用户。

先分清延迟、丢包和抖动

延迟高不一定丢包，丢包也不一定延迟高，两者的排查方向不同。

• 延迟：数据包从本机到目标再返回的时间，用 ping 的 time 值衡量。内网通常小于 1ms，同城公网 5-20ms，跨省 30-60ms，跨国 150ms 以上都算常见范围，具体看线路。
• 丢包：发出的包没有收到回应，ping 统计里显示 packet loss。偶尔丢 1% 可能是线路抖动，持续丢包要重点看链路。
• 抖动：延迟忽高忽低，mtr 里表现为各跳延迟标准差偏大，常见于无线网络或拥塞链路。

排查前先记录现象：是访问某个 IP 慢，还是所有外网都慢？
是高峰期慢，还是全天都慢？
这些信息能帮你快速缩小范围。

准备条件与基础命令确认

开始前确认你有服务器登录权限，并且系统里已安装常用工具。
CentOS 用 yum install -y iputils traceroute mtr tcpdump，Ubuntu/Debian 用 apt install -y iputils-ping traceroute mtr-tiny tcpdump。

查看本机网络配置和默认网关：

ip addr show
ip route show

ip route show 里的 default via 就是默认网关。
如果网关都 ping 不通，问题基本在本机或局域网，不用往外查。

第一步：从本机到网关看是否正常

先 ping 网关，确认本机网络栈和局域网链路没问题：

ping -c 20 192.168.1.1

把 192.168.1.1 换成你实际的网关地址。
关注两个结果：

• 平均延迟是否稳定在 1ms 以内；
• packet loss 是否为 0。

如果网关延迟高或丢包，检查网线、交换机、网卡状态（ip -s link 看 errors 和 dropped 计数）。
这一步排除后，再查外网。

第二步：用 traceroute 和 mtr 定位链路哪一跳异常

traceroute 显示数据包到目标经过的每一跳，mtr 则持续采样，更适合看丢包和抖动：

traceroute -n 8.8.8.8
mtr -n -c 50 8.8.8.8

-n 表示不解析域名，速度更快。
看结果时注意：

• 某一跳开始持续丢包，且后续跳也丢：问题可能在该跳或之后；
• 中间某跳丢包，但最后一跳不丢：通常是该路由器限制了 ICMP 回应，不代表链路真有问题；
• 最后一跳延迟高：问题可能在目标服务器本身或其入口。

如果目标是网站，也可以换成域名，例如 mtr -n -c 50 www.example.com，但注意域名解析结果可能因线路不同而变化。

第三步：检查本机连接状态和端口延迟

排除链路后，回到本机看具体连接。
用 ss 查看当前连接和重传情况：

ss -s
ss -tin state established

ss -s 显示各状态连接总数，ss -tin 能看到每条连接的 rtt（往返时间）和 retrans（重传次数）。
重传多说明链路质量差或对端响应慢。

如果要测特定端口的延迟，用 nc 或 telnet 配合时间观察：

time nc -zv 目标IP 80

连接建立慢或超时，可能是防火墙拦截、目标端口未监听或路由问题。

第四步：tcpdump 抓包确认延迟出在哪一段

当 ping 正常但应用访问慢时，抓包是最直接的证据。
先抓本机与目标之间的包：

tcpdump -i eth0 -nn host 目标IP and port 80 -c 100 -w /tmp/cap.pcap

把 eth0 换成实际网卡名，目标IP 和端口换成实际值。
抓完后用 tcpdump -r /tmp/cap.pcap -nn 查看，或用 Wireshark 打开。
重点看：

• SYN 发出后多久收到 SYN-ACK，时间差就是连接建立延迟；
• 是否有重复 SYN 或 RST，说明连接被拦截或重置；
• 请求发出到响应返回的间隔，判断是网络慢还是服务端处理慢。

如果本机抓包显示请求很快发出、响应很晚才回，问题在目标端或回程链路；
如果本机发出就慢，检查本机 CPU、网卡队列和防火墙规则。

常见坑与容易误判的地方

• 只 ping 一个目标就下结论：不同目标走不同线路，多测几个才能判断是普遍问题还是个别目标。
• 把中间跳丢包当成故障：很多路由器对 ICMP 限速，中间跳丢包但终点正常，通常不用处理。
• 忽略 DNS 解析时间：应用慢可能是 DNS 查询慢，用 dig 域名 +stats 看解析耗时，必要时换 DNS 或加缓存。
• 防火墙丢包不报错：被防火墙 DROP 的包不会返回 ICMP，表现为超时，用 iptables -L -n -v 或 nft list ruleset 检查规则。
• 无线或虚拟化环境干扰：虚拟机网卡、无线信号弱都会引入额外延迟，先确认物理链路和宿主机负载。

验证排查是否有效

调整后按同样方法复测，确认结果改善：

• ping -c 50 目标IP 看平均延迟和丢包是否下降；
• mtr -n -c 50 目标IP 看异常跳是否恢复；
• ss -tin 看重传次数是否减少；
• 应用侧观察接口响应时间是否回到正常范围。

如果延迟只在高峰期出现，建议在不同时段各测一轮，记录数据再对比，避免单次结果误判。

几个常见疑问

ping 延迟正常但网站打开慢，是什么原因？

ping 只测 ICMP，不测 TCP 和应用层。
网站慢可能是 TCP 握手慢、TLS 协商慢、DNS 慢或服务端处理慢。
用 curl -w "%{time_connect} %{time_starttransfer} %{time_total}" -o /dev/null -s 网址 分段看耗时，再结合 tcpdump 定位。

内网延迟突然升高，先查什么？

先查本机网卡错误计数和网关延迟，再看交换机端口流量和广播风暴。
内网延迟升高常见于环路、ARP 冲突或某台机器大量发包，用 arp -n 和 ip -s link 能快速发现异常。

mtr 显示中间跳丢包，需要联系运营商吗？

如果最后一跳不丢包且应用正常，通常不用。
只有最后一跳持续丢包或延迟明显偏高时，才把 mtr 结果保存下来作为依据，向运营商或机房反馈。

网络延迟排查的关键是分段验证：本机、网关、中间链路、目标端，每段用对应命令确认，不靠猜。
先记录现象，再逐段排除，最后复测确认效果。
按本文步骤执行后，如果问题仍在，优先回看避坑部分，检查 DNS、防火墙和虚拟化环境这些容易被忽略的环节。