2026年软路由流量监控与带宽归因完全指南：看清每台设备、每类流量与每条代理连接的去向

宽带是 500M，路由器也不便宜，可一到晚上全家都在喊卡；机场订阅明明写着每月 1TB，月中就见了底，却不知道是谁用掉的；路由器后台只有一根上上下下的总流量曲线，除此之外什么都看不出来。这是大多数自组软路由的家庭都会遇到的处境。

问题不在"测不出速度"，而在"看不见结构"：总带宽被谁占了、瓶颈在上行还是下行、被吃掉的是运营商的宽带流量还是订阅的额度、哪台设备在后台偷偷跑——这些都要先把观测这件事做对。

下面按三步走：先把"流量"拆成三种互不相等的口径，别再用一个数字解释所有问题；再按需求挑工具（nlbwmon、wrtbwmon、vnstat、实时工具与代理面板）；最后把"网速慢"和"流量见底"定位到具体的设备、时段和连接上。如果你只想省事、要一个稳定出口，直接挑一家靠谱的机场（例如自由猫）也能解决问题；但只要你用的是机场订阅或自建节点，这套"看清楚"的方法都值得花半小时搭一次。

一、先分清三种口径：宽带总量、每设备用量、代理用量

"流量"这个词在家里至少对应三个互不相等的数。混着用，就会得出错误结论。

口径	回答什么问题	数据在哪一层	典型工具	能否归因到设备
宽带总量	这条线这个月一共跑了多少、离套餐/账单还有多远	WAN 网卡计数器	vnstat、运营商 App	不能
每设备用量	哪台设备、哪类协议用了多少	连接跟踪（按 IP/MAC 计数）	nlbwmon、wrtbwmon	能
代理用量	订阅被谁吃掉了、走的是哪条线路	代理内核的连接与流量统计	OpenClash 连接面板、内核 API	能（含进程与链路）

第一种常见错误，是拿 WAN 总量去解释代理问题。接口计数器跑满只说明"运营商这条线用满了"，它既说不清是谁用的，也说不清有没有走代理。

第二种，是只看下行。家庭宽带的上行通常比下行小得多，一次相册备份或一段录屏上传就能把上行占满，而屏幕上显示的"下载速度"完全正常——于是你一直以为网络没问题。

第三种，是把接口级统计当成每设备统计。接口计数器只回答"这个口进出了多少"，它不知道数据属于谁；要知道"哪台设备用了多少"，必须让路由器按主机（IP/MAC）分别计数。

把三种口径分开之后，选工具就变成一道选择题：要长期账本，选按主机计数的方案；要抓现行，用实时工具；要看订阅被谁吃，看代理侧；要跟运营商账单对账，看接口统计。下面逐层展开。

二、底层机制：为什么有的监控"在跑，数字却不动"

先讲一个能解释大部分疑惑的机制：连接跟踪记账（conntrack accounting）。

Linux 内核的连接跟踪子系统会为每一条"流"维护状态；开启记账后，内核会给每条流附上字节与包的计数器。nlbwmon 这类工具就是通过 ctnetlink 这个 netlink 接口，把这些计数器读出来汇总的——这一点从它的软件包依赖就能看出来（依赖里明确列了 kmod-nf-conntrack-netlink）。

机制本身决定了三个特性，也正好是三个坑：

读后清零。 每次轮询，内核把计数交给用户态后就把该连接的计数清零。所以这类工具必须长期运行：服务一停、或者路由器一重启，正在进行的连接里还没落盘的那段增量就丢了，表现是"某天的数字突然变小或断掉"。
连接销毁时补收。 连接超时或关闭时，内核会先通知工具把最后一段统计收走，再删除该条目。这也意味着短连接密集的场景对缓冲区很敏感——netlink 缓冲区太小会来不及收，官方配置注释写得很直接：缓冲区选小了会丢记账信息，导致统计失真。
被流量加速绕过。 软件/硬件流量加速（flow offloading）会把已建立的连接交给 flowtable 直接转发，绕开常规的 netfilter/conntrack 逐包处理。结果是速度上去了、按主机与按连接的计数开始漏。基于防火墙规则计数的那类工具，作者在项目说明里干脆标注"不兼容 Routing/NAT、Flow Offloading"。

