千兆宽带一开下载，游戏就卡？锅多半在路由器缓存，不在运营商_路由器

千兆宽带一开下载，游戏就卡？锅多半在路由器缓存，不在运营商

千兆宽带，上千块的路由器，测速跑满940M。晚上开一局游戏，延迟稳在20毫秒。这时候家里人手机开始备份相册，你的延迟直接跳到两三百毫秒，放技能慢半拍，走位莫名回弹。暂停下载，延迟立刻回位；一恢复下载，卡顿马上回来。

打开任务管理器看一眼：下载其实只跑到几十Mbps，千兆带宽十分之一都没占满。路明明没堵满，为什么卡？

堵的不是路宽，是路口的候车厅

这就是缓冲区膨胀（Bufferbloat）。路由器转发数据前，要先把数据包存在内存里排队，这个队列就是缓冲区，相当于路口的候车厅。2010年，X Window 的共同作者 Jim Gettys 在自己家里抓到了它：只要有人往云端同步照片，视频会议延迟就从20毫秒飙到1200毫秒以上。知乎

问题出在内存变便宜之后。厂商发现塞一块大缓存就能宣称"零丢包"，跑分还好看。但 TCP 的拥塞控制靠丢包判断拥堵、主动减速——丢包被大缓存整个吞掉，等于把刹车拆了。发送端以为前方一路畅通，继续加速，数据包在路由器内存里越排越长。知乎

你的游戏数据包只有几十字节，按先来后到的规矩，得排在成千上万个下载大包后面。

更麻烦的是上行：家用宽带的上行往往只有30到50Mbps，按行业标准 YD/T 3328-2023，下行超过200M的套餐，上行给到40Mbps就算合规。知乎知乎

按 50Mbps 的上行往外挤，10MB 的积压要整整1.6秒——你的操作不是堵在光纤里，是在路由器内存里排了1.6秒的队。

下行数字一路翻倍，上行没人管、缓存越堆越大，这就是"测速跑满、一开下载就卡"的原因所在。

两分钟测出你有没有中招

浏览器搜索并打开 Waveform 的 Bufferbloat Test，空载和满载各记一个延迟：空载10毫秒左右，满载冲到两三百以上，就是缓冲区膨胀。更土的办法也行：一直 ping 网关和外网地址，同时跑一次上传——ping 网关还是2毫秒，说明家里无线这一段没问题；ping 外网从20毫秒跳到400毫秒，问题就钉死在路由器的队列上。知乎

反过来，如果你空载延迟就高、丢包超过1%，那是线路和光衰的事，别折腾设置了，直接报修。

按动手难度，从上往下试

第一步，不花钱，先管住偷上行的任务。云备份和相册同步挪到凌晨跑，Steam 下载设个限速，监控摄像头换 H.265 编码，一路码率能从4Mbps压到2Mbps。上行留出余量，队列自然就短。

第二步，路由器后台开 QoS。认准"智能队列""自适应QoS（Adaptive QoS）"这类做队列管理的选项，别只用按 IP 限速的笨办法。很多家用路由的"游戏加速"只是给游戏包打个优先级标记，队列够深时照样卡，别指望太高。知乎

第三步，有动手能力就上 SQM。OpenWrt 装上 SQM 插件，选 fq_codel 或 CAKE。这套思路来自2012年 Van Jacobson 团队的 CoDel 算法：不看队列多长，只盯每个包在内存里待了多久，超过5毫秒就丢——主动丢掉几个包，发送端才重新踩得下刹车。近两年出厂的中高端路由，不少已经内置类似功能，下单前查一眼参数表有没有 SQM 或 Adaptive QoS。哔哩哔哩