How can you tell whether your VPN is working? Check your public IP first, then review the DNS resolution path, and finally test the apps you actually want to use. A connected status only means the client’s connection criteria have been met; it doesn’t mean all traffic is routed through the VPN. When split tunneling, a system proxy, or a separate browser proxy is in use, a test website and your target app may use different exit routes.
First, distinguish connection status from traffic routing
Tools often grouped under the term VPN don’t all work the same way. A system-level tunnel routes eligible network traffic through the tunnel, while a system proxy mainly affects apps that respect the proxy settings. Browser extensions typically apply only to browser traffic, so they say nothing about the routes used by desktop apps or background processes.
Importing a configuration through a subscription link doesn’t mean traffic routing is enabled. A subscription provides nodes and may include configuration options, but whether you’re connected, which mode is active, and which domains bypass the proxy all depend on the client’s current settings. Selecting a node, updating a subscription, or getting a response from a latency test doesn’t replace testing real app traffic.
Shadowsocks, VMess, Trojan, VLESS, and similar names refer to proxy protocols or related protocol families—not proof that every app’s traffic is being routed through the VPN. Even clients that support the same protocol may offer different system proxy, tunnel, and rule-based routing features. Check the active mode instead of relying on the protocol name.
| What you see | What it can confirm | What it can’t confirm yet |
|---|---|---|
| The client shows “Connected” | The client reports that a connection or tunnel has been established | That the target app is using this route |
| The test website shows a different exit IP | That this website’s request used a different public exit | That other apps or address families are also routed through the VPN |
| A DNS test shows the expected resolver | That this test observed the corresponding DNS resolution path | That all DNS queries on the device use the same path |
| An app request matches a proxy rule and succeeds | That the request followed the selected policy and received a response | That all subsequent requests will follow the same policy |
Compare your exit IP and note the pre-connection baseline
Disconnect the client, open the IP check page, and note your current public IP and its reported location. Then connect to the route you want to test and run the same check in the same browser on the same page. If the page shows cached results, use its retest option or reload it. Don’t compare location labels across different test sites as if they were exact; each may use a different IP geolocation database.
If your exit IP changes to the address associated with the selected route, that’s useful evidence. But a location label isn’t proof of physical location: databases may be out of date, and route labels can differ from how websites identify an IP. If the IP changes but the location looks wrong, check the client’s route details and the target service before concluding the VPN isn’t working.
Check IPv4 and IPv6 separately, too. Some configurations route only one address family, leaving the other on your regular connection. A browser may prefer whichever address family is available, so an IPv4 change alone doesn’t rule out IPv6 traffic going direct. If a test tool doesn’t show the other address family, that only means it wasn’t observed in this test—not that it’s absent.
- Disconnect and record your baseline public IP. Don’t mistake a local network address for your public exit IP.
- Connect to the route and confirm the client is using the intended rules or tunnel mode.
- Check your exit IP again, compare it with the pre-connection address, and review any address-family results shown.
- If the result hasn’t changed, check whether the test domain is set to bypass the proxy before changing your routing policy.
Check DNS and distinguish resolution from traffic routing
DNS translates domain names into IP addresses; the actual connection then uses those addresses to reach a service. The two can take different routes. A changed public IP doesn’t mean DNS queries use the same route. Conversely, using an overseas DNS resolver doesn’t prove that web traffic is going through the proxy.
A DNS leak usually means DNS queries have left the expected protected route—for example, when queries that should be resolved inside the tunnel are instead sent to a resolver on your local network. When using a DNS test, check whether it reports resolvers, exit IPs, or an estimated location, then compare that with the client’s DNS settings. Don’t call it a leak just because the resolver belongs to a particular company or appears to be in a certain location.
A browser’s Secure DNS setting may use encrypted DNS independently, while a client may support remote resolution, rule-based DNS, or virtual IP mapping. The recursive resolver shown by a test page may not be the server your device contacts directly. Encrypted DNS can protect queries between your device and the resolver, but it doesn’t by itself ensure that requests use the VPN tunnel.
Start by noting your current DNS settings. Then check whether the browser has its own DNS configuration, whether the client handles DNS, and whether direct and proxied domains are treated differently. Change one setting at a time, reconnect the app, and test again. If DNS is bypassing the intended route, follow the client’s documentation to fix routing and DNS handling. Don’t enter an unfamiliar DNS address just to get a better-looking test result.
Test apps individually and check the requests that matter
Passing a test in your browser doesn’t mean other apps are covered. Open the app you actually want to use and trigger a fresh network request—for example, refresh content, start a new session, or load something that isn’t cached. Then check the client’s connection logs for the relevant process, domain, matched rule, and routing policy.
Even one app may connect to multiple domains, and login, content, images, and real-time communications may not all use the same route. If the homepage loads but login fails, check the login requests. If text loads but voice calls don’t work, check whether the client supports and routes the traffic that feature needs. Don’t assume the whole app is configured correctly just because part of it works.
What to check on desktop and mobile
- Windows and macOS: Check whether the app respects system proxy settings. Command-line tools, standalone environments, and some desktop apps may use their own proxy settings; enabling the system proxy doesn’t automatically route their traffic through it.
- iOS and Android: A VPN indicator means the related network extension or tunnel is running, but the client may still have exclusions or per-app routing rules. Check the app’s actual requests again after switching apps or changing networks.
- Linux: Desktop proxy settings, shell environment variables, and tunnel routing operate at different levels. Don’t use browser results to infer what command-line tools are doing, or assume one terminal session’s settings apply system-wide.
If you temporarily switch to a broader routing mode to diagnose a problem, note the original mode and restore it when you’re done. The goal of changing rules is to route specific requests correctly, not to make every app use the same exit permanently. If you’re importing a configuration for the first time or switching clients, check the setup steps in our guides.
Common false positives that make a VPN look connected
A page may load from cache
An already-open page, offline content, or an existing connection can make it look like the route is working. Test with a fresh request, and fully quit and reopen the target app if needed. After switching routes, an app may keep an existing long-lived connection until it reconnects, so it won’t use the new exit immediately.
Your exit IP changes, but the platform still shows the same location
Platforms may determine available content using account location, payment details, browser permissions, and previous sessions. A changed exit IP and an updated platform location aren’t the same thing. If you see a location notice, first confirm the network request’s route, then check the platform’s rules. Not every restriction means the VPN isn’t working.
A WebRTC test showing an address doesn’t automatically mean there’s a leak
Browser real-time communications can expose address candidates, which may include public or local IPs, or a hostname processed for privacy. Check whether your original public IP is exposed when it should be hidden; the presence of any address doesn’t necessarily indicate a problem. A WebRTC test also can’t replace DNS and app traffic checks.
The node test passes, but the target service still fails
A node test may contact a different destination from the app you’re using. The target service could be down, the exit IP could be restricted, a rule could match incorrectly, or there could be an issue with your account. IEPL, relay, and direct connection describe route organization or transport paths; their names alone don’t prove that your device is routing traffic correctly, and they can’t replace testing the target service.
Review the checklist and keep useful diagnostic evidence
The most effective troubleshooting approach isn’t to keep switching nodes; it’s to hold the target constant and check each factor in turn. Confirm your local network works, then check the connection status, exit IP, DNS, and app rules. If you change networks or routes, note the change so you don’t mix results from different conditions.
- ✅ Recorded the public exit IP before and after connecting, and checked the observed IPv4 and IPv6 results separately.
- ✅ Confirmed which routing rule applies to the test page and the target app.
- ✅ Checked DNS settings in the client and browser, and understood what the test results show.
- ✅ Tested the target feature with a fresh request instead of relying on the client icon or a cached page.
- ✅ Rechecked the target app after changing networks, routes, or routing modes.
- ❌ Don’t share subscription links, account passwords, or full logs containing sensitive queries publicly.
When asking for help, include your operating system, client name, operating mode, selected route, the feature that failed, and when it happens. Redact account details and subscription links in screenshots; share only the log excerpts needed to diagnose the issue. Use the Help Center to organize what you’ve checked—this is more useful than simply saying “it shows connected, but nothing works.”