VPN Connected but No Internet: Fix It in Order

The words "connected" only tell you one thing: a tunnel exists between the app and the server. They do not promise that your browser put its request into that tunnel, nor that the far end could bring an answer back.

So this failure almost always sits in one of the layers in between rather than in the connection itself. The good news is that there are only a few layers, and working through them in order usually pins the problem down inside five minutes.

One rule governs the whole process: change one variable at a time. Switch the node, switch the protocol and reinstall the app together, and even when the problem disappears you have learned nothing, so it will happen again.

Start with a thirty-second triage

Open two things: a domestic site and an overseas one. There are only four outcomes, and they point in four completely different directions.

• Neither opens: your local network is down and the app is irrelevant. Check Wi-Fi or mobile data.
• Domestic opens, overseas does not: the classic case. Keep reading.
• Overseas opens, domestic does not: routing rules are wrong and domestic traffic is being pushed through the tunnel.
• Everything opens except one site: that site is the problem, or a rule singles it out.

Do not skip this step. Without it, everything that follows is guesswork.

Layer one: DNS is not following the tunnel

The most common cause by a wide margin. Name resolution is still using the local resolver, the address that comes back is wrong, and the browser cheerfully connects to somewhere unreachable.

It is easy to recognise: the page spins until it times out instead of failing immediately. Reaching the same service by IP works.

Disconnect and reconnect once. Most clients take over DNS as they connect, so a reconnect effectively sets it up again.

After reconnecting, clear the browser cache before retrying. Browsers cache resolutions themselves, so a stale wrong address keeps getting used for several more minutes.

If you want the underlying mechanism rather than the fix, what DNS is covers this layer properly.

Layer two: rules sent the traffic back to a direct connection

Every modern client splits traffic: domestic sites go direct, overseas sites go through the tunnel. When the rule list is out of date, or you once added something to a bypass list, you get sites that never open no matter what.

Check whether a whole class of sites fails together. An entire family failing at once — every Google hostname, say — points at rules. A single site failing points at the site.

Switch to global mode and open the same page. If it works, the rules were the problem. If it still does not, the fault is a layer further down.

Layer three: an old proxy setting is still in the system

This one is a computer-only trap. You used another tool once, or installed a browser extension, and a dead entry stayed behind in the system proxy settings. The new app connects fine while traffic keeps being posted down that dead end.

Try a different browser. If the other browser works, the problem is an extension. If neither works, it is the system settings.

Turn off every proxy-type extension in every browser and leave only the app you actually use. These conflicts rarely raise an error; they just fail quietly, which is exactly why they deserve a deliberate look.

Layer four: the node itself

With the first three layers ruled out, suspect the node. It may be overloaded, it may be blocked by the destination specifically, or that stretch of route may simply be down at the moment.

Pick a node in a different region rather than another one nearby. Exits in the same region often share upstream capacity, so they tend to fail together.

If a different region works immediately, the node was the whole story and nothing else needs changing. For which region to sit on day to day, choosing a server location has recommendations by use case.

Layer five: the system clock

Almost nobody thinks of this one, and when it bites, the symptoms are nearly identical to every layer above: no HTTPS site opens, and the message explains nothing.

Encrypted connections check a certificate's validity dates. If the device's clock is off by hours or days, the certificate reads as "not valid yet" or "expired", the connection is refused during the handshake, and the whole thing looks like a dead network.

The usual triggers: a machine switched on after a long time off, a time-zone change, a dead motherboard battery, or automatic time sync turned off by hand.

Compare the system clock against the real time. A few minutes off is worth suspecting; hours off settles it.

Turn automatic time sync on, or set the correct time and zone by hand, then reconnect. Fix this layer and every symptom above disappears at once.

Beyond the five layers, one more subtle case

Work through all five layers and the symptom can turn into something oddly specific: the page loads fine, icons and text render normally, but one particular large image, a video, or a big file download stalls partway through and goes nowhere. The likely cause is packet size, usually called MTU.

Here is the mechanism. Network data travels in fixed-size chunks, and a tunnel wraps each chunk in an extra layer, making the whole thing slightly bigger than it would be without the tunnel. Most equipment along the way handles that fine, but if even one hop only accepts smaller chunks, anything over its limit gets silently dropped, with nothing telling you the packet was too big.

That is exactly why the symptom looks so strange. A small chunk, like the request for a web page, gets through fine and the page renders. Anything that needs a steady stream of large chunks — a big file, a full-resolution image, a video — stalls far more often. It is not a lack of speed; the packet died somewhere along the route, and the device is still waiting for a reply that was never going to arrive complete.

Test with something obviously smaller, like a small image instead of a video. If the small file is fine and the large one reliably stalls, that points squarely at this layer, with no need to keep suspecting the five above.

Most clients handle this layer automatically, with no manual setting involved. If a client exposes a manual packet-size option, try a smaller value. If it doesn't, switching nodes usually routes around whatever is enforcing the limit on the current path.

Write down what worked

Do not close the laptop the moment it works. Spend thirty seconds on one line: when, which network, which layer, what fixed it.

The value shows up next time. Faults repeat per person: the office network always stalls on ports, home is always DNS, hotels are always the portal. Three or four entries in and you stop diagnosing from scratch — you jump straight to the layer that is usually yours.

There is a second use. If you do end up contacting support, arriving with four facts — the time, which region's node, which hostnames failed, and whether another node helped — saves several rounds over "I can't open websites". Those are the four things support asks for anyway.

When to suspect the network itself

A few environments produce this failure on their own:

• Office or campus networks that permit only a short list of ports
• Hotel Wi-Fi that wants a portal login you have not completed
• Weak mobile signal, where the tunnel builds but throughput is near zero
• A router running its own proxy layer, with the two stacked and fighting

The test: tether your computer to your phone's hotspot and retry. Swapping to a completely different physical link separates an environment problem from a device problem in one move.

In summary

Connected but nothing loads is worked in five layers — DNS, routing rules, system proxy, node, clock — after the thirty-second triage at the top. That combination locates the overwhelming majority of cases inside five minutes. Change one variable at a time.

To meet this less often, there is really only one direction: let the client handle DNS, routing and reconnection itself instead of asking you to configure them. FastOrange is built that way — one tap to connect, automatic reconnection when a link drops, one tap to change node. Every registered account gets free trial time daily, so run that thirty-second triage with it first.