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调用间隔是否规律