计数机制	计数对象	粒度	受 flow offloading 影响	典型实现
连接跟踪记账	内核为每条流附加的字节/包计数器	连接 → 可归并到主机	明显受影响（漏记）	nlbwmon
防火墙规则计数	命中规则的数据包	主机或规则	明显受影响	wrtbwmon（iptables 规则）
接口计数器	网卡的收发字节	接口	不受影响	vnstat
应用侧统计	代理内核处理过的连接	连接（含进程/链路）	不受影响	代理面板、内核 API

所以第一原则是：先验证，再相信。装好工具后，用一台设备下一份已知大小的文件（比如一个几百 MB 的系统镜像），对照统计里那台设备的变化，确认数字是动的、量级是对的，再拿它做判断。如果数字纹丝不动，优先怀疑两件事：固件是否裁掉了 conntrack 记账能力，以及转发层是否开着加速。下面各节的具体配置，都建立在这条验证成立的前提上。

三、nlbwmon：官方软件源里的"按主机 + 按协议"长期账本

如果只看一个工具，优先看 nlbwmon。它就在 OpenWrt 官方软件源里，配一个 LuCI 前端，两条命令装好：

opkg update
opkg install nlbwmon luci-app-nlbwmon

它按四个维度记录用量：IP 版本（IPv4/IPv6）、IP 地址、MAC 地址、以及 Layer7 协议（按端口）。默认以自然月为一个记账周期，保留最近 10 个周期；协议文件里预置约 45 条端口定义，匹配不上的流量归入 "Other"。

装好后界面在「服务 → Bandwidth Monitor」，三个页签分别是显示、配置、备份。配置项写在 /etc/config/nlbwmon，几个值得记住的默认值：

配置项	默认值	含义
netlink_buffer_size	524288	netlink 接收缓冲（字节），太小会丢计数
refresh_interval	30s	从内核刷新活跃连接计数的间隔
commit_interval	24h	内存数据库落盘间隔
database_directory	/var/lib/nlbwmon	账本存放目录
database_interval	1	每月 1 日起新周期
database_generations	10	保留的历史周期数
database_limit	10000	账本最大条目数

命令行也能查：软件包里带一个 nlbw 的符号链接指向本体，可以直接输出当前统计。接口 up 时还有一个 hotplug 脚本会自动 reload 服务，避免新接口漏统计。

两个必须知道的坑：

缓冲与周期要按家庭规模调。 设备多、短连接多的家庭，默认的 netlink 缓冲可能偏紧；把记账周期保持每月 1 日、历史周期数按需加大，才能和"月度套餐"对齐着看。
部分第三方固件上它会"装了不计数"。 社区有明确报告：ImmortalWrt 25.05.x 配 firewall4 时 nlbwmon 全是 0，把防火墙切回 iptables 版本的 firewall 就恢复正常；而同版本的官方 OpenWrt 配 firewall4 是正常的。遇到这种情况，先按上一节的小样本验证确认，再决定换固件、换防火墙后端，还是改用下一节的做法。

nlbwmon 的定位是"账本"：它回答"过去一个月，这台设备、这类协议用了多少"。它的记账周期默认跟自然月对齐，而多数机场后台的流量也是按自然月重置的——两边口径一致，就能逐个设备去对。如果你用的是按月计费、单价偏低的大流量档（例如瑶瑶领先那类入门档位），把这套账本挂上，谁在吃额度当天就能看出来，不必等到月底才发现超额。

四、wrtbwmon：按 MAC 认设备，界面更像"谁在用"

nlbwmon 主要以 IP 为单位记账（同时记录 MAC），而 wrtbwmon 从设计上就是"按设备"的：它用防火墙规则给每个客户端单独计数，界面直接列出一台台设备的累计用量，还能看实时速率。

要用就得选对版本：认准 brvphoenix 维护的兼容版（配套的 wrtbwmon 与 luci-app-wrtbwmon），不要用更早的原始版，两者互相不兼容。新版额外支持 IPv6，并且改用 MAC 而不是 IP 识别主机——设备换了 IP 也不会把历史拆成两台。装好后在「网络 → Traffic status」。

它的限制要提前知道：与 Routing/NAT、Flow Offloading 不兼容，作者在项目说明里写得很清楚。这和第二节讲的"加速会绕过计数"是同一个原因。所以如果你的软路由开着硬件加速又想要按设备精确记账，就得在这两者之间做取舍，取舍方法放在第九节。

