Why Wireless Debugging Traffic Isn't Proof of a VPN Leak
A paired ADB session over Wi-Fi proves a debugging relationship, not an internet egress path. Here is what that observation actually covers.
You enabled wireless debugging, connected a laptop, and the session kept working while the VPN was up. That looks like something slipped past the tunnel. It almost certainly did not. A debugging session and an app's request to a website are different network relationships, and only one of them is supposed to cross the tunnel.
I have hit this misreading twice: once with the phone and laptop on the same Wi-Fi, and once after a reboot when the pairing survived. In both cases the VPN was doing exactly what it was configured to do.
Name the observation before you name the bug
Three events can come before a leak claim, and they are not interchangeable. A tool can discover a service, the device can approve a workstation, or an authorized session can actually carry commands and bytes. Write down which one you saw, because each proves less than people assume.
Discovery is usually mDNS or a port scan. Pairing is an enrollment decision made on the phone, confirmed with a code the user types. A live session means traffic moved between two paired endpoints. None of that describes where an app's HTTPS request goes.
Keep the destination, interface, address family, timestamp and user profile attached to the event. Without those details the observation cannot be compared with the intended local-network policy, or with the VPN build that was running at the time.
Why the two paths never meet
Wireless debugging is an inbound connection to the device. adbd listens on a port bound to the Wi-Fi interface, and the workstation connects to it after pairing. The direction matters: your laptop reaches into the phone, not the other way around. That is the opposite of an egress leak.
An app's internet traffic leaves through the tunnel interface that VpnService installs, matched by UID and routing rules. adbd is a system daemon running as the shell user, not an app inside that routing set. It stays on the underlying Wi-Fi link even when every app is pinned to the tunnel.
Lockdown mode enforces the tunnel for covered apps. It does not turn a listening socket into an egress path.
That is why a working ADB session and a working kill switch coexist without contradiction. To prove a leak, you have to observe the direction that is supposed to be blocked.
What an egress test actually looks like
Test the covered app, not the debugging channel. Set up the failure condition deliberately, then make one fresh request and record what happened.
- Confirm the VPN is the only path: turn on always-on VPN with block connections without VPN.
- Stop the VPN in the supported way and confirm the app reports no connectivity.
- Issue one harmless request from that app and note whether it fails or succeeds.
- Repeat with wireless debugging on, then off, so the variable is isolated.
A blocked request under those conditions is evidence. A successful ADB session is not, and neither is a single ping from a terminal app.
If the request does succeed while lockdown is on, capture the app's UID and its VPN allowance, the active network, and the client version. That combination is a real finding.
Pairing outlives the session
Pairing is persistent state, not a handshake you can forget about after the cable test. Android's debugging documentation describes the wireless workflow and notes that the relationship lasts until it is explicitly forgotten or the authorizations are revoked.
Check what is still authorized before you blame the tunnel. Open Wireless debugging, look at Paired devices, and forget anything you no longer recognize. Run adb devices from the workstation to see which entries still answer, and adb disconnect to drop a stale one. Turning wireless debugging off closes the listening port entirely.
On a shared or untrusted network, leave it off. A persistent authorization on a network you do not control is a larger problem than a hypothetical TUN bypass.
Before you file that bug
A useful report names the exact boundary that failed. Include the device model and Android release, the VPN client and version, whether lockdown was enabled, the app package and UID, and the network the phone was on. Add the command or request that produced the observation, plus the time it happened. Without that, nobody can reproduce the boundary you claim is broken.
Do not disable enforcement or expose debugging on an untrusted network to make the test look more dramatic. That changes the system you are measuring and leaves evidence nobody can repeat.
If your only proof is that ADB connected while the VPN was on, you measured the wrong path. Re-run the app-level test first; the answer usually arrives there.