First, the Difference: Connected Doesn't Mean Right Route

Clicking Connect and seeing the status turn green only means the tunnel from your device to the node was established. It doesn't guarantee the exit IP is in the region you picked, that domains resolve remotely, or that every app is captured.

A successful tunnel, an unusable node, an expired subscription or a routing rule that matches direct can all send traffic back out through your local connection — and the client UI won't tell you. So “Connected” is the result of an action, not proof that the route is working.

To confirm the route is really working, you need answers to three specific questions: which IP traffic exits from, where domains resolve, and which apps go through the tunnel.

3 checks: exit IP, DNS resolution, per-app routing
120+ countries and regions — the location you look up should match the route you picked
180+ routes — switching to another one and retesting quickly separates node issues from config issues
7 days no-questions-asked refund, so testing and trying stay low-risk

Turn those three things into checkable criteria and you get the list below. Only when all three pass is traffic really going through the international route.

Step 1: Check the Exit IP and Its Region

The exit IP is the most direct check: disconnect the route and note your current public IP and its location, then connect and look it up again, comparing the two results. You can search “what is my IP” in a search engine, or run a single command in your terminal.

# Run after connecting to the route to see the current exit IP
curl -s https://ipinfo.io/ip

# Alternative lookup
curl -s https://ifconfig.me/ip

The pass criterion is clear: the location of the IP you look up after connecting should match the region of the route you selected. If you still see your local ISP's IP, traffic never entered the tunnel — don't rush the next two steps, troubleshoot with the last section first.

One easy misread is IPv6: many clients only capture IPv4 by default, so IPv6 requests go out directly, and lookup sites may return the IPv6 address first — making it look like “connected but not working.” Fix it by enabling IPv6 capture in the client, or temporarily disabling IPv6 and testing again.

Another easily missed point is WebRTC. In TCP-only proxy modes, its UDP traffic can bypass the tunnel and expose your public address. This doesn't affect the exit IP verdict, but if exposure matters to you, restrict WebRTC in the browser or have the client capture all traffic in TUN mode.

Step 2: Run a DNS Leak Test

Traffic inside the tunnel is encrypted to military-grade standards, but DNS requests travel a separate path from web traffic. If domains are still resolved by your local ISP's DNS, you have a DNS leak: the IP goes through the route while the domain is resolved locally. The result is that responses get steered to a nearby CDN node, so pages slow down or fail to load — and the resolution path itself reveals what you're visiting.

How to check: search for “DNS leak test,” open any test page and look at the list of resolvers it returns. If you see your local ISP or a DNS server in your own city, that's a leak; you should see resolvers in the route's exit region.

You can also check in the terminal: the output of nslookup includes a Server line. Run it once before and once after connecting, and compare whether that address changed.

# Run once before and once after connecting, then compare the Server line
nslookup example.com

If you find a leak, turn on “Remote DNS” or “Use route DNS” in the client so resolution requests also go through the tunnel; if the client offers a DNS handling mode, choose the tunnel-managed option. Note that a browser's built-in encrypted DNS (DoH) bypasses system settings, so align it or turn it off while testing.

A DNS leak doesn't change the client's connection status — the UI stays green. It can only be found by testing, so don't skip this step.

Step 3: Per-App and Routing Checks

Per-app proxying is most common in Android clients: only the apps you tick go through the tunnel, and the rest connect directly. Desktop clients rely more on routing rules: the client uses a rule set to sort domains and IPs into proxy and direct groups, and a wrong match sends the target site out through your local connection.

Verify in four steps:

  1. Open the client's connection log or rule-match log;
  2. Visit a target site that should use the route, find the matching entry in the log and confirm it hit a proxy rule, not a direct one;
  3. Repeat for each key app: look up the exit IP in the browser, look it up in the terminal, and compare the two;
  4. For any app where the results differ, go back to the per-app list or custom rules, adjust it individually and test again.

It's common for the browser and terminal to show different exits: the terminal doesn't use the browser's proxy settings by default, and if the client runs in SOCKS or HTTP proxy mode, the terminal needs its own proxy environment variables — otherwise it still reports your local IP. That's not a route problem, it's a question of what's being captured.

