Mac VPN 的字节计数器能证明什么、不能证明什么

打开客户端的状态窗口，数字看起来令人安心：字节在增长，隧道已连接。关掉窗口，办公应用仍然失败，也就是说计数器回答了一个没人提出的问题。在某个接口上统计字节，只能衡量该观测点的流量，仅此而已。请从你眼前的这个数字出发，走到它所报告的那一层，再走到应用实际给你的结果。

先选接口，再选数字

先从数字显示的位置开始，读一读它旁边的标签。客户端窗口可能显示会话总量，隧道接口可能显示内层 IP 字节，物理适配器可能显示加密后的外层字节；三个不同的计数器恰好都以字节计量。在命令行里，netstat -ibn 会为每个接口上的每个地址打印一行，因此同一个隧道可能出现多次。把这一行与客户端真正拥有的接口对应起来，再用目标所选择的路由加以确认。名为 utun 的设备可能属于这个 VPN，可能属于另一个隧道，也可能与你无关。

不要因为它更容易读就换成 Wi-Fi 计数器。不同的观测点回答的是不同的问题。

取差值，而不是开机以来的总量

读一次这一行，发一个小的获准请求，然后再读同一行。差值才是证据，因为自开机以来的总量包含机器做过的一切。把间隔保持得短一些，后台流量污染它的机会就少一些。在繁忙的机器上，nettop 可以把吞吐量归到某个进程，这能在你回到接口计数器之前先缩小范围。

要接受差值并不干净。邮件、更新以及客户端自己的保活消息都有贡献，所以把这个数字当作上限，而不是测量值。如果这段时间里你只做了应用这一件事，上限通常已经紧到足够有用。

内层计数器和外层计数器衡量的是不同的东西

物理适配器统计的是加密数据包，包括它们的外层头部；隧道接口则计入它接收或交出的载荷。把两者相加，同一份传输就被算了两遍。额外开销、重传和封装也让简单的等号无法成立。

两个计数器朝相反方向变化，这是一条发现，而不是矛盾。它通常意味着流量进入了某一层，却从未从另一层出去。

把计数器与应用的结果对照

接收总量可能因协议寒暄而上升，而你想要的业务仍然失败。发送量的增加说明的更少：它只能证明内核接受了数据包，不能证明有什么回应了。

把确切的结果记在计数器旁边：域名解析失败、连接超时、TLS 被拒绝，或者收到了 HTTP 响应。这是四种不同的故障，其中只有一种与隧道有关。如果证据还要往前推，下一个观测点就是网关或服务边界，在那里可以看清请求是否到达。重置 Mac 的网络偏好设置会毁掉你正在测量的状态，什么也告诉不了你。

写下下一个人需要的记录

接口名称、计数器标签、时间间隔、前后数值，以及应用的结果。这些足够让同事复现这次观测，而不必重走你的那个下午。再加上客户端版本和 macOS 版本，因为计数器的语义可能随版本变化。

跳过完整抓包和系统转储。要解释一次请求期间哪个本地计数器动了，它们很少必要，而且会拖慢每一个读报告的人。如果客户端显示了它自己的统计，就照抄它的标签，而不是翻译成你的说法。这条记录的意义在于记下测了什么，而不在于争论它意味着什么。