Check the scope of coverage, not just the connection icon
How can you tell if your VPN is actually working? Check your public IP first, then DNS, and finally the apps you want to use. A “Connected” status usually means only that a connection or traffic-capture component is active. It doesn’t prove that all traffic is using the VPN.
First, clarify what you want: should selected international websites use the proxy, or should most of your device’s internet traffic go through the tunnel? With rule-based routing, local sites can connect directly while international sites use the proxy. In that case, different sites showing different exit locations may be expected. Check the routing rules rather than expecting every test page to show the same location.
| Test | What it shows | What it doesn’t prove |
|---|---|---|
| Public IP | The address and network used by the current request | That other apps use the same route |
| DNS test | Which resolvers handled the test domain | Whether there’s a leak based only on the resolver’s location |
| Client connection logs | The matched rule, route, and error details for a request | That an app with no log entry definitely has no internet access |
| Test in the target app | Whether the app works and its requests use the expected exit | That account-region or permission restrictions have been lifted |
Compare before and after connecting
Don’t change all your settings at once. Save your current configuration and note whether the client is using rule-based routing, global proxy mode, or TUN mode. Turn off other proxy extensions and network clients that could override proxy settings. On a work-managed device, check your organization’s requirements first; don’t disable security software on your own.
- When direct internet access is available, disconnect from the VPN, open a trusted public IP checker, and note the address, network, and time.
- Connect to the route you want to test, then check again in the same browser. Make sure the page runs a fresh test rather than showing a cached result.
- Check which routing rule matches the test domain. If it’s set to connect directly, temporarily route that domain through the proxy and compare the results.
- Record the results, restore your original routing settings, then check DNS and the target app. Change one setting at a time to make the cause easier to pinpoint.
Importing a subscription successfully and routing traffic successfully are two different things. A subscription link provides nodes and related settings; the client must also support the protocols in the configuration and have the right traffic-capture mode enabled. Node names may be server labels, not proof of your exit IP. Don’t paste subscription links into unfamiliar test sites—they often contain access credentials.
Public IP: Check the address and the route
If a public IP checker shows your expected exit address after connecting, that’s direct evidence that this browser request used the route. Location labels are only a guide: IP databases can disagree, and city-level geolocation is especially imprecise. For a more reliable assessment, consider the address, network, and client logs together.
If the address hasn’t changed, check whether your browser has its own proxy extension, whether a direct-connection rule matches the test domain, and whether the system proxy is enabled. The old and new nodes may also share a public exit, so getting the same address after switching nodes doesn’t by itself mean the switch failed.
Check IPv4 and IPv6 separately, too. A test service may check only one, while your browser uses the other on different sites. If the client captures only some address families, the test page might use the proxy while other connections still go direct. Use a checker that distinguishes both address types, then review the client’s IPv6 routing and DNS settings.
A public IP check only confirms the connection to that test service. It’s normal for your computer’s local network address to stay the same; your router’s internal address isn’t the VPN exit.
DNS: Check the resolver path, not just its location
DNS translates domain names into addresses, and DNS lookups can take a different route from web traffic. A changed web exit doesn’t automatically mean DNS queries are going through the tunnel. If your setup is meant to route all relevant queries through the tunnel, queries still going to your local network’s resolver warrant a closer look.
A trusted DNS leak test typically triggers a lookup for a newly generated test domain, then shows which recursive resolvers handled it. Compare resolver names, networks, and changes before and after connecting, and check them against the client’s DNS settings. A resolver in your local region doesn’t necessarily mean there’s a leak, and one overseas doesn’t prove the query was protected by the tunnel. Public DNS, anycast networks, and database errors can all affect the results.
Your browser’s Secure DNS, the system’s encrypted DNS, and the client’s own DNS may all be active at once. With DoH enabled, DNS queries may use a separate HTTPS connection; its route still depends on proxy and routing rules. Encrypted DNS protects queries in transit, but encryption doesn’t tell you whether they used a specific route.
If the results aren’t what you expected, first check the DNS mode recommended by your client, then see whether the browser overrides system settings. Clear the DNS cache or restart the relevant apps before testing again, so old records don’t interfere. Don’t change resolver addresses just to make the test page show a matching flag, and don’t leave DNS protections disabled to hide a problem.
App-by-app checks: a working browser doesn’t mean every device connection is covered
A system proxy gives proxy settings to apps that support it; it doesn’t force every network connection on the device through the proxy. Some command-line tools, games, updaters, and built-in app components may not use the system proxy or may need separate configuration. If the browser test passes, you’ve only confirmed the browser’s route so far.
TUN mode uses a virtual network adapter and routing to capture IP traffic. It usually covers more traffic, but routes can still be excluded, and app-specific rules, protocol support, and permissions matter. “Global proxy” may simply route all requests that reach the proxy core through a selected proxy—it doesn’t necessarily capture all device traffic.
On Windows and macOS, check the system proxy, network extensions, or virtual adapter permissions separately. On mobile devices, check network-capture permissions and any app-bypass rules in the client. Options vary between clients, so a toggle’s name alone doesn’t tell you what it covers. For setup and permissions, see our setup guide.
- ✅ Browser: Open a fresh page and check the exit. Also check for proxy extensions and separate Secure DNS settings.
- ✅ Target app: Quit it completely, reopen it, and trigger a real network request. Then look for the relevant domain or process in the client’s connection logs.
- ✅ Command-line tool: Check whether it uses the system proxy or needs its own supported proxy options and environment variables.
- ✅ Rule matching: Check whether the request matches a proxy, direct, or reject rule, and confirm the selected exit is right for your needs.
- ❌ Don’t assume all device traffic is routed through the VPN just because a website opens, an account signs in, or the client icon is lit.
When reviewing logs, match up the domain, process, and timestamp. DNS lookups, background heartbeats, and actual app requests may use different connections; missing entries may also be due to the logging level or an existing long-lived connection. Before sharing logs with support, remove subscription credentials, account identifiers, and unrelated browsing records.
Why a connection can look active when traffic isn’t routed through it
Existing connections keep using their original route
Apps may reuse connection pools, background sessions, or already established connections. After changing the exit, fully quit and reopen the target app, then trigger a new request. Opening a new browser tab doesn’t necessarily create a new connection; check the latest test results and logs as well.
A routing rule sends the request directly
A website may use separate domains for its main page, assets, login, and media. Changing only the rule for the main site may leave other requests on a different route. Check related requests one by one in the logs. If temporarily routing everything through the proxy fixes the issue, return to rule-based routing and update the relevant rules; there’s no need to proxy unrelated traffic long-term.
Protocol support or UDP capture is incomplete
The node protocol and traffic-capture mode solve different problems. The client needs to support the relevant configuration for Shadowsocks, VMess, Trojan, VLESS, and other protocols. Hysteria2 and TUIC also rely on UDP. A successful node test doesn’t mean every app’s UDP requests are being forwarded; check the client, exit capabilities, and local network restrictions.
A platform restriction is mistaken for a routing problem
If the exit is as expected but a platform still doesn’t work, the cause may be the account region, app cache, exit reputation, or the platform’s access rules. IEPL dedicated lines, transit, and direct connections describe transport paths; they don’t replace an exit check or guarantee that an app will work. Don’t assume an account is supported based on repeated location changes.
How to reach a conclusion you can verify later
Keep records of the exit before and after connecting, DNS results, traffic-capture mode, and target-app logs. Make your conclusion specific—for example, “The browser request to the test domain used the expected exit, and the target app matched a proxy rule”—rather than simply writing “VPN works.” This reduces false assumptions and makes it easier to spot changes in your setup later.
How to assess the results: You can confirm the tested use case is working only when the exit matches expectations, the DNS route matches your configuration, and new requests from the target app use the correct exit. If any check fails, troubleshoot that layer before changing settings. Passing these tests is not an absolute guarantee of anonymity or security.
For more troubleshooting help, visit our Help Center or contact support through the user panel. Include your device platform, client name, traffic-capture mode, symptoms, and checks already completed; that’s more helpful than a screenshot showing only “Connected.”