Why does my VPN connect but nothing loads?

Your VPN client says connected. The timer is counting up. And every page hangs until it times out.

Almost always this means the tunnel came up but packets are not completing the round trip. Four causes account for nearly all of it: DNS is resolving to nowhere, packets are too big to get through, a captive portal is holding the network hostage, or the network let your handshake through and is dropping the tunnel afterwards. They look identical from the outside and they have completely different fixes, so it is worth ten seconds of diagnosis before you start reinstalling things.

Step one: is it DNS, or is it everything?

Try to reach something by IP address rather than by name. On any desktop, open a terminal and run ping 1.1.1.1. Then try opening a website normally.

If the ping replies but names do not resolve, your problem is DNS. The tunnel is carrying packets fine, but your device is still asking a DNS server it can no longer reach — often the router's own resolver on the local network, which is now unreachable because your traffic exits somewhere else. Setting the client to use the VPN's resolver, or a public one, fixes it.

If the ping does not reply either, nothing is getting through and DNS is a red herring. Keep reading.

Step two: MTU, the failure that looks like a slow network

This one is the most misdiagnosed problem in VPNs, because it does not fail cleanly. Small requests work. Large responses hang. A page loads its HTML and then sits there forever waiting for an image.

Every network link has a maximum packet size, the MTU. Wrapping your traffic in an encrypted tunnel adds header overhead, so a packet that fit perfectly on the way in no longer fits on the way out. Normally the network tells the sender to send something smaller, but the message that does the telling is an ICMP packet, and an enormous number of networks and firewalls drop ICMP by default. The sender never hears about it, keeps sending packets that are silently discarded, and the connection stalls instead of failing. This is called an MTU black hole, and Cloudflare's explainer on MTU is a good short read on the mechanics.

WireGuard defaults to an MTU of 1420 for exactly this reason, as the WireGuard documentation notes. On networks with extra layers underneath, such as PPPoE broadband or mobile tethering, even that is too big. Dropping the tunnel MTU to 1380, or 1280 if you want to be certain, usually turns a dead connection into a working one instantly. If lowering MTU fixes it, you have your answer, and you can raise it back gradually.

Step three: the captive portal you never saw

Hotel, airport, campus and conference wifi almost always sits behind a sign-in page. Until you accept the terms, the network answers every DNS query with its own address and refuses to route anything else.

If your VPN connects automatically at boot, you may never see that page. The client comes up first, encrypts everything, and the portal has no way to intercept your traffic to show you the page. From your side it looks like the VPN connected and then the internet died. RFC 8910 exists to make portals announce themselves to devices, but plenty of hardware ignores it.

The fix is unglamorous: disconnect the VPN, load any plain http page, complete the sign-in, then reconnect. No VPN can get you past a portal that has not let you onto the network yet, and any provider claiming otherwise is selling you something.

Step four: the network let you connect, then killed the tunnel

If DNS is fine, MTU changes nothing, and there is no portal, the remaining explanation is the network itself. This is the pattern to look for: the connection establishes normally, works for a few seconds or a few minutes, then everything stops. Reconnecting works briefly, then stops again.

That is a filter doing traffic inspection rather than address blocking. It is not looking at where you are connecting to, it is looking at what the connection looks like. Standard WireGuard and OpenVPN have recognisable handshakes — distinctive packet sizes and byte patterns in the first few exchanges — so a system doing deep packet inspection can identify the protocol without decrypting anything, and then throttle or drop it. Some filters go further and actively probe the server you connected to, to see whether it responds like a real web server or like a proxy.

This is why switching to a different server almost never helps here, and why people conclude their VPN is broken when it is working exactly as designed. The address was never the thing being blocked. The protocol was.

What changes the outcome is a different transport: traffic that does not carry the fingerprint the filter is looking for. Pangea is built around that, with five stealth transports tried in order — VLESS with Reality, Cloak, Shadowsocks, Hysteria2 and NaiveProxy. Reality borrows a genuine site's TLS handshake, so probing sees a real site. Hysteria2 runs over UDP and QUIC instead of TCP, which is worth trying when a filter is killing every TCP connection. The client cycles through them rather than betting everything on one protocol, and the whole desktop client is GPLv3 on GitHub, so you can read what it actually does rather than take a marketing page's word for it.

What none of this fixes

Being honest about the edges matters more than the pitch. A captive portal you have not signed into cannot be tunnelled around. A network that has been shut down entirely has nothing to connect through. If a network operator blocks the specific address your VPN connects to, that route is gone until the provider changes it. And new filtering techniques appear constantly, so anyone promising you a connection that can never be blocked is guessing.

The realistic claim is narrower and more useful: most of the time a VPN that connects and then does nothing has a fixable cause, and it is usually one of these four. Work through them in order before you start blaming the app.

If your problem turns out to be step four, that is the one Pangea was designed for. There is a five day free trial with no card needed, so you can find out on the network that is actually giving you trouble — try it on the network that's blocking you.