A VPN changes your apparent location, your exit address, your route, and usually your DNS resolver, all at once. That makes it an excellent diagnostic and a frequent cause of the very problem it is being used to investigate.
Using a VPN as a test ¶
Toggling a VPN is the closest thing an individual has to a second vantage point. The result tells you a lot, provided you change one thing at a time:
- Fails without, works with: something on your normal path is the problem. Your ISP, your region, or your local network.
- Works without, fails with: the VPN is the problem. Read on.
- Fails both ways: the site. Confirm with a multi-method check.
- Works both ways: intermittent, or already resolved.
Try at least two exit locations before concluding anything. A single exit proves one path, and VPN exits break as often as anything else does.
Five ways a VPN causes the outage ¶
1. The exit address is blocked
VPN exits are datacenter addresses shared by thousands of users. Sites block them to fight abuse, and CDN reputation systems score them harshly. A 403, a permanent captcha, or a challenge page that never passes is the signature. Nothing is broken; you have been categorised.
2. Geographic restriction, in the other direction
Streaming, banking and government services restrict by country. Connecting through another country can turn a working service into a blocked one, sometimes with a plausible-looking generic error rather than an honest explanation.
3. DNS leaking or being overridden
Some VPNs route traffic but not DNS, or set a resolver that answers differently from your normal one. You can end up resolving a name through one country and connecting from another, which some services treat as suspicious and some CDNs answer badly. If a site loads but is slow or serves the wrong regional content, suspect this first.
4. MTU and fragmentation
Tunnelling adds header overhead, so the usable packet size shrinks. If the path drops oversized packets without saying so, small requests succeed and large ones hang. The signature is distinctive: the page starts loading and stalls partway, consistently. Lowering the VPN client MTU to around 1400 is the standard test.
5. Split tunnelling sending half the traffic the wrong way
Split tunnel configurations route some destinations through the VPN and some directly. When the rules are wrong, a site's main hostname goes one way and its API or asset host goes the other, producing a half-loaded page that looks like a partial outage. See partial outages for what that looks like from the browser.
Testing cleanly ¶
- Disconnect fully. Confirm the failure still happens. If it does not, you have your answer already.
- Reconnect to a nearby exit, then a distant one. Two data points beat one.
- Check what address you are resolving with the VPN up:
dig example.com +short, and compare against our DNS lookup. - Note whether failures are instant or slow. Instant means something decided; slow means nobody answered.
- Run a multi-method check from outside your path entirely, as a control.
Reporting it ¶
If you contact support, say whether a VPN was involved. It is one of the first things they will ask, and an unmentioned VPN is why a lot of tickets end in a diagnosis that does not fit the symptoms. If the service works without the VPN and fails with it from several exits, that is not an outage, and reporting it as one costs you the response you wanted.
Corporate VPNs behave differently ¶
A work VPN is not a consumer privacy product and fails in its own ways. It usually forces DNS through internal resolvers, applies the company's filtering policy to everything you do, and routes traffic through a single corporate egress that the whole company shares.
Three consequences follow. Internal-only hostnames resolve on the VPN and nowhere else, which is expected. Public sites can be blocked by company policy while appearing simply broken, which is covered in the blocked-network guide. And the shared egress means one colleague's automated script can get the entire company rate-limited by a service, producing a 429 that has nothing to do with you.
Phones are not laptops ¶
Mobile VPN behaviour differs in ways that produce confusing results:
- Both platforms suspend background VPN connections aggressively, so the tunnel may be reconnecting rather than connected when the request fails.
- Always-on or lockdown mode blocks all traffic when the tunnel drops. That looks exactly like a total outage and is the correct behaviour.
- Some apps use their own networking stack and ignore the system proxy, so a browser and an app can take different paths on one device at the same moment.
If a phone works and a laptop does not while both use the same VPN, that difference is the finding, not a distraction.
The control test ¶
Every VPN conclusion needs a control, because a VPN changes several variables at once and it is easy to attribute the result to the wrong one. The cheapest control is a check from somewhere that is neither your network nor your VPN: run a multi-method check on the hostname. If four independent probes reach it while both your paths fail, the site is up and the fault is yours to find. If they fail too, stop testing VPN exits, because you are debugging someone else's outage.