Linux 网络抖动需分层排查：先查物理链路（网线、光模块、误码），再用 MTR 定位异常跳点，接着分析内核软中断与 qdisc 队列积压，最后排除 DNS 解析慢或应用读取延迟等上层干扰。
Linux 网络抖动频繁，核心在于延迟波动大（如 ping 值忽高忽低、mtr 某跳抖动剧烈），不能只盯着系统调参。真正有效的排查要分层定位：先确认是不是链路本身在“抽风”，再看系统是否扛不住，最后查应用是否拖后腿。
一、从物理链路开始验证——抖动往往藏在“线”里
链路抖动常由硬件或介质问题引发，比如网线接触不良、光模块老化、电磁干扰、SFP 不兼容等。这类问题会导致接口反复 UP/DOWN，或出现大量 CRC/enc_out 误码。
- 用 ethtool eth0 检查网卡状态：关注 Link detected: yes 是否稳定，Speed和 Duplex 是否协商正常，有无 RX/TX errors 持续增长
- 对光纤链路，登录 FC 交换机执行 porterrshow，重点看enc_in、enc_out、crc_err 是否每秒递增
- 更换网线、SFP 模块、交换机 端口，做最小化替换测试；若抖动随硬件变动消失，基本可锁定物理层
二、用 MTR 抓准“哪一跳”在抖动
单纯 ping 只能看到终点，而抖动常发生在中间某台设备（如企业出口 路由器、云厂商接入节点、CDN 边缘节点）。MTR 能持续探测整条路径，统计每跳的丢包率和延迟标准差，比 traceroute 更可靠。
- 运行 mtr -r -c 100 www.example.com，输出中重点关注Loss% 和StDev（标准差）列：StDev > 20ms 或 Loss% > 1% 的跳即为可疑点
- 对比不同时段（如白天 vs 深夜）的 MTR 结果，判断是否与业务高峰重合——若是，大概率是上游拥塞或 QoS 限速
- 若抖动出现在你控制范围外的跳（如第 3 跳起），联系对应网络管理员，提供 MTR 截图和时间戳
三、检查内核软中断与 qdisc 队列是否积压
即使链路正常，Linux 内核处理能力不足也会造成抖动：软中断（NET_RX）长时间占用 CPU，或 qdisc 队列堆积导致数据包排队延迟突增。
- 用 cat /proc/interrupts | grep eth0 观察网卡中断是否集中在单个 CPU，再用 sar -I ALL 1 看各 CPU 的 INTR 负载是否失衡
- 执行 tc -s qdisc show dev eth0，检查drops、overlimits、requeues 是否非零且持续增长；若 backlog 长期>100KB，说明队列已饱和
- 临时缓解：通过 ethtool -L eth0 combined 4 开启多队列，配合 RPS/RFS 将中断分散到多个 CPU
四、排除 DNS 与应用层接收节奏干扰
有些“抖动”其实是应用行为导致的：DNS 解析慢引发连接建立延迟，或应用进程读取 socket 太慢，让数据包在内核缓冲区滞留，被误判为网络延迟。
- 用 dig +stats www.example.com @8.8.8.8 单独测 DNS 响应时间，若>300ms，换用本地dnsmasq 或 systemd-resolved 缓存
- 用 ss -i 查看连接的 rcv_rtt、rttvar 和unacked字段：若 unacked 持续高，说明远端未及时 ACK；若 rcv_rtt 剧烈波动，可能是本端应用读取不及时
- 结合 perf record -e syscalls:sys_enter_recvfrom -a sleep 30 采样，看 recvfrom 调用间隔是否规律
