VPN Connected but Not Working? How to Verify IP and DNS

The client shows “Connected”, yet the site you want in the browser still won't load; or the page loads, but an exit address lookup still reports your local carrier's location. Cases like these come up constantly in troubleshooting logs, and most of the time it isn't a route failure — the traffic simply never entered the tunnel. To tell whether a VPN is really working, don't trust the connection status in the UI. Look at two verifiable signals: whether the exit IP changed, and whether DNS resolution changed with it.

This guide lays out a three-step check — exit IP, DNS leaks and per-app comparison tests — and breaks down six typical “looks connected but isn't routed” cases with the fix for each. The whole process covers Windows, macOS, iOS, Android and Linux, needs no extra diagnostic tools, and uses only browser pages and built-in system commands.

2 Must-check: exit IP and DNS resolver location

3 Verification steps: check IP → check DNS → per-app comparison

1 Pass/fail rule: the exit address must change

Why “connected” doesn't mean working

The connection status in the client only means the handshake between the client process and the route entry point succeeded. It doesn't guarantee that traffic from other programs on the system will use that tunnel. What really decides whether it's “working” is the capture layer: how the client steers traffic into the tunnel, and whether DNS and IPv6 are captured along with it.

Capture layers: extension, system proxy and TUN

Capture method	Coverage	Typical failure symptom
Browser extension / single-app proxy	Browsers with the extension installed, or apps configured with their own proxy	Other software still reports a local exit IP
System proxy (PAC / manual settings)	HTTP(S) apps that read system proxy settings	Command-line tools, UDP apps and some desktop software bypass it entirely
TUN / virtual adapter capture	System-level routing, usually covering IPv4 and IPv6 together	A split-tunnel rule matches “direct”; IPv6 goes local when it isn't captured

None of the three is strictly better. A system proxy is light to deploy and barely touches the system, but its coverage is narrow — it only works for apps that read system proxy settings. TUN capture covers far more, at the cost of needing higher privileges: a virtual adapter driver on Windows, and an authorised network extension or equivalent permissions on macOS and Linux. If your goal is to route every program, first make sure the client is in TUN / global capture mode rather than system proxy mode.

DNS is the other layer that often gets overlooked. Even when traffic is inside the tunnel, resolution requests can still go to the resolver handed out by the local network, returning results that are geo-steered or substituted — which shows up as “connected, but the domain won't load, or it loads the version for another region”. That's why verification has to look at IP and DNS together; neither alone is enough.

Step 1: check the exit IP to see whether traffic is leaving through the route

The goal here is simple: capture the exit address before and after connecting, then compare them. Work through the steps below in order and you'll usually have your answer.

Disconnect the client and take a baseline reading: note the exit IP, its location and the carrier (ASN).
Connect the client and confirm which route and which region you're on.
Run the same lookup service again and compare whether the IP and location changed.
Check the IPv6 exit separately. IPv6 is easy to overlook and is where “connected but not routed” happens most often.
Repeat the test with a different lookup service to rule out a false reading from page caching.

The lookup service itself can be affected by CDN: some sites sit behind a CDN and report the location of the CDN node rather than your real exit. If the IP changed but the location looks wrong, try another lookup service, or judge by the ASN field instead.

# Current exit IPv4
curl -4 -s https://api.ipify.org

# Current exit IPv6 (no output usually means this machine has no IPv6 exit)
curl -6 -s https://api.ipify.org

# Lookup with location and ASN
curl -s https://ipinfo.io/json

✅ The exit IP differs before and after connecting, and its location matches the route's region
✅ The IPv4 result points to the route exit; with no IPv6 on the machine, the IPv6 lookup returns nothing
✅ A second lookup service on the same device returns the same result
❌ The UI says connected, but the exit IP is identical to the disconnected state: traffic isn't being captured
❌ The browser shows a new exit, but command-line tools still report a local address: you're in system proxy or single-app proxy mode
❌ The IPv6 lookup returns your local carrier's address: IPv6 traffic is skipping the tunnel

There's only one rule that matters: the exit IP has to change before traffic is really taking the route. The connection status, live speed and latency readouts in the client are no substitute for this step.

Step 2: check for DNS leaks and confirm resolution takes the route too

DNS lookups happen before a connection is established. If resolution requests go to the resolver handed out by the local network, then even when the traffic that follows uses the tunnel you can still get geo-steered or substituted results — showing up as “connected but won't load”, “loads the wrong regional version” or “fast one minute, slow the next”. This is what's usually called a DNS leak. It has nothing to do with route quality; it's a question of what the client captures.

How to read a DNS leak test result

The test page lists the resolver IP, location and carrier used for the lookup. How to judge it: the resolver's location should match the route exit, or at least belong to the same provider network. If it shows the name of your local broadband or mobile carrier, that's a leak; if the resolver address sits in the same subnet or ASN as the exit IP, it's normal.

A browser's built-in encrypted DNS (DNS over HTTPS) overrides the system DNS settings, so the test page may show the browser's own resolver. That isn't a leak, but it does skip the resolution policy on the route side; when troubleshooting, turn off “Secure DNS” in the browser first, then test again.

Fixes, in order of priority:

Turn on DNS capture in the client (some clients call it DNS hijack or DNS proxy) so resolution requests go through the tunnel.
Switch to the resolver address pushed by the route side instead of the local one handed out by your router.
Check whether the browser has encrypted DNS enabled. It overrides system DNS settings, so turn it off before testing.
If IPv6 is enabled on the router, make sure IPv6 DNS is captured too — otherwise lookups can leak out over the IPv6 path.

