Why a Blocked Site Still Loads After the VPN Disconnects

A site was blocked, worked while the VPN was connected, and still works after the VPN is disconnected. That is a small piece of evidence about where the block lived, not proof that the tunnel stayed in force. If the block had been on the destination address, a cached name would not have helped and the connection would still fail. The page loading points at name resolution instead. Reading that clue correctly saves you a long detour through firewall rules.

There are two places a block can sit, and from a browser they look identical.

Two blocks that look the same in a browser

A naming block happens in resolution. The resolver returns a wrong address, an empty answer or a captive-portal page, and the browser reports that the site cannot be reached.

An address block happens later. The name resolves correctly and packets to the real address are dropped, redirected or reset. Changing the resolver does nothing here, because the failure starts after the name has already been answered.

Only the first kind can be carried by a cache, which is what makes your observation useful.

Why the answer outlives the tunnel

Resolver caches are keyed by name and held for the record's time to live. The operating system keeps one, and the browser usually keeps another, so a single name can be stored twice with two different lifetimes. Connecting or disconnecting a VPN flushes neither of them; it only changes which resolver future queries are sent to.

While the tunnel was up, the lookup went to the provider's resolver, which returned the correct address, and that answer was stored locally. After the disconnect the browser asked again, the local cache answered without consulting anyone, and the page loaded.

It will keep loading until the entry expires or someone clears the cache, and then the old behaviour returns.

A three-step test that separates them

Do these in order, because the first one is the only step that proves the cache was carrying the page.

Flush the resolver cache and the browser cache, then reload. If the site fails again, the cache was the reason it worked. Then query the same name through the resolver you had before the VPN and through a different one, and compare the two answers: a disagreement locates the block in naming. If you know the address, try reaching it without the name, because success there confirms the address itself is not filtered.

What each result means for your next move

For a naming block, the direct change is a different resolver, and encrypted DNS changes who can see and alter those queries. The VPN was doing that job as a side effect.

For an address-level block, a resolver change is irrelevant and the cache theory is simply wrong.

Two boundaries are worth stating before you act. Whether you may switch resolvers on a given network is a policy question rather than a technical one. And not every network blocks through DNS, so a result describes the network you tested and not blocking in general. Write down which resolver you used, because that detail is what makes the test repeatable by the next person.