A VPN client can show “Connected” while a website still fails to open. The status usually confirms that a tunnel or proxy connection was established; it does not prove that your browser resolved the site’s domain, that the destination accepts the selected exit location, or that every app is using the intended route. The quickest way to troubleshoot is to narrow down where the failure occurs before changing several settings at once.
Use the checks below in order: compare the affected site with other sites, test another browser or app, inspect the selected route and DNS behavior, and then review operating-system settings such as split tunneling. Keep a note of each change and its result. That makes it easier to undo a setting and helps you give support a useful description if the problem continues.
Identify Where the Failure Occurs
First, determine whether the problem is limited to one website, one browser, one device, or the entire VPN connection. A blank page and a timeout can have different causes, so note the exact browser message and whether the site starts loading before it fails. Do not assume that a successful connection indicator means the destination website is reachable through that route.
| What you observe | Likely area to check | Useful comparison |
|---|---|---|
| Only one website fails | Site availability, domain resolution, browser data, or the site’s access policy | Try another site and check the affected site in a private window |
| Several sites fail in one browser | Browser proxy settings, extensions, cached data, or secure DNS configuration | Open the same sites in a different browser on the same device |
| All browsers fail on one device | VPN routing, DNS, firewall rules, or operating-system network settings | Test another device on the same network, if available |
| The same sites fail on multiple devices | Router, local network, selected route, or a wider service-side issue | Compare the VPN connection with the VPN disconnected, where appropriate |
| Pages open, but sign-in or media does not | Cookies, account checks, blocked third-party requests, or app-specific routing | Test the login page and the affected feature separately |
When comparing with the VPN disconnected, use a site you trust and follow the rules that apply to your network and location. The comparison is only diagnostic: it helps distinguish a local connection problem from one associated with the selected route. A website may also be temporarily unavailable or restrict access from some network addresses, so a failure on one route does not by itself prove that the VPN client is misconfigured.
5
Checks in the diagnostic sequence
3
Useful comparison scopes: site, browser, device
Check the Site, Browser, and Cache
Before editing network settings, rule out issues that can look like a VPN failure. Confirm that the web address is correct, including the spelling of the domain and any subdomain. If the site has a status page or a separate official app, check whether the service itself reports an outage. A site can also reject a login attempt because of its own security checks, even when its public pages load normally.
Try the address in a private or incognito window. This usually gives you a quick comparison without deleting saved data. If the page works there but not in the regular window, a stale cookie, cached redirect, or browser extension may be interfering. Disable extensions temporarily, especially extensions that filter traffic, change DNS behavior, block scripts, or manage proxies. Re-enable them one at a time after testing so you can identify the cause rather than leaving useful protections disabled.
If a private window works, clear data for the affected site rather than wiping every saved password and browsing record. Browser menus differ, but look for site-specific cookies and cached files under privacy or site settings. Then close the affected tabs, reopen the browser, and sign in again if needed. Clearing cookies can sign you out and remove site preferences, so avoid doing it as a first step when a private-window test is enough.
Check the browser’s own network settings as well. Some browsers can use a configured proxy or secure DNS provider independently of the system setting. A browser proxy pointing to an unavailable address can prevent pages from loading even though the VPN client remains connected. If you use a custom proxy intentionally, record its current setting before changing it and restore it if the test makes no difference.
- ✅ Confirm the full web address and test more than one unrelated site.
- ✅ Compare a regular browser window with a private window.
- ✅ Temporarily test without traffic-changing extensions, then restore them one by one.
- ❌ Do not delete all browser data or disable security tools before narrowing down the cause.
Run a Controlled Route and DNS Test
Now make one change at a time. Disconnect the VPN through its client, wait for the system network to settle, and test whether the affected site loads on the ordinary connection. Reconnect, select a different available route, and test the same address again. Keep the browser, device, and network unchanged during this comparison. If you switch the browser or clear its data at the same time, it becomes harder to tell which change mattered.
- Refresh the client configuration if needed. If the client uses a subscription, check that it has updated successfully and that the selected entry is still present. Do not copy configuration URLs into a public forum or share them in screenshots; they may contain account-specific access information.
- Reconnect cleanly. Disconnect from the current route using the client, wait briefly, then connect again. If the client offers more than one compatible route, try another one rather than repeatedly tapping connect on the same entry.
- Compare a different exit location. A website may apply access or fraud checks based on the apparent location or network address. Choosing a nearby alternative can help establish whether the failure is specific to one route. It is a diagnostic comparison, not a guarantee that a particular region will work with every site.
- Check DNS behavior. DNS translates a domain name into an address. A browser message such as “server IP address could not be found” points toward name resolution, though it does not identify the exact cause. Review whether the client, browser, or operating system has a custom DNS setting that conflicts with the route.
- Test the same domain again. Use the same browser and address after each change, and record whether the message changes from a name-resolution error to a timeout or a site-specific access message.
DNS settings can exist in more than one place: the VPN client may provide DNS handling, the operating system may have a configured resolver, and the browser may use secure DNS. Avoid changing all three together. If you use a custom secure DNS provider in the browser, temporarily return to the normal browser setting for a controlled test, then restore the original choice if it was not responsible. Some managed, school, or workplace devices enforce DNS settings; do not bypass those policies.
For a basic Windows cache refresh, open Command Prompt and run ipconfig /flushdns, then retry the site. This clears the local DNS resolver cache; it does not change the VPN route or repair a remote DNS service. On macOS, Android, iOS, and Linux, the available controls vary by operating-system version, network configuration, and device management. Prefer the system’s documented network controls or the client’s own instructions over copying a command intended for a different setup.
For readers comparing general network-access options and setup guidance, VPNGF Best VPN for China is the site’s homepage. When troubleshooting, however, use the checks on the device and route that are actually failing; a general service overview cannot identify a local browser or DNS conflict.
Check Platform-Specific Network Settings
When the problem affects multiple browsers on one device, look for platform settings that can alter traffic after the VPN connects. The goal is to verify how the device routes requests, not to turn off every security feature. A system VPN, a browser proxy, and per-app routing are separate controls, and overlapping tools can compete for the same traffic.
| Platform | Check | Safe test |
|---|---|---|
| Windows | System proxy, firewall permissions, DNS cache, and other VPN or proxy clients | Verify the intended client is the only active traffic-routing tool; refresh DNS and reconnect |
| macOS | Network proxy settings, content filters, DNS profiles, and other network extensions | Review the active network service and test with only the intended VPN client connected |
| Android | Per-app routing, battery restrictions, always-on VPN, and Private DNS | Confirm the browser is included in the intended routing rules and review Private DNS settings |
| iOS | VPN profiles, content filters, on-demand connection rules, and app-specific behavior | Reconnect from the VPN client and test the same page in another browser before resetting network settings |
| Linux | Proxy environment variables, firewall rules, DNS resolver, and competing tunnel interfaces | Check the active network and resolver configuration; use distribution-specific guidance for changes |
Windows: Open the system proxy settings and check whether an unexpected manual proxy is enabled. Also review firewall prompts for the VPN application; a firewall rule may allow the client to connect while blocking browser traffic or a related network component. If more than one proxy client is running, exit the one you are not testing. Do not remove firewall protection entirely; adjust only a rule you understand and can restore.
macOS: Check the proxy options for the active network service, and review any network filters or profiles installed by security software or an organization. A network extension can affect traffic even when the VPN app reports a connection. If the device is managed, contact its administrator before changing a profile. Reconnecting through the VPN client is a safer first test than deleting VPN configurations from system settings.
Android: If the client supports per-app routing, verify that the browser is assigned to the route you expect. A rule that excludes the browser may send it directly while other apps use the VPN, or the reverse. Private DNS is a separate Android setting and may affect name resolution; temporarily compare the configured mode only if you understand how to restore it. Battery optimization can interrupt some background connections, but it is not the first explanation for a page that fails immediately while the client remains connected.
iOS: Confirm that the VPN profile shown by the operating system corresponds to the client you intend to use. A second network-filtering or security app may also install a profile or on-demand rule. Avoid “Reset Network Settings” as an early fix: it can remove saved network details and require reconfiguration. Try reconnecting from the client and comparing a second browser first; if a managed profile is present, ask the administrator before removing it.
Linux: Check whether the desktop environment, shell, or application has proxy variables such as http_proxy or https_proxy configured. Review the active DNS resolver and firewall rules using guidance for your distribution. Commands and resolver services differ across Linux systems, so do not assume that a command for one distribution applies to another. If a second tunnel or proxy service is active, test with only one routing tool enabled.
Review Split Tunneling and Know When to Contact Support
Split tunneling determines which apps or destinations use the VPN route and which use the ordinary network. A website can fail because its browser is excluded from the tunnel, because a domain rule sends it to the wrong outbound connection, or because an app-specific rule differs from the browser’s route. In a rule-based client, check both the selected mode and the rules that match the affected domain. A connected status alone does not show which rule handled a particular request.
For a clean comparison, temporarily use the client’s simplest routing mode if one is available and appropriate for your network. Test the affected site, then restore your usual mode and adjust only the relevant rule if the comparison identifies a routing difference. Do not add broad exceptions or disable protections just to make one page load; a narrow rule is easier to understand and undo. If you use a third-party client, confirm that its core supports the configuration and that the subscription or profile has refreshed successfully.
If the issue remains, collect details before contacting support. Include your operating system and version, the client and version, whether the problem affects one site or all sites, the exact browser error, the selected route label, and the time the issue occurred. Explain which comparisons you performed: another browser, another device, another route, and a test with the VPN disconnected. Redact account names, subscription links, tokens, and any personal data from logs or screenshots.
- ✅ Report whether the failure is a timeout, DNS error, certificate warning, blank page, or site-specific block.
- ✅ State whether the same website works in a private window, another browser, or on another route.
- ✅ Mention recent changes to DNS, proxy, firewall, browser extensions, or split-tunneling rules.
- ❌ Do not send a subscription URL, password, or unredacted configuration file in a public channel.
Stop and seek help if the client shows repeated connection errors, the device loses access to ordinary network services after disconnecting, or the issue began after a managed security profile changed. Support can use the controlled comparisons to distinguish a route-specific problem from a local configuration conflict. If only one website fails while other sites and apps work, the website’s own access policy or availability may also be involved.