If your VPN works on mobile data and fails on Wi-Fi, the problem is almost never the app. It is the Wi-Fi network: a captive portal you have not cleared, a firewall that blocks the protocol, a router that mangles large packets, or a DNS setup that hijacks queries. The fixes below are ordered from most to least likely, and each takes a minute or two to try.
First, confirm the pattern
Turn Wi-Fi off, connect on mobile data, open What Is My IP: the VPN shows the server's address. Turn Wi-Fi back on: the VPN fails to connect, connects but nothing loads, or drops after a while. If the VPN fails on mobile data too, the cause is different; check subscription, device clock and app permissions first.
Note which of the three symptoms you have: cannot connect, connected but no internet, or keeps dropping. Each points to different causes below.
1. Captive portal not cleared (cannot connect)
Hotel, airport and café networks require you to accept terms or log in on a web page before they let any traffic through. The VPN app cannot see that page and simply fails. Fix: open the browser, load any plain site, complete the portal, then connect the VPN. If the portal never appears, forget the network and rejoin it.
2. The network blocks UDP (cannot connect)
WireGuard runs only over UDP, and IKEv2 mostly does. Corporate, campus and some hotel networks block UDP entirely or allow only a few ports. Fix: in the app, switch to a protocol that runs over TCP on port 443, which is what web browsing uses and what no network blocks. VLESS does this and looks like ordinary HTTPS. OpenVPN in TCP mode is the older alternative. If the app has an "automatic" protocol setting, turn it on.
3. The network filters known VPN protocols (cannot connect or drops)
Some networks go further and recognize VPN handshakes by their shape, then drop or throttle them. Symptoms: connects for a few seconds and dies, or connects with almost no throughput. Fix: same as above, a protocol designed to be indistinguishable from HTTPS. VLESS with Reality was built for this case; the reasoning is in WireGuard vs OpenVPN.
4. MTU too large for the network (connected but pages hang)
Every tunnel adds overhead to each packet. On some Wi-Fi networks, especially behind older routers or on satellite and mobile hotspots, packets that were fine on mobile data become too large, get fragmented or dropped, and pages start loading and then stall. Fix: in the VPN app or the WireGuard configuration, lower the MTU to 1280 and test; raise it in steps if you want to tune. This one is easy to overlook and fixes a lot of "connected but broken" cases.
5. DNS hijacked by the router (connected but nothing resolves)
Some routers intercept every DNS query and answer it themselves, which breaks the VPN's DNS or leaks it. Symptom: the tunnel is up, What Is My IP shows the server, but sites fail to load or resolve slowly. Fix: turn on the app's DNS leak protection or set the app to use the VPN's own DNS; on Android, set Private DNS to Off or to the VPN's hostname while connected. Verify with the steps in is my DNS leaking.
6. IPv6 on the Wi-Fi, IPv4-only tunnel (connected, some sites fail)
Your mobile carrier may be IPv4-only while the Wi-Fi provides IPv6. If the tunnel carries only IPv4, the system tries IPv6 first for many sites, times out, then falls back, so pages open slowly or not at all, and traffic leaks outside the tunnel. Fix: enable IPv6 inside the tunnel if the app supports it, or disable IPv6 on the Wi-Fi connection. The IPv6 leak test shows whether IPv6 is escaping.
7. Wi-Fi power saving on the phone (keeps dropping)
Android and some laptops throttle the Wi-Fi radio when the screen is off, and long-lived tunnels drop. Symptom: fine while you are using the phone, disconnected when you pick it up again. Fix: on Android, set the VPN app's battery setting to Unrestricted and enable Always-on VPN with Block connections without VPN; on Windows laptops, disable the "allow the computer to turn off this device" option on the Wi-Fi adapter.
8. A second VPN, firewall or antivirus on the device (cannot connect)
Only one VPN configuration can be active at a time on iOS and Android, and desktop security suites sometimes block the tunnel's port on Wi-Fi networks they classify as public. Fix: disable other VPN or filtering apps, and on Windows or macOS temporarily disable the third-party firewall to confirm; if that fixes it, add the VPN app to its exceptions.
9. The router itself (everything else failed)
Older routers with SIP ALG or aggressive NAT settings break tunnels. If it is your own router: reboot it, update firmware, disable SIP ALG, and enable UPnP or leave NAT defaults. If it is someone else's network, use a TCP-based protocol and accept the network's limits.
Order of operations, in one list
- Clear the captive portal.
- Switch protocol to VLESS or OpenVPN TCP 443.
- Lower MTU to 1280.
- Turn on DNS leak protection; check Private DNS on Android.
- Fix IPv6: inside the tunnel or off.
- Battery and power settings for the app and the Wi-Fi adapter.
- Disable other VPNs, filters, firewalls.
- Router: reboot, firmware, SIP ALG.
- Try another server; if all fail on this Wi-Fi and all work on mobile data, the network is the limit and a TCP protocol is the workaround.
404 VPN's apps switch between VLESS and WireGuard automatically, so a network that blocks UDP or filters VPN traffic usually connects on the first try, with DNS inside the tunnel and a kill switch during reconnects. Details on the how it works page; get started here.