五、vnstat 与实时工具：接口级总量与"抓现行"

前面两个都是"按主机"，vnstat 则是"按接口"：它读的是网卡计数器，回答"这个月 WAN 口一共进出了多少"。它适合跟运营商账单、套餐余量对账，但不能告诉你"是谁用的"——所有流量都被归到 WAN 这一个数上。常用三条命令：vnstat -l 看实时、vnstat -d 看按天、vnstat -m 看按月。

要"抓现行"——此刻到底是谁在跑满：nlbw 能看实时增量，iftop 能按连接列出当前吞吐，bmon 给的是接口曲线。这类工具只解决"此刻"，不解决"过去"，但排查突发卡顿时最快。

顺带说清一个容易踩的预期：OpenWrt 官方 LuCI 源里对应的是 luci-app-nlbwmon 与 luci-app-statistics（collectd 统计框架）；vnstat 本体在软件源里有，但它有没有 LuCI 界面取决于你刷的固件打包了什么，别默认菜单里一定能找到。

工具 / 方案	粒度	数据保留	实时性	是否受加速影响
vnstat	接口	长期（日/月）	有实时视图	否
nlbwmon	主机 / 协议	默认保留 10 个周期	准实时（刷新间隔）	是
wrtbwmon	设备（MAC）	可持久化，随数据库保留	界面可显示速率	是
iftop / bmon / nlbw	连接 / 接口	仅当前	实时	否（连接级）
代理面板 / 内核 API	连接（含进程与链路）	仅当前连接	实时	否

一句话总结：接口级看总量、主机级看账本、连接级抓现行、应用侧看代理。前三类解决"宽带被谁用"，最后一类解决"订阅被谁吃"——从这个区分开始，就进入了观测里最容易做错的一半。

六、把本地数字和订阅后台对上：口径差异清单

做观测的人迟早会撞上一个问题：自己在软路由上统计出的用量，和机场后台显示的已用流量对不上，有时差得还不小。这不是谁在造假，而是两边口径本来就不同。逐项对一遍：

倍率不同。 同一个订阅里不同节点倍率不同（常见如直连或普通中转 1x、优质专线 1.5–3x），后台按"扣除量 = 实际传输量 × 倍率"记账，而本地统计的是实际字节。专线节点走得多的月份，后台一定比本地多。
双向计费。 多数机场把上传与下载合计进额度；本地若只看下行，就会少算一半。
多设备共用。 同一个订阅可能被手机、电脑、路由器一起用；软路由只统计得到"经过软路由"的那部分。
统计起点不同。 本地账本按你的部署日期起算，后台按自然月或购买日重置。
代理之外的开销。 DNS 查询、心跳、订阅自动更新通常很小；但如果你开了 TUN 模式，系统更新、后台同步也会一并进代理，量就不容忽略。

把这五项列清楚再算"一个月到底需要多少流量"，误差才会收敛。套餐条款本身怎么读（倍率、限速阈值、重置口径），可以对照机场流量计费陷阱全解析，这里不重复。

分设备统计在多设备家庭里格外有用。当同一台软路由后面挂了用途不同的设备——比如需要固定 IP 属性、专门用来做跨境多账号的那一类，常常单独配一个出口（仙路湾这类住宅 IP 方案就常被放在这个位置）——能分设备看清各自消耗，就不会出现"某台设备把额度用光、全家一起断"的情况。

七、代理侧归因：OpenClash 连接面板与内核 API

前面几节都在看"宽带这一侧"。但你真正付钱的是订阅，所以还必须能看代理这一侧。OpenClash（以及它底层的 mihomo 内核）自带一套连接视图，不用额外装东西。

三个入口：

运行状态页。 顶部工具栏就有累计上传/下载统计，一眼看到代理此刻跑了多少。
控制面板。 yacd、metacubexd、zashboard 这些 Dashboard 读的是同一份连接数据，能按连接列出源地址、目标域名、命中的策略组与节点，并按连接排序——"谁在跑、跑到哪、用了多少"都在这里。
内核 API。 要让脚本自动取数，直接请求内核的 /connections。它返回两个总量字段 uploadTotal / downloadTotal，以及一个连接数组；数组里每条连接都带元数据（源/目标地址、协议，部分平台还能给出进程名）、该连接已上传/已下载的 upload / download 字节数，以及命中的代理链路 chains / providerChains。

