A VPN client can display “Connected” while websites, apps, or even basic network checks fail to load. That status usually confirms that the client has established a connection to a server; it does not prove that your device’s DNS, routing rules, system proxy, or internet connection is working as expected. The quickest way to find the cause is to check one layer at a time, changing only one setting before testing again. These five fixes cover common causes on Windows, macOS, Android, and iOS, while allowing for differences between clients.
Fix 1: Confirm that the problem is actually the VPN
Start with a simple comparison. Disconnect the VPN and try to load a familiar website or use an app you know normally works. If nothing loads with the VPN off, the problem is more likely to be your local connection, router, mobile data service, captive portal, or the destination itself. Resolve that issue first; changing VPN settings cannot repair an internet connection that is already down.
If ordinary browsing works while disconnected but stops as soon as you connect, the VPN path or a setting applied by the client is a stronger suspect. Test more than one destination. A single website may be unavailable, may be rejecting the current exit address, or may have a temporary service problem. If several unrelated websites and apps fail in the same way, look at the device’s routing, DNS, and proxy settings rather than assuming that one site explains the issue.
On a phone, switch between Wi-Fi and mobile data, if both are available, and repeat the comparison. On a computer, try another network when practical, such as a trusted personal hotspot. A network may block or interfere with particular connection methods, while another network allows the same client configuration to work. If a hotel, campus, or public Wi-Fi network requires a sign-in page, disconnect the VPN and complete that network’s sign-in before reconnecting.
- ✅ Test a familiar website with the VPN disconnected, then connected.
- ✅ Compare multiple destinations instead of relying on one app or website.
- ✅ If available, compare Wi-Fi with mobile data or another trusted network.
- ❌ Don’t reset every network setting before identifying whether the failure occurs with or without the VPN.
Fix 2: Check the selected route, proxy mode, and client state
A connected client may still have no usable route selected, or it may be routing only some applications. Open the client and confirm that the selected configuration is current, enabled, and associated with the connection status you are seeing. If the client offers a route list, select another available route and reconnect. Do not infer that every listed route has the same location, protocol, or access to every destination; use the labels and guidance presented by your service.
Next, identify how the client handles traffic. A system proxy generally directs compatible applications through proxy settings recognized by the operating system. Some applications use their own proxy settings or ignore the system proxy, so they may not follow the same path as a browser. A virtual network adapter or tunnel mode can route traffic differently and may require the client to install or enable a network component. A mismatch between the active mode and the applications you are testing can look like a total connection failure even when the client reports a successful connection.
Look for a system-proxy toggle, a routing mode, or a rule setting, but avoid switching several of these at once. If the client has a documented recommended mode, use that as your baseline. Close and reopen the client if its controls appear out of sync, then connect again and test. If you have recently changed proxy settings manually, restore the previous setting or use the client’s own reset option where available. Avoid leaving a manual proxy configured after disconnecting if that setting prevents applications from reaching the internet.
For a service such as VPNSR VPN for China, use the client and subscription instructions intended for that service rather than importing an unrelated configuration. Compatible apps can differ in how they interpret subscription data and routing rules. A successful import alone does not confirm that a route is selected or that the chosen mode sends the app’s traffic through it.
Also check whether another VPN, proxy utility, firewall tool, or network-filtering app is running at the same time. Two clients can compete to set routes, DNS, or system proxy values. Quit the extra tool completely for a controlled test, then reconnect the VPN client. If the problem disappears, re-enable tools one at a time to identify the conflict instead of keeping overlapping network controls active.
Fix 3: Reconnect carefully and test another route
Before changing advanced settings, perform a clean reconnect. Disconnect from the current route, wait for the client to show that it is disconnected, and connect again. If the client offers a refresh or update action for its subscription, use the documented control and wait for it to finish. Then select an available alternative route and test the same websites or apps you used in the first comparison. This separates a route-specific problem from a device-wide configuration problem.
Use the following sequence so you can tell which change helped:
- Record the current setup. Note the client name, selected route label, connection mode, and whether the issue affects every app or only some. Do not share a full subscription URL or a screenshot containing access credentials.
- Disconnect through the client. Wait for its status to change before toggling Wi-Fi, mobile data, or another network setting.
- Refresh the configuration if needed. Use the client’s documented subscription update function. If an update fails, record the message rather than repeatedly importing the same link.
- Select one alternative route. Connect and test a small set of ordinary websites or apps. Keep the same device and network so the comparison remains useful.
- Restore and compare. If the alternative works, return to the original route once to confirm that the difference is repeatable. If neither works, continue to the DNS and protocol checks.
For example, if one route fails but another works on the same device and network, the issue may be specific to the original route or to how a destination handles its exit address. If every route fails only on one Wi-Fi network, investigate that network or its restrictions. If all routes fail on one device but work on another device using the same network, compare the clients, proxy settings, and DNS configuration on those devices.
Do not repeatedly switch routes at random and assume that the first successful page proves everything is fixed. Test the applications that matter to you, and check whether they use different proxy settings. A browser working does not necessarily establish that a desktop application, game, or background service is using the same route.
- ✅ Change one variable at a time and compare the same destinations.
- ✅ Use an alternative route to determine whether the issue is route-specific.
- ❌ Don’t publish subscription links, passwords, or other account credentials while asking for help.
Fix 4: Check DNS, kill switches, and device-level settings
DNS translates a website name into an address that a device can contact. A VPN connection may be active while DNS requests are delayed, blocked, or sent through an unexpected resolver. A useful clue is whether an application reports a name-resolution error while other network activity behaves differently. However, DNS symptoms can resemble a route problem, so treat them as evidence rather than proof.
First, disconnect the VPN and check whether the device can resolve and load the same destinations. Reconnect and inspect the client for a documented DNS option, such as using the service’s DNS handling or restoring the system default. The exact labels vary. Avoid entering an unfamiliar DNS address just to see whether it helps: that can change where your lookups go without solving the routing issue. If you previously configured DNS manually, note the setting and restore the prior value for a controlled comparison.
Then check for a kill switch or “block connections without VPN” setting. A kill switch is intended to prevent traffic from escaping outside the VPN, but it can also leave internet access blocked if the tunnel drops, the client is stuck, or the selected mode is not functioning. Temporarily changing it may help isolate the cause, but consider the privacy trade-off: disabling a kill switch can allow traffic to use the ordinary network during a failure. If you do test this, use a trusted network, avoid sensitive activity, and restore your preferred protection setting afterward.
Operating-system network controls can also matter. On Windows, review the active proxy setting and whether the client reports an adapter or driver problem. On macOS, check the network service and proxy configuration that the client uses. On Android, inspect whether another VPN is active and whether the VPN app has permission to establish a connection; Android generally permits only one active VPN service at a time. On iOS, check the VPN configuration and any content-filtering or device-management settings that could affect traffic. Menu names differ by OS version and client, so follow current on-device instructions instead of relying on a label from another platform.
If changing a setting does not help, restore it before trying the next check. This matters especially for manually configured proxies, DNS, firewall rules, and kill switches: leaving temporary changes in place can create a second problem that obscures the original one.
Fix 5: Try a supported protocol, then prepare a useful support request
Some networks handle different connection protocols differently. If your client and service provide more than one supported option, try another protocol using the documented settings, then reconnect and repeat the same test. Depending on the service and app, options may include protocols such as Shadowsocks, VMess, Trojan, Hysteria2, or WireGuard. They are not interchangeable labels, and an app may support only a subset of them. Use a protocol only when it is actually offered for your account and supported by the client; do not copy a protocol name into a custom setting or convert a configuration without instructions.
A protocol change is a diagnostic step, not a guarantee of faster or more reliable access. If switching protocols restores connectivity on one network, that suggests the original connection method may have been incompatible with that network or configuration. It does not establish that the same choice will work everywhere. If the client shows an error while creating a tunnel, save the exact wording and note whether the error appears before or after the connected status.
Restart the device only after recording any useful error message and confirming that the client is fully disconnected. A restart can clear a stale network state, but it is less informative than a controlled test and may not fix a subscription, routing, or provider-side issue. Avoid uninstalling the client or deleting all configurations as an early step: doing so can remove information that would help identify the cause. If you do need to reinstall, first confirm that you can access the official instructions and retrieve the correct configuration again.
If none of the five checks restores access, contact your VPN provider through its official support channel. Include the operating system and version, client name and version if visible, the selected route label, the connection mode and protocol, the network type, the approximate time the issue began, and the exact error message. Explain whether the problem affects every app, whether it happens with the VPN disconnected, and which checks you already tried. This lets support distinguish a device setting from a route, configuration, or service issue without asking you to repeat basic tests.
Share only the information support needs. A subscription URL, password, verification code, or account token can grant access to your service and should not be posted publicly. If support requests diagnostic logs, read the client’s instructions and check whether those logs contain identifiers or configuration details before sending them. Do not disable security software or follow instructions to install unknown certificates unless you understand why they are required and can verify the source.
- ✅ Try only protocols listed as supported by your service and client.
- ✅ Provide reproducible test results and the exact error wording to support.
- ❌ Don’t share credentials or apply undocumented network changes to “force” a connection.
In short, work from the outside in: verify the local internet connection, confirm the client’s route and mode, compare another route, inspect DNS and device controls, and then test a supported protocol. If the connection still shows as active but no traffic reaches its destination, a concise record of those checks gives your provider a much clearer starting point.