Is Your VPN Working? Three Ways to Verify Exit IP and DNS

A status light in the client tells you nothing about whether the VPN is really working. It only means the proxy process is running — not that the site you’re visiting actually goes through the route. There are just three results worth checking: whether the exit IP has moved to the route’s location, whether DNS lookups follow the route, and whether the specific app really uses the proxy.

The three sections below take each check in turn, with steps you can run yourself, and close with a checklist you can reuse after changing routes, devices, or networks.

Method 1: confirm the exit IP matches the region you picked

Your exit IP is the source address that external websites see. Once you connect to a route it should become an address in that route’s location; if it’s still a local address, your traffic never went through the route, and talking about speed or stability is pointless.

1. Disconnect first and note your current exit IP and its location as a baseline.
2. Pick a route in the target region in the client and connect, then wait for the client to report success.
3. Reopen the test page in a private window so browser cache doesn’t hand back a pre-connection result.
4. Compare the exit IP and its location with the route you selected; on cross-region routes the registered location may differ slightly from the node city.

The network test page on this site shows your exit IP and its location directly, with no extra tools to install.

When a command-line check makes more sense

Outside the browser there’s no cache to skew the result, which makes the command line good for a one-off check:

# Show the current exit IP
curl -s https://ifconfig.me

# Show the location of the exit IP
curl -s https://ipinfo.io/json

On Windows you can run the same commands in PowerShell. If the command line still returns a local address while the browser shows the route’s location, the shell isn’t using the system proxy — switch to TUN mode or set the proxy environment variables yourself, which Method 3 covers in more detail.

Three common misreads

• Geolocation databases lag: newly allocated or reassigned address blocks may be listed in a neighbouring region, so don’t draw conclusions from a single database.
• Cache interference: browser cache and the system DNS cache can both return pre-connection results; a private window rules out most of it.
• Multiple exits: one region may have several exit addresses, so results that change between refreshes are normal — no need to reconnect over and over.

Method 2: check DNS to make sure lookups aren’t resolving locally

DNS decides which address a domain name resolves to. If lookups still go to your local ISP, the answers come back based on your local position even when page traffic goes through the route: cross-border sites may be steered to a node closer to you, region locks still apply, and your queries stay visible to the local resolver. This is what people call a DNS leak.

How to read the resolver list

DNS leak testers list the resolver addresses that actually received your queries and the networks they belong to. Run the test again after connecting and read it like this:

The command line also shows which resolver your machine is using: in the output of nslookup example.com, the Server line is the address that actually answered. If it’s your local router or ISP address, lookups aren’t going through the route.

fake-ip versus remote DNS

Some clients default to fake-ip mode: what you see locally is a virtual address and the real lookup happens remotely. In that case an address returned by a local command doesn’t mean a leak — the resolver list on the leak test page is still the thing to judge by, not the IP your machine hands back. In remote DNS mode the queries leave from the route’s exit, and the answers sit closer to the route’s location too.

Method 3: test per app to confirm your actual use case goes through the proxy

Modern clients generally offer routing rules: by domain, by region, or by app, deciding which traffic goes through the route and which connects directly. With rules on, “Connected” only means the proxy process is running — it doesn’t mean the app you’re using goes through the route.

Check each scenario in turn

Traffic capture differs by platform

• Windows: the system proxy only affects programs that read system settings; enable TUN to cover the command line and other apps.
• macOS: traffic is captured through a system network extension, and the first time you enable it you have to allow the extension in System Settings.
• Android: built on the system VPN service, so it captures everything by default once enabled; routing details come from the client’s internal rules.
• iOS: also works through a system network extension and only captures traffic after you complete the configuration prompt.
• Linux: most clients don’t change the system proxy automatically; configure TUN by hand or set proxy environment variables for the terminal.

To set a proxy temporarily from the command line, use the following — take the port number from what the client actually shows:

export https_proxy=http://127.0.0.1:7890
export http_proxy=http://127.0.0.1:7890
curl -s https://ifconfig.me

Routing rules decide whether traffic goes through at all

Rule mode matches on domain suffix, GeoIP region, and process name; a domain that matches a direct rule never touches the route. When testing a specific site, switch to global mode temporarily and retest: if it works in global but not in rule mode, the rules are the problem, not the route. If it fails in global mode too, go back to Methods 1 and 2.

Cases that look connected but aren’t routed

These symptoms come up most often in troubleshooting; check them first, then decide whether to change configuration or change route.

The clock skew item is the easiest to overlook: protocols like VMess are sensitive to the time difference between client and server, and a large gap makes the handshake fail outright — which looks like “connected but immediately dropped” and seems like a route problem, when syncing the system clock fixes it.

Protocol and route type affect how you read results, not the method

The checks stay the same, but different protocols and routes fail in different ways — “won’t connect” versus “connects but unstable” — and knowing the difference saves time.

• Shadowsocks: a lightweight SOCKS5-based proxy; UDP needs relaying enabled on the server, so voice and game apps that rely on UDP show up as “web works, calls don’t”.
• VMess: sensitive to time sync; handshake failures usually trace back to the system clock or the client version.
• VLESS: no built-in encryption, it relies on outer TLS; a misconfiguration shows up as connecting but transferring nothing.
• Trojan: carried over TLS; if the certificate and domain don’t match, the handshake fails outright.
• Hysteria2 / TUIC: QUIC-based and entirely UDP; where UDP is blocked they fail to connect at all rather than running slowly.

Route type matters too: IEPL dedicated lines carry the cross-border segment on a private circuit rather than the public internet exit, so peak-hour stability is usually better; relay routes are an entry point in mainland China plus a cross-border segment, and how they perform depends on the relay; direct routes connect straight to overseas nodes and are the most exposed to congestion at the international gateway. All three connect fine — the difference shows up at peak times and on long-lived connections.

A checklist you can reuse

Here are the methods above compressed into a checklist — run through it after changing routes, devices, or networks.

• ✅ Check the exit IP before and after connecting, and note how the location changes
• ✅ Retest in a private window to rule out browser and DNS cache
• ✅ Check the resolver list and confirm no local ISP address appears
• ✅ Test at least one real target app instead of watching the status light
• ✅ Verify once from the command line, enabling TUN if needed
• ✅ Note the symptoms when it fails, so you can tell rules, DNS, and node problems apart
• ❌ Treating “one homepage loads” as proof it works
• ❌ Judging route quality in rule mode

If all three checks pass and the target app still underperforms, the problem is usually the route rather than your configuration: retest on another route in the same region, or switch to a dedicated line. VPNVan offers 100+ countries and 240+ switchable routes, no limit on devices per account, no email address required to get started, and a no-questions-asked refund within 7 days of your first payment — which makes this kind of comparison testing cheap.

One last note: a subscription URL works like account credentials, so don’t forward it to anyone after importing it into a client. Once it leaks, someone else is burning through that account’s data, and your test results become hard to explain.