Is Your VPN Connected? Three-Step Check of Egress IP, DNS and Per-App Routing

“The client says Connected but pages won't load” and “the client says Connected but traffic isn't using the route” are two different problems. A client icon tells you nothing on its own: it only means the local app and the node completed a handshake, not that every request enters the tunnel. The three checks below — egress IP, DNS ownership and per-app testing — each give an answer on their own, and they confirm one another.

You don't need extra tools: a browser plus the client is enough. Keep the order fixed — first confirm the egress address changed, then that domain resolution changed with it, and finally that the app you care about really uses the route.

• 3 steps Egress IP / DNS ownership / per-app — each gives its own verdict
• 120+ Countries and regions with route coverage
• 240+ IEPL dedicated and relay routes to choose from
• 7 days No-questions-asked refund

Why “Connected” Doesn’t Mean Traffic Uses the Route

“Connected” in the client means the local app and the node completed a handshake: session established, authentication passed, keys negotiated. It does not guarantee that every request on the system enters that tunnel. Whether traffic really uses the route depends on the client's working mode, the routing rules, and each app's own network settings.

Working mode sets the coverage

TUN (virtual adapter) mode creates a virtual adapter and takes over the system routing table: TCP and UDP go into the tunnel by default, and only traffic allowed by a routing rule goes direct. System proxy mode only changes the system proxy settings: apps that honour those settings use the route, while software with its own network stack that ignores the system proxy connects out directly. Same client, same route — completely different coverage.

Routing rules define the exceptions

Split routing isn't a fault; it's the design goal: domains and IP ranges in mainland China go direct by default, so local services don't take a detour. The risk is misclassification — a target domain lands on the direct side and the result looks like “connected but not routed”. Rule sets go stale over time, and stale rule sets mean more misclassifications.

Interference from apps and caches

Browsers can have their own proxy settings, and extensions can take over requests; with secure DNS enabled, resolution may bypass the system settings entirely. After you switch routes, long-lived connections (HTTP/2, HTTP/3 sessions) may still follow the old path. Restart the browser after switching, then flush the DNS cache at system level:

# Windows
ipconfig /flushdns

# macOS
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

# Linux（systemd-resolved）
sudo resolvectl flush-caches

Egress IP check: test before and after connecting

The egress IP is the address the outside world sees, and it's the easiest of the three to reproduce: check it before and after connecting and compare. Pick a test page that shows both the IP's location and the ISP — the more detail it gives, the easier the call.

1. Disconnect the client, open the test page and note three things: egress IP, country / region, and ISP or ASN.
2. Connect the client and pick a route. With a Japan or Singapore route, for example, the test page should show an address in that region.
3. Hard-refresh the test page — don't rely on a cached copy — and compare: did the IP change, and does its location match the route you picked?
4. Look at the IPv6 field on its own: if it still shows an IPv6 address belonging to your local ISP, the tunnel only took over IPv4, and sites that also publish AAAA records will go out over IPv6.
5. If you're only testing in a browser, check WebRTC once more: it can expose your local or real public address, and it's a separate path from the egress IP.

Check	Expected	Needs attention
IPv4 egress	Shows an address in the route's country / region, different from before connecting	Identical to before connecting, or still located locally
IPv6 egress	No IPv6 address, or one on the route side	Shows an IPv6 address from your local ISP
WebRTC	Only tunnel-side or route-side addresses appear	A LAN address or your real public address appears
ISP / ASN	Shows the data centre or ISP on the route side	Still your local broadband ISP

If the test page lists an IPv6 address and the client isn't handling IPv6, the simplest fix is to turn off IPv6 forwarding in the client so domains fall back to the IPv4 path. The trade-off is that IPv6-only sites become unreachable, which you'll rarely notice in daily use.

DNS ownership check: where does resolution happen

The egress IP only answers “where does my data leave from”, not “which domains did I look up”. The resolution path decides who can see the list of sites you visit, so DNS gets a step of its own.

Two resolution paths

In-tunnel resolution: the client sends DNS queries into the tunnel and the resolver on the node side answers; in Fake-IP mode the domain is first mapped to a virtual address locally (typically a reserved range such as 198.18.0.0/15), the real lookup happens on the node side, and the connection is made by domain name. Local resolution: the app queries the router or the ISP resolver directly and only then decides which path to take. In that case, even if page traffic enters the tunnel, the list of domains stays on the local network — this is what's usually called a DNS leak.

How to test

1. Open a DNS leak test page; it lists the resolver addresses and locations that answered your queries.
2. After connecting, refresh it a few times so the page issues queries for several different domains.
3. Look at the resolver list: normally only node-side resolvers should appear; if local ISP resolvers and your city show up, those queries went out locally.

