Linux网络延迟卡顿排查方案：从入门到实战

服务器网络延迟高、页面加载慢，是运维中最常见的“头疼病”。
很多新手一上来就重启网卡或者重装系统，其实完全没必要。
只要掌握几个工具和一套流程，你也能像老手一样快速锁定问题源头。
下面我按实际排查顺序，带你一步步操作。

排查前的准备：确认环境与工具

在动手之前，先确认几件事：

• 当前服务器系统：本文以 CentOS 7/8 和 Ubuntu 20.04 为例，命令基本通用。
• 检查基础网络：执行 ip a 查看网卡是否正常获取 IP。如果网卡状态为 DOWN，先 ifup eth0 启动。
• 安装必要工具：

  # CentOS / RHEL
  yum install -y mtr iftop iperf3 net-tools
  # Ubuntu / Debian
  apt install -y mtr iftop iperf3 net-tools

如果提示找不到包，换用 epel-release（CentOS）或 universe 源（Ubuntu）。

• 准备一个远端测试 IP：比如谷歌的 8.8.8.8，或者你自己另一台服务器的公网 IP。

第一步：用 ping 做初步延迟测试

ping 是最快的“试金石”。

ping -c 10 8.8.8.8

关注两个值：

• min/avg/max 延迟：如果平均延迟大于 50ms（对国内机房来说），说明网络链路可能有瓶颈。
• 丢包率：丢包超过 0.5% 就需要重视了。

常见情况：

• 一直超时：检查防火墙（iptables -L 或 firewall-cmd --list-all），或者远端屏蔽了 ICMP。
• 偶尔超时：可能链路不稳定，进入下一步。

第二步：用 mtr 定位卡顿节点

mtr 结合了 ping 和 traceroute 的功能，能显示每一跳的丢包和延迟。

mtr -r -c 10 8.8.8.8

参数说明：

• -r：报告模式，自动退出。
• -c 10：发送 10 个探测包。

结果分析要点：

• 最后一跳丢包高，前面都正常：一般是目标服务器自身问题（如带宽跑满、内核参数问题）。
• 中间某一跳丢包严重：可能是运营商问题，你可以试着换个机房或联系 IDC。
• 多个跳点延迟突然飙升：可能是路由绕路，比如从北京走到了广州再出去，需要调整路由策略。

避坑：有些路由器会主动丢弃探测包导致假丢包，但延迟不变则不影响数据转发。如果只有丢包没有延迟增大，别慌，继续看下一跳。

第三步：用 iftop 监控带宽占用

如果以上链路都正常，那可能是服务器内部带宽被某些进程占满了。

yum install -y iftop   # 或 apt install iftop
iftop -i eth0          # 替换成你的网卡名

运行后界面会实时显示每个连接的流量。
按 t 切换显示模式，按 n 以数字形式显示 IP。

常见问题：

• 某个 IP 的流量异常高：先确认 IP 归属（白名单还是未知），用 lsof -i :端口 查进程。
• 本机流出流量爆满：检查是否有对外发包的服务，比如被挖矿程序当作跳板。

第四步：用 iperf3 进行带宽和延迟专项测试

当怀疑本地带宽或 TCP 参数不对时，用 iperf3 做点对点测试。

服务端（在被测的远程服务器上启动）：

iperf3 -s -p 5201

客户端（在本机执行）：

iperf3 -c <远程IP> -p 5201 -t 30

输出会告诉你实际的带宽、重传率、发送窗口大小等。
重传率超过 1% 说明丢包严重，需要检查网络质量或调整 TCP 参数（如 net.ipv4.tcp_congestion_control）。

常见高频问题解答

Q1：ping 通但业务拉取数据慢？
可能是 TCP 拥塞控制算法不适合高延迟链路。尝试改成 BBR：

echo "net.core.default_qdisc=fq" >> /etc/sysctl.conf
echo "net.ipv4.tcp_congestion_control=bbr" >> /etc/sysctl.conf
sysctl -p
lsmod | grep bbr   # 确认模块加载

Q2：mtr 显示中间节点不响应（*）？
多数是运营商做了安全策略，不必纠结，重点看最后一跳。

Q3：iftop 看不到内网流量？
默认只显示实时流量，用 -F 192.168.0.0/24 强制过滤。

验证与收尾：让结果落地

排查完问题后，必须验证“修好没有”：

1. 再次运行 ping -c 20 <目标IP>，观察延迟和丢包是否恢复正常。
2. 用 curl -o /dev/null -s -w "%{time_total}" http://你的域名 测试接口响应时间。
3. 最后用 nload eth0 看带宽曲线是否平稳。

如果以上都正常，恭喜你，网络卡顿问题已解决。
记得把关键服务器配置（如 BBR、防火墙规则）写入自动化部署脚本中，避免下次再踩坑。

如果你正在处理Linux网络延迟卡顿排查方案，建议先按本文步骤完整执行，再根据自己的环境做微调；
遇到异常时优先回看避坑和高频问题部分。