VPN Stuck on Connecting in Airplane Mode: Find the Uplink
A client that sits on Connecting in airplane mode may simply have no uplink. Separate radio state, association, portal sign-in and the blocking policy.
The phone shows the airplane icon, the VPN client has been on Connecting for two minutes, and the profile is correct. It worked an hour ago in the same building. Nothing is broken: a VPN is a connection carried by another network, and airplane mode just removed the network it was being carried by. The client keeps retrying because that is what it does without an uplink.
What makes this confusing is that the airplane symbol does not tell you whether Wi-Fi is available, and Connecting does not tell you whether the client is authenticating or merely waiting. Separate those two readings and the diagnosis takes a minute.
The airplane symbol is not a radio report
On supported Android devices, Wi-Fi and Bluetooth can stay enabled in airplane mode, and the device remembers the choice you made last time. Google's Pixel airplane-mode guidance describes exactly that behaviour. So the icon can mean cellular is off and nothing else.
Check the actual state rather than the glyph. adb shell settings get global airplane_mode_on returns 0 or 1 for the mode itself, and adb shell dumpsys connectivity lists the networks the device currently has, with their validation status. Those two outputs together answer the question the icon cannot.
If Wi-Fi is off, or on but not associated with anything, there is no path to the VPN endpoint and no amount of reconnecting will create one. That is the case worth ruling out first, because it is the only one where the correct fix is outside the VPN app.
What connecting actually means
A client can hold a saved profile, render its name, and display a spinner without having contacted anything. Configuration is local. Establishing a tunnel requires a reachable server, a completed handshake, and an interface to route through. Only that last part needs a working network, which is why the first two can look successful with the radio off.
So the spinner is consistent with at least three different situations: no uplink at all, an uplink that cannot reach the endpoint, and an uplink that reaches it but fails authentication. They look identical on screen and completely different in a log. That is why the first useful artifact in any of these cases is the log, not another retry.
Android's own VPN documentation draws the same line between connection establishment and the separate always-on and blocking policies. That separation is the reason a phone can look protected while offline and still have no tunnel.
Four states worth telling apart
The four states below are the ones worth naming, because the screen renders them identically.
| State | What you will see | What to do |
|---|---|---|
| Airplane mode, Wi-Fi off | No networks in dumpsys, VPN retries forever | Turn Wi-Fi on, or accept that the tunnel cannot exist |
| Wi-Fi on, not associated | Interface exists, no default network | Join the access point |
| Associated, not validated | Network listed, captive-portal flag set | Complete the portal sign-in, then reconnect |
| Validated, tunnel down | Internet works, VPN fails or blocks | Debug the tunnel, not the radio |
The third row catches most people in hotels and airports. Association is not admission: a portal that has not let the phone through will happily accept the Wi-Fi password and then refuse to pass traffic to the VPN endpoint. Signing in through the browser first, while the tunnel is off, is usually the only way through.
Why blocking makes it look worse
If always-on VPN and block connections without VPN are both enabled, every covered app is blocked whenever the tunnel is not up. That is the feature working, not a second fault. The symptom changes from one app failing to everything failing, which reads like a much bigger problem.
It also explains the sequence people misread: airplane mode on, no uplink, apps blocked, VPN says connecting. The blockage was the policy doing its job. Turning the policy off to test the uplink removes the protection you presumably wanted and teaches you nothing.
Check the scope instead. Which apps are covered, which are excluded, and whether the profile is per-user or device-wide. A task that starts the VPN app once Wi-Fi appears is a trigger, not a guarantee that no packet left before it ran.
A diagnostic order that ends the guessing
Work from the bottom up. Confirm the mode, confirm a network exists, confirm it is validated, confirm it can reach something outside the local subnet, and only then look at the client. adb shell ping -c 3 1.1.1.1 is a blunt test but it separates a missing path from a path that exists while the tunnel is unhappy.
If the ping fails while a network is listed, the problem is upstream of the VPN and no client setting will fix it. If the ping succeeds and the tunnel still will not establish, capture the client's log at that moment: the error will distinguish a timeout from an authentication rejection, and those two have nothing in common.
Finish by restoring the intended state: Wi-Fi allowed in airplane mode if that is your normal setup, the portal completed, and the blocking policy back on. Then reconnect once and confirm the tunnel comes up on its own, because a configuration that only works after manual retries will fail again on the next boot.