前段时间折腾家里的网络，换了一批设备之后，总想知道内网速度到底跑满了没有。
以前测内网吞吐量，基本就是 iperf3 走一遍。服务端开起来，客户端打命令，看数字。这个流程用了好几年，倒也没出什么问题。直到我想用手机测一下 Wi-Fi 到 NAS 的速度，才发现 iperf3 在移动端几乎没法玩——要么装终端，要么找第三方客户端，体验割裂得厉害。
就开始找有没有更简单的方式。
浏览器里跑测速
Homebox 的定位很直白：家庭网络工具箱。作者 XGHeaven 用 Rust（actix-web）搭了后端，前端是 React，打包成单二进制或者 Docker 镜像，部署完后打开浏览器就能测。
它的核心能力就三个：Ping、下载测速、上传测速。没有花哨的图表，也没有历史记录，就是给你一个干净界面，点一下开始，等结果。
我把它扔到了 NAS 的 Docker 里，一行命令：
docker run -d -p 3300:3300 --name homebox xgheaven/homebox
然后在局域网任意设备的浏览器里打开 http://NAS-IP:3300，手机、平板、笔记本都能直接测。这个体验比 iperf3 友好太多。
两种模式的取舍
Homebox 的测速逻辑有点意思。它用了 Web Worker 来做网络请求，避免阻塞主线程。但一个 Worker 的吞吐有限，作者说单 Worker 大概只能跑到 500MB/s 左右，离万兆还差得远。
所以做了两种模式：
- 低速模式：单 Worker，资源占用低，千兆环境够用
- 高速模式：多 Worker 叠加，压榨客户端性能，目标万兆以上
我在笔记本上试了一下。千兆内网，低速模式就能跑满，数值稳定。切换到高速模式，CPU 占用明显上去，但速度并没有提升——因为瓶颈在网口，不在客户端。
这个设计是合理的。很多人设备性能一般，没必要强行开多 Worker 吃资源。
几个意料之外的坑
虽然部署简单，但实际用下来还是碰到了一些细节问题。
服务端瓶颈。 我把 Homebox 跑在 NAS 上，第一次测速发现下载速度只有理论值的一半。排查后发现是 NAS 的 CPU 单核性能不够，服务端生成测速数据时成了瓶颈。换到一台性能更好的小主机上重跑，速度就正常了。README 里也提到了这点，但亲身体会一遍印象更深。
M2 的高速模式反而更慢。 作者的性能测试数据里有一条很有意思：M2 MacBook Air 在低速模式下能跑到 20G 下载，但开高速模式后数值反而下降且不稳定。原因是多 Worker 之间的资源调度竞争。这说明不是 Worker 越多越好，得看设备架构。
OpenWrt 的 arm64 二进制跑不起来。 如果要在软路由上直接跑 Homebox，arm64 版本可能会报 ELF interpreter 找不到。需要下载 arm64-musl 的静态链接版本。这个 FAQ 里写了，但第一次遇到确实会愣一下。
它适合谁
Homebox 不是一个全能的网络诊断平台。没有流量分析，没有设备拓扑，没有历史曲线。它就是解决一个具体的问题：让局域网里的任意设备，用浏览器快速测速。
如果你跟我一样，经常需要在手机、平板、电视、笔记本之间切换着测内网速度，又不想每台设备都装 iperf3，那 Homebox 是个不错的补充。放在 NAS 或者小主机上常驻，随时打开浏览器就能用。
但如果你要排查丢包、延迟抖动、路由路径这些问题，它帮不上忙，还是得用专业工具。
项目最近刚发了 v0.1.3，主要更新了移动端的测速界面和图表展示。作者还在做一个终端测速模式（WIP），脱离浏览器直接用脚本跑，理论上精度和性能都会更高。等这个功能上线，我再试一波。