家庭开源网关 07｜从 940Mbps 到 Bufferbloat：性能测试与 SQM 调优

家庭开源网关系列 · 第 7/8 篇

千兆网口测速只有 940Mbps，不一定是性能不足；测速能跑满带宽，也不代表视频会议和游戏延迟正常；开启硬件卸载后吞吐提高，又可能让 SQM 和流量统计失效。

网关调优不能只看一个 Speedtest 数字。需要把链路、裸路由、PPPoE、代理/VPN 和满载延迟分开测试。

千兆为什么通常不是 1000Mbps

1GbE 的物理速率是 1,000Mb/s，但以太网帧、IP、TCP/UDP 等都存在协议开销，测速工具和服务器也会影响结果。

因此，有线 TCP 实测约 930–950Mbps 通常已经接近千兆链路上限。看到 940Mbps 时，先确认它是否稳定、CPU 是否有余量、错误计数是否正常，不要立即把差值归因于交换机或软路由。

如果结果只有约 90–95Mbps，则更像是某一段链路只协商到了 100M，需要检查端口、网线、水晶头、墙内模块和八芯连接。

测速结果还受到方向、并发连接和测试端影响。单连接无法跑满，不代表链路总容量不足；公网测速服务器忙碌，也不能用来证明局域网有问题。家庭网关的基线应来自可控的有线端点，随后才逐层加入运营商线路和软件功能。

记录结果时至少保留：测试时间、两端接口与协商速率、数据方向、单/多连接、启用的代理/VPN/SQM/卸载、CPU 与温度，以及空闲和满载延迟。只保存一张测速截图，几乎无法用于后续版本对比。

五层测试顺序

1. 局域网 iperf3

先在两个有线终端之间测试，验证网卡、交换机和布线。NAS 与 PC 位于同一 VLAN 时，流量通常由交换机直接转发，不经过网关。

分别测试正向、反向和多连接，并确认两端没有同时进行云同步或磁盘密集任务。若同网段结果异常，先处理终端网卡、交换机、布线和存储，暂时不要调整网关代理。

2. 裸路由 WAN-LAN

关闭代理、SQM、复杂统计和自定义防火墙，只测试基础转发。这样才能判断瓶颈来自硬件/驱动，还是来自后加的组件。

测试 WAN-LAN 时要确保数据确实经过网关，而不是两个端点仍在同一交换网络。记录 NAT、软件/硬件流量卸载状态以及接口错误计数。裸路由已经不稳定时，后续任何插件测试都没有基准意义。

3. PPPoE

启用实际拨号方式，观察吞吐、CPU 和 MTU。PPPoE 会改变处理路径，不能用 DHCP WAN 的结果直接替代。

4. 透明代理与 VPN

分别记录 CPU 单核、软中断、单连接和多连接吞吐。加密算法、节点质量、协议和规则复杂度都会进入结果。

代理测试应至少准备一个确认直连的目标和一个确认走代理的目标。两者都慢，可能是设备负载或 DNS 数据面问题；只有代理目标慢，则还要排查远端节点、协议和线路。VPN 也要区分“远程进入家庭 LAN”和“家庭流量通过远端出口”，两类方向的瓶颈不同。

5. 满载延迟

同时观察空闲 ping 与上下行满载时的 ping。下载数字不变、延迟从几毫秒增加到数百毫秒，就是典型的队列积压问题。

上行往往更容易被忽略。照片备份、网盘同步或视频上传把上行打满后，确认包和交互流量也会排队，最终表现为下载、游戏和语音同时变差。测试 SQM 时要分别压满下行、上行，再进行双向满载测试。

流量卸载不是默认开关

软件或硬件流量卸载会绕过部分常规网络处理路径，从而提高吞吐。但同一机制也可能绕过 SQM、精细流量统计、透明代理或部分自定义防火墙处理。

不要把“开启卸载”作为固定优化项。应在自己的功能组合中分别测试：

裸路由 + 卸载
裸路由 - 卸载
代理 + 卸载
SQM - 卸载

如果主要目标是低延迟，必须确认卸载没有绕过整形。OpenWrt 的 SQM 文档明确指出，硬件流量卸载与 SQM 不兼容，因为卸载会绕过部分内核处理路径。