其中 chains 是整篇里最有价值的一个数：它把"某个进程的流量"和"走了哪条线路"直接连了起来。链路短、走纯专线的节点（比如SS-ID这类纯 IEPL 方案）在连接列表里表现为层数少、状态稳定，出问题时更容易判断是节点侧还是本地侧。选线路之前先把线路类型搞清楚，可以看国际线路科普那一层的基础。

还有一个常被忽略的功能：访问控制。OpenClash 把"哪些设备走代理、哪些直连"做成了两组可维护的名单（内核里对应一组 nft 集合）。想验证某台设备到底进没进代理，看它在不在名单里、再看连接列表里有没有它的连接即可，比在设备上来回改配置可靠得多。设备分组与名单位置的完整做法，见软路由网段隔离与内网安全完全指南。

八、把"网速慢"定位到源头：一份可照做的排查顺序

有了数据，排查就从"猜"变成"排除"。建议固定按这个顺序走，每一步都能排掉一整类原因：

先看是上行还是下行。 下行跑满多半是下载或流媒体；上行跑满更常见于备份、云同步、P2P 做种——而家庭宽带的上行往往小得多，体感会特别明显。
再看是"一台设备满"还是"全屋都慢"。 用按主机统计区分：单台设备跑满，说明那台设备在偷跑；全屋都慢且每台设备都不高，更像 WAN 侧或代理侧的问题。
看是不是固定时段。 晚高峰（大约 20:00–23:00）规律性变慢，多半是线路或节点在拥堵；全天均匀地慢，更像设备或配置问题。
区分代理与直连。 关掉代理再测一次：只有走代理慢，问题在节点或协议；两者都慢，问题在宽带或转发。
最后才怀疑"被蹭网"。 查访客网络是否开着、无线密码是否泄露、主机列表里有没有陌生 MAC。

常见的"偷跑源"按出现频率排：系统与游戏平台的自动更新、云盘与相册的自动同步、手机照片备份、流媒体的预加载与自动连播、BT 与网盘客户端的后台上传、摄像头等 IoT 设备的上行、NAS 的备份任务。它们共同的特点是"只在你不用网的时候跑"——反而更该用账本把它们抓出来。

顺带一个容易被忽略的联动：这类后台任务多数会经由代理（尤其是开了 TUN 之后），也就是说它们消耗的不只是宽带，还有你的订阅额度。把它们的出口改到直连组，或者干脆在账本里给它们单独标记出来，是让订阅额度花在刀刃上最直接的一招。

九、观测与加速的取舍：flow offloading、SQM 与按设备计数

到这里必须把第二节和第四节里那根刺挑明：你要的"精确账本"与"极致转发速度"，在实现上是冲突的。

流量加速之所以快，是因为它让已建立的连接绕过逐包的 netfilter 处理，直接交给 flowtable 转发；而按主机、按连接的统计恰恰寄生在这条通往 conntrack 的路上。两者同时开，通常的结果是"测速很好看，账本开始漏"。SQM（智能队列管理）也会和加速互相牵制：追求多人场景下的低延迟通常要开 SQM 并关加速，纯追求吞吐时反过来。这三件事互相制约，没有"全都要"的免费方案。

你更在意	加速（flow offloading）	按设备精确账本	多人低延迟（SQM）	建议组合
看清用量	关	要	可选	关加速 + 主机级账本
极致吞吐	开	放弃	关	开加速，改用接口级/代理侧统计
多人稳定	关	要	要	关加速 + SQM + 主机级账本
只关心订阅	随意	不必	可选	保持加速，只看代理侧连接

实践中的折中办法，按优先级排：

平时关加速、只做账本。 家庭带宽利用率本来就不高，大部分时间跑不满，关掉加速对日常体验几乎无感，换来的是可信的数据。
要加速就设"观测窗口"。 需要精确定位时，临时关掉加速跑一天，收完数据再开回来。
改用不依赖 conntrack 的路径。 接口级（vnstat）与代理侧（连接列表）不受 flowtable 影响，代价是失去"按设备"这一维。
只在代理出口做归因。 如果你只关心"订阅被谁吃"，代理侧的连接统计已经够用，完全不必为了它去动转发层。