Routing rules can misjudge too. When a target site sits on an overseas CDN but its main domain looks local, the rule set may classify it as direct by domain; an outdated rule set that doesn't include newer domains will also send traffic the wrong way. In that case, add the domain to your custom proxy rules and test again.
By now the criteria for all three checks are concrete: the exit IP's location matches the route's region, the resolvers sit on the route's side, and every key app matches a proxy rule. If even one of the three fails, don't conclude the route is broken yet — work through the common cases in the next section one by one, and you can usually pin it down in minutes.

Common Cases Where It Looks Connected but Traffic Doesn't Go Through

What these symptoms share: the client's connection status looks fine, but traffic isn't going through the route as expected. Matching each symptom to its cause beats reconnecting over and over.

Symptom Actual cause What to do
Client shows connected, but lookups still return your local IP The node handshake failed and fell back to direct, or the subscription expired or its data ran out Switch to another route and retest, and check your subscription status
Pages load, but video keeps buffering Domains resolve locally and get steered to a nearby CDN node Turn on remote DNS and rerun the leak test
Some apps use the route, others don't The app isn't ticked in per-app proxying, or a routing rule matched direct Compare the per-app list with the rule-match log
Browser and terminal report different exits The browser has a proxy extension or its own proxy settings Align the proxy settings and look it up again
Only the IPv6 address comes back as local The client isn't capturing IPv6 Enable IPv6 capture, or temporarily disable IPv6
Sites in mainland China stop loading once connected Global mode sends all traffic out, or the rule set classifies mainland China domains as proxy Switch back to rule-based routing and update the rule set

Verification Focus by Platform

The same verification flow has different gotchas on each system; going through it platform by platform saves detours.

Windows and macOS

Desktop clients usually capture traffic in one of two ways: system proxy and TUN mode. System proxy only covers apps that read the system proxy settings — terminals and some software bypass it. TUN mode captures more thoroughly, but don't enable it alongside system proxy, since running both tends to cause rule conflicts. Before testing, confirm which mode the client is using.

Android and iOS

Mobile devices use the system VPN configuration, and the connection status also shows in system settings. Android supports per-app proxying, so focus on the ticked list when verifying; iOS usually has no per-app switch and leans on routing rules, so focus on DNS and rule matches. Also, on cellular networks DNS is pushed by the carrier, which makes the leak test worth running again over mobile data.

Linux and Routers

On Linux you'll mostly use command-line clients. Note that systemd-resolved takes over DNS — resolvectl status shows the resolvers currently in use, so you can confirm they're handled by the tunnel. When the route runs on a router, every device on the network shares the same exit, so verifying from any one device is enough; but the router's own DNS forwarding settings determine the resolution path, so the leak test has to be judged at the router level.

VPNYN clients cover Windows, macOS, iOS, Android and Linux, so once you import your subscription you can run through the checks above item by item; one account allows unlimited simultaneous devices, so you can retest on several at once.

Once everything passes, write down the three results: exit IP location, resolvers, and the list of key apps. Next time you change routes, switch devices or upgrade your system, rerun the same flow — it takes only a few minutes.

Troubleshooting Order When Checks Fail

Work through the order below; each step narrows things down, so you don't change a pile of settings at once.

  1. Switch routes and retest. If the same configuration works on another route, the problem is on the node side and you don't need to touch your local settings.
  2. Check your subscription status. An expired subscription or exhausted data shows up as “connects but no traffic,” so confirm both first.
  3. Disable browser proxy extensions and built-in encrypted DNS to rule out browser-level settings.
  4. Check DNS capture. Turn on remote DNS in the client and rerun the leak test.
  5. Check IPv6. Enable capture or temporarily disable it, then test the exit IP again.
  6. Restart the client and the network. The tunnel and DNS configuration are rebuilt with the connection, and it's worth rebooting the router too.
  7. Keep the logs. Send the client log together with your three check results to support and the diagnosis will go much faster.

This flow needs no extra tools: one IP lookup, one DNS leak test page and the client's connection log cover all three checks. Before switching routes, take a look at the route list and pick one whose region matches before testing again.

It's worth fixing the order of the three checks: exit IP first, then the DNS leak test, then per-app routing one by one. Only when all three pass is traffic really going through the international route; passing just the first only means the tunnel is up — two steps short of “working.”