The VPN client shows connected, but one website simply won't load. A connected indicator is a starting observation, not an explanation of the failed request. Work through a calm, non-destructive set of checks, changing one thing at a time without assuming which part is responsible.

Record the exact error text, the time, and whether the page fails to open or stops at sign-in or verification. For example, ERR_CONNECTION_RESET can involve a VPN, browser, connectivity, or security-software issue; the message alone does not identify the cause. Keep security protections enabled and do not bypass certificate warnings.

Start by confirming it's really connected

Before diagnosing a load failure, check the client's current connection state and whether it is reconnecting after a network change. Let it settle if needed. Even an established connection does not confirm that every destination is reachable or that every request follows the same traffic path.

If the connection itself is unstable, start with the reconnection guide or troubleshooting checklist. If it is up and steady, continue gathering evidence about this request; that state alone neither clears nor blames the VPN.

Is the site itself up?

Websites can have outages or maintenance windows. Check any official status information the site provides, while keeping other possible causes open.

Try another familiar site and record the result. If it loads, you have evidence that some requests work, not proof that the failing site's server is down. A destination-specific DNS, routing, filtering, or website-policy issue can still be involved. If an outage is confirmed, waiting and trying again later is reasonable.

Try a different browser or a private window

If it is appropriate for your work, try the site in a different browser or a private/incognito window. If the result changes, browser state or settings may matter, including cookies, extensions, or different proxy or DNS handling. This is a clue, not proof that the VPN, network, or site is uninvolved.

Keep the comparison narrow and record which browser or window worked. Use the browser's own guidance for the next check instead of changing several settings at once.

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

Workplace networks, guest networks, and public Wi-Fi can restrict or handle traffic in their own ways. Captive-portal networks, such as those in hotels and airports, may require their normal sign-in step before internet access is available.

If the result changes between networks, record that difference without treating it as proof of one cause. Complete any required captive portal through its normal process and follow employer, network, and device policies. On a managed device, ask the policy owner before changing connection settings.

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 or a page asking for verification — note that separately from a page that never opens. Sites can apply account, security, and network/IP rules. A challenge alone does not reveal which rule applied or exclude a connection-related factor. Use the site's normal verification and support process.

Record the page or error where progress stops and avoid inferring a site's policy from a single result. A loading failure and a verification prompt call for different next questions, even when some contributing factors overlap.

Test from a normal network context

Only when allowed by your device and network policies, and safe for your work, compare the same site on another trusted network or briefly with the VPN disconnected. Pause sensitive activity before any optional disconnection. Skip the comparison if the connection is required. Record what changed and restore the required connection before resuming sensitive work; a changed result narrows the investigation without proving the cause.

Do not replace a profile merely because one site fails. Refresh it only if it is confirmed outdated or official support identifies a profile-specific reason. For the documented OpenVPN Connect path, use a fresh download from your own Lisar Panel and follow the supported import steps for your device.

The calm order, together

These observations can narrow possible causes without guaranteeing a diagnosis. If you need help, share the error text and the safe comparisons you made with the site's support or official Lisar support as appropriate, without sending profile files, passwords, or other sensitive material.

Frequently asked questions

My VPN says connected but one website won't load — is the VPN broken? Not necessarily. Connected state and a single-site failure do not identify the cause. Record the exact error, compare another site or browser when appropriate, and use any safe, permitted network comparison as a clue rather than proof.

How do I tell if it's the site or my setup? Compare the exact error and result on another familiar site, browser, or permitted network. Each difference can narrow the next check, but no single comparison proves that the site, browser, VPN, or network is responsible.

The page loads but won't let me sign in. Is that the same problem? It is a different observation from a page that never opens. A site can apply account, security, or network/IP checks, and a verification prompt alone does not identify the cause. Use the site's normal 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? First check that the device has joined the hotel's Wi-Fi, then complete its normal captive-portal sign-in if required and confirm ordinary browsing works. Pause sensitive activity before any optional VPN disconnection, follow device and network policies, and skip that test if the VPN is required. If access still fails, ask the network operator or use another permitted connection.

Sources: Chrome error messages; Firefox connection troubleshooting; Website IP access rules; Windows VPN routing.

Related guidance: VPN After Sleep, Roaming, and Network Switches: What Reconnection Looks Like and What "Connected" Actually Means in a VPN Client.