How can you tell if your VPN is working? Compare your public IP before and after connecting, check the DNS resolution path, then test the apps you actually use. A connected indicator is only a starting point: it may mean the proxy process is running, a virtual network interface is active, or a node check has passed. It doesn’t necessarily mean every app’s traffic is being routed as expected.
Start by defining what you want to route: just your browser traffic to international websites, or specific apps as well? Do you want split tunneling, or should the client handle all supported traffic? The right result depends on your setup. With rule-based routing, local websites may continue using your regular internet connection—that can be a sign that your rules are working.
Connection Status vs. Traffic Routing
What people call a VPN may be a system-wide tunnel or a proxy client using protocols such as Shadowsocks, VMess, Trojan, or VLESS. The protocol name alone doesn’t tell you which traffic is covered. What matters is whether the system proxy or TUN interface is enabled, how per-app rules are configured, and how DNS is handled.
A system proxy provides a proxy address to apps that follow the system settings; apps that ignore them may connect directly. TUN mode uses a virtual interface to route matching network traffic and often covers more, but exclusions, system permissions, and the client’s implementation still matter. So “system proxy enabled” doesn’t automatically mean “all device traffic goes through the VPN.”
| Check | What it can confirm | What it can’t prove on its own |
|---|---|---|
| Client shows connected | The local connection feature or node check has reached the indicated state | That every app is using the VPN |
| Check your public IP | The apparent network exit for that specific request | That other sites and apps use the same route |
| Check DNS | Clues about the resolver used for the test domain | That all DNS queries and app traffic pass through the tunnel |
| App behavior and connection logs | Whether the request matched the expected rule and route | That the target platform will accept your location or account |
Check Your Public IP: Record a Baseline, Then Compare
Visit My IP to see the apparent exit for your current web request. Don’t just note the country—record the IP address too. Geolocation databases can lag behind, and different databases may show different cities. A country or city label isn’t a precise measurement of a server’s physical location.
- If it’s safe to briefly connect directly, pause the client, refresh the lookup page, and note your regular connection’s exit IP. If you have tasks that must stay on the VPN, finish them before testing; don’t disconnect just to get a baseline.
- Connect to the route you want to test, confirm the selected node and mode, then reload the lookup page. If needed, close the old tab and open a new one to reduce the chance of cached page data affecting the result.
- Compare the IP addresses, then check the client’s connection log to see whether the request matched a proxy or direct-connection rule. If the lookup page is configured to connect directly, an unchanged IP is expected.
- Make a new request to the site you want to use and cross-check it against the connection log from the same time. Don’t assume the whole browser is routed the same way based only on an IP lookup page.
If the IP doesn’t change after switching routes, check your rules before cycling through more nodes. Nodes may share an exit, or the request may not have reached the client at all. Conversely, a changed IP only confirms that this request used a different exit. Different domains can match different rules, and a single app can have both direct and proxied connections.
Check DNS: The Resolver’s Location Isn’t the Same as Your Traffic’s Exit
DNS translates domain names into addresses your device can connect to. Routing a webpage through a proxy doesn’t automatically send its DNS queries along the same path. A DNS leak usually means queries bypass the expected tunnel or DNS policy and are handled by an unintended resolver. Assess the result against your setup; a test showing a local location doesn’t prove there’s a problem.
Start with the client’s DNS settings: does resolution happen locally or remotely, and are direct and proxied domains handled differently? Then check your browser’s Secure DNS or encrypted DNS settings. A browser may use its own resolver, so its results can differ from the operating system’s.
If your DNS test tool shows resolver details, run a fresh test and check whether it actually triggered a new lookup. Cached results may persist. Test pages generally show the public address of a recursive resolver; that alone can’t prove whether the connection to it used a tunnel or encryption, or where webpage traffic exits.
- Resolver appears to be in another region: This may reflect where a public DNS service is hosted or how a database labels it. Don’t assume it’s a problem.
- Resolver appears to be your local ISP: Investigate this for domains expected to use remote DNS. For local domains intentionally set to connect directly, it may be by design.
- System and browser results differ: Check the browser’s built-in encrypted DNS, extensions, and the client’s DNS interception settings first.
The system command nslookup can help check system-level DNS results, but it may not use the same resolution path as your browser. After changing settings, follow the operating system or client instructions to flush the cache, then establish a new connection to the site. Don’t disable all encrypted DNS just because results differ; first identify which layer handles DNS and make sure the settings are consistent.
Test Apps Individually: A Working Browser Doesn’t Mean Other Apps Are Routed
On computers, browsers may follow the system proxy while chat apps, download tools, or command-line utilities use their own network settings. On mobile devices, per-app allowlists or exclusions and on-demand connection rules can affect routing. Test each app you plan to use rather than stopping after the browser test.
On Windows and macOS, check that the client successfully applied the system proxy settings and that TUN mode has the permissions it needs. On Android, make sure the app you want to test isn’t excluded from routing. On iOS, check which network configuration is currently active and review the client rules—an installed configuration may not be enabled.
- ✅ Browser: Temporarily disable extensions that may change proxy settings, reopen the target page, and check the rules and route for the new request.
- ✅ Desktop app: Check the app’s own proxy settings, fully quit and restart it, then try the network-dependent action again.
- ✅ Command-line tool: Check proxy environment variables and the tool’s own settings. Don’t assume the browser test applies to it.
- ✅ Mobile app: Make sure the app is included in the routing list, reconnect, and then make a new network request.
- ❌ Don’t rely on rising total client traffic as proof: background updates can use data without the request you’re testing going through the VPN.
If the client provides connection details, note the target domain, matched rule, outbound route, and request time. Some apps use multiple domains or connect directly to IP addresses, so searching only for the app’s name may not be enough. If the main page loads but images, sign-in, or voice features fail, check the connections for those features separately.
How Rules, IPv6, and Existing Connections Can Mislead You
Split-Tunneling Rules and Fallback Policies
Rules are usually matched in the order defined by the client. Domain, IP, process, or location rules can all affect the outcome. If a broad direct-connection rule appears before the rule for your target, the proxy rule may never match. Requests that don’t match an explicit rule follow the fallback policy. Check which rule actually matched—not just whether a rule appears in the list.
Also distinguish “route everything through the proxy” in rule mode from system-level traffic capture. Even if the client sends every request it receives through the proxy, apps that never reach the client may still connect directly. A mode label doesn’t tell you which traffic is being captured.
Different IPv4 and IPv6 Routes
A device may use IPv4 and IPv6 at the same time. If the client captures only one, while the target site supports the other, some requests may take an unexpected route. An IP lookup page that shows only IPv4 can’t confirm that IPv6 is routed as expected. Check tests that distinguish address families alongside the client’s routing documentation.
Don’t treat disabling IPv6 as a universal fix. First check whether the client supports and captures IPv6, then adjust it to suit your needs. If you temporarily disable IPv6 to troubleshoot, note the change so you can avoid disrupting other network features.
Connection Reuse and Browser Cache
After you switch nodes, existing long-lived connections may continue using the old session, depending on how the client handles route changes. Page, DNS, and platform account caches can also preserve old results. Try closing the target app, reconnecting, and opening it again to test; there’s no need to clear all browsing data as a first step.
A local network address in a WebRTC test doesn’t automatically mean your public IP is leaking. Browsers may hide or replace local candidate addresses. Focus on whether an unexpected public address is exposed, and consider the browser’s privacy settings as well.
A Site Still Shows the Wrong Region: What to Check Next
If your public IP looks right but a site still shows a location restriction, that doesn’t necessarily mean the route failed. Platforms may also consider account region, payment region, location permissions, previous sessions, and how they classify the exit IP. Your system time zone and interface language don’t determine your network exit, and changing the language isn’t a substitute for testing your connection.
| Symptom | Check first | Next step |
|---|---|---|
| IP unchanged; target site won’t load | System proxy, routing permissions, direct-connection rules | Check whether the new request reaches the client |
| Browser works, but other apps fail | App proxy settings, per-app exclusions, protocol support | Reconnect from the target app and check its outbound route |
| IP changed, but the platform still restricts access by region | Account region, location permissions, exit IP classification | Check the platform’s message and rules; don’t keep changing DNS by guesswork |
| Page loads, but voice or games fail | UDP forwarding, app rules, network restrictions | Check whether the client and route support that traffic |
| Old result still appears after switching nodes | Existing sessions, DNS cache, page cache | Restart the target app and test again |
IEPL dedicated lines, relay routes, and direct connections describe how a route is organized and how traffic is carried. They don’t automatically change an app’s proxy settings or determine its account region. Switching route types may affect connection performance, but it won’t replace checking rules and traffic capture. For route details, see Global Nodes. For platform access requirements, check Streaming Support and the platform’s own decision.
Keep Reproducible Troubleshooting Notes
Change one variable at a time—for example, the selected node, traffic-capture mode, or DNS settings. Record what happened before and after, including the target domain, operating system and client versions, test time, exit IP, and matched rule. This makes it easier to distinguish configuration, routing, and platform-side issues, and helps you explain the situation to Support.
Bottom line: Follow the request path. Compare public IPs to see where a web request exits, check DNS to see whether resolution follows your policy, and review app connection logs to confirm which route the requests you care about actually took. When the results align, you can conclude that the setup is working as expected for that specific scenario—not that every app or platform is guaranteed to work.