Narrowing Down Why Your VPN Is Not Working
“My VPN is not working” describes at least five different faults, and they all look much the same in the app’s status display. The tunnel may never have been established; it may exist but not be carrying your traffic; names may be failing while addresses still work; the network you are attached to may be interfering with the handshake; or the tunnel may be fine and one particular destination is refusing the address you now arrive from.
Each of those has a cheap question that rules it in or out. Asking them in order costs a few minutes and replaces guesswork with a shrinking list.
Say what the symptom actually is
The symptom already excludes most of the list, so pin it down before changing any settings.
- The client never reaches a connected state. Only the first candidate is in play.
- It connects, then drops, repeatedly. The handshake succeeded once, so credentials are fine — look at the network path.
- It says connected and nothing loads at all. Routing or name resolution.
- It says connected, pages load, but sites act as though you never connected. Nothing is broken; something is being cached or bypassed.
- Everything works except one app or one site. The tunnel is healthy. The problem is at the far end, or in that application’s own settings.
Write the symptom down in that form. A good share of the time, doing so is the diagnosis.
Candidate one: the tunnel never came up
The client is the only party that can tell you this, so read its actual error text rather than its icon.
An authentication failure, a lapsed subscription, or a device limit reached all present as “cannot connect” and are trivially fixable once named. So is a client that lacks the privileges it needs to create a network interface, which on desktop platforms usually surfaces as a permission prompt someone dismissed weeks ago.
If the error is a timeout instead, the handshake is leaving your device and not being answered. Try a second server in a different location — if that connects, the first server is the problem and you are not. Then try a different protocol if the client offers one, since the common choices behave differently on restrictive networks.
Candidate two: the tunnel is up and unused
A connected VPN that carries no traffic is the most misleading failure of the five, because every indicator reports success.
Connecting creates a second network interface, and something has to decide that your traffic should prefer it. That decision lives in the routing table. If the entry sending default traffic through the virtual interface is missing — because another VPN client claimed it, because the interface came up without an address, or because a crash left stale entries behind — the tunnel exists and your traffic goes around it.
This is where you stop reading and go look at the device. Enumerating your interfaces, their addresses, and your routes takes one command and answers the question outright; the fields and what they mean are covered in how to read your own network settings. The positive version of the same exercise — what a healthy connection should look like, and in what order to establish it — is in confirming your VPN is working.
Reconnecting is a legitimate fix here rather than superstition: it tears the interface down and reinstalls the routes.
Candidate three: names are failing, addresses are not
One test separates a resolution problem from everything else — reach something by numeric address instead of by name.
If a numeric address responds while hostnames time out, the tunnel is carrying traffic and name lookups are the broken part. That happens when the client points your device at a resolver it cannot reach through the tunnel, when a resolver on your own network becomes unreachable the moment default traffic is redirected, or when leak-protection rules block every resolver except one that is not answering.
The opposite pattern — lookups succeed but resolve somewhere unexpected — is not a fault at all. It is usually an answer cached from before you connected, which is why clearing the cache belongs early and why a site can show a stale region while the tunnel is entirely healthy.
Candidate four: the network you are attached to
Some networks permit ordinary web traffic and very little else, and a VPN handshake is not ordinary web traffic.
Signs that point here: the same client and server work elsewhere; nothing connects on this network regardless of server choice; or the connection establishes and then stalls on large transfers while small requests succeed. The last one is a packet-size problem rather than a blocking problem, and clients usually expose a setting for it.
The distinguishing move is to change networks — a phone’s hotspot is enough. If the tunnel comes up immediately there, you have learned that your client and account are sound and the constraint was where you were attached.
Candidate five: the far end does not want your exit address
When one service fails and everything else works, the tunnel is not the fault.
Services can and do refuse traffic from address ranges they associate with VPN providers, and because those exit addresses are shared, the behaviour depends partly on who else has been using yours — the tradeoff described in shared versus dedicated VPN addresses. Switching servers often clears it, which is itself the confirmation that the destination was making the decision.
Two other single-site failures belong here too: a service that needs to see your real local network to function, and an application carrying its own proxy configuration that ignores the tunnel.
Why this order
Each step is cheaper than the one after it and eliminates more.
Reading the client’s error text costs seconds; reading your interfaces and routes costs a minute and settles the two most common failures outright; testing by numeric address costs one command; changing networks separates your device from its surroundings. A specific destination is worth suspecting last, because it is the candidate you can do least about. Going the other way — reconfiguring on a hunch — changes several variables at once and tends to produce a working connection nobody can explain.
What makes the next time faster
Record what normal looks like while everything is working: your interfaces, your routes, and which resolver is in use with the tunnel up. Comparison is much easier than interpretation.
And change one thing at a time. If you switch server, protocol, and DNS setting together and the problem clears, you have fixed nothing you can rely on. If the symptom survives all five candidates, the remaining possibility is that traffic is escaping the tunnel rather than failing in it — a different investigation, and the categories are laid out in how to check for a VPN leak.