The VPN client shows connected, but one website simply won't load. It's a naturally frustrating moment, and the instinct is to blame the VPN first — yet a connection being up and a single site not loading are often unrelated, and the surest way through is a calm order of checks rather than a panicked change. This is that order: non-destructive, one step at a time, working from the most common causes outward.

Nothing here involves tearing anything down. The goal is to find where the problem actually lives, and almost every step ends up pointing somewhere other than the VPN.

Start by confirming it's really connected

Before diagnosing a load failure, confirm the premise: is the VPN actually connected right now, or just showing a stale indicator? A quick glance at the client's current state — and, if in doubt, letting it settle for a moment — rules out the simplest explanation. A connection that's mid-reconnect after a network change can look connected while it's still settling.

If the connection itself is unstable, that's a different article's territory (reconnection behavior and the troubleshooting checklist). If it's genuinely up and steady, move on — the problem is likely not the connection at all.

Is the site itself up?

The check people skip first is the one that most often explains it: the site may simply be down, for everyone, right now. Websites have outages, maintenance windows, and hiccups that have nothing to do with you or your VPN.

The quick test is whether other sites load normally while this one doesn't. If everything else is fine and only this one site fails, an outage on the site's end is a leading suspect — and no amount of local troubleshooting fixes someone else's server. Waiting and trying again later is a legitimate step, not a cop-out.

Try a different browser or a private window

If other sites work and you suspect this one is up, narrow it to your browser next. Open the site in a different browser, or in a private/incognito window of the same one. If it loads there but not in your usual browser, the issue is browser-side — a cached version of the page, a stored setting, or a browser add-on interfering — not the VPN or the site.

This is a pure narrowing step: it tells you which side of the fence the problem is on. Browser-side problems have browser-side answers, and they're common enough to always be worth this ten-second test.

Consider DNS behavior

Name lookups sit between "connected" and "page loads," so DNS is a fair thing to consider when one site misbehaves. A site that won't resolve is different from a site that resolves but won't respond, and DNS behavior on a device has several owners — the device, the browser, the network, and, while connected, the profile's DNS handling.

Keep this a considering step, not a reconfiguring one. If DNS seems involved, the DNS settings checklist covers how to read which layer is answering without changing anything destructive — and where a plan includes DNS AdBlock, some domain-level lookups may be filtered by design, which is expected rather than a fault. GeoDNS, DNS AdBlock and Custom Exit are available according to plan.

Check the local network's own rules

Some "won't load" situations are the network you're on, not your device. Workplace networks, guest networks, and public Wi-Fi can restrict or handle certain traffic in their own ways, and captive-portal networks (hotels, airports) often need their sign-in step completed before anything loads properly.

Reading it: if the problem appears on one network but not others, the network is a strong suspect. Complete any captive portal, and recognize that a network you don't control has its own rules — this article doesn't suggest working around employer, network, or device policies, which are the network owner's to set. On a managed device, its policy is the policy owner's call.

Remember the site's own account and security checks

If a site loads but won't let you in — a sign-in that won't complete, a page that keeps asking to verify — that's the site's own account and security layer, not a loading problem and not the VPN. Services run their own checks regardless of how you connect, exactly as covered elsewhere in this series, and the path through them is the service's own verification and support process.

Distinguishing "the page won't load at all" from "the page loads but won't let me proceed" is worth a beat, because they point at completely different places: the former is connectivity, the latter is the service's account layer.

Test from a normal network context

The single most clarifying move, when it's available: try the same site from a different, ordinary network — with and without the VPN, briefly, on a network you trust. If it works fine elsewhere, the problem was specific to the first network or moment, not your setup. If it fails everywhere the same way, that's more useful information to bring to support than any single observation.

This is also where a fresh profile from your own Lisar Panel, set up the supported way (download the .ovpn file, open OpenVPN Connect, choose Upload File, import and save the profile, and connect), rules out a stale local profile as a variable — one clean check, not a fix-everything ritual.

The calm order, together

Worked in that order, "the VPN broke this site" almost always resolves into something more specific and more fixable — and when it doesn't, the specific observations the order produces are exactly what official Lisar support can act on.

Frequently asked questions

My VPN says connected but one website won't load — is the VPN broken? Usually not. A steady connection and a single site failing are often unrelated. Check whether the site is simply down (do other sites load?), try a different browser, and test from another network — most of the time the cause is the site, the browser, or the local network, not the VPN.

How do I tell if it's the site or my setup? Narrow it: if only one site fails while others load, suspect that site or your browser; if every site fails on one network but works on another, suspect the first network. Testing the same site from a normal network context localizes it quickly.

The page loads but won't let me sign in. Is that the same problem? No — that's the site's own account and security layer, not a loading issue and not the VPN. Services run their own checks regardless of how you connect; the way through is the service's own verification and support process.

Could DNS be why a site won't load? It can be a factor, since name lookups sit between connecting and loading. Consider it as a layer rather than reconfiguring anything — the DNS settings checklist covers reading which layer is answering. Where a plan includes DNS AdBlock, some domain-level filtering is expected by design.

Nothing loads on this hotel network — what now? Complete the network's captive-portal sign-in first, since many networks pass no traffic until that's done. Networks you don't control have their own rules; if one won't cooperate, testing from another network or using a fallback is more productive than changing a working setup.