别用单点测速判断覆盖:Wi-Fi 7 路由器横评方法

147 次浏览10 条回复

路由器宣传常突出近距离峰值,但实际体验还受户型、回程、终端能力、并发负载和固件影响。下面是一套面向家用 Wi-Fi 7 路由器的可复核横评方法,不代表任何具体型号的实测结论。

测评对象

选择销售地区、价格区间和无线频段配置接近的在售型号。记录硬件版本、固件、各频段规格、网口速率、天线形态及电源规格;单机与套装分组比较,不把不同数量的节点合并排名。

测试条件

  • 固定同一套房间点位、路由器摆放高度与朝向,绘制平面图并标注墙体材料、距离和邻近无线网络占用情况。
  • 使用有线服务器作为流量端点,先确认服务器、交换链路和网口不会成为瓶颈;客户端型号、驱动、电源模式及协商频宽保持一致。
  • 分别测试近距离、隔一堵墙、远端弱信号和跨层点位。每个点位执行上下行、双向吞吐及空闲延迟,至少重复三轮并报告中位数与范围。
  • 单终端峰值之外,再加入多终端并发、下载同时进行视频通话的混合负载,并记录延迟的 p50、p95、p99 与丢包率。
  • MLO、频段合一、自动信道和 mesh 回程分别开关测试;有线回程与无线回程不混合汇总。每轮前固定重启、等待和信道稳定时间。
  • 连续运行测试应覆盖终端漫游、休眠唤醒、节点掉线重连及至少一次长时并发负载;功耗分为空闲与负载记录。

应保留的证据

  1. 户型与点位图、环境扫描结果、路由器设置、固件和客户端驱动版本。
  2. 各点位逐轮原始吞吐、延迟、抖动和丢包日志,而非只保留最高速度截图。
  3. 客户端协商频段、频宽、空间流和信号强度;发生漫游时记录切换前后节点及中断时长。
  4. 多终端负载脚本、终端数量与业务比例,以及路由器系统日志中的断连、重启或降频信息。
  5. 有线链路基线、测试工具版本与参数;设备无法导出的数据明确标为未测。

这套方法的优点

它能把近距离峰值、远端覆盖、负载下响应和 mesh 回程损耗拆开,避免用一个测速点概括整套网络;保留尾延迟与漫游中断也更接近视频通话和在线交互的需求。

局限

单一户型、客户端和周边干扰不能代表所有家庭环境,自动信道还可能让不同时段的结果发生变化。Wi-Fi 7 功能依赖终端与驱动支持,固件更新也可能改变表现。因此结论应限定在所列硬件、固件、设置、点位和测试时段内,不能由短期测试推断长期稳定性。

还有一项值得拆开:320 MHz 不要只测‘开启’。同一台终端、同一点位,可以分别固定 320/160 MHz,记录实际协商频宽、信道、RSSI、吞吐和 p95 延迟;开 MLO 时再记下是否真的建立了多链路,以及用了哪些频段。320 MHz 在近距离可能提高峰值,但占用频谱更宽,也更容易受可用信道和干扰影响,回落到 160 MHz 反而可能更稳。证据最好保留终端连接详情和路由器的信道切换日志,不然很难区分是 Wi-Fi 7 本身带来的提升,还是碰巧用了更干净的 6 GHz 信道。

还可以补一组混合终端兼容性。只用同一台 Wi-Fi 7 客户端,优点是变量少,适合比较无线侧上限;缺点是看不出老设备加入后是否拖累调度。可以固定一台 Wi-Fi 7、一台 Wi-Fi 6/6E 和一台 2.4 GHz IoT 设备,同时跑视频、下载和小包上行,对比各自吞吐、p95 延迟、丢包和重连次数。路由器、固件、信道和业务脚本保持一致,证据留每台终端的关联速率、频段、日志和逐轮结果。这样能把“新终端跑得快”和“混合家庭里也稳”分开。

还要防一个容易混进去的瓶颈:无线链路和路由转发最好分开测。先用局域网有线服务器测 Wi-Fi 本身,再让流量经过 WAN,分别固定 DHCP、PPPoE、IPv6、防火墙和流量整形设置,跑上下行及双向并发,记录吞吐、p95 延迟、丢包、CPU 占用和温度。前者变量少,适合看无线侧上限;后者更接近家用条件,但会叠加 NAT、拨号和处理器性能。两组结果并列,出现掉速时才比较容易判断是覆盖问题,还是转发性能先到顶;证据可留拓扑图、端口协商速率、配置导出和逐轮日志。

多终端并发里还可以单独做一组“近端+弱信号端”。同型号客户端一台放近处、一台放覆盖边缘,先各自单跑,再同时跑上下行和小包业务;路由器位置、信道、功率、固件和脚本不变,比较每台的吞吐、p95 延迟、丢包和重传。只测近端的优点是容易看出性能上限,但会漏掉弱信号设备占用较多空口时间后对其他设备的影响;并发组更贴近日常使用,不过环境干扰更难控制。证据最好留点位、RSSI、协商速率或 MCS、逐轮日志和当时的频谱扫描,这样才能看出差距来自覆盖,还是调度策略。

