A VPN app can show “Connected” while webpages fail to load, apps time out, or only some services work. That status usually means the client has established a tunnel or applied a proxy configuration; it does not prove that DNS, routing, the local network, and the app you are using are all working correctly. Start by checking whether the problem affects every device and every website, then change one setting at a time so you can identify what actually fixes it.
First, identify where the connection is failing
Before changing server settings, check whether your device can access the internet without the VPN. Disconnect the VPN briefly and try to open a familiar website or use another ordinary online service. If that also fails, the cause is more likely to be the Wi-Fi, mobile data, router, or network sign-in page than the VPN tunnel. If internet access returns as soon as you disconnect, focus on the VPN client, its route, DNS, or a conflict with another network tool.
Next, compare different kinds of access. Try a website by name, then try an app that was already working before the connection problem. If the app works but websites do not, DNS or browser proxy settings are worth checking. If neither websites nor apps connect, investigate routing, a kill switch, client permissions, and the server connection. If some sites work and others do not, the issue may be limited to DNS filtering, a particular route, or the destination service.
Write down the device, network type, client status, and the change that preceded the failure. For example, note whether the problem began after switching Wi-Fi networks, updating the operating system, enabling another proxy, or changing a client profile. This simple record makes it easier to undo a change and avoids repeating the same tests.
Bottom line: If the internet fails with the VPN disconnected, troubleshoot the local network first. If it works only when the VPN is disconnected, investigate the VPN route and device settings before reinstalling anything.
Seven practical fixes to try in order
Work through these checks in sequence. After each change, reconnect and test the same website or app. If the connection starts working, stop there rather than changing several settings at once; otherwise, you will not know which adjustment made the difference.
- Complete any network sign-in. Hotels, cafés, airports, and guest networks may require an acceptance screen or other local authentication before general internet access is available. Disconnect the VPN, open a browser, and finish the network’s sign-in process. If the sign-in page does not appear, try the network’s official instructions or ask its operator. Do not enter sensitive credentials into a page unless you can confirm it belongs to the network provider.
- Restart the connection in a clean order. Disconnect in the VPN client, turn Wi-Fi off and on or reconnect mobile data, then connect the VPN again. If that does not help, close and reopen the client. Restarting the device can also clear a stuck network route, but save your work first. Avoid rapidly toggling several adapters or network settings without noting their original state.
- Pause other proxy or VPN tools. A second VPN, browser proxy extension, local proxy, security application, or traffic-filtering utility can compete for the same route. Close or pause one tool at a time, including tools that run in the background, then reconnect. Do not disable company security software or device-management controls on a work device; ask the administrator which tools may be used together.
- Check DNS and proxy settings. DNS translates a site name into an address, while a proxy setting can direct application traffic through a separate service. If the tunnel is connected but names do not resolve, check whether the client offers a DNS reset or a documented DNS mode. Review the operating system’s proxy settings and the affected browser’s own proxy configuration. Remove only settings you recognize and can restore; changing DNS does not fix a broken local internet connection or an unavailable route.
- Review permissions and the kill switch. Desktop clients may need permission to create or manage a virtual network interface. Mobile clients may require approval for an operating-system VPN profile. If permission was denied or revoked, follow the client’s documented steps to grant the required access. A kill switch may block traffic when the tunnel is unavailable or its route changes. Check whether it is enabled and read what its setting does before adjusting it; do not leave protective settings disabled as a permanent workaround.
- Choose a different server or route. Disconnect first, select another available location or route in the client, and reconnect. A particular server can be unavailable, congested, or incompatible with the network you are currently using. Test a nearby alternative before trying a distant route, and give the connection time to establish before testing. A server list or a “connected” label alone cannot confirm that a specific destination service is reachable.
- Try another supported protocol or client profile. Some networks handle VPN traffic differently, so a protocol or transport that works on one network may fail on another. If your client and subscription offer multiple supported options, switch using the client’s own settings or documentation, then reconnect. Do not paste a subscription into an operating-system VPN form unless that form explicitly supports its format. Protocol names such as Shadowsocks, VMess, Trojan, and Hysteria2 describe different technologies; they are not interchangeable labels for a universal system setting.
For a quick checkpoint, test the connection after steps one through three before moving to DNS or protocol changes. The distinction matters: a captive network, proxy conflict, and name-resolution failure can produce similar symptoms, but require different remedies.
Device-specific checks for Windows, macOS, Android, iOS, and Linux
Operating systems manage VPN permissions and network routes in different ways. Use the following checks as a guide, and follow the instructions for your client and operating-system version when menu names differ.
- Windows: Confirm that the VPN client is allowed to manage its adapter and that the expected network adapter is enabled. Check Windows proxy settings as well as any proxy configured separately in your browser. If you use a firewall or endpoint-security product, check its approved application rules rather than turning protection off wholesale. On a managed computer, ask your administrator before changing adapters, routes, or security policies.
- macOS: Look for the VPN connection or network extension in System Settings and confirm that the operating system has not asked you to approve an extension or profile. A client that uses a system proxy and one that creates a virtual interface can behave differently, so check the method described by that client. If you previously tested another proxy app, make sure its system proxy settings are not still active.
- Android: Review the VPN entry in system settings and check whether an always-on VPN or “block connections without VPN” option is preventing traffic while the tunnel is incomplete. These controls can be useful, but a stale profile or a client that is no longer connected may leave internet access blocked. Change them only for diagnosis and restore the intended privacy settings after testing.
- iOS: Check whether the VPN profile is present and whether the client has permission to establish a VPN connection. If the connection fails after switching between Wi-Fi and mobile data, disconnect and reconnect from the client, then test each network separately. Some iOS apps use system-managed VPN configurations, so follow the app’s current guidance instead of adding a second profile manually.
- Linux: Check which network manager or client owns the active tunnel and whether a second tool has installed a competing route or DNS configuration. If you are comfortable with system network settings, inspect the active interface and resolver configuration without deleting routes or configuration files blindly. Distribution, desktop environment, and client setup affect the exact commands; use the documentation that matches your system.
When the issue appears only on one device, compare its proxy, DNS, and VPN permission settings with a device that works on the same network. When every device fails on the same Wi-Fi, investigate the router, network restrictions, or required sign-in before assuming that the VPN service is the cause. For a broader overview of available connections and support options, VPNSee VPN for China Travel provides a useful starting point.
- ✅ Test the local internet connection with the VPN disconnected before changing VPN settings.
- ✅ Pause one conflicting proxy or VPN tool at a time and restore it if the test does not help.
- ✅ Use the client’s documented permission and profile controls for your operating system.
- ❌ Do not remove work certificates, disable managed security, or delete network routes to force a connection.
- ❌ Do not assume that a successful connection indicator proves DNS and application traffic are working.
When to change servers, protocols, or subscription settings
Changing the server is a useful test when local internet works and the client completes its connection, but all traffic through the tunnel fails. Choose another available route, reconnect, and test the same destinations. If the new route works, the original route may have been temporarily unavailable or unsuitable for the current network. If every route behaves the same way, changing locations repeatedly is unlikely to identify the underlying issue; return to DNS, permissions, proxy conflicts, and network restrictions.
Try a different protocol only when the client provides that option and the service supports it. Networks may restrict or interfere with particular connection methods, but an arbitrary protocol change can also make the profile unusable. Keep a note of the original setting, change one option, and reconnect. If you use a compatible third-party client such as Clash Verge, sing-box, or Shadowrocket, check that the subscription was imported successfully and that the selected profile is enabled. A subscription link is configuration data, not a standalone connection, and client support varies by format and protocol.
Also check whether the device’s date and time are correct, whether the client is current, and whether its subscription or profile needs to be refreshed. Use the client’s normal update and refresh controls. Avoid deleting a working profile until you know how to restore it, and do not share a private subscription link in a public support request. If a network blocks the connection method, follow applicable local rules and the network provider’s terms rather than trying to bypass workplace or institutional controls.
If you are comparing a service or client for different networks, prioritize the ability to import a compatible configuration, choose a supported route, and review clear troubleshooting instructions. The VPNSee setup guide can help with basic client and subscription steps. Keep in mind that device permissions, router policies, and public Wi-Fi sign-in requirements are separate from subscription configuration.
Bottom line: Change a server or supported protocol after confirming that local internet works and competing network tools are paused. If the same failure persists across routes and devices, collect the details and contact support instead of making increasingly broad system changes.
What to include when the problem continues
If the checks do not restore access, send support enough detail to distinguish a local configuration issue from a route or service problem. Include your operating system and version, the VPN client and version, whether the issue occurs on Wi-Fi, mobile data, or both, and whether ordinary internet works with the VPN disconnected. Describe which applications or destinations fail and whether changing the server or protocol changes the result.
Share the exact error message or a screenshot with account identifiers, private addresses, and subscription links removed. Mention recent changes such as an operating-system update, a new security tool, or a network change. Do not send passwords, authentication codes, or a complete private subscription URL. If the device is managed by an employer or school, involve its administrator before changing network permissions or security controls.
Once access returns, restore any temporary setting you changed unless the client’s documentation recommends otherwise. Re-enable the intended kill-switch or always-on behavior, resume paused security tools, and confirm that local services still work. This final check prevents a short-term troubleshooting workaround from silently becoming a less secure permanent configuration.