Why “Connected” Doesn't Mean Traffic Uses the Tunnel
When the client flips to Connected, it only means a tunnel was established between your device and the route server. Whether traffic actually enters that tunnel depends on the client's working mode, the routing rules, and how each app handles its own network traffic — three things that are separate from the Connected status.
Working modes usually fall into two groups. System proxy mode only rewrites the system proxy settings, so only apps that read those settings hand their requests to the tunnel: browsers generally do, some desktop apps don't. TUN / virtual adapter mode creates a virtual network adapter and takes over the routing table, so traffic from almost every app goes through the tunnel, including apps that ignore the system proxy. The same subscription can produce completely different results in the two modes.
The second layer is split-tunnel rules. Rule lists sort domains or IPs into direct, proxied or blocked groups; if the target domain is matched as direct, that request leaves through your local connection even when the tunnel is perfectly healthy. An outdated rule set, or different default rules built into different clients, produces the classic “same site works on one device but not another”.
The third layer is the app itself. Some apps ship their own network stack and ignore the system proxy; some prefer IPv6 while the tunnel only handles IPv4; UDP-based traffic (QUIC, voice calls, some games) is either downgraded or sent direct when only TCP forwarding is supported. In all of these cases the client says Connected while the app still exits locally.
To tell whether it's actually working, ignore the client status and look at three external pieces of evidence: where the exit IP is registered, where the DNS resolver is located, and whether the target app actually works.
Three-Step Check: Exit IP → DNS → App Test
The three steps run from the outside in: first confirm traffic enters the tunnel, then confirm resolution inside the tunnel is clean, and finally confirm the apps you actually use work in real scenarios.
- Check your exit IP once with the connection off and once with it on, then compare country / region and ISP.
- Check which server handles DNS resolution and confirm the queries aren't going to your local ISP.
- Test each app you actually use, one by one, instead of just opening a web page.
The three steps build on each other: if any one fails, Connected hasn't turned into working yet. Pin down which step fails, then decide whether to switch routes, change modes or update rules.
Step 1: Check the Exit IP and Confirm the Region Matches Your Route
There are plenty of IP lookup tools; what matters is comparison. Look up your IP with the connection off and write it down, then connect and look it up again in a private window, and compare the two. The command-line approach suits situations where you need to verify repeatedly.
# Check the current exit IP (works on Windows / macOS / Linux)
curl -s https://ifconfig.me
# For region and ISP details, use a lookup endpoint that returns JSON
curl -s https://ipinfo.io/jsonThe browser route is more visual: open any IP lookup page and check both the IPv4 and IPv6 entries. If only one changed, the other is still leaving through your local connection.
| Exit seen after connecting | Meaning | What to do |
|---|---|---|
| Matches the country / region of the selected route | Traffic is going through the tunnel | Continue to step 2 |
| Still your local ISP and local city | Traffic is not entering the tunnel | Check the working mode and split-tunnel rules |
| Same country as selected, different city than the route label | Exit pool scheduling — normal behaviour | No action needed |
| IPv4 changed, IPv6 is still a local address | IPv6 isn't captured — there's a leak | Enable IPv6 capture, or temporarily disable IPv6 on the system |
Before checking your IP, turn off any proxy extensions in the browser and reopen the lookup page in a private window. Extension proxies override the system proxy, and page caching can show you the previous result.
Step 2: Check DNS Resolution and Confirm There's No Leak
A DNS leak means web traffic goes through the tunnel while domain lookups are still sent to your local ISP's DNS. It has two consequences: your browsing intent is exposed to the local resolver, and the answers point to the node closest to you, which can mean the wrong content library or odd speeds. A DNS leak won't drop the client connection, so connection status alone will never reveal it.
There are two ways to check. Open a DNS leak test page in the browser — it lists the servers used for the lookup and where they're registered. On the command line, looking at the resolver address tells you the same thing.
# macOS / Linux: view the DNS resolvers
dig example.com | grep SERVER
# Windows: view the DNS resolvers and lookup results
nslookup example.comThe reading is straightforward: the resolver should be registered in the same region as your route, or show an internal DNS address inside the tunnel. If it still shows your local ISP's resolver, the lookups aren't going through the tunnel.
After changing DNS settings or switching routes, flush the system DNS cache before checking again, otherwise you'll still see the old result.
# Windows
ipconfig /flushdns
# macOS
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
# Linux(systemd-resolved)
sudo resolvectl flush-cachesStep 3: Verify Per App, Not Just the Browser
The browser is the easiest app to route, because it reads the system proxy settings. What actually shapes your experience is usually other apps. Test against your real usage instead of opening a random web page and calling it done.
| App type | Test | What working looks like |
|---|---|---|
| Browser visiting international sites | Open the target site and sign in | Pages load, region shown matches the route |
| Streaming playback page | Open the player and watch for a minute | Library matches the route region, playback doesn't stall |
| AI tools | Start a long conversation | Session holds, no region-restriction message |
| App store / system updates | Check the store region and download source | Region matches the route region |
Command-line and developer tools need their own check
Command-line tools such as git and package managers don't read the system proxy by default — you need to set the HTTP_PROXY / HTTPS_PROXY environment variables, or switch to TUN mode and let the virtual adapter take over. Verify the same way as the browser: look up the exit IP from the command line and compare it with what the browser shows; if they differ, one of them isn't going through the tunnel.
Common Cases Where It “Looks Connected” but Isn't Working
These are the symptoms that come up most often in troubleshooting — match them by symptom → cause → fix.
| Symptom | Common cause | What to do |
|---|---|---|
| Browser shows your local region, other apps are fine | A proxy extension in the browser is overriding the system proxy | Disable the extension and test again |
| Browser is fine, a desktop app reports the wrong region | That app doesn't read the system proxy | Switch to TUN mode, or enter the proxy manually in the app |
| Works right after connecting, then stops | Split-tunnel rules match the target domain as direct, or the rule set is out of date | Update the subscription and rule set, then test again |
| Most sites are fine, a few still show a local address | Those sites use IPv6 while the tunnel only handles IPv4 | Enable IPv6 capture, or temporarily disable IPv6 on the system |
| Web pages load, but voice / games / QUIC traffic misbehaves | The current mode doesn't support UDP forwarding | Switch to a protocol or route type that supports UDP |
| Results differ after switching to another client | The two clients use different default modes and rule sets | Align the mode and rule set, then compare again |
Why Results Differ After Switching Clients
A subscription link only carries route information — server address, port, protocol parameters — not the policy for how to use it. Import the same subscription into different clients and the default mode may be global, rule-based or direct; the rule set may come from the client's built-ins in one case and from the subscription provider in another, and a different match order gives a different result.
Protocol differences affect the results too. Shadowsocks, VMess, Trojan and VLESS are mainly TCP-based, and some implementations support UDP forwarding; Hysteria2 and TUIC run over QUIC and therefore use UDP natively, so they may fail to connect or behave erratically on networks that restrict UDP. If the exit IP and DNS steps both pass and only one kind of app misbehaves, suspect the protocol and UDP support before blaming the route. For how direct, relayed and IEPL dedicated route types differ, see the locations page.
Platforms differ as well: desktop clients can create a virtual adapter and capture all traffic; mobile platforms are more restricted and usually work per profile or per app; a router captures the whole network, but you need to confirm separately that DNS is forwarded too.
Judge whether it's working by whether exit IP, DNS resolution and the target app all pass at the same time. Conclusions drawn from the client status alone, or from one web page loading, are usually wrong.
A Reusable Self-Check List
The steps above, condensed into a checklist you can run through whenever you change devices, routes or clients. For fuller client import instructions, see the Guides.
- ✅ Disconnect and record your local exit IP and DNS resolvers as a baseline
- ✅ After connecting, re-check the exit IP in a private window and confirm it matches the selected route's region
- ✅ Check the IPv6 address at the same time to confirm it isn't bypassing the tunnel
- ✅ Flush the DNS cache, then re-check where the resolver is registered
- ✅ Verify each app you actually use, not just the browser
- ✅ Run the whole sequence again after changing routes, clients or rule sets
The whole sequence takes only a few minutes, but it separates “it feels connected” from “it's confirmed working”. Find out which step fails first, then decide whether to switch routes, change modes or update rules — far more effective than reconnecting over and over.
FAQ
The client says Connected but pages won't load — is it not working?
Connected only means the tunnel was established. Pages failing to load can mean split-tunnel rules matched the target domain as direct, lookups aren't going through the tunnel, or the route is congested right now. Work through exit IP → DNS → app and you can usually pin down the step, then decide whether to change modes, update rules or switch routes.
Only one app isn't using the route — do I need to switch routes?
Usually not. First check whether that app reads the system proxy and whether it has its own network stack, then consider switching to TUN mode or entering the proxy manually in the app. A problem with the route itself would affect every app, not just one.
Do I need to verify again after changing devices?
Yes. The results are tied to the working mode, rule set and DNS settings on that device, not to the account. After importing the same subscription on a new device, run the three steps again — especially when moving between mobile and desktop.
Why do mobile and desktop give different results?
Mobile platforms place more restrictions on background traffic and virtual adapters, and usually work per profile or per app; desktop clients can capture the whole machine. Before comparing, confirm both use the same mode and rule set, otherwise the results aren't comparable.
VPNAK
110+ countries / 160+ routes, unlimited devices, no email address required, 7-day no-questions-asked refund.