ADB and the Android Emulator Fail Behind a VPN: Three Paths

You connect the office VPN and Android Studio loses the running emulator, adb start-server hangs, and a physical phone on Wi-Fi drops off the device list. It looks like one product being blocked by one tunnel. In practice three separate paths fail in three separate ways: adb device discovery, the emulator virtual network and the host resolver. The tunnel usually owns only the last one, and often only part of it.

Three sockets, three owners

The adb server listens on port 5037 on the host and talks to devices over USB or over TCP, with mDNS for network discovery. The emulator runs behind its own virtual router: the guest is 10.0.2.15, its gateway is 10.0.2.2 and its DNS server is 10.0.2.3, all translated by the emulator process into host sockets. The host resolver is where a VPN client installs DNS and search domains.

That separation explains why a fix appears to work for one tool and not another. A client that changes the host resolver leaves a running emulator process with the resolver state it read at startup. A client that filters multicast breaks discovery without touching DNS. A client that filters virtual adapters denies the emulator while the host browser keeps working. Each symptom has a different cause, so identify the failing path before changing any setting.

Start with what adb can see

Run adb devices before touching the VPN. An empty list is a transport problem, not a routing problem, and no tunnel setting will fix a device the server never enumerated. Restart the server cleanly with adb kill-server followed by adb start-server, then read the output for the port it bound. If startup itself hangs, mDNS discovery is the usual suspect on a network that filters multicast; the documented workaround is to start the server with discovery disabled:

ADB_MDNS_OPENSCREEN=0 adb start-server
adb devices

For a physical device, USB is the shortest path. If you need TCP, put the device into listening mode with adb tcpip 5555 and connect to the device address and device port, adb connect 192.0.2.10:5555. Port 5037 is the host server port and is not the port a device listens on.

Test the emulator from inside

The emulator answers DNS from 10.0.2.3, and that resolver is fed by the host process. When the VPN client changes the host resolver, the emulator can inherit it; when the client filters the emulator process or the host adapter list changes after the emulator started, it cannot. Separate the two with a numeric target and a name from the same shell. adb shell ping -c 2 10.0.2.2 proves the virtual network can reach the host side. A name lookup after that tells you whether resolution crossed the boundary.

Then run the same name lookup on the host. Host resolves and emulator does not means the break is between the host resolver and the emulator virtual network, not in the tunnel itself. Both fail means the host resolver is the place to look. Restarting the emulator after the VPN connects is worth one attempt, because some clients install resolver state that a running emulator process never picks up.

Check the host resolver and client filters

A full-tunnel client replaces the host resolver with its own, and a split-DNS client adds search domains and conditional forwarders. Internal names often depend on that split-DNS configuration, so check what the host uses while connected: the resolver address, the search domain and whether the internal zone is routed to the corporate DNS. A resolver that answers public names but not internal ones is a policy question, not a broken tunnel.

Some corporate clients also block traffic from virtual adapters. An emulator looks like a virtual adapter to a filter driver, so the host can work perfectly while the emulator is denied by policy. That policy is not visible from the workstation, and guessing at proxy settings will not reveal it. If the host resolves and the emulator is blocked regardless of resolver settings, the correct escalation is to the team that owns the client policy.

Order of checks and what each result means

Work top to bottom and stop at the first failing row. Each result points at a different owner, and none of them is fixed by reinstalling Android Studio.

Only the last two rows are VPN questions in the usual sense, and only the last one is about DNS content. The adb documentation covers the server port and the environment variables named here, which is enough to keep the transport side honest while you test the rest.