A VPN can report “Connected” while websites, apps, or even basic network checks fail to load. The status usually confirms that a tunnel was established; it does not prove that DNS is resolving correctly, that your traffic is using the intended route, or that the selected server can reach the service you are trying to use. Work through the checks below in order, changing one thing at a time. That makes it easier to find the cause and undo any temporary change.
Start with a quick network check
First, establish whether the problem is limited to the VPN. Disconnect it and try opening a familiar website or app. If nothing loads without the VPN either, check the underlying connection before changing VPN settings: confirm Wi-Fi or mobile data is enabled, reconnect to the network, and see whether other devices on the same network can get online. If the connection works without the VPN but fails as soon as you connect, continue with the checks below.
When testing, use more than one kind of destination. A browser page might fail because of a browser setting, while an app might use its own DNS or connection method. Try a second browser or a different app, and note whether the problem affects all traffic or only particular services. Avoid drawing a conclusion from one website: the site itself could be unavailable, or its connection may be restricted independently of your VPN.
Make a brief note of the current setup before changing anything: the network you are using, the selected server or route, the VPN app, and whether the issue began after an update or a network change. On a laptop, also note whether a wired connection behaves differently from Wi-Fi. On a phone, compare Wi-Fi with mobile data if that option is available. These comparisons help separate a local network issue from an app, DNS, or route issue.
- ✅ Test the same device with the VPN disconnected and connected.
- ✅ Try more than one website or app before deciding the whole connection is down.
- ✅ Record the original route and settings so you can restore them after testing.
- ❌ Don’t change DNS, protocol, and server settings all at once; you won’t know which change mattered.
Six fixes to test in order
These checks start with changes that are easy to reverse and move toward settings that can affect how the VPN handles traffic. After each test, disconnect and reconnect if the app requires it, then try the same destinations again. If a change makes no difference, restore the original setting before moving on.
Fix one: Switch to another server
A particular server may be unavailable, overloaded, or a poor match for the network you are currently using. Select another server in the same region first, if the client offers one, then reconnect and test again. If that does not help, try a different region as a comparison. This is a diagnostic test, not a promise that a farther-away route will be faster or that every server will work with every app.
Check whether the client shows a connection error or simply reports a successful connection while traffic stalls. If one server works and another does not, the problem is more likely related to the route or that server than to your device’s general internet access. If every server fails on one Wi-Fi network but works on mobile data, the local network may be interfering with VPN traffic.
Fix two: Reconnect and refresh the client
Disconnect from the VPN, close the client fully, and open it again. If the app has a stop or quit command, use it rather than leaving it in the background. Then reconnect. A fresh session can clear a stalled tunnel or an outdated connection state without changing your saved configuration. If you recently updated the app or imported a subscription, check that the client is using the current configuration and that the selected server is still present.
Restarting the device can also help if the operating system still appears to route traffic through a previous VPN session. Save any work first. After restarting, test the internet without the VPN, then connect once and test again. Avoid installing a second VPN client as a troubleshooting shortcut: two apps trying to manage system routing can conflict.
Fix three: Check DNS and routing
DNS translates a website name into an address. If the tunnel is connected but DNS requests are not reaching a working resolver, a website may appear unavailable even though some direct connections still work. If your client provides a DNS option, note its current value, then use the client’s supported default or recommended DNS setting as a test. Reconnect and try several sites. If the problem persists, restore the original value rather than adding an unrelated public DNS address without checking how the VPN handles DNS.
Routing mode matters too. In a rules-based or split-tunnel setup, some apps or destinations may go through the VPN while others use the local connection. A rule, local proxy setting, or per-app exclusion can therefore make the result look inconsistent. For diagnosis, use the client’s full-tunnel or global mode if it offers one, test briefly, and then restore your preferred mode. Do not assume a browser and a messaging app follow the same route.
If you are choosing a client for a particular workflow, review the setup guidance alongside the app’s supported formats; for example, VPNVT VPN for AI Tools in China provides a starting point for understanding the service and its client options. A subscription link, a server configuration, and a DNS or routing policy are separate parts of the setup, and a successful import does not by itself confirm that all of them are working together.
Fix four: Review kill switch and system proxy settings
A kill switch is designed to block traffic when the VPN tunnel is disconnected or judged unsafe. Depending on the client and operating system, it may continue blocking traffic while the app is reconnecting, or it may prevent all access if the tunnel cannot be restored. Check the kill switch status in the VPN app. If you temporarily turn it off for diagnosis, do so only long enough to test, and turn it back on afterward if you rely on it. A kill switch does not repair a failed tunnel; it changes what happens to traffic when the tunnel is unavailable.
Also check for proxy settings configured outside the VPN app. A manually configured system proxy, a browser proxy extension, or another network utility can send requests to a proxy that is no longer reachable. Note the original settings, disable only the setting you are testing, and retry. If that makes no difference, restore it. On managed work or school devices, do not remove organization settings without permission; ask the administrator whether a network policy is blocking the connection.
Fix five: Test a different VPN protocol
Networks do not all handle VPN traffic in the same way. A protocol or transport that works on one connection may be blocked, filtered, or unreliable on another. If the client lets you choose a protocol, record the current option and test another supported one. Reconnect after changing it. If the alternative works, the original protocol or its transport may be incompatible with that network; it does not necessarily mean the original configuration is broken everywhere.
Protocol names are not interchangeable. Shadowsocks, VMess, Trojan, and WireGuard use different connection designs, while Hysteria2 and TUIC use QUIC and depend on UDP transport. A client must support both the protocol and the relevant configuration format and options. If a subscription contains a protocol your app does not support, changing an unrelated DNS setting will not make that configuration compatible. Check the app’s current support information and use a client that can import the format provided to you.
Fix six: Compare Wi-Fi, mobile data, and local network rules
If it is safe and practical, connect through another network and repeat the same VPN test. A connection that works on mobile data but not on a particular Wi-Fi network points toward that network, its router, or its access policy. Public Wi-Fi portals may require you to accept terms or sign in before general internet access is available. Disconnect the VPN, complete the portal step through the normal network connection, and then reconnect.
Some routers or managed networks restrict certain VPN transports. If the VPN app offers a supported alternative protocol, test it as described above. Do not change router firewall rules or disable security controls just to see whether the VPN connects, especially on a shared or managed network. If you control the router, review its documentation and make only a change you understand; record the original value and reverse the change if it does not resolve the issue.
A practical troubleshooting sequence
Use this sequence to keep the investigation focused. It works on desktop and mobile, though the names of menus vary by client and operating system. If a setting is missing, do not substitute an unrelated system control; use the options actually documented by your VPN app.
- Confirm baseline access. Disconnect the VPN and test the same websites or apps. If the connection still fails, troubleshoot Wi-Fi, mobile data, the router, or the service itself first.
- Refresh the session. Disconnect, fully quit the VPN app, reopen it, and reconnect. If needed, restart the device and repeat the test.
- Change only the server. Try another available server, first in the same region and then elsewhere if needed. Note which one works.
- Check DNS and routing. Test the client’s supported DNS setting and a full-tunnel mode if available. Restore each original option if it does not help.
- Review blocking and proxies. Check the kill switch, system proxy, browser extensions, and per-app routing. Test one setting at a time and restore it afterward.
- Test protocol and network compatibility. Try another supported protocol, then compare Wi-Fi with mobile data or another trusted network.
After any successful test, repeat it once after reconnecting so you know the result is not just a temporary recovery. Then restore any diagnostic setting you do not intend to keep. For example, if switching protocol helped, you can retain that supported option; if disabling the kill switch did not help, enable it again. Keep a short record of the working server, protocol, network, and mode so you can recognize whether the problem returns after a network or app change.
When connection status and access disagree
A “Connected” label is useful, but it is only one signal. The client may have established a tunnel while DNS, routing rules, a kill switch, or the destination’s own connection requirements still prevent a page from loading. An IP-check page can help determine whether a browser request appears to exit through the VPN, but it does not prove that every application uses the same route or that DNS is protected. Treat it as one test rather than a complete diagnosis.
If only one service fails, check that service’s own status and access requirements before repeatedly switching VPN servers. If every service fails only while connected, focus on the VPN route, client settings, DNS, and local network restrictions. If the issue started after importing a new subscription, confirm that the subscription was imported in the intended format and that the client has updated its configuration. Re-importing repeatedly without removing or replacing an old profile can leave confusing duplicate entries.
For support, provide useful diagnostic details without sharing passwords, private keys, or an unredacted subscription URL. State your device platform, client name and version, the network type, whether the internet works with the VPN disconnected, the protocol and route tested, and the exact error text. Include which steps changed the result. This makes it easier to distinguish a device setting from a network restriction or a route-specific issue.