网络抖动太烦人？这5个实战策略帮你稳住连接

开会正说到关键处，视频突然卡成PPT；远程调试设备时命令半天没响应；游戏里人物原地瞬移……别急着骂运营商，大概率是网络抖动在搞鬼。

抖动不是丢包，但比丢包更难缠

丢包好理解——数据发出去就没了；抖动则是数据包到达时间忽快忽慢，像高峰期挤地铁：有人3分钟到，有人12分钟才晃进来。音视频卡顿、VoIP断续、工业PLC指令错序，根源往往不是带宽不够，而是抖动超标（一般超过30ms就明显感知）。

先摸清抖动在哪发生

别一上来就调路由器。用 ping -t（Windows）或 ping -c 100（Linux/macOS）连续测目标IP，重点看 延迟波动值（jitter） 而非平均延迟：

ping -c 100 114.114.114.114
# 查看输出里的 'mdev = 12.3 ms' —— 这个值越小越好

如果本地到光猫延迟稳定，但到公网DNS就飘忽，问题大概率出在ISP链路；如果连光猫都抖，先重启光猫+检查网线接口是否松动。

路由器设置别只盯着WiFi

很多用户以为开个QoS就能搞定，其实关键在缓冲区管理

老式路由器用“笨缓存”（Bufferbloat），一拥塞就疯狂囤积数据包，导致抖动飙升。登录路由器后台，找到 “智能队列管理” 或 “FQ_CoDel” 选项（OpenWrt/Padavan固件常见），务必开启。没有该选项的老旧设备，建议限速到实际带宽的80%：

# 举例：宽带签约500Mbps，手动限速至400Mbps
# 可显著降低缓冲区堆积

有线优先，但线材也得较真

别小看一根网线。办公室用超五类线跑千兆，中间接了3个水晶头，高频信号衰减+串扰，抖动轻松破50ms。实测过：换一条屏蔽型六类线（带金属编织层），同一路由器下WebRTC通话抖动从42ms降到8ms。光纤入户后，第一跳必须用原装光猫LAN口直连，中间别插HUB或劣质交换机。

应用层也能主动扛抖动

对实时性要求高的业务（如远程桌面、监控平台），别依赖TCP重传。改用支持Jitter Buffer的协议：

• WebRTC默认开启自适应抖动缓冲，前端可强制启用：

  const pc = new RTCPeerConnection({
    iceServers: [{urls: 'stun:stun.l.google.com:19302'}],
    optional: [{googDscp: true}, {googSctpDataChannels: true}]
  });

• FFmpeg推流加参数：-vsync cfr -max_delay 500000（单位微秒），让编码器主动平滑时间戳。

最后盯紧那个“隐形杀手”

公司茶水间微波炉一开，隔壁工位WiFi视频会议立马雪花。2.4GHz频段本就拥挤，加上蓝牙耳机、无线键鼠全挤在同一段频谱里。解决办法很土但管用：把路由器2.4G信道手动固定在1、6、11之外的干净信道（比如用WiFi分析仪扫出的13信道），同时把IoT设备全切到2.4G，主力设备强制连5G频段。实测某制造车间AP抖动从110ms压到22ms。