流量卸载、透明代理、精确流量统计和 SQM 之间存在实现路径冲突。不要同时打开所有开关再看哪个“好像有效”。先明确优先级：追求最高裸 NAT 吞吐，可以测试卸载；追求满载低延迟，优先确保 SQM 真正控制瓶颈；需要透明代理和统计，则要验证相关流量没有绕开规则。

SQM 解决的是满载延迟

Bufferbloat 是设备在链路满载时缓存过多数据包，导致排队时间迅速上升。SQM 通过流队列、主动队列管理和流量整形，把可控瓶颈放在网关上。

OpenWrt 的 sqm-scripts 支持 CAKE、fq_codel 等方案，具体参数见官方 SQM configuration。

调试顺序：

1. 测出多次运行都能达到的稳定上行和下行，不使用运营商标称值。
2. 初始整形设置为真实瓶颈的约 90%–95%。
3. 同时压满上下行，比较吞吐与延迟。
4. 优先把上行整形准确，因为上行更容易形成严重排队。
5. 逐步提高整形值，在可接受延迟下寻找吞吐平衡。

整形值应填写实际可持续速率，而不是套餐名。例如千兆宽带在多次有线直连测试中稳定得到约 940Mbps，可以从略低的数值开始；上行若只有 50Mbps，则上行必须单独测量和设置。运营商在不同时段的实际容量会变化，参数也需要以较差但常见的时段为基线。

判断效果时同时看三组数据：吞吐损失多少、延迟峰值降低多少、网关 CPU 是否接近极限。若启用 SQM 后吞吐剧烈下降且单核满载，说明设备处理能力或当前队列配置成为瓶颈；这时继续提高整形值不会解决问题。

CAKE 与 fq_codel 的选择、链路层开销补偿和高级队列参数应在基础整形有效后再调整。一次修改多个高级选项，会让改进无法归因。家庭调优的目标是稳定、可重复的低延迟，不是追逐一次测试中的最佳分数。

SQM 在 CPU 上执行。千兆下行使用复杂队列时，ARM 设备能否跑满必须实测。目标是控制延迟波动，不是让测速数字最大。

MTU 与 MSS

标准以太网 MTU 常见为 1500。PPPoE 会引入额外封装，错误 MTU 可能表现为部分网站、VPN 或大包连接异常，而普通 ping 仍然正常。

优先使用系统自动配置与 MSS Clamp。只有出现明确的路径 MTU 问题时，再手工调整；不要把“改成某个固定数字”当作通用优化。

路径 MTU 问题常表现为小包和普通网页正常，但特定 HTTPS、VPN、上传或大文件连接卡住。排查时先恢复自动 MTU，关闭叠加隧道，再逐层加入 PPPoE、VPN 和代理；如果只有某个隧道出现问题，再根据该路径的封装调整。全网盲目降低 MTU 可能掩盖故障，也会增加不必要开销。

供电、温度和存储也会表现成网络问题

高负载时出现降频、网口掉线、随机重启和存储 I/O 错误，应先检查：

• 电源电压、电流与 USB-C 线材；
• 金属外壳、导热垫和弱电箱通风；
• microSD/eMMC 错误与 overlay 空间；
• 网口协商、CRC 错误和驱动日志。

间歇性电源压降很容易被误判成代理插件或内核问题。

按症状定位故障层

客户端拿不到 IP

1. 确认物理 Link 状态。
2. 确认 AP 已关闭 DHCP，主网关 LAN DHCP 已启用。
3. 检查交换机/VLAN 端口是否属于正确 LAN。
4. 电脑设置临时静态 IP，直连主网关。
5. 查看 dnsmasq、odhcpd 和 netifd 日志。

能访问网关但不能上网

• 检查 WAN 是否获得地址，PPPoE 是否建立；
• 先测试上游网关，再测试公网 IP，最后测试 DNS；
• 检查 LAN 到 WAN 的防火墙转发和 masquerading；
• 停用代理、PBR 和自定义 nftables，恢复基础路径。

速度只有约 100Mbps

