VPN Works on Wi-Fi but Not on Mobile Data: Why

Start with a comparison, not a conclusion: same phone, same profile, two networks. If the tunnel fails on one and works on the other, the difference is somewhere in the path rather than in the credentials. Note which failure you get, because a refusal before login and a connection that carries nothing are different problems. Everything below assumes that test, done with only the network changed.

A VPN needs the underlying connection; it does not replace it, and it cannot make an operator carry what the operator declines to carry.

Keep the Phone Fixed, Change Only the Network

Changing the network and the server at the same time leaves two candidate causes and no way to separate them. Compare the same endpoint first on Wi-Fi, then on cellular, and record the exact symptom each time. A failure before authentication points at reachability, a credential rejection points at the account, and a connected tunnel that carries nothing points at routing or DNS. Only the first is really about the network.

An explicit rejection at login belongs in the authentication checks too, even if it only appears on one network. Some operators and guest networks intercept traffic in ways that produce misleading errors.

What the Access Network Can See and Charge

The operator carrying the tunnel observes the connection itself: timing, volume and the address of the VPN endpoint. Encrypting the payload does not hide those properties, and that holds on a home Wi-Fi link as much as on cellular. What a VPN changes is who can see what, and the answer differs at each hop. Write it down per hop rather than describing the connection as private in general.

Charges are the other practical difference. Encapsulation, keepalives and retries all consume bytes, and applications may resume a transfer after a handover. Metered home Wi-Fi exists too, so check the device counters and the plan rather than assuming either network is unlimited.

Portal Logins and Operator Restrictions

A captive portal has to be satisfied before the tunnel can reach anything. Reconnecting the VPN will not admit a device the network has not authorised, and an always-on policy can make the portal unreachable. Complete the sign-in through the normal browser flow first, then bring the tunnel up. If a managed policy prevents that order, follow the operator's or administrator's documented process.

Operator restrictions are the other variable: some paths carry only certain protocols, some translate addresses aggressively, and some handle one address family differently from another. A comparison narrows the failure to the path without identifying which mechanism is responsible.

Handover Is Not the Same as Reconnect

Once each network works on its own, observe a real handover. The client may detect the change and reconnect, or it may keep a session that is now dead. Applications already in use recover differently from ones opened after the switch, so a persistent tunnel icon proves little. Test the application you actually care about across the transition, and note whether it recovers without manual intervention.

If the tunnel fails only after sitting idle, a keepalive can address one NAT-state case. It does not repair a weak signal, and it does not fix every handover. Distinguish idleness from movement before changing settings.

Record the network, the failure stage and the behaviour across a handover. Those three separate a path problem from a client problem.