最近为 MikroTik L23UGSR-5HaxD2HaxD 设计了一款 3D 打印外壳，并借到一块主板进行测试，以下将其简称为 L23。这款设备采用 IPQ-5010 与 QCN-6102 的组合，5GHz 支持 2×2 MIMO 和 160MHz 信道，标称最高物理层速率约为 2400Mbps。

在强信号、纯桥接用途以及关闭连接跟踪等条件下，本次测试得到的吞吐约为下行 700Mbps、上行 460Mbps，低于预期。同样运行 RouterOS 的改装小米 AX3600，在 80MHz 下反而表现更好。

这次测试反映出一个值得讨论的问题：部分 MikroTik WiFi 6 产品拥有较高的无线连接速率，但实际数据吞吐未能同步提升。官方社区也存在相近反馈。不过，现有证据更适合用于分析具体平台和软件路径，不能据此认定所有 MikroTik WiFi 6 产品都存在相同上限。

测试设备与对照平台

L23 使用 MMCX 转 SMA 跳线和标称 12dBi 的外接天线，终端为 2×2 MIMO 设备。对照设备为通过非官方 RouterOS patch 运行的小米 AX3600，其硬件组合与 Chateau PRO ax 接近，但不应把改装设备视为官方产品的等价测试样本。

以上硬件参数来自官方产品页：L23、hAP ax³、Chateau PRO ax。

相同的 2400Mbps 标称值，可能来自不同的空间流和信道宽度组合。面对 2×2 终端，4×4 AP 并不会让客户端使用四条空间流。在此次 AX3600 的 80MHz 工作模式下，2×2 WiFi 6 终端的最高 PHY 约为 1201Mbps；L23 在 160MHz 下则约为 2402Mbps。

RouterOS 7.25 下的实际结果

本次 L23 使用 RouterOS 7.25。测试时已确认：

• 关闭 Connection Tracking。
• 启用 FastPath。
• Bridge 的 use-ip-firewall 未开启。
• 未运行 Torch 或 Sniffer。

这些条件排除了几项常见的额外处理开销。FastPath 的全局开关启用，并不等于测速流量实际完整经过 FastPath，后者还需要结合接口统计和驱动支持情况确认。

表中的 AX3600 与 hAP ax³ 是经验对照。

截图显示的不只是强信号

L23 测试描述中的信号约为 −36dBm， WinBox 快照显示约 −39dBm，均属于很强的接收信号。但当时的 PHY 为 1729.4Mbps 和 1921.6Mbps，并未达到标称最高值约 2402Mbps。

PHY 是无线物理层发送速率，不是应用可获得的有效吞吐。信道竞争、确认帧、重传、聚合效率及协议开销都会拉开二者之间的距离。因此，不能直接用 700÷2400 计算所谓整机效率。不过，1.7～1.9Gbps 的连接速率与数百兆吞吐之间的落差，仍值得进一步定位。

CPU 窗口也提供了线索：记录到 IRQ 列分别出现 71%／59% 和 14%／84%。这些数值位于 IRQ 列，不能误写为 CPU 总负载，也不能与 Load 直接相加。它们表明部分时刻中断处理开销较高。

另外， WinBox 快照都主要显示 ether1 接收、wifi2 发送。在无线终端下载的场景中，这两张图均对应下载路径，不能分别作为上下行 CPU 分析的证据。

CPU 没到 100% 仍可能限制吞吐

多核 CPU 的总利用率不足 100%，不能排除处理瓶颈。无线中断、接收队列或驱动中的某个顺序执行环节，可能主要由一个核心承担。当这个环节达到上限，其他核心的空闲时间未必能够用于分担工作。

但高 IRQ 或某个核心接近满载，也不能单独证明是 CPU 选型不足。驱动处理每个包需要多少工作、队列如何分配、数据如何在主机和无线芯片间流转，都会影响 CPU 何时达到上限。

因此，硬件与软件不是互斥的解释。同一颗 CPU，经过不同的数据路径，可能表现出不同的吞吐和负载。本次现象支持进一步检查 IPQ-5010 的处理余量，以及 RouterOS 无线驱动和队列的效率；尚不足以确定某个具体环节就是根因。

官方社区已有相似性能反馈

这里的“官方社区”指 MikroTik 运营的论坛。普通用户的测试和判断不等于厂商正式结论，但具有条件说明的案例可以作为对照。

NetMetal ax 在 700～800Mbps 时出现单核满载

