A VPN client can show “Connected” while websites, apps, or even every online service fail to load. That status usually means the client has established a tunnel or selected a proxy route; it does not prove that your device can reach the internet through that route. The cause may be your Wi-Fi or mobile connection, a DNS problem, a routing rule, a blocked permission, or a temporary issue with the selected server. Work through the checks below in order, and test after each change so you can tell which one helped.
Identify what is not working before changing settings
First, narrow down the scope. Try opening more than one familiar website, then test an app that uses a different kind of connection, such as email or a messaging service. If only one site or app fails, the problem may be limited to that service, its account, or the way its traffic is routed. If nothing works, start with the device’s basic internet connection and then check the VPN path.
When possible, disconnect the VPN and try the same destinations again. If they still fail, the VPN is unlikely to be the only cause. If they work without it but fail as soon as it connects, focus on the client, selected route, DNS, and routing mode. This simple comparison is more useful than repeatedly reinstalling the app or changing several settings at once.
Also check whether the connection is truly system-wide. Some proxy clients route only selected apps or domains, while others create a virtual network interface that can handle more device traffic. A browser configured to use a proxy can behave differently from another browser, and an app outside the selected rules may continue using the ordinary connection. Make a note of which apps fail and whether the same sites load with the client disconnected.
- ✅ If all apps fail with the VPN disconnected, check Wi-Fi, mobile data, and the device’s network settings first.
- ✅ If only selected apps fail, review split tunneling, rule mode, and app-specific proxy settings.
- ✅ If everything works without the VPN but fails with it, test another route and inspect DNS or system permissions.
- ❌ Do not change DNS, protocol, routing mode, and firewall settings simultaneously; you will not know which change mattered.
Check Wi-Fi or mobile data first
A VPN cannot provide internet access if the underlying connection is offline, unstable, or waiting for a sign-in page. Confirm that Wi-Fi is connected to the network you intended to use, or that mobile data is enabled and available to the app. If you are on hotel, campus, office, or public Wi-Fi, open a browser with the VPN disconnected and check whether the network requires you to accept terms or sign in. A captive portal may prevent the VPN tunnel from completing useful traffic even when the client appears to be connecting.
Next, test a different access network if one is available—for example, switch from Wi-Fi to mobile data, or try another trusted Wi-Fi network. Do not assume that a network is working just because its Wi-Fi icon is visible. The device may be connected to the router while the router has lost its internet connection. A network change is a diagnostic test, not a reason to reset every network setting.
On a phone, check whether the VPN app is permitted to use mobile data and whether a system data-saving mode is restricting background activity. On a computer, check whether a wired connection, a second Wi-Fi adapter, or a manually configured proxy is taking priority. If you recently changed networks, briefly disconnect and reconnect the device, then reopen the VPN client and test again.
Restarting the router can be reasonable when other devices on the same Wi-Fi also cannot reach the internet, but it is not the first fix for a problem limited to one VPN-connected device. Before restarting shared equipment, consider whether other people rely on it for work or calls. If the ordinary connection fails across multiple devices, contact the network operator or internet provider rather than changing VPN settings that are not involved.
Follow a step-by-step test sequence
Once the basic network is available, use this sequence to isolate the failure. Keep the same test website or app throughout, and record whether the result changes. The goal is not to find the largest number of settings to toggle; it is to identify the earliest point at which traffic stops working.
- Disconnect the VPN and verify ordinary access. Load a few known destinations. If they do not load, resolve the local network or captive-portal issue before continuing.
- Reconnect using the current configuration. Wait for the client to finish connecting, then test again. A short wait can allow routes and DNS settings to be applied, but a persistent failure needs further checks.
- Select another available server or route. Choose a different location or route type that is appropriate for the task. If the new selection works, the issue may be limited to the original route or its current availability.
- Review connection mode and rules. Check whether the client is in a mode that sends the test app’s traffic through the proxy. For a controlled test, use the client’s documented global or full-device mode if available, then restore your preferred rules after testing.
- Refresh DNS and test again. Reconnect the client after changing its DNS option, if one is available. Avoid entering an unfamiliar DNS address simply because it appears in an online tip.
- Check permissions and competing network tools. Approve the operating system’s VPN or network-extension prompt. Temporarily close another VPN, proxy, firewall, or traffic-filtering app, then test with only one active.
- Undo temporary changes that did not help. Return to the previous mode or DNS choice before trying a different test, so the final setup remains understandable.
For example, if you are reading a VPNPaper China VPN service page or using another provider’s client, the same basic diagnostic order applies: confirm ordinary access, confirm the app is routing the test traffic, and then compare a different route. Provider-specific menu names and available protocols can vary, so use the client’s own labels rather than assuming that every app offers identical controls.
On Windows and macOS, a system VPN or network-extension prompt may need approval, and a manually set proxy can conflict with the client. On Android and iOS, the operating system normally asks permission to create a VPN connection; review the system VPN settings if the client’s status and the device’s status disagree. On Linux, confirm which network manager or service owns the active interface and whether a second tunnel is already running. These checks are more reliable than applying commands copied for a different operating-system version.
Check DNS, routing, and client settings
DNS translates a domain name into an address that a device can contact. If DNS requests are sent to an unreachable resolver, a website may appear offline even when the tunnel itself is established. A useful clue is that a service may open by a saved session or existing connection while new websites fail to resolve. This is not conclusive, but it makes DNS worth checking.
Start with the DNS option inside the client, if it provides one. Restore the default or recommended setting if it was changed recently, reconnect, and retry the same destination. If the failure began after enabling a custom DNS app, encrypted DNS feature, or device-wide filtering tool, temporarily pause that feature for a controlled test. Do not keep multiple DNS overrides active while diagnosing: the operating system, browser, client, and filtering app can each influence name resolution in different ways.
Next, review routing rules. Rule-based clients may send some domains directly and others through the proxy. A rule that classifies the test destination as direct can make the client look connected while the relevant traffic avoids the selected route. Conversely, an overly broad rule can send local network traffic into a tunnel that cannot reach the printer, router page, or office resource you are testing. Compare the client’s rule mode with its global mode briefly, then restore the intended setting once you have a result.
Look for another active tunnel or proxy as well. Two VPN apps, a browser proxy, a system proxy, or a filtering product can compete to control traffic. Close or disable one at a time and retry. If you use a firewall, check whether it has a rule for the client or its network extension; do not turn off the firewall permanently to make a connection work. A safer test is to inspect its event log or allow the specific app according to the operating system’s normal controls.
Finally, review any recent changes: a client update, an imported configuration, a new routing rule, or a change to the device’s time and network settings. If the issue began immediately after importing a subscription, refresh the configuration through the client’s normal subscription function and verify that a usable route is selected. Keep the subscription link private; it can contain access credentials. Do not paste it into a public troubleshooting forum or an unfamiliar conversion website.
Try another route and decide when to ask for help
If the local connection, permissions, and routing mode look correct, select another available server or route and test the same destinations again. A route name describes a selection, not a guarantee that every destination will work from every network. A temporary route issue, a network restriction, or a service-specific policy can affect some destinations while leaving others reachable. Avoid repeatedly changing locations at random; compare one alternative at a time and note what changes.
If the client offers protocol choices, first return to its recommended or automatic setting if you previously changed the protocol. Only test another supported option when the client documents it and the current network may be blocking or interfering with the existing connection. Protocol names such as Shadowsocks, VMess, Trojan, Hysteria2, and WireGuard refer to different technologies and are not interchangeable labels. A configuration must support the protocol selected in the client; choosing a name that is absent from the imported configuration will not repair the connection.
When one route works and another does not, keep the working selection for the task and report the failing route to the provider if the problem persists. If every route fails only on one Wi-Fi network, ask that network’s administrator whether VPN or proxy traffic is restricted. If all routes fail on several independent networks while ordinary internet access works, collect the client version, operating system, approximate time of the failure, selected mode, and the tests you performed before contacting support.
Share only the information needed to diagnose the issue. Redact account names, passwords, subscription URLs, authentication tokens, and private addresses from screenshots or configuration files. A useful report says which device and network were tested, whether ordinary access worked with the client disconnected, which modes or routes were compared, and what error appeared. This gives support a reproducible sequence without exposing credentials.
- ✅ Keep a working route selected while reporting a problem with another route.
- ✅ State whether the issue affects all apps, only selected apps, or only specific destinations.
- ✅ Include relevant client and operating-system versions, plus the troubleshooting steps already tried.
- ❌ Do not send an unredacted subscription link, password, or full account configuration in a public post.
- ❌ Do not leave a temporary global mode, custom DNS setting, or disabled security feature in place unless you intended to keep it.
After service returns, restore the connection mode and routing rules you normally use, remove temporary DNS overrides, and confirm that local services behave as expected. If the device still cannot reach the internet, disconnect the VPN and verify the ordinary connection once more. That final comparison helps determine whether the next step belongs with the VPN provider, the device administrator, or the network operator.