1. 查看 WAN、LAN、交换机和测试终端每一段的实际协商速率。
2. 更换已知正常的八芯网线和交换机端口，绕过墙内模块复测。
3. 检查水晶头、墙内面板和配线架是否八芯全部接通。
4. 确认测试终端使用有线或合适的 5/6GHz Wi-Fi，不是在 2.4GHz 环境中比较千兆结果。
5. 关闭代理、SQM、流量统计等附加功能，重新建立裸链路基线。

约 90–95Mbps 是 100M 以太网在协议开销后的典型结果，优先检查链路协商。若接口明确协商到千兆而吞吐仍稳定停在这一范围，再检查限速策略、虚拟机网卡、CPU 和测试端磁盘。

IP 能通但域名不通

• 确认客户端 DNS 指向主网关；
• 检查 53 端口冲突与 DNS 转发循环；
• 分别测试网关本地解析与上游解析；
• 检查 Fake-IP、DoH/DoT 和 IPv6 AAAA 策略。

代理开启后降速或部分网站异常

• 观察 CPU 单核与软中断；
• 检查节点、协议和 MTU；
• 排除局域网、上游网关、DNS 与代理服务器地址；
• 检查 IPv6 是否绕过或被错误阻断；
• 只保留一套透明代理组件。

无法投屏或发现设备

先确认发送端和接收端是否同一子网。双重 NAT、访客网络和 VLAN 会阻断广播/组播发现。跨 VLAN 需要 mDNS 中继、组播配置和精确防火墙规则。

随机重启和掉线

• 替换符合设备要求的电源与 USB-C 线材；
• 检查温度、导热垫和弱电箱通风；
• 检查 microSD/eMMC I/O、overlay 空间和只读错误；
• 恢复最小配置，排除插件内存泄漏和内核模块冲突；
• 检查网口协商、驱动日志和上游光猫状态。

随机故障需要时间线。记录重启前后的负载、温度、供电、日志与正在运行的任务，才能区分电源压降、过热、存储错误和软件崩溃。单纯更换代理规则不会修复物理供电问题。

保留最小诊断路径

OpenWrt 的路由基础文档建议结合接口状态、路由表、规则和 nftables 查看实际路径。排障时最重要的原则是逐层恢复最小配置：先链路，再地址，再路由，再 DNS，最后才是代理与应用。

建议为每次故障保存同一组证据：接口与协商状态、地址和默认路由、DNS 查询结果、相关防火墙/策略规则、CPU/内存/温度、系统与内核日志，以及发生时间。固定证据集合比“重启一下看看”更容易发现重复模式。

最终诊断顺序可以保持为：物理 Link → DHCP/静态地址 → 默认路由与 WAN → 公共 IP → DNS → 防火墙/NAT → 代理/VPN/PBR → 应用。每一层通过后再进入下一层，避免把一个 DNS 问题同时当成拨号、代理和 Wi-Fi 问题处理。

建立自己的性能验收基线

没有一套数字适合所有家庭，但每套网络都应该拥有可重复的基线：局域网有线吞吐、裸路由 WAN-LAN、实际 PPPoE/IPoE、代理或 VPN、空闲延迟、上下行满载延迟，以及高负载时 CPU 与温度。

系统升级、改变插件、调整 VLAN 或更换电源后，重复同一组基线测试。结果发生变化时，先看最近一次明确变更。性能调优的真正产物不是某次跑分，而是一套能帮助你定位变化发生在哪一层的测试方法。

只有当裸路由、供电、散热和链路都已验证，目标功能仍持续把 CPU 或网口推到极限时，才应该把“更换硬件”列为结论。若问题来自 100M 协商、DNS 循环、错误 MTU 或无线回程，升级 CPU 不会改善结果。

反过来，如果目标是千兆 SQM、持续高强度加密或多 2.5G 跨网段转发，而现有设备在最小配置下已经满载，继续寻找神奇参数也不会创造算力。测试基线的作用，就是区分应该调配置、修链路还是换硬件。

系列最后一篇将处理安全加固、远程访问、升级、备份和恢复，让已经跑通的网关能够长期稳定运行。

参考资料

• OpenWrt：SQM
• OpenWrt：SQM configuration
• OpenWrt：Routing basics
• OpenWrt：Firewall components