When the client says “Connected”, it only means the local tunnel process is running — not that traffic actually leaves through the route. Confirming a VPN works follows a fixed order: exit IP and location first, then where DNS resolution happens, then a per-app check. Only when all three pass is that route genuinely usable on this device.
The order matters because troubleshooting has to isolate the cause. Test the app first and, when it fails, you can't tell whether the route isn't working, resolution went the wrong way, or the app itself has requirements about the exit region. Pin down exit and resolution first, and whatever remains is on the app side.
The Three Checks: Order and Pass Criteria
The table below covers all three steps. Each has an observable pass criterion; stop at the first row that fails, fix it, then move on.
| Step | What to check | Pass criteria | Typical failure |
|---|---|---|---|
| 1 | Exit IP and location | Country shown matches the selected route | Still shows your local country, or a country that doesn't match the route |
| 2 | DNS resolution path | Lookups are handled on the route side, not by your local ISP | The resolver is still a local ISP address |
| 3 | App-level connectivity | The app works continuously with no region-restriction errors | Pages open but features are limited, or verification is requested repeatedly |
Step 2 is the one people skip. After checking IP location they just start using it: pages load, but slowly, some assets fail, and logins trigger extra verification. That pattern usually comes from the resolution path, not from the route itself.
Change one variable at a time while testing: don't switch routes, edit split-tunneling rules and swap clients all at once. One change per round is what lets a pass or fail map back to a specific setting.
Step 1: Check the Exit IP and Location
The exit IP is the address target sites see, and the most direct evidence that traffic is going through the route. There are two ways to check it, for two different purposes.
GUI method: open a private window and visit any page that shows your visiting IP; it will display both the IP and its location. Use a private window to avoid cache and extensions — proxy settings in a browser extension override the system proxy the client writes, so a normal window may not show the route you think it does.
Command-line method: unaffected by browser proxy settings, which makes it the right tool for “the browser is routed but other programs aren't”.
# IP only — handy for scripted checks
curl -s https://api.ipify.org
# JSON when you also need location and ISP
curl -s https://ipinfo.io/jsonThere is exactly one pass criterion: the country in the location field matches the selected route. Don't insist on city-level accuracy — IP geolocation databases are imprecise, and datacenter addresses are routinely mapped to a neighbouring city or even a neighbouring country. In dense regions like Hong Kong, Tokyo or Singapore the city field is of limited value; go by the country field.
IPv6 is the usual leak
Most routes only take over IPv4 by default. If the machine also holds a usable IPv6 address and the target site supports IPv6, the browser will prefer the direct IPv6 path. The result: the IPv4 exit is overseas while the actual request leaves from your local connection. During the check, look at the IPv6 row — if it shows a local address block, IPv6 isn't going through the route. Either disable IPv6 in the client or switch to a mode that handles dual stack.
Note: reconnect after changing settings, then check again. Some systems rebuild the default route when the adapter state changes, and the old tunnel isn't necessarily still on it.
Step 2: Check for DNS Leaks
A DNS leak means traffic goes through the route while domain lookups still go to your local ISP's DNS servers. The tunnel takes over IP-layer traffic, but lookups may be sent before the tunnel is up, or handed to the local resolver by adapter priority.
Two consequences. First, results don't match the exit region: CDNs schedule by resolver location, so they return nodes near you rather than near the exit — pages open but load slowly, or some assets fail. Second, it looks anomalous: the target service sees an overseas exit IP together with a local resolver, which makes extra verification more likely.
| Platform | How to check | What to look for |
|---|---|---|
| Windows | Run ipconfig /all in Command Prompt |
Whether the “DNS Servers” line is a local ISP address |
| macOS | Run scutil --dns in Terminal |
The address nameserver[0] points to |
| Linux | Run resolvectl status in Terminal |
DNS and encrypted-resolution status on the current link |
| Browser | Search settings for “Secure DNS” | Whether it's on; when on, it skips system DNS |
Then confirm where lookups actually go: query a fixed domain with nslookup or dig; the Server line in the output is the resolver in use. If it still points at your local ISP, resolution isn't going through the route.
nslookup example.com
dig +short example.comBrowser Secure DNS skips the tunnel
Chrome, Edge and Firefox all ship “Secure DNS”, i.e. DNS over HTTPS. Once enabled, the browser does its own encrypted resolution and ignores system DNS settings. Even if the client has taken over system resolution, the browser's lookups may still go straight to its chosen resolver, out of step with the exit region. Turn it off while testing, confirm the route itself is fine, then decide whether to re-enable it.
Pass criteria: the system resolver shows a route-side address (or one consistent with the exit region), and nslookup no longer returns a local ISP address. Both, then move to step 3.
Step 3: Verify App by App
A healthy exit and clean resolution don't guarantee every app works. Different programs read proxy settings differently, so go through the ones you actually use.
- Browser: open the target site in a private window and confirm the page loads fully and you stay logged in. If you have extensions, use a private window first to rule them out.
- Desktop clients: some programs only read the system proxy, some only speak SOCKS, and some ignore the system proxy entirely and need TUN mode. The test is simple: quit the client — if the program still gets online as usual, it was never going through the proxy.
- Command-line tools: most only read environment variables.
curlneedshttp_proxyandhttps_proxy, or just use TUN mode so it's handled transparently. - Mobile: both iOS and Android reclaim connections in the background. After switching back, check the client status before opening the app; going straight in after a long spell in the background often means a dead tunnel.
- Services with strict region checks: these look at exit IP, resolver location and the account's historical region together. If the three disagree, the connection works and you're still blocked.
Passing means it works continuously for a while — no failed assets, no repeated verification prompts. Opening the homepage once doesn't count.
Common Cases Where It Says Connected but Isn't Routed
In each case below the client shows connected, yet traffic doesn't take the route as expected. Ordered by how often they come up.
- ❌ System proxy wasn't written. The client says connected, but the system proxy switch is off and the browser stays on the local network. Check whether the system proxy points at a loopback address plus port.
- ❌ Only TCP is captured and the browser uses QUIC. HTTP/3 runs over UDP 443; when the route only forwards TCP, the browser goes direct. Disable QUIC in the browser, or use a mode that captures UDP.
- ❌ Direct IPv6. See step 1 — when IPv6 isn't captured, the system prefers the local address.
- ❌ Split-tunneling rules classify the target domain as direct. Outdated rule sets and incomplete domain databases both send the target site out directly.
- ❌ Wrong multi-adapter priority. After installing a VM or adding a second adapter, the default route may leave through the other one.
- ❌ The tunnel dropped but the UI didn't refresh. After a failed heartbeat the client sometimes still shows connected; reconnect and look again.
- ✅ The reverse also holds: if all three steps pass and an app still doesn't work, the problem is that app's own region policy, not the route.
Split Tunneling: Why Some Sites Are Routed and Others Aren't
Clients usually offer three modes: global, rule (split), and direct. In global mode all traffic takes the route, which makes self-checks easiest to pass; rule mode decides by domain or IP ownership — flexible, but also the most likely to produce “some goes through, some doesn't”.
- Global: all traffic takes the route. Good for testing and temporary use; long term it wastes data and can slow local services.
- Rule: decided by rule sets — matches marked direct stay local, everything else takes the route. Rule sets need regular updates; stale ones misclassify.
- Direct: the same as off. Use it to confirm whether the route itself is the problem.
While troubleshooting, switch to global mode temporarily and check the exit IP again. Passes in global but fails in rule mode means the problem is in the rule set, not the route.
After the Checks Pass
All three passing means this route works on this device and this network. What's left is long-term behaviour: stability at peak hours, whether a long connection drops, and whether it recovers by itself when you move from Wi-Fi to a phone hotspot. There's no one-shot test for that — only real use over time.
If the checks keep failing, switch to another route and test again. Exit IPs blocked by the target service or routes taking a long way round aren't fixed by changing client settings. VPNEH currently covers 90+ countries and 190+ routes; monthly plans start at ¥9.9 and include 60GB. A full refund, no questions asked, can be requested within 14 days of your first payment, so you can try different routes while testing.