VPN Connected But Sites Are Still Blocked
Short answer
Load an IP-checking site first. If it shows your real location, traffic is bypassing the tunnel and the VPN connection status is lying to you. If it shows the VPN's location and the site still blocks you, the site has identified that server's address range — switch to a different server and clear that site's cookies, in that order.
On this page
“Connected” in a VPN client means one thing: a tunnel was negotiated with a server. It does not mean your browser is using that tunnel, that DNS is going through it, or that the site you want has any intention of serving you.
Three completely different failures produce the identical symptom, and the fix for one does nothing for the other two. Two minutes of checking tells you which you have.
The four-check triage
Check 1 — what is your apparent IP? Load any IP-checking site, or search for “what is my IP”. Compare the location it reports against the server you selected.
Check 2 — run a DNS leak test. A DNS leak test site lists which resolvers answered your queries. They should belong to the VPN provider, not your internet provider.
Check 3 — try a different site. If only one site is blocked and everything else works, the problem is that site, not the VPN.
Check 4 — try a different server. Preferably in a different city.
| Check 1 result | Check 2 result | Diagnosis | Section |
|---|---|---|---|
| Your real location | Either | Traffic is bypassing the tunnel | Traffic is leaking |
| VPN location | Your provider’s DNS | DNS leak | DNS outside the tunnel |
| VPN location | VPN’s DNS | The site is blocking the server | The site blocked it |
When traffic is bypassing the tunnel
Your IP check shows home. The client says connected. Both are true, and the routing table is the reason.
Work through these:
Split tunnelling is on. Check the client’s settings for a split tunnel, per-app or bypass list. Your browser may be on the excluded list, possibly from a configuration you set up months ago and forgot. How split tunnelling works covers the settings.
IPv6 is escaping. Many VPN clients tunnel IPv4 and leave IPv6 on your normal connection. If the site supports IPv6, your browser prefers it and goes straight out. Look for an IPv6 leak protection or Block IPv6 option in the client and enable it. Where the client has no such option, disabling IPv6 on the network adapter works, at the cost of breaking IPv6 everywhere.
A stale route from a crashed session. Fully quit the client, confirm the virtual adapter is gone from your network settings, then reopen and reconnect.
The browser has its own proxy. Browser VPN extensions and proxy settings operate independently of the system VPN and can route around it. Check the browser’s own network settings and disable extensions one at a time.
The app uses its own networking. Some applications, particularly ones with embedded browsers, ignore system routing in ways that are difficult to diagnose. Test in a plain browser before concluding anything about the VPN.
When DNS escapes the tunnel
IP check correct, DNS leak test showing your internet provider’s resolvers.
This matters for two reasons. Your provider still sees every domain you look up, which defeats the main privacy purpose. And a provider’s DNS may return a regionally filtered answer, so a site “blocks” you while your IP address says otherwise.
Fixes, in order:
- Enable the client’s DNS leak protection. Most have it; it is sometimes off by default.
- Set DNS manually on the adapter to the VPN provider’s resolvers, listed in their documentation.
- Check for encrypted DNS in the browser. Chrome and Firefox can use their own DNS-over-HTTPS resolver, which bypasses whatever the VPN configured. Chrome: Settings → Privacy and security → Security → Use secure DNS. Firefox: Settings → Privacy & Security → DNS over HTTPS.
- Check Android’s Private DNS. Settings → Network & internet → Private DNS. If this is set to a hostname, it overrides the VPN’s DNS. Set it to Automatic while using a VPN.
Point 3 catches a surprising number of cases, because the browser setting looks like a privacy feature and is quietly undermining the one you paid for.
When the site has blocked the server
IP check correct, DNS correct, site still refuses. The VPN is working. The site has decided not to serve that address.
How they know: VPN providers rent servers in datacentres, and datacentre address ranges are published and catalogued. A site does not need to identify your provider; it just needs to see that the connection came from hosting infrastructure rather than a residential connection.
In rough order of what works:
- Change server. Different city first, then different country if the content allows. Some of a provider’s ranges are flagged and others are not.
- Clear that site’s cookies, then reload. A site that previously decided your region may have stored it. Do this after changing server, not before.
- Try a private window. Faster than clearing cookies and tells you whether cookies were the issue.
- Check whether the provider offers a dedicated IP. A paid option on some services, giving you an address not shared with thousands of others. It is still a datacentre address, so sites that block ranges wholesale will still block it.
Streaming platforms are the most aggressive about this and have a dedicated guide: why streaming services block VPNs.
The case where one app fails and the browser is fine
Worth separating, because it points somewhere different from everything above.
If a website loads in your browser but the same service fails in its own application, the application is likely doing something the browser is not. Certificate pinning is the usual mechanism: banking and some messaging apps embed the expected certificate and refuse connections that do not match, which can trip on networks that inspect traffic.
Some applications also use the device’s location services rather than the IP address, so a tunnel to another country makes no difference to them and may produce a mismatch warning instead.
The quick test is to exclude that single application from the tunnel using split tunnelling and see whether it recovers. If it does, you have your answer and a permanent fix in the same step. How split tunnelling works covers setting the exclusion up without disturbing anything else.
When the block is on your own network
A separate case worth naming: you are on a work, school or hotel network, and the VPN connects but nothing passes.
These networks filter. The usual approach is blocking the UDP ports VPN protocols use, which leaves you with a client that connects briefly and then stalls, or never completes the handshake.
Switching the client to OpenVPN over TCP port 443 makes the traffic structurally resemble ordinary HTTPS, which filters generally permit. It is slower than everything else, and it is often the difference between a working connection and none.
On a company-managed device, be aware that circumventing the organisation’s network policy may breach their acceptable use terms. That is a question for your IT department rather than a technical one.
Realistic expectations
Most cases in this guide resolve at check 1. Either the traffic was leaking, usually through IPv6 or a forgotten split tunnel rule, or the site had simply blocked that server and a different city fixed it in thirty seconds.
The honest limit is the third case. If a site is determined to block datacentre addresses, you are in a contest between its blocklist and your provider’s address rotation, and the result changes week to week. No setting on your side wins that permanently, and any service claiming it has is describing the current state of a moving target.