转发层优化本身的取舍（硬件转发、MTU、多 WAN、QoS）在软路由性能优化完全指南里讲得更细：那一篇的目标是"怎么更快"，本篇的目标是"怎么更清楚"，两者要放在一起规划，别先后打架。如果你还要在自建节点一侧做流量监控（VPS 的月度流量、超额告警、被入侵后的异常暴涨），那是另一套做法，可以参考自建VPN进阶管理里的对应章节。

十、按需求选：四种典型场景的配置组合

场景	首要目标	推荐组合	代价
普通三口之家	知道谁在偷跑	nlbwmon 长期账本 + 面板看代理	需关加速
设备多、常换 IP	按设备认账	wrtbwmon（MAC 识别）	不兼容 NAT/加速
只想跟套餐对账	总量与余额	vnstat + 订阅后台	无法归因到设备
只关心订阅被谁吃	代理侧归因	代理面板 / 内核 API + 访问控制名单	只能看当前连接

用一句话收口：账本（nlbwmon）保证你不被"谁用了多少"卡住，接口统计（vnstat）保证你和运营商与套餐的账对得上，连接列表（代理面板）保证订阅没被偷跑，实时工具保证你当下能立刻定位。四者数据来源不同，互为补充，不能互相替代。

还有一条容易被忽略的纪律：这些工具都能看到域名、IP 甚至进程名，属于"能看见你在上什么网"的级别。它们只该跑在自己家的路由器上，别把带原始连接数据的截图随手发到公开场合。

十一、常见问题（FAQ）

Q1：装完 nlbwmon，数字一直是 0，怎么排查？
按顺序查三件事：第一，确认内核的 conntrack 记账能力在不在（换一个固件或防火墙后端做对照）；第二，确认转发层没开流量加速；第三，用一台设备下一份已知大小的文件做小样本验证。三者都正常还不动，基本就是固件问题，换官方固件通常能解决。

Q2：能不能同时装 nlbwmon 和 wrtbwmon？
技术上可以，但没必要——两套机制都在读内核计数，同时开会重复记账、增加负担，还容易出现两个界面数字对不上。建议只留一套：要长期账本用 nlbwmon，要"按设备 + 实时速率"用 wrtbwmon。

Q3：为什么账本里的总量比运营商账单少？
接口统计只覆盖经过这台路由器的流量。光猫上如果还接了机顶盒、或者有其他设备走了运营商自带的路由，就不在这台软路由的视野里；反之，如果有设备自己开了客户端直连某个节点，也绕开了账本。两种方向都会造成差值。

Q4：开了 TUN 模式之后统计变化很大，正常吗？
正常，但要重新校准预期。TUN 会把系统更新、后台同步这类原本直连的流量也拉进代理，代理侧统计自然上升；同时部分环境下会出现"同一份流量在两块网卡上都被记到"的错觉。看总数时以代理侧连接列表的总量为准，看单机用量时以主机级账本为准。

Q5：我想知道某台设备走了哪条线路，能查吗？
能。代理侧的连接列表每条都带 chains，会显示命中的策略组与节点；按源地址过滤出那台设备的连接，就能看到它实际走的链路。这也是验证分流规则有没有按预期生效最直接的办法。

Q6：为了精确记账，必须关掉硬件加速吗？
看你更看重什么。带宽利用率不高（很少跑满）的家庭，关掉加速几乎无感，换来可信数据，通常划算；经常跑满千兆、又需要精确数据的场景，用"临时观测窗口"的办法折中更现实。

Q7：账本数据存在哪？重启会不会丢？
内存数据库按固定间隔落盘（默认 24 小时），重启会丢掉"最后一次落盘之后"的增量；正在进行的连接如果没被回收，那部分也可能丢。所以看到"重启当天数字偏小"属于机制的正常表现，不是统计坏了。想更稳，可以把落盘间隔调小。

Q8：这些工具会不会拖慢路由器？
读内核计数本身很轻，官方实现还带 nice 值降低优先级；真正影响性能的是你为了记账而关掉的加速。低配设备（如 ARM 小主机）挂长期账本问题不大，但要留意账本条目上限，别让它无限增长。