空闲的 VPN 会占用带宽吗？看准正确的计数器

你的隧道开了一整夜，没有播放任何流媒体，用量曲线却仍在移动。这很正常：VPN 保持的是一条会话，而不是预留一段线路，因此预留份额为零，而字节虽小却真实存在。这两个概念经常被互换，所以“空闲 VPN 是否占用带宽”这个问题在两个方向上都被答错了。在你能描述的观察窗口里测量正确的计数器，一个下午就能得出结论。

空闲隧道为何仍在搬运字节

隧道是一份有生命周期的映射，必须有东西让它保持存活。握手会过期，NAT 设备会丢弃空闲映射，而沉默足够久的对端可能在两端都不报错的情况下变得不可达。各协议在“无事可发”时的行为不同：WireGuard 在握手稳定后默认不发送任何东西，而可选的 PersistentKeepalive设置会加入周期性数据包，让位于映射之后的对端保持可达。有意打开它，这个间隔就会在计数器里显现。

OpenVPN的 keepalive 助手做法不同：它定义类似 ping 的检查，让两端能区分存活会话与失效会话；自带传输的客户端则用其他名字实现等价定时器。这些都不会出现在应用窗口里，所以空白的界面并不能说明线路上发生了什么。

空闲的应用不等于空闲的设备

一条打开的隧道要服务所有接入它的客户端，而客户端很少停下来。照片同步、解析器查询、更新检查和监控代理都会走默认路由，而在全隧道配置里，这条路由就是隧道本身。口袋里休眠的手机仍在轮询，备份任务也不会在意没人在看视频。说隧道空闲，意思是设备在用它的时候你没有用。

桥接与路由配置承载的流量不同，所以同一次观察在两者上可能得到不同答案。测量前先记下谁还连着，因为一个同步客户端就可能盖过该时段内所有 keepalive。

只选一个计数器，并说清它统计的是什么

总量有三种，各自回答不同问题：穿过隧道的是什么、穿过物理链路的是什么、服务商决定计费的是什么。在上行链路上计数，会把从未进入隧道的东西也算进去，从 ARP 波动到邻居的串流。在隧道接口上计数，会漏掉外层报头、握手重试和维持映射的 keepalive。两边都读代价很低，而这是看清一个字节记在隧道哪一侧的唯一办法。

ip -s link show wg0
ip -s link show eth0

引用任何一个数字之前，先确定你的问题问的是哪一种，因为把两者相加会把相关工作算两遍。服务商的账务可能在你测量的时段之后才结清，所以与账单不一致的总量并不自动等于错误。发布任何数字时，都附上接口、方向和时段。

做一次短时受控测量

让隧道及其防护保持平日的运行状态，跳过可选的传输，并记录谁一直连着。读取计数器，等一段足够长的窗口，再读一次，并把经过的时间与差值写在一起。大规模测速回答的是另一个问题：它把链路跑满，却对空闲成本只字不提。

如果第一次结果看起来不可能，就把窗口重复一遍，因为单个样本可能正好撞上计划任务。两个互相吻合的区间才是证据；只有一个区间，那只是带单位的轶事。

不要用更差的隧道换一个更干净的零

为了让曲线好看而关掉 keepalive 或存活检查，会改变你正在测量的部署，而且隧道可能在下一次空闲期之后再也回不来。动手之前先问这个机制服务的是可达性还是维护性；如果是前者，就在它运行时测量，因为那才是你要支持的配置。一个掩盖了损坏恢复路径的更干净的零，是这项练习里最昂贵的结果。

当数字确实很大时，去找产生它的进程或客户端，而不是假定协议把线路填满了。比较内外两个计数器，看字节落在哪一侧，然后报告该时段的用量，而不是你以为拥有的容量。