Linux网络抖动排查需分四步：先用ping和mtr验证抖动范围与链路异常；再查网卡错误、中断分布及速率双工；接着分析TCP连接rtt波动与抓包重传；最后排除软中断、内存换页及缓冲区限制。
Linux网络抖动严重，不能只盯着ping结果看。真正影响业务的是TCP连接的实际表现，比如HTTP请求超时、数据库连接卡顿、gRPC延迟突增等。抖动本质是延迟波动大（例如RTT在10ms和600ms之间跳变），而非单纯延迟高。排查要分层推进：先确认是不是真抖动，再锁定是链路问题、本机处理瓶颈，还是应用自身行为导致。
第一步：验证抖动是否存在，且定位大致范围
别只用ping -c 100看平均值。重点看标准差和最大最小值：
- 执行
ping -c 100 -i 0.1 target_ip | awk '{if(NF==7) print $7}' | cut -d'=' -f2 | awk '{print $1}' | sort -n | head -10，快速查看最低10个延迟值 - 同时跑
mtr --report-cycles 50 --tcp -P 443 target_domain，它走真实端口路径，能发现某跳TCP丢包而ICMP显示“全通”的情况 - 如果mtr中间某跳显示
???但后续跳正常，大概率是该设备禁了ICMP，不是故障，不用深究
第二步：检查本机网卡与驱动是否拖后腿
很多抖动其实源于本地——网卡RX队列溢出、中断扎堆在一个CPU核、驱动bug都会让包进得慢、发得卡：
- 查错误计数：
ethtool -S eth0 | grep -E "(drop|overrun|error|reset)"，重点关注rx_missed_errors（持续涨说明ring buffer溢出）、tx_aborted_errors（非零且递增，物理链路可能松动或光模块过热） - 查中断分布：
cat /proc/interrupts | grep eth0，若某一CPU核上中断数远高于其他核，需手动分散，例如echo 03 > /sys/class/net/eth0/queues/rx-0/rps_cpus（按实际CPU数量调整掩码） - 确认双工与速率稳定：
ethtool eth0，确保显示Speed: 1000Mb/s和Duplex: Full，避免协商失败反复重连
第三步：区分是内核协议栈问题，还是应用层行为异常
抓一个典型连接，对比两个关键时间点：
- 运行
ss -i dst target_ip:port，观察输出中的rtt和rttvar是否剧烈波动。若rtt本身忽高忽低，说明内核已感知链路不稳（如乱序多、重复ACK频繁），需检查拥塞控制算法（BBR/CUBIC）或net.ipv4.tcp_rmem设置 - 同步抓包：
tcpdump -i eth0 'host target_ip and port port' -w debug.pcap -c 1000，打开Wireshark看SYN重传节奏。若重传间隔是1s→2s→4s→8s→放弃，问题在连接建立阶段，可能是防火墙拦截、SYN Cookie触发，或对端net.ipv4.tcp_max_syn_backlog设得太小 - 如果抖动只出现在长连接建立之后（比如首包RTT正常，后续数据包延迟飙升），重点查应用读取socket是否太慢、是否有阻塞IO、或是否未启用TCP_NODELAY
第四步：排除系统资源与配置干扰
软中断高、内存换页、缓冲区太小，都会让网络响应像踩刹车一样一顿一顿：
- 用
top看si（softirq）是否长期超过30%，这是网络包处理压力大的信号 - 执行
free -h确认没swap活跃；用vmstat 1观察so（swap out）列是否非零 - 查监听溢出：
netstat -s | grep -i "listen.*overflow"，若数字增长，说明应用accept不够快，或net.core.somaxconn设得太低 - 临时调大TCP缓冲区：
echo 'net.core.rmem_max = 16777216' >> /etc/sysctl.conf && sysctl -p
不复杂但容易忽略：抖动往往不是单一原因，而是链路质量差 + 本机中断不均 + 应用读取延迟三者叠加。从mtr和ethtool入手，把“看起来像网络问题”的表象一层层剥开，就能找到那个真正卡住流量的环节。
