What a Mac VPN byte counter does and does not prove

Open the client's status window and the numbers look reassuring: bytes going up, tunnel connected. Close the window and the office application still fails, which means the counters answered a question nobody asked. Counting bytes at an interface measures traffic at that observation point and nothing more. Walk from the number you are looking at to the layer it reports, then to the result the application actually gave you.

Pick the interface before you pick the number

Start where the number is displayed and read the label beside it. A client window may show session totals, a tunnel interface may show inner IP bytes, and a physical adapter may show encrypted outer bytes; three different counters that happen to be denominated in bytes. On the command line, netstat -ibn prints one row per address on each interface, so a tunnel can appear several times. Match the row to the interface the client actually owns, and confirm it against the route the destination selects. A device named utun might belong to the VPN, to another tunnel, or to nothing you care about.

Do not swap in a Wi-Fi counter because it is easier to read. A different observation point answers a different question.

Take a delta, not a lifetime total

Read the row, make one small authorised request, then read the same row again. The difference is the evidence, because a lifetime total includes everything the machine has done since boot. Keep the interval short so background traffic has less opportunity to contaminate it. On a busy machine, nettop can attribute throughput to a process, which narrows the field before you return to interface counters.

Accept that the delta is not clean. Mail, updates and the client's own keepalives all contribute, so treat the number as a bound rather than a measurement. If the application was the only thing you did during the interval, the bound is usually tight enough to be useful.

Inner and outer counters measure different things

The physical adapter counts encrypted packets including their outer headers, while the tunnel interface accounts for the payload it receives or hands over. Adding the two together double-counts one transfer. Overhead, retransmissions and encapsulation also make a simple equality impossible.

Two counters moving in opposite directions is a finding rather than a contradiction. It usually means traffic entered one layer and never left the other.

Pair the counter with the application result

A received total can rise from protocol chatter while the service you wanted still fails. A transmit increase says even less: it proves the kernel accepted a packet, not that anything answered.

Record the exact outcome beside the counters: name resolution failed, the connection timed out, TLS was rejected, or an HTTP response arrived. Those are four different faults, and only one of them is about the tunnel. If the evidence needs to go further, the next observation point is the gateway or the service boundary, where someone can see whether the request arrived. Resetting the Mac's network preferences destroys the state you were measuring and tells you nothing.

Write the note the next person needs

Interface name, counter label, interval, before and after values, and the application result. That is enough for a colleague to reproduce the observation without repeating your afternoon. Add the client version and the macOS version, since counter semantics can change between releases.

Skip the full packet capture and the system dump. They are rarely needed to explain which local counter moved during one request, and they slow down whoever reads the report. If the client exposes its own statistics, quote its label verbatim instead of translating it into yours. The point of the note is to record what was measured, not to argue about what it means.