Is Your VPN Working? Check the Connection and App Traffic Separately
If your VPN connects but doesn't seem to work, start by checking your public IP and DNS, then test the app you're having trouble with. A connection indicator is only the first step: a working browser connection doesn't prove that other apps are using the same route.
Troubleshooting means checking several layers: whether the client can reach a server, whether the operating system sends traffic to the client, whether routing rules select the proxy, and what public address a site ultimately sees. In some clients, “Connected” only means the proxy core is running or a configuration is enabled—not that every request has reached a remote server.
First, define what “working” means for your setup. Do you want international sites to open in a browser, or should desktop apps use the same route too? Rule-based modes often send some requests directly. A local site using your regular connection may be expected; what matters is whether the request follows the rule you intended.
What the results tell you: Your public IP is evidence of the request route, DNS results offer clues about where domain lookups are handled, and the target app's connection logs show how that app is routed. Comparing all three is more useful than repeatedly clicking Connect.
Exit IP check: Compare before and after connecting
Your public IP is the address a test site sees for your request—not your device's private address on your home network. Start with our network check page and note the result. Then connect with your client and run the same check in the same browser. Don't rely on the flag shown beside an address alone.
- Pause other proxy tools and browser extensions, disconnect your current client, and note your local network's public IP and location details. On a managed work device, check your organization's policies first; don't disable a company connection without authorization.
- Select the route you want in the client and make sure system proxy or virtual network adapter routing is enabled. Selecting a server alone may not change how your system sends requests.
- Close the original test tab, reopen the test page, and check again. If needed, clear the site's cache so you don't mistake an old result for a new one.
- See whether the address changed, then check the client's connection log for the destination domain, matched rule, and route. The test site itself may be set to connect directly.
A changed address means this test request used a different route; it doesn't prove that all traffic is being routed through the client. If the address is unchanged, check whether the test site is set to connect directly, the browser is bypassing the system proxy, or proxy settings are disabled. You can briefly switch to global proxy mode and test again, then restore your original rules.
If the test page shows separate IPv4 and IPv6 results, check both. Some configurations route only one address family, while an app may prefer the other. Check the client's IPv6 routing and DNS support first; disabling IPv6 isn't a suitable long-term fix for every device.
DNS check: DNS resolution location isn't your traffic exit
DNS translates domain names into addresses; the app then connects to the destination. These paths can differ: web traffic may use a proxy while DNS queries still go through your local network. A browser may also use secure DNS while other apps continue to use the system resolver.
A DNS leak generally means domain lookups that should follow an expected route are instead sent through your local network to an unintended resolver. Use a trusted DNS test, note the resolver details before and after connecting, and compare them with your client's DNS settings. A basic IP lookup page can't tell you where DNS queries are going unless it explicitly offers a DNS test.
DNS tests often use different test domains to identify recursive resolvers. An address in the results may belong to the resolver's exit point, not the address your device connects to directly. Public DNS services may also use anycast, so a resolver's location differing from your server's location doesn't automatically indicate a leak.
- ✅ Check whether DNS handling is enabled in your client, and which resolution method is used for proxied and direct domains.
- ✅ Check your browser's secure DNS settings to see whether it uses a resolver independent of the system.
- ✅ After changing settings, restart the relevant apps and, if needed, clear the system DNS cache before testing the domain again.
- ❌ Don't assume that seeing a public resolver means you have a leak, or treat one successful test as a lasting guarantee for every app.
Encrypted DNS in a browser can reduce exposure of DNS queries along its own connection path, but it doesn't automatically route web traffic through a VPN. Likewise, a changed web exit address doesn't mean DNS is being routed through the client. Check each separately.
Test apps individually: system proxy vs. virtual network adapter
A system proxy makes proxy settings available to apps, but whether an app uses them depends on its implementation. Virtual network adapter mode typically routes more IP traffic, but can still be affected by exclusions, permissions, address families, and the client itself. Global proxy mode is a rule-selection strategy; it doesn't necessarily route every app at the system level.
| Method | Typical coverage | What to check |
|---|---|---|
| System proxy | Apps that follow the system proxy settings | Whether the system setting is enabled and the target app reads it |
| Browser proxy extension | Requests in that browser that match the extension's rules | Whether the extension rules or browser settings override the client configuration |
| Virtual network adapter mode | IP traffic captured by routing rules | Whether the adapter is running and whether routes are excluded or permissions are missing |
| App-configured proxy | Connections the app supports and has configured to use a proxy | Whether the proxy address and type match what the app supports |
To test a desktop app, quit and restart it, then perform a clear network action, such as refreshing content or opening a remote file. Check the client's connection log at the same time: does it show requests from the app, which rule matched, and whether the traffic went direct or through the selected route? No log entry only means no request has been observed yet; it doesn't prove the app is offline.
On Windows and macOS, the system proxy may not cover command-line tools or apps that manage their own networking. On Linux, desktop proxy settings may differ from the environment variables an app reads. iOS and Android often route traffic through a system VPN interface, but coverage still depends on client settings and OS restrictions. Follow the instructions for your client and platform rather than relying on screenshots from another setup.
Connected but not routed: common causes and what to check
Subscription imported, but traffic routing isn't enabled
A subscription link provides server and routing-rule settings; importing it successfully doesn't mean the tunnel is working. Confirm that the active configuration is selected, the server is still listed, the client supports its protocol, and system proxy or virtual network adapter routing is enabled. A protocol defines how data is transmitted; it doesn't automatically choose a route for every app.
A subscription URL may contain account credentials. Don't paste it into public test sites or share it in screenshots. If you need help, submit a log with sensitive details removed through the support panel.
Rules send traffic direct, or multiple tools override one another
Some domains are configured to connect directly, while requests that don't match a rule may use the default route. Check the matched rule first, then adjust the policy for the destination domain. Multiple proxy clients, browser extensions, or company connections running at once can change system settings or routes. Decide which tool should handle traffic and rule out conflicts one at a time.
Browser works, but the target platform reports the wrong region
A platform may use account region, billing details, location permissions, session cache, and exit IP to determine your location, or it may restrict certain exit addresses. First confirm that the request is using the intended route, then check the platform's own requirements. Trying a different route can help with comparison, but a changed IP doesn't guarantee access to a particular regional catalog.
Wrap up: keep the evidence and isolate the route issue
Check in this order: local network access → client routing → test request's exit IP → DNS path → target app's rules. Change one setting at a time and note the results before and after. Changing the server, DNS, and mode all at once makes it hard to tell what fixed—or caused—the issue.
If the exit address and routing rules look right but the target app still fails, investigate server reachability, platform restrictions, or an app-side error. IEPL, relay, and direct connections describe how network paths are arranged; they don't replace testing in the app or guarantee ongoing access to any platform.
When contacting support, include your device platform, client name, selected configuration, network conditions, and the checks you've already tried. A specific report like “the browser's exit IP changed, but the desktop app's log still shows a direct connection” is more helpful than “it connects but doesn't work.” See Quick Start for setup instructions and the Streaming Guide for choosing a region.