One site failing while everything else loads proves the tunnel carries traffic, which narrows the problem more than most people expect. Three observations sort the rest: whether you received an HTTP response at all, whether the hostname resolved to an address, and whether small requests pass while large ones stall. Guessing at the VPN before you have those answers usually moves the fault instead of clearing it.

Work the observations in order, because a site that answered cannot also have failed to resolve. If nothing loads at all, you are in the wrong branch and the connected-but-no-internet checks apply instead.

Let the Error Message Choose the Branch

A refusal, a bot challenge, or an error page means the service replied, so packets reached an application and came back. That moves the question to the site's access policy, which may weigh the exit address, the account, or request patterns it does not publish. A name-resolution failure never reached the site at all, and the address is the first thing to inspect. A timeout sits between the two: something was sent, and nothing acknowledged it.

Certificate warnings belong to a fourth branch. They mean the connection was answered by something whose identity the browser could not verify, which is either a proxy on your side or a genuine mismatch you should not click through. Treat that as a trust question rather than a routing one.

A Site That Answers Has Not Proved a Broken Tunnel

When the reply is a block page, compare the same page through a second exit while keeping the browser and the machine unchanged. If the result follows the exit address, the site is treating that address differently, and no client configuration will change its mind. If the block follows your browser instead, the cause sits in an extension, a saved proxy, or a resolver setting. Two runs separate those explanations cheaply.

Browser-only failures are common enough to test early. A page that loads in one supported browser and fails in another points at profile state, a content blocker, or encrypted DNS configured inside the browser itself. Chrome's secure DNS guidance covers where that setting lives, and changing it through the supported control beats resetting the device.

When Only Large Transfers Stall, Look at Packet Size

A page that renders its header and then hangs has a different signature from a page that never starts. Small responses can pass while a full-size payload is dropped somewhere that cannot signal the sender, which is what a path MTU failure looks like from a browser. Compare a tiny request and a large one to the same host before theorizing about filtering. Path MTU discovery is supposed to learn the smallest link size along the path, and it depends on ICMP feedback that filtered networks routinely discard.

Test that hypothesis with a size sweep rather than a single ping. A failure that begins at a consistent payload size is strong evidence, while a failure that moves around is not.

Confirm the Fix on the Request That Failed

Retest the original operation, not the homepage, because a cached shell can render while the API call behind a sign-in still fails. The commands below separate name resolution, a small request, and a large one against the same host. Substitute the hostname and path from the request that actually broke.

dig +short www.example.com
curl -sS -o /dev/null -w '%{http_code} %{time_total}\n' https://www.example.com/
curl -sS -o /dev/null -w '%{http_code} %{size_download}\n' https://www.example.com/assets/app.js
ping -M do -s 1400 -c 3 203.0.113.20

If the dig answer differs from what the browser used, the resolver is the variable and the browser's own DNS setting is the place to look. If the small request returns a status while the large one stalls, work the packet-size branch. If both time out, the exit path and the site's handling of that address are back on the table.

Keep the change that made the original request succeed and undo the rest. A pile of simultaneous browser, resolver and client edits leaves you unable to say which one mattered.

Inyandiko zihuye