# Windows: show the DNS servers the system is using
ipconfig /all

# macOS: show the system resolver configuration
scutil --dns

# Linux: show the current resolver configuration
cat /etc/resolv.conf

# The returned address is the resolver's exit; compare it with your exit IP
nslookup whoami.akamai.net

Step 3: per-app and per-scenario comparison tests

Even with the exit IP and DNS both correct, an individual app may still not use the route. The goal here is to pin down which app isn't routing, instead of blaming the route in general.

Browser: visit the target site in a private window or after clearing the cache once, and note the result.
Command line: check the exit IP with curl and compare it with the browser result. Command-line tools don't read the system proxy by default, so you need to set the http_proxy / https_proxy environment variables explicitly, or rely on TUN capture.
Desktop apps: in the client's per-app proxy list, confirm the app is marked to use the route; software that relies mainly on UDP is usually not proxied in system proxy mode.
Mobile: on Android, confirm the VPN permission is granted and the client is on the battery-saver allowlist; on iOS, confirm the VPN profile is connected and hasn't been dropped early by an on-demand rule.
Cross-check: repeat the test on another device signed in to the same account. VPNDX allows unlimited simultaneous devices, so testing from a second device needs no extra steps.

Platform-by-platform checks

Windows: before troubleshooting, check whether “Settings → Network & Internet → Proxy” has been switched back to automatic configuration by other software; some apps use the WinHTTP proxy, which you can check separately with netsh winhttp show proxy. TUN mode depends on a virtual adapter driver, and security software blocking that driver will break capture.
macOS: some apps don't read the system proxy; use scutil --dns to see the system resolvers and networksetup -getwebproxy Wi-Fi to see the current proxy entries. Capturing via a network extension requires authorisation in System Settings.
iOS: the system VPN profile handles capture for everything, so per-app settings usually aren't needed; Low Power Mode limits background refresh, so after a long spell in the background, bring the client back up and confirm its status.
Android: per-app proxying is a system-level feature — you can pick which apps use the route in the system VPN settings or inside the client; battery-saving policies may kill the client process, leaving it looking connected when the tunnel is actually down.
Linux: creating a TUN device needs root or equivalent permissions; command-line tools don't read the system proxy by default, so either set the environment variables or use TUN.

Don't change several settings at once while troubleshooting. Change one thing at a time: switch the capture mode first, then touch DNS, then look at the per-app list. Otherwise, even if the problem disappears, you won't know which change fixed it — and next time it comes back you'll be starting over.

Six typical “connected but not routed” cases and their fixes

Match the results of the three steps above against the table below and you can usually pin down the cause directly.

Symptom	Likely cause	Fix
Exit IP is exactly the same as when disconnected	The client is in system proxy mode and this software doesn't read the system proxy	Switch to TUN / global capture mode, or enter the proxy address inside the app itself
The browser exit changed, the command line didn't	Only the browser reads the system proxy	Same as above; decide whether you need global capture instead of configuring apps one by one
IPv4 uses the route, IPv6 is still local	The client isn't capturing IPv6 routes	Enable IPv6 capture in the client, or turn IPv6 off in the client / on the router
Exit IP is fine, but domains won't load or resolve oddly	DNS is still handled by the local resolver	Turn on DNS capture in the client and check the browser's encrypted DNS setting
One particular app doesn't use the route	The per-app proxy list doesn't mark that app as routed	Add the app to the routed list, or switch to global capture mode
It stops working after switching to another network	Routes and proxy settings weren't rebuilt after the network change	Disconnect and reconnect the client; if needed, restart the client process and test again

Four of the six cases share a single fix: move the capture layer from system proxy to TUN and make sure DNS and IPv6 are captured along with it. The other two come down to missed configuration — check each item in turn.

When you need to re-verify

The three-step check isn't a one-off. After any of the moments below, the capture state may have changed, so it's worth running through it again.

After changing networks: moving from home broadband to an office network, or from Wi-Fi to a mobile hotspot, rebuilds routes and proxy settings.
After switching routes or route regions: split-tunnel rules and resolvers can change with the route.
After a major client or OS update: network extension permissions and system proxy settings can both be reset.
After a router restart or replacement: the handed-out DNS addresses and IPv6 prefix both change.
When pages load slowly or individual sites won't open: run the check first, then decide whether the problem is on the route side.

Once the three steps pass, write down the exit IP and resolver address as a baseline. Next time something won't load, comparing those two values tells you immediately whether local capture has failed or something changed on the route side.

Bookmark an exit IP lookup page — the three steps usually take under two minutes. Most “route failures” can be classified right here: either local capture isn't working, or the route side really is having problems. VPNDX offers 120+ countries / 220+ routes, covering IEPL dedicated and relay lines as well as direct connections, with unlimited simultaneous devices. Clients cover Windows, macOS, iOS, Android and Linux, using military-grade encryption. No email address is required, payment is supported via Alipay, WeChat and USDT, and there's a 30-day no-questions-asked refund. The site's routes page shows live route status — compare it with your local results to tell faster which end the problem is on.

Verify locally before blaming the route. Only when the exit IP, DNS resolver and per-app checks all pass is traffic really taking the route; if any one fails, the problem is in local capture, and switching routes won't fix it.