How can you tell if your VPN is working? Don’t rely on the connection icon alone. Check the public IP used by your request, the DNS resolution path, and the target app’s actual connection. If a webpage loads, that only confirms that the browser request succeeded. It doesn’t mean every app is using the intended route or that every DNS lookup is going through the expected resolver.
Follow these steps, which you can repeat yourself. Note what happens before connecting, compare the results after connecting, then test the software you actually use. You don’t need to share your subscription link or give your account password to a testing site.
What’s the difference between “connected” and working?
“Connected” can mean different things in different clients. It may indicate that a system tunnel is established, that a proxy core is running, or simply that a local proxy port is open. You still need to check whether the remote route is reachable, whether the app is using the proxy, and whether the routing rules match.
A system proxy usually covers only apps that honor the system proxy settings. Tunnel mode routes traffic through a virtual network interface, but its actual coverage still depends on routing, exclusion lists, app permissions, and the client’s implementation. The “global” setting in a client may only change how captured traffic is routed; it doesn’t mean all operating system traffic automatically goes through the client.
| What you observe | What it tells you | What else to check |
|---|---|---|
| The client shows “connected” | The client reports a connection or that its local service has started | Whether the remote route is reachable and the app’s traffic is captured |
| The test page shows a different public IP | This webpage request used a different public IP address | Other apps, IP versions, and routing paths |
| The DNS test shows the expected resolver | The resolver shown handled the query triggered by this test | Secure DNS in the browser and app-specific DNS lookups |
| The target app signs in and loads normally | This app session succeeded | Whether it used the intended route rather than a direct connection or cached data |
Check your public IP: compare before and after connecting
Open a test page that shows your public IP address, region, and network provider. Note the results before connecting, then run the same test in the same browser after connecting. Don’t compare an old result from Wi-Fi with a new result after switching networks: changing networks can change your public IP on its own.
- Disconnect the client and make sure your regular internet connection still works. Note the public IP address and region shown on the test page.
- Connect to your chosen route. Check that the system proxy or tunnel is enabled as intended, and note the route name and operating mode.
- Reload the test page. If you suspect it’s showing an old result, close and reopen it, then cross-check with another testing service.
- Check the client’s connection logs to see which rule matched the test page’s domain and whether it used a direct connection or your chosen proxy route.
If the test site is set to bypass the proxy, an unchanged IP doesn’t mean the proxy isn’t working. Test a destination that’s explicitly routed through the proxy, or temporarily adjust the test rule while preserving access to your local network. Restore your usual routing rules when you’re done; there’s no need to route every test page through an international exit on an ongoing basis.
Region results aren’t precise location data. IP databases may update at different times, and the route name, entry location, and exit location seen by a website may all differ. If your IP changed but the region label looks wrong, compare other databases and check what the target website reports instead of relying on a single label.
Check whether IPv4 and IPv6 use the expected routes
A device may have both IPv4 and IPv6 connectivity. If the client captures only one, a webpage may use the other, depending on availability. Check whether the test page displays both address types and whether the client supports traffic for each. A changed IPv4 address alone doesn’t prove that IPv6 traffic is also being captured.
Check DNS: don’t judge a leak by region alone
DNS translates domain names into IP addresses. A DNS leak usually means a query took an unexpected route—for example, a lookup that should have gone through a tunnel was sent to a resolver on your local network. DNS and your public IP are related but distinct clues: a webpage request can use a proxy while DNS lookups are still handled by your local network.
A DNS test typically triggers queries for test domains, then shows the recursive resolvers it detected. These aren’t the remote server addresses used by your client, and they don’t necessarily share a region with your public IP. Public DNS deployment, forwarding arrangements, and database labels can all affect the results, so a resolver showing a different region from your exit IP isn’t enough to prove a leak.
- ✅ Check the client’s DNS mode and find out which resolution strategy it uses for proxied and direct domains.
- ✅ Check your browser’s Secure DNS settings. The browser may use a separate resolver over encrypted DNS.
- ✅ Compare the results before and after connecting, and check the client logs to see how the test domain was actually resolved.
- ✅ Clear the relevant DNS cache and test again so a cached result isn’t mistaken for a new lookup.
- ❌ Don’t declare a DNS leak just because the resolver is labeled as being in your region. Encrypted DNS doesn’t automatically use the proxy, either.
Encrypted DNS changes how a browser sends queries, but whether those queries use a proxy still depends on the route for that connection. Conversely, proxy requests that use remote DNS may not require you to configure encrypted DNS in the browser. First check how your current client works, then adjust settings as needed. Changing system DNS, browser DNS, and client DNS settings all at once makes the cause harder to identify.
If results differ between your home and work networks, consider DNS restrictions on the network itself. Note which network you’re using during each test so you don’t mistake differences caused by network policies for route quality issues.
Test apps individually: a working browser doesn’t mean everything works
Once the browser test passes, check the app you actually want to use. Fully quit and reopen it so it creates new connections under the current rules; existing long-lived connections may keep using their old route. Test sign-in, content loading, and the app’s key functions while checking the client’s connection logs. Don’t rely solely on whether the app’s home screen appears.
On Windows and macOS, desktop apps may use the system proxy or their own network settings. Command-line and developer tools especially need to be checked separately: a successful browser test doesn’t mean the terminal is using the proxy. Whether a command-line program uses HTTP_PROXY, HTTPS_PROXY, or ALL_PROXY depends on its implementation. Having an environment variable set doesn’t mean every program will honor it.
On iOS and Android, clients often use the system VPN interface to create a tunnel, but actual coverage still depends on the configuration. Android clients may let you include or exclude specific apps; iOS behavior also depends on the client’s settings. If one app consistently behaves differently, check app exclusions, custom rules, and the app’s own proxy settings first.
Separate “it connects” from “you’re allowed to use it”
If a webpage loads but shows a notice about account region, subscription access, or content availability, the service’s requirements may not be met. That doesn’t mean the network connection failed. Your exit region is only one possible signal a platform may consider; account details, past activity, and platform policies can also affect the result. Avoid repeatedly switching routes to retry sign-in: it can make troubleshooting harder and may trigger additional account checks.
Voice, gaming, and real-time communications may also rely on UDP. A webpage loading successfully doesn’t prove that UDP traffic is getting through. Check the client’s capabilities, the configuration in use, and the app itself; don’t assume a feature is enabled based on a protocol name alone.
If connected but traffic isn’t routed, what should you check first?
Check traffic coverage before investigating the remote route. Switching regions won’t help if the request never reaches the client. If the connection logs show that the request entered the proxy but keeps failing, then check the route, your network, and your subscription status.
- Check how traffic is captured. Make sure the system proxy is enabled or that the tunnel has system permission. Importing a configuration without enabling the corresponding mode won’t change the traffic route.
- Check which rule matched. Search the connection logs for the target domain or app and see whether a direct, excluded, or blocked rule matched. Rule order and the client’s matching behavior can also affect the result.
- Rule out configuration conflicts. Another proxy, browser extension, or network filtering tool may be intercepting the same request. Pause unnecessary traffic-handling tools and test again to avoid settings being overridden by multiple tools.
- Check your subscription status. Refresh your subscription from the service dashboard, confirm the plan is active and data is available, and make sure you’ve selected a working route rather than an outdated configuration.
- Compare routes last. Keep the device, network, and target app the same; change only the route and test again. Then compare other local networks to help distinguish a route issue from a problem with your current network.
A subscription link is used to import configuration, including server and routing information. It isn’t a connection page you need to keep open in a browser. Successfully importing it doesn’t mean you’ve selected a route or started the proxy. Protocols such as Shadowsocks, VMess, Trojan, VLESS, Hysteria2, and TUIC require compatible client and server configurations; changing a protocol name alone won’t convert a setup.
IEPL, relay, and direct routes describe different network architectures or traffic paths; they aren’t substitutes for checking whether a connection works. Whatever the architecture, check the actual exit IP, matched rules, and app results. A dedicated line doesn’t guarantee that every app will use the proxy or that a platform will grant access.
Final check: keep a record you can test again
When you’re done, note the network, client mode, selected route, exit region, DNS results, and how the target app behaved. Don’t keep screenshots of configurations that contain credentials. If something goes wrong later, repeat the same tests in the same order; that’s usually more helpful than relying on the impression that “the network feels off today.”
If you’ve only confirmed that the browser works, limit your conclusion to the browser. And if some apps are meant to connect directly, that isn’t a failure. The goal is to route the requests that need a proxy as intended while keeping local access where needed—not to make every test show the same region.
For more troubleshooting, see the troubleshooting guide. If you’re unsure about the order for setting up a subscription and client, review the Guides. When contacting support, include the checks you’ve already completed and their results to avoid repeating steps.