"VPN says connected but nothing works" is one of the most common beginner confusions: the client clearly shows connected, yet pages still won't load, or they load and still show your local address. The test itself is simple — look at which address your traffic actually leaves from. This guide walks through three steps: exit IP, DNS resolution, and per-app verification, with concrete steps and pass/fail criteria at each stage, so you can tell exactly where things break.
Connected ≠ Working: first, see where your traffic actually goes
The "Connected" status in your client only means the encrypted channel between client and server is up — the tunnel is established. It does not guarantee that every program on your system actually uses that tunnel. These two things get mixed up all the time, which is where the "connected but not working" confusion comes from.
There are three main ways a client can take over your traffic, and each one covers a different set of apps:
- System proxy: only affects programs that read the system proxy settings. Browsers usually do; command-line tools and many desktop apps don't.
- TUN / virtual network adapter: rewrites the system routing table and takes over traffic at the adapter layer. It has the widest coverage and pulls in most programs.
- Per-app proxy: only takes over the apps you tick. Anything outside the list still connects directly.
So most "connected but not working" cases aren't a broken route — the takeover simply doesn't cover the app you're using. Once that's clear, the rest of the troubleshooting is just confirming each layer one by one.
In system proxy mode, curl in your terminal and some desktop apps don't read the system proxy, so their traffic still goes out directly. That's not a fault — it's just how far this mode reaches.
Step 1: check whether your exit IP changed
Your exit IP is the "you" that outside websites see. Comparing the exit IP before and after connecting is the most direct and least error-prone test.
- First disconnect, open any IP lookup page, and note your current exit IP and its location.
- Connect, refresh the same page, and note it again.
- If the two addresses differ and the second one is located in the region you picked, your traffic is going through the tunnel.
- If they're identical, the program you're using isn't going through the tunnel at all — keep reading.
If you'd rather not open a web page, you can also check from the built-in command line:
# macOS / Linux
curl -s https://api.ipify.org
# Windows PowerShell (curl.exe ships with Windows 10 / 11)
curl.exe -s https://api.ipify.org
# To see the ISP and city, use this instead
curl -s https://ipinfo.io/jsonIt's very common for the command line and the browser to disagree: browsers read the system proxy, terminals don't. That difference is useful in itself — it tells you which takeover mode your client is running in.
If the exit IP hasn't changed at all, it's usually one of these:
- The client is in system proxy mode and the program you're using doesn't read the system proxy.
- A routing rule has classified the current domain as direct.
- Another proxy tool is running, and the two clients fight over the takeover — whichever started last wins.
- A proxy extension is installed in your browser and its settings override the system proxy.
Step 2: check for DNS leaks
DNS translates domain names into IP addresses. If the tunnel carries your web traffic but domain lookups still go to your local ISP, you get "connects fine, but the wrong site opens — or nothing opens at all." That's what people mean by a DNS leak.
Two ways to check — pick either one:
- Open any DNS leak test page and look at where the listed resolvers are located. If the list is all local ISPs after you connect, your lookups aren't going through the tunnel.
- Command line: on macOS / Linux run
dig +short whoami.akamai.net; it returns the exit address your recursive resolver sees, which tells you where lookups are coming from. On Windows, usenslookupfor comparison.
In rule-based routing mode, sending mainland China domains to local DNS is by design, not a leak. To judge whether you have a leak, check only whether the overseas domains you visit are also resolved through an overseas exit.
If lookups are indeed going out locally, work through these in order:
- Turn on DNS takeover in your client — some clients call it "DNS protection" or "encrypted DNS."
- If your browser has "secure DNS / DoH" enabled, turn it off or set it to match the client — it can bypass the client's DNS takeover.
- After changing the setting, reconnect and run the checks above again to see whether the resolver exit has changed.
Step 3: verify per app
The same address behaving differently in different programs is the single most informative step in troubleshooting.
Browser
Open the target site in a private window. If it loads in private mode but not in a normal window, an extension is probably modifying requests — disable them one by one to find which one.
Terminal
The command line doesn't read the system proxy. To route it through the tunnel, either switch the client to TUN mode or set the environment variable temporarily — use the port shown in your client:
export http_proxy=http://127.0.0.1:7890
export https_proxy=http://127.0.0.1:7890
curl -s https://api.ipify.orgCheck the exit IP again after setting it. If the address changed, your terminal is going through the tunnel too.
Desktop apps and mobile
- Most desktop apps have their own proxy settings, defaulting to "no proxy." You'll need to switch them to follow the system proxy, or enter the local address and port manually.
- On mobile, per-app proxy only applies to the apps you've ticked; anything outside the list connects directly, which shows up as "connected, but one particular app won't open."
- On iOS, Low Power Mode and background refresh policies can cut long-running background connections. If the app has been in the background for a while, check the client's connection status first.
Common "connected but not working" cases and fixes
| Symptom | Likely cause | Fix |
|---|---|---|
| Exit IP hasn't changed at all | Client is in system proxy mode and the app doesn't read the system proxy | Switch to TUN / virtual adapter mode, or enter the proxy manually in the app |
| Only one app won't open | It isn't in the per-app proxy list | Add it to the list, or switch to global takeover |
| Pages load, but the content is wrong | A routing rule classified the domain as direct | Check the rules and add the domain to the proxy list |
| Lookups resolve to a local location | DNS isn't going through the tunnel, or the browser's secure DNS bypasses it | Enable DNS takeover and turn off the browser's DoH |
| Slower after connecting, some sites time out | Two proxy tools running at once, fighting over the takeover | Keep only one; quit the other, including its background process |
| Drops after a while and needs a manual reconnect | Sleep or power-saving policies cut the tunnel | Turn off the relevant power-saving limits and enable auto-reconnect in the client |
Keep only one proxy tool on a device. When two clients run at once, the one started last grabs the takeover, which shows up as "fine right after connecting, then broken a while later."
- ❌ Treating "Connected" in the client as success without checking the exit address.
- ❌ Treating local DNS for mainland China domains as a leak and repeatedly changing settings.
- ❌ Troubleshooting with two proxy tools running at once — too many variables.
- ❌ Testing only in the browser and forgetting that terminals and desktop apps don't read the system proxy.
- ✅ After every route change, check the exit IP and DNS exit again.
- ✅ Run only one proxy tool and work through the order: exit IP → DNS → per app.
Three-minute self-check routine
Here are the three steps as one fixed routine — run through them in this order whenever you change routes or devices:
- Disconnect, check the exit IP and its location, and write them down.
- Connect, refresh the page, and confirm the exit IP has changed and the location matches the region you picked.
- Open a DNS leak test page and confirm the resolver exit is overseas too; while you're there, turn off the browser's secure DNS.
- Visit the same target site once from a private window and once from the terminal. If the results match, system-level takeover is working.
- Check the per-app list and routing rules to confirm the target app and domain are both covered.
- Pass all three and the connection is genuinely working; if one fails, use the table in the previous section.
The exit IP changed, the DNS exit is overseas, and the target app opens — meet all three and you can be sure this connection is really working.
Before switching routes, confirm these two things
If "won't open" is the only check that fails, the first instinct for many people is to switch routes. Confirming two things first saves a lot of back and forth.
Plan and data status
Monthly plans reset their data allowance on the activation date each month; if this month's data is used up, the symptom is usually "connects, but nothing opens." Data packs are bought by volume, last until used up, never expire, and can be topped up at any time.
Differences between route types
- IEPL dedicated line: runs on a dedicated channel, steadier during evening peak, and suited to situations that demand stability.
- Relay: the entry point is in mainland China, adding one hop but allowing more flexible scheduling.
- Direct: connects straight from your location to an overseas node, so it's more exposed to fluctuations in international bandwidth.
Switch to another route in the same region and run the exit IP check again: if the address changes and the site opens, the old route was the problem; if the address still doesn't change, the issue is still in your local settings.
Bottom line: judging whether a connection is really working comes down to three things — the exit IP changed, the DNS exit is overseas, and the target app actually opens. Pass all three and there's no need to change anything else; if one fails, it's almost always the takeover mode, a routing rule, or a second proxy tool — rarely the route itself.