If your VPN is connected but not working, check your public IP first, then DNS, and finally test each app. The connection icon only confirms that one part of the connection is up; it doesn’t prove that sites and apps can actually reach their destinations. Rather than clicking Connect repeatedly, check where requests are routed, which resolver handles domain lookups, and whether the app is covered by your rules.
First, distinguish connection status from traffic routing
A VPN client may create a tunnel through the operating system’s VPN interface, or it may mainly provide a local proxy. Shadowsocks, VMess, Trojan, VLESS, Hysteria2, and TUIC are different proxy protocols or protocol suites. Their names alone don’t tell you whether they automatically route traffic from the entire device. The actual coverage also depends on the client, operating mode, and routing rules.
On desktop, the system proxy usually affects only apps that follow that setting. Some apps use their own network settings and won’t follow it automatically. TUN or virtual network adapter mode can route more traffic, but routing rules, exclusions, and system permissions still matter. On Android, the VPN icon means the system has established the relevant interface; it doesn’t mean every app is included.
A connection can also be established even when the actual request never completes. Reaching the VPN entry point doesn’t guarantee that the exit route, DNS resolution, or destination site is working. IEPL, transit, and direct connections describe the route or transport—not which apps are covered—and don’t replace app-by-app testing.
| What you observe | Possible cause | Check first |
|---|---|---|
| Client says connected, but the browser’s public IP hasn’t changed | The test site is routed directly by a rule, or the browser isn’t using the proxy | System proxy settings, browser extensions, and the rule matching the test domain |
| Browser’s public IP changed, but one app still doesn’t work | The app is excluded, using an existing connection, or being blocked by the service | Per-app settings, behavior after restarting the app, and the exact error |
| A domain won’t load, but the client still says connected | DNS lookup failure, a rule issue, or a problem with the exit route or destination | DNS logs, connection logs, and other destination sites |
| Connection stopped working after switching networks | Local network restrictions, a failed tunnel reconnect, or stale DNS cache | Basic connectivity, reconnect status, and client diagnostics |
Check your public IP and note the baseline
Your public IP is the address a website sees as the source of your request, not your device’s address on the local network. With the client disconnected, visit a reputable public IP lookup site and note the address and network provider. Then connect to your chosen route and reload the same page in the same browser. Compare the address and network provider, not just the displayed location.
- Disconnect and confirm that regular websites load. Note your public IP without the VPN. If basic connectivity is already down, troubleshoot your local network first.
- Connect to a route and confirm that the configuration is enabled. Refresh the IP lookup page. If needed, close the old tab and open a new one to avoid a cached result.
- Check the client’s connection log to see whether the lookup domain matched a direct or proxy rule. In rule mode, a direct connection to the lookup site doesn’t mean other sites are also routed directly.
- If the client supports it, temporarily apply a proxy rule to the test request and try again. Restore your original settings afterward, then test the apps you actually need.
If the route offers separate IPv4 and IPv6 handling options, check both address types. Test results may differ if one type of request uses the proxy while the other goes through your local network. If the client doesn’t fully route IPv6, consult its documentation and use a supported routing option or restriction rather than changing system network settings at random.
Check DNS: trace the resolution path
DNS translates domain names into IP addresses. Routing web traffic through a proxy doesn’t guarantee that DNS queries take the same route. Lookups may be handled by the operating system, the client, the browser’s secure DNS, or a resolver built into the app. A DNS leak generally means a query that should be protected by the expected tunnel or proxy policy is instead sent out over the local network.
While connected, run a DNS test on a reputable site and note the resolvers and locations it reports. Then compare those results with the client’s DNS settings. A test site typically identifies the recursive resolver’s exit point, not the full path between your device and that resolver. The provider name alone therefore can’t confirm either a leak or that your queries are protected.
How to investigate a mismatch
- Check whether the client is handling DNS, and whether direct and proxied domains use different resolution policies. In rule mode, leaving some lookups local may be intentional.
- Check your browser’s secure DNS settings. If the browser uses encrypted DNS independently, its results may differ from the system’s. Encrypted DNS protects the query in transit; it doesn’t automatically route your web traffic through the proxy.
- After changing settings, reconnect and clear the DNS cache as instructed by your operating system or browser. A stale cache can make it look as though the new settings aren’t taking effect.
- If you’re still unsure, use the client logs to trace DNS queries. Before sharing logs, redact subscription credentials, account details, and any access records that aren’t needed.
Don’t assume that setting a public DNS resolver has fixed the problem. The resolver’s location, how queries reach it, and where traffic goes after an address is returned are separate issues. Nor should you draw conclusions by visiting a site’s IP address instead of its domain: HTTPS certificates, virtual hosting, and content delivery can all make that fail even when the network route is fine.
Test each app, not just your browser
After a browser test passes, check the software you actually use. See whether it can load fresh content, then try a normal action, such as opening a new page, refreshing data, or sending a routine request. A cached homepage or old content doesn’t prove that the current connection works. A sign-in failure may also stem from account status, regional policies, or the service’s security checks—not the network.
On Windows and macOS, first check whether the app follows the system proxy. If it supports its own proxy settings, avoid entering conflicting addresses in both places. Terminal apps may also use proxy environment variables, so it’s not unusual for a browser to work while command-line requests fail. Check the client’s documentation for TUN mode availability and required permissions.
Android clients often have per-app proxy settings or bypass lists. Check that the app is included, and make sure battery restrictions aren’t stopping the client in the background. On iOS, review the active VPN configuration and client rules. If on-demand connection is enabled, confirm that it actually starts during the test rather than assuming it does because the setting is saved.
- ✅ Make sure the target app isn’t excluded by per-app rules, and check that its domain hasn’t been mistakenly set to connect directly.
- ✅ After switching routes, fully quit and reopen the target app so it creates a new connection instead of reusing an old session.
- ✅ Test the browser and the app separately, and note each result. A browser test passing doesn’t mean the whole device is covered.
- ✅ Keep the exact error message so you can distinguish a timeout, DNS lookup failure, certificate error, and account access restriction.
- ❌ Don’t rely solely on a cached page loading, a lit connection icon, or a successful test on one website.
Still not working? Narrow it down in order
Change just one setting at a time. If you change the route, DNS, protocol, and routing mode all at once, even restoring access won’t tell you what fixed it. Back up your current settings first, then check coverage before investigating DNS and the route. If you see a permissions prompt, verify who issued it and why; don’t grant every permission just to make the icon light up.
Check the configuration, then the route
Open the client’s configuration page and confirm that the expected profile is selected. A subscription link is a way to fetch routes and rules; importing it successfully doesn’t guarantee that it will keep updating automatically. Refresh the subscription using a method supported by the client, confirm that it succeeds, and check that the selected route is still in the current profile. If the import fails, the subscription format may not be compatible with the client’s core; changing the file extension won’t fix that.
Next, check whether other proxy clients, browser proxy extensions, or network filtering tools are running. They may compete for the system proxy, routes, or DNS. Temporarily disable nonessential tools of the same kind and try again, but don’t turn off system security protections as a guess. On a device managed by your employer or school, follow the administrator’s policies rather than bypassing management settings.
Cross-check the results
If switching to another route on the same device fixes the issue, that narrows it down to the original route or its path to the destination. If the same route works on another network, focus on restrictions in the local network. Public Wi-Fi may also require portal sign-in. Disconnect the proxy to confirm that regular internet access works, complete any portal sign-in, then reconnect so you don’t mistake an unauthenticated network for a service failure.
What counts as a successful test?
A useful test means that requests meant to use the route match the expected rules, the public IP is as expected, DNS behavior makes sense, and the target app can complete a real task. With rule-based routing, local websites connecting directly isn’t a failure. If you expect the entire device to use the route, also check exclusions, IPv6, and apps that don’t follow the system proxy.
When contacting support, include your operating system, client name, current mode, selected route, test time, and a redacted error message. “The browser’s public IP changed, but the app timed out” is more useful than “the VPN doesn’t work.” Don’t include passwords, full subscription links, or logs you haven’t checked for sensitive information.
If you’re not sure where to configure things, start with the getting started guide and follow the import and connection steps for your platform. For route details, see the global server locations page. Whether a particular site works still depends on your region, account, and conditions at the time of testing.