2024年8月14日，用户 dulasau 在NetMetal ax 与 L23 讨论帖第18楼反馈：使用 Apple 桌面客户端、约 −55dBm 信号、多连接 Speedtest，吞吐约为 700～800Mbps，其中一个 CPU 核心达到 100%。

NetMetal ax 官方型号为 L23UGSR-5HaxD2HaxD-NM，采用相近的平台，因此这个结果与本次 L23 有较强参考关系。但该帖没有交代完整的无线参数和受控测试条件，不能据此确定硬件上限。

高 PHY 与未满载 CPU 也可能伴随低吞吐

2025年5月的AX hardware speed limit 讨论帖中，有用户报告链路 PHY 达到约 2.1～2.4Gbps，实际吞吐仍约为 400～500Mbps，并称每核 CPU 未满载。测试涉及 7.18.2 和 7.19rc1。

同帖第32楼，maigonis 用 wAP ax 作为 Station 连接 hAP ax³，并通过有线电脑运行本地 iperf3。在 7.19rc2 下，80MHz 的五连接和二十连接结果分别为 550Mbps、665Mbps；40MHz 则为 422Mbps、434Mbps。用户报告两个核心均未超过约 70%。

这些反馈与本次“宽信道未充分转化为吞吐”的现象相似，但部分测试含 MikroTik Station 端，不能与手机直接连接 AP 完全等同。用户对驱动或软件的怀疑，也应与实际测量结果分开引用。

同平台也有接近千兆的结果

负面案例之外，同平台的较高结果同样需要保留。

2024年10月23日，maigonis 在wAP ax 讨论帖第97楼给出了以下测试：

wAP ax 官方规格同样为 IPQ-5010＋QCN-6102。这条记录说明，这个芯片组合并不存在已被证实的固定 700Mbps 上限。

在7.21rc 讨论帖第334、336和344楼，还有用户报告约 900Mbps 或 924／450Mbps；此前反馈性能问题的 itimo01 则表示，使用 7.21rc6 重测后，80MHz 两个方向分别可达约 700Mbps。后者属于再次测试的结果，不是控制其他变量后的版本回归实验，不能直接归因于某项修复。

同一问题帖中，第31楼所在页面还出现用户转述的支持答复：隔离或安静信道测试中，UDP 每个方向曾达到约 1Gbps，TCP 的较低结果约为 630～700Mbps。由于这是工单答复转述，且测试方法不同，应视为补充信息，不能当成所有场景下的官方性能承诺。

L23 的测试运行在 RouterOS 7.25，因此不能简单用论坛早期版本的问题解释当前结果。同时，同平台存在更高吞吐，说明也不能仅凭 IPQ-5010 的规格，就断言它无法接近千兆。

改装 AX3600 在 80MHz 下的领先表现，说明信道宽度不是决定吞吐的唯一因素，更强的平台和不同的射频实现可能带来优势。但这不是“补丁让无线变快”的证据：CPU、板级配置、天线和驱动环境都不同，不能将差距归于单一变量。

对 MikroTik WiFi 6 性能的评价

本次测试表明，在 RouterOS 7.25、强信号和较简化的桥接配置下，L23 的 160MHz 无线能力没有转化为预期的千兆级应用吞吐。结合社区相似案例，部分 MikroTik WiFi 6 设备在高连接速率下仍可能遇到实际速度受限、上下行差异明显，以及 CPU 或 IRQ 开销偏高的问题。MikroTik 部分 WiFi 6 产品在实际吞吐表现及其可解释性上仍有改进空间，标称无线速率在硬件和RouterOS结合后，无法发挥WiFi 6实际性能。

个人观点：IPQ-5010在RouterOS系统上无法发挥 WiFi 6 160MHz的性能，如果跑到1Gbps的速率，CPU必然100%，L23配置2.5G光口完全是浪费，我不清楚MikroTik 官方为什么要这样设计硬件，为什么不用IPQ-6010，因为控制产品的成本问题？

我只能认为全球IT和相关产业链成本不断增加，加上MikroTik将产品生产迁移回欧洲本土，导致MikroTik在自己性价比的产品设计上出现严重的局限，导致现在RouterOS在 WiFi 无线上的无赖。从hAP be系列可以看出，hAP be3 lite阉割CPU性能导致WiFi 7 性能被压制，hAP be3的性能发挥出来，但覆盖距离很拉跨，要靠多媒体的容器和伪NAS来为产品续命。那容器应用和网络处理抢占CPU开销又如何解决？

从我的眼里看唯一能给MikroTik续命的只有CRS和CCR系列