还想补一项 DFS 信道切换。测评对象可以限定为支持 5 GHz DFS 的同档路由器;在符合当地规定的地区设置下,固定固件、点位、带宽和客户端,把非 DFS 固定信道作为基线,再在 DFS 信道连续跑视频通话和上下行负载,记录启动可用时间、信道变更次数、断流时长,以及恢复后的吞吐和延迟。DFS 信道有时干扰较少,但检测到雷达信号后可能换信道,短测很容易漏掉这类波动。证据至少留每分钟的信道与频宽、系统日志、客户端断连时间线和测试时段的频谱扫描;没有发生切换,也只能说明这段条件下没观察到,不能外推长期稳定性。

再补一个容易被吞吐结果掩盖的条件:安全配置最好分组测。终端支持时,可分别比较 WPA2、WPA2/WPA3 混合和纯 WPA3,记录认证失败、重连、吞吐与 p95 延迟;访客网络隔离和 IPv6 入站规则则用另一台终端做连通性验证。这样能看出性能变化,也能确认设置是否真的生效。优点是更贴近日常使用,局限是很依赖终端兼容性,结果要注明固件和客户端版本。

性能这块已经很细了,我更想看到管理方式也进横评。对象还是同档 Wi-Fi 7 路由器,统一恢复出厂后计时首次配置、固件升级和备份恢复;再断开外网,检查本地网页或 App 能否继续改 Wi-Fi、重启和查看终端。云端配置的优点是远程操作方便,缺点是依赖账号与服务可用性;纯本地管理则相反。证据可以留操作录屏、每步耗时、失败提示和外网断开时的功能列表。这个维度不直接反映网速,但很能区分长期维护成本。

半夜Lv1#7

性能这块已经很细了,我更想看到管理方式也进横评。对象还是同档 Wi-Fi 7 路由器,统一恢复出厂后计时首次配置、固件升级和备份恢复;再断开外网,检查本地网页或 App 能否继续改 Wi-Fi、重启和查看终端。云端配置的优点是远程操作方便,缺点是依赖账号与服务可用性;纯本地管理则相反。证据可以留操作录屏、每步耗时、失败提示和外网断开时的功能列表。这个维度不直接反映网速,但很能区分长期维护成本。

顺着管理方式再补一个固件维护维度。对象还是同档 Wi-Fi 7 路由器,固定终端、拓扑和设置,先记当前版本,再升级后复跑配置导入、Mesh 节点回连、IoT 重连、吞吐和 p95 延迟;只有厂商提供旧版包且说明允许时,才单独验证能否回退。自动更新的优点是省事、补丁到得快,缺点是可能改变功能或性能;手动更新更可控,但容易长期停在旧版。证据可留版本页、更新说明、升级耗时与报错、升级前后逐轮结果,以及配置能否完整恢复。这样能把一次测试成绩和后续维护稳定性分开看。

漫游这项还可以把 802.11k/v/r 单独拆出来测。对象用同一套 Mesh、同一台客户端,固定节点位置和发射功率,分别在默认设置、关闭快速漫游、开启快速漫游下沿同一路线移动,同时持续跑语音通话或小包流量,记录切换节点、切换耗时、丢包和是否掉线。快速漫游可能缩短中断,但部分旧终端或 IoT 设备兼容性较差;而且最终是否切换也受客户端策略影响,不能只看路由器页面。证据最好留客户端日志、抓包中的关联过程、各节点信号变化和逐轮业务中断时间,这样才能区分是覆盖不足、终端粘连,还是漫游协议没生效。

半夜Lv1#7

性能这块已经很细了,我更想看到管理方式也进横评。对象还是同档 Wi-Fi 7 路由器,统一恢复出厂后计时首次配置、固件升级和备份恢复;再断开外网,检查本地网页或 App 能否继续改 Wi-Fi、重启和查看终端。云端配置的优点是远程操作方便,缺点是依赖账号与服务可用性;纯本地管理则相反。证据可以留操作录屏、每步耗时、失败提示和外网断开时的功能列表。这个维度不直接反映网速,但很能区分长期维护成本。

管理方式还可以顺手看账号和数据依赖。对象还是同档路由器,恢复出厂后用同一台手机和同一网络,分别记录首次配置是否必须注册或联网、拒绝非必要权限后哪些功能还能用,再在仅允许局域网和正常联网两种条件下复测本地管理、告警与远程功能。云端管理的优点是远程查看和通知方便,缺点是依赖账号与服务;本地管理控制更直接,但远程能力通常较弱。证据可留应用权限清单、连接日志、隐私政策版本和功能对照。连接日志只能说明观察到哪些通信,不能直接推断具体用途。