Browser secure DNS is a common culprit

Chrome, Edge and Firefox all offer a secure DNS (DoH) switch; once it's on, the browser sends encrypted queries straight to the DoH provider. In TUN mode those queries still enter the tunnel — only the resolver changes to the DoH provider; in system proxy mode they may bypass the tunnel entirely and go out directly. When troubleshooting, turn the switch off first, or confirm that it goes through the tunnel.

Fixes

• Enable DNS takeover (DNS hijacking) in the client so queries to port 53 are redirected to the resolver inside the tunnel.
• Turn off the browser's secure DNS, or point it at the resolver inside the tunnel.
• Don't run two proxy tools at once — they fight over the routing table and DNS settings.

Per-App and Split-Tunnel Rule Tests

The first two steps test the system level; the third tests the app level. Per-app proxy lets you choose which apps use the route, and routing rules decide which domains use it — both can make the same IP test page give different answers.

How to verify per-app proxy

1. On the same device, use two different apps to open the same page that shows your egress IP.
2. One app is proxied (usually the browser), the other is not.
3. The first should show a route-side egress IP, the second should still show your local address. If both match expectations, per-app settings are working.
4. If both show the same address, go back and check the client's app list: desktop systems match by process name, mobile systems by app package name, and reinstalling or renaming an app means you have to select it again.

How routing rules are matched

Rules are matched one by one from the top and stop at the first hit, so the order is part of the configuration. Common types:

Rule type	Matches	Typical use
DOMIN	Full domain	Route or proxy a single domain precisely
DOMAIN-SUFFIX	Domain suffix	Cover a site and all of its subdomains
DOMAIN-KEYWORD	Keyword in the domain	Match many similar sites at once
IP-CIDR	IP range	Split traffic by address range
GEOIP	IP country / region	Direct for mainland China, routed for overseas
RULE-SET	External rule set	Reference a continuously maintained rule list
MATCH	All remaining traffic	Catch-all rule, placed last

The most direct way to check that routing behaves as intended is the connection log: most clients show a live connection list, and each entry states which rule it hit and whether it went through the proxy or direct. If the target domain shows DIRECT, a rule allowed it — that's not a route failure. Rule sets carry an update date, and a stale set will misjudge new domains; updating the subscription and rule set in the client is the quickest fix.

Common cases where it looks connected but isn't

These are the symptoms that come up most often in troubleshooting — read across the symptom, cause and fix columns.

Symptom	Likely cause	Fix
Client shows Connected, browser still uses the local IP	The browser uses its own proxy settings, or an extension took over requests	Disable browser proxy extensions and let the client handle everything
Some sites won't load while others work	The target domain hits a direct or REJECT rule; the rule set is out of date	Check the rule hit in the connection log and update the subscription and rule set
IPv4 switched, IPv6 still local	The tunnel doesn't handle IPv6, and the local network offers IPv6	Turn off IPv6 forwarding in the client, or let the tunnel handle IPv6
A local DNS resolver appears on the test page	Browser secure DNS connects directly, or local resolution in system proxy mode	Enable DNS takeover and turn off browser secure DNS
Connection succeeds but every request times out	Node egress problems, MTU and fragmentation issues, UDP blocked	Switch routes, change protocol (TCP / QUIC), adjust MTU
Old IP still shown after switching routes	Long-lived connection reuse and DNS caching	Flush the DNS cache, restart the browser, disconnect and reconnect

One more thing to keep separate: verification only tells you that traffic uses the route, not how good the route is. The route type decides stability — a direct route connects from the client straight to an overseas node over the public internet the whole way, so it's prone to congestion at peak hours; a relay route connects to a nearby entry point first and forwards to the exit, which makes the path more predictable, though the second half still depends on the public internet; an IEPL dedicated line runs on a private channel and never touches the public internet, so jitter and packet loss are lower. If all three checks pass and speed is still poor, the problem is route selection, not verification.

Troubleshooting Checklist and Pass Criteria

Here are the three steps condensed into a checklist — go through it item by item:

• ✅ Egress IP matches the location of the route you picked, and differs from before connecting
• ✅ No local ISP IPv6 address appears on the test page
• ✅ The resolver for proxied domains sits on the node side, with no local resolver mixed in
• ✅ The connection log shows the target domain hitting a proxy rule, not DIRECT
• ✅ Apps excluded from the proxy really do show a local address, so per-app settings are working
• ❌ The test page still shows your local broadband address after flushing caches and restarting the browser
• ❌ Both a local ISP and your city appear in the resolver list
• ❌ Every target domain in the connection log hits DIRECT or REJECT

FAQ