A VPN can show “Connected” while a website remains unavailable because the status usually confirms that a tunnel or proxy session was established—not that every app is sending traffic through it, that DNS is resolving correctly, or that the destination is reachable. The quickest way to avoid random setting changes is to identify the scope of the failure first: does it affect one website, several sites, or all browsing? Then test the browser, route, DNS, and traffic rules in a consistent order.
Before troubleshooting, note what still works. Check whether other websites load, whether the same page opens on another device using the same network, and whether it opens when the VPN is disconnected. Do not enter passwords into a page reached through an unexpected warning or certificate error. These comparisons help distinguish a site-side outage from a device, network, or VPN configuration issue.
Fix 1: Check whether one site or all browsing is affected
Start by opening a few unrelated websites in the same browser. If most sites work and only one fails, the VPN tunnel may be functioning normally. The affected site could be temporarily unavailable, rejecting a particular exit IP, redirecting incorrectly, or relying on a browser session that has gone stale. If no websites load, the likely causes are broader: a browser proxy setting, DNS failure, an incomplete system-wide route, or a local network restriction.
Try the affected page in a private window, then in a different browser. A private window can help reveal problems caused by cached redirects, cookies, extensions, or an account session. It does not bypass every browser setting: extensions and managed policies may still apply, and a system proxy or VPN route remains active. If the page works in another browser, avoid changing VPN protocol or server settings until you have checked the original browser.
Also compare the same website with the VPN temporarily disconnected, if doing so is appropriate for your network and privacy needs. If it loads only without the VPN, that points toward a route, DNS, exit-IP, or filtering interaction rather than a general browser failure. If it fails both ways, test another network, such as switching between Wi-Fi and mobile data, when available. A page failing on one connection does not by itself prove that the VPN is the cause.
- ✅ If only one site fails, test its address in a private window and another browser.
- ✅ If every site fails, check system proxy, DNS, and whether the VPN is routing device traffic.
- ❌ Do not change several network settings at once; that makes the cause harder to identify.
Fix 2: Refresh the browser and check local proxy settings
A browser may retain a failed connection even after the VPN reconnects. Close the affected tab, reopen the browser, and try the full address again. If the problem appears limited to one browser, temporarily disable extensions that filter traffic, modify requests, block scripts, or manage proxy connections. Ad blockers and privacy extensions can sometimes interfere with a particular site, but do not disable security tools permanently; restore them after the test.
Next, check whether a proxy was configured separately from the VPN. A browser extension, manual system proxy, or another networking app can point traffic to an unavailable local address. This is especially relevant when a VPN client uses a system proxy mode rather than a virtual network interface. An active VPN indicator does not guarantee that the browser is using the same route as the client.
On Windows, open Settings and review the network proxy options. Turn off a manual proxy only if you did not intentionally configure it, and check that the VPN client’s own proxy mode is enabled as intended. On macOS, inspect the active network service’s proxy settings in System Settings. If a third-party client is in use, consult its own connection mode: system proxy and TUN mode handle traffic differently, and not every app follows a browser-only proxy. Avoid running two proxy clients simultaneously while diagnosing, because they can compete for system routes or local proxy ports.
If you are comparing a provider’s supported platforms and connection options, its Free VPN for China page can help establish which official clients and compatible setups are available. That context is useful, but it does not replace checking the settings on the device where the page is failing.
Fix 3: Reconnect and test a different server
A successful connection can still use a route that cannot reach a particular destination reliably. Disconnect from the VPN in its client, wait for the connection status to clear, and connect again. Then load the site in a fresh tab. If the same site still fails but other websites work, select a different server or location that is appropriate for the service you are trying to reach. A different exit address may behave differently, but no server can guarantee that every website will accept its traffic.
Change one variable per test. Keep the device, browser, and network the same while switching the server; otherwise, it becomes difficult to tell what affected the result. If the client offers several connection modes or protocols, first test another server using the existing mode. Only then consider changing protocol, because a protocol change can alter transport behavior and may be restricted by the current Wi-Fi, mobile carrier, firewall, or router.
Check whether the problem happens only on a public network, workplace connection, or school network. Captive portals often require a sign-in or terms page before normal internet access is available. Disconnect the VPN briefly, open the network’s sign-in page, complete the required access step, and then reconnect. Follow the network owner’s rules; do not attempt to bypass access controls. On managed work or school devices, administrator policies may also block VPNs, proxies, or particular destinations.
Fix 4: Refresh DNS and check address resolution
DNS translates a domain name into an address a device can contact. A VPN may connect successfully while a stale, unreachable, or conflicting DNS resolver prevents a browser from finding the website. This can cause an error such as “server IP address could not be found,” although wording varies by browser. A site that opens by an existing tab but not after a fresh visit may also be using cached information.
First, fully close and reopen the browser. If only one device is affected, restart that device after saving your work. Reconnecting the VPN can also prompt the client to apply its DNS settings again. Check whether the VPN client has an option to use its supplied DNS or to restore default DNS behavior. Do not enter an unfamiliar DNS address just because a troubleshooting post recommends it; DNS choices affect where domain lookups are sent and may interact with the provider’s routing and filtering features.
Windows users can open Command Prompt and run ipconfig /flushdns, then retry the site. This clears the local DNS cache; it does not repair a broken VPN route or an incorrect proxy. On macOS, restart the browser and reconnect the VPN first; if the issue persists, restart the Mac before using terminal commands copied from elsewhere. DNS cache commands can differ between macOS releases, so use current platform documentation if a manual flush is necessary.
On Android and iPhone, toggling Airplane Mode briefly and restoring the network connection can refresh network state, but it may not clear every app’s cache or resolve an incorrectly configured Private DNS setting. Check Android’s Private DNS setting if it was changed manually, and review any DNS or content-filtering profile installed on an iPhone. Change one setting at a time and restore the original value if the test does not help.
Fix 5: Review split tunneling and device-specific settings
Split tunneling tells the VPN which apps or destinations should use the tunnel and which should connect directly. If the browser is excluded, it may bypass the VPN even while the client displays “Connected.” Conversely, a rule that sends only selected apps through the tunnel can leave a browser outside the intended route. Open the VPN client’s routing or split-tunneling page and confirm that the affected browser is included in the route you want.
On Windows, check both the client’s app-routing rules and the Windows proxy options. If the VPN uses a TUN adapter, confirm that the client has permission to create or manage it and that the adapter is not disabled. On macOS, review the VPN app’s per-app rules and any system network extension permission requested during setup. If macOS recently displayed a permissions prompt, check the relevant Privacy & Security settings rather than repeatedly reconnecting without granting the required permission.
On Android, verify that the VPN is not limited to selected apps unless that is intentional. Android’s “always-on VPN” and “block connections without VPN” options can affect behavior when a tunnel drops or reconnects; check them if browsing stops immediately after a network change. On iPhone, review the VPN app’s connection status and any installed VPN or DNS profiles. iOS may reconnect when switching between Wi-Fi and cellular, so allow the app to finish reconnecting before judging the page result.
Battery-saving features, background restrictions, or a device changing networks can interrupt a client that needs to maintain a persistent connection. If failures happen mainly after the screen locks or after switching from Wi-Fi to mobile data, check the client’s background permissions and reconnect behavior. These settings vary by device manufacturer and operating-system version. Avoid installing multiple VPN profiles or clients as a workaround; competing routes can make traffic behavior less predictable.
Fix 6: Test IPv6, MTU, and the local network
Some connection failures occur only on particular network paths. A device may prefer IPv6 for a destination even though the VPN or local network handles that path differently from IPv4. If the client has a clearly documented IPv6 option, compare its current setting with the provider’s guidance. Do not disable IPv6 across the whole device as a first step: operating systems and applications may depend on it, and a broad change can create new problems.
MTU is the maximum packet size a network path can carry without fragmentation. A mismatch can make some sites load partially, stall during secure connections, or fail on a particular network while other traffic appears normal. If the VPN client provides a documented MTU adjustment, try the supported setting and test the same page again. Avoid guessing values from unrelated devices or networks. If the client does not expose this setting, do not edit low-level adapter configuration unless you understand how to restore it.
Compare Wi-Fi with mobile data, or compare two Wi-Fi networks if available. If the page works on one connection but not another, investigate the router, captive portal, DNS configuration, or network policy on the failing connection. Restarting the router may help when its connection has become stuck, but first make sure other users are not relying on it. If several devices on the same network fail in the same way, the issue is more likely to involve that network or the destination than one browser installation.
| What you observe | Likely area to inspect | Next controlled test |
|---|---|---|
| One site fails in one browser | Browser cache, extension, session, or site behavior | Try a private window and another browser |
| All sites fail on one device | Proxy, DNS, route, or client permissions | Reconnect, inspect routing rules, and test another server |
| Several devices fail on one network | Router, captive portal, DNS, or network policy | Compare with a different network |
| Only one VPN location fails | Route or destination-specific exit behavior | Test another suitable server with other settings unchanged |
What to do if the page still won’t open
At this point, return the device to a simple configuration: use one VPN client, remove accidental browser proxy overrides, keep the intended routing mode, and test with a single browser. Note the operating system, browser, network type, VPN server or location, connection mode, exact error message, and whether the failure affects one site or all sites. This information makes support requests more useful than a screenshot of a “Connected” badge alone. Do not send a password, authentication token, or private subscription link in a public post.
If the page shows a certificate warning, do not bypass the warning to force access. Check that the device date and time are correct, retry after reconnecting, and verify whether the warning occurs on other secure websites. A warning limited to one page may be a site configuration problem; a warning across many sites can indicate device time, local interception, or a network security product. If the page returns an access-denied message rather than a connection error, the website may be rejecting the request or exit address, which is different from a DNS failure.