The icon turns green and the status reads Connected, yet pages still load at the same speed and show the same content as before — that's the classic picture of a VPN that's connected but not working. The problem is usually not the route itself but whether your traffic is actually being sent into it: system proxy mode only applies to apps that read the proxy settings, split tunneling rules may classify the target domain as direct, and DNS lookups may not be going through the route at all. The way to tell isn't complicated, and the order is fixed: check the exit IP first, then DNS, then verify app by app. Once all three steps are done, most cases of "looks connected but isn't really going through" can be traced to a specific cause.
Why "Connected" Doesn't Mean It Works
A connection between the client and the route only means the control channel is up: node information was retrieved, authentication passed, and heartbeats are normal. Whether your traffic actually enters that channel is a separate matter, and it depends on three variables — the client's operating mode, the split tunneling rules, and whether the app you're using reads the proxy settings.
There are three common operating modes, and they differ a lot in what they cover:
- System proxy mode: the client changes the operating system's proxy settings (HTTP / SOCKS). Only apps that actively read those settings go through the route. Most browsers do; terminals, some desktop software, and game launchers don't.
- TUN / virtual network adapter mode: the client creates a virtual network adapter and takes over the routing table, so most apps' traffic is captured as a whole and no longer depends on each app reading the proxy settings.
- Global / rule mode: this is the policy for which traffic goes through the route. Global sends every request into the route; rule mode evaluates domain by domain, IP range by IP range, and region list by region list, and domains that match a direct rule never touch the route.
So Connected is only a necessary condition. To judge whether the route is really in effect, you need data: has the exit IP changed, who handled the DNS lookup, and what source address does each specific app get.
The same not-working symptom has completely different causes in system proxy mode and in TUN mode. Open the client settings, confirm which mode you're in, and the rest of the troubleshooting will have a direction.
Check the exit IP: compare the address before and after
The exit IP is the most direct evidence of whether the route is in effect. If traffic goes through the route, external sites see the address where the route lands; if it doesn't, they still see your local broadband or cellular address. There are just four steps:
- Before connecting, open a page that shows your source address and note the address and its location.
- Connect to the route and wait 5–10 seconds for the status to settle before doing anything else.
- Refresh the same page and compare the two addresses.
- Check with a second lookup source to rule out a false reading caused by page caching.
| Comparison result | What it means | Next step |
|---|---|---|
| The address changed, and its location matches the selected node | The data channel is in effect | Continue with the DNS and app checks |
| The address didn't change at all | The current app's traffic isn't entering the route | Check the operating mode and split tunneling rules |
| The address changed, but the location isn't the region you selected | The entry and exit may be in different regions, or the page is showing a CDN edge address | Cross-check with another lookup source, then look at the node details in the client |
How the exit IP relates to route type
Direct, relay, and IEPL dedicated lines change the path from your local network to the exit: direct connects the client straight to an overseas node over the public international gateway; relay connects first to a relay server in mainland China, which then forwards to the overseas exit; IEPL dedicated lines run over international Ethernet private line links and don't pass through the public internet gateway. All three affect latency and packet-loss stability, while the exit IP is determined by the exit node — switching nodes changes the exit address, but changing from direct to relay won't change the location.
Check DNS: where the lookups go
A domain has to be resolved to an IP address before a connection can be established. If the DNS query doesn't go through the route and is handed to your local ISP's resolver instead, there are usually two consequences: the destination is exposed to the local network at the resolution stage, and the result may point to a nearby but unreachable — or even poisoned — address, which shows up as "connected but pages won't open" or "works sometimes, fails other times".
There are two ways to check:
- Open a DNS leak test page and look at the resolvers it lists. If a local ISP address appears in the list, the queries aren't going through the route.
- Confirm from the command line. On Windows, run
nslookup example.com; on macOS / Linux, rundig +short example.com; on macOS you can also usescutil --dnsto see the current resolver order.
Three common reasons DNS doesn't go through the route
- The browser has its own secure DNS (DNS over HTTPS) turned on. The browser connects to the DoH server directly, bypassing system DNS, so the client can't intercept it. Fix: turn off secure DNS in the browser settings, or set it to follow the system.
- The client only proxies TCP and doesn't take over UDP 53. Fix: enable the DNS takeover or remote resolution option in the client.
- The split tunneling rules classify DNS requests as direct. Fix: review the rule list and make DNS follow the proxy.
If your local network hands out an IPv6 address while the route only proxies IPv4, some traffic may bypass the route and go out over IPv6 directly. Either enable IPv6 support in the client, or temporarily disable IPv6 on the system and test again.
Verify app by app: a working browser doesn't mean the terminal is covered
Browsers are the app most easily covered by a proxy, so testing only the browser often gives an overly optimistic conclusion. A safer approach is to test one example from each of three typical categories.
- Browser: open a page that shows your source address and confirm it matches the region of the selected node.
- Terminal: Windows 10 / 11 ships with curl, so just run
curl https://api.ipify.org; in PowerShell useInvoke-RestMethod https://api.ipify.org; on macOS / Linux usecurl -s https://api.ipify.org. - Desktop software and mobile: mail clients, sync drives, and game launchers mostly don't read the system proxy, so they need their own in-app settings or rely on TUN mode; on a phone, confirm again after switching between Wi-Fi and cellular.
What to do when the terminal and browser disagree
If the browser shows the route address but the terminal returns your local address, you can be fairly sure you're in system proxy mode — terminals don't read the system proxy by default. Two ways to handle it: turn on the client's TUN mode so the routing layer takes over, or set a proxy for just the current terminal session.
# Set a proxy for the current terminal session only; use the local port shown in the client UI
export https_proxy=http://127.0.0.1:7890
export http_proxy=http://127.0.0.1:7890
# Confirm the exit address again
curl https://api.ipify.orgThe equivalent in Windows PowerShell is $env:https_proxy="http://127.0.0.1:7890", which only applies to the current window and stops working once you close it.
Looks connected but isn't really going through: the common cases
The table below covers the situations beginners run into most often. Work through it from top to bottom: confirm whether the route is in effect overall first, then handle exceptions for a single app or a single site.
| Symptom | Likely cause | What to do |
|---|---|---|
| The exit IP is exactly the same before and after | The client is in system proxy mode and the current app doesn't read proxy settings | Switch to TUN or global mode, or configure that app separately |
| The browser works, but the terminal returns your local address | Terminals don't read the system proxy by default | Turn on TUN mode, or set the http_proxy / https_proxy environment variables |
| One particular site doesn't go through the route; everything else is fine | The split tunneling rules classify that domain as direct | Check the client's connection log and rule matches, then add the domain to the proxy list |
| You switched nodes, but the exit address is still the old one | The node didn't actually switch, or old connections are still in use | Disconnect and reconnect, and confirm the selected node in the client |
| The DNS test page shows a local ISP resolver | The browser's secure DNS bypasses system resolution, or the client isn't taking over DNS | Turn off the browser's secure DNS and enable DNS takeover in the client |
| One protocol connects and the original one doesn't | The network is dropping UDP packets | Switch to a protocol that can run over TCP and compare |
| Web pages load, but voice calls still go out locally | WebRTC or the app's own P2P direct connection bypasses the proxy | Disable WebRTC in the browser, or restrict direct connections in the app |
| The status says Connected, but there's no network at all | Leftover proxy settings on the system point to a port from software that has already quit | Check the system proxy settings, reset them to automatic or off, then reconnect |
Protocols like Hysteria2 and TUIC are built on QUIC and depend on UDP; Shadowsocks, VMess, Trojan, and VLESS can run over TCP. When a node looks fine but won't connect, change the transport first and consider changing nodes second — corporate and campus networks dropping UDP is not uncommon.
Three-step self-check and conclusion
Here's the above condensed into a checklist you can follow, and re-run every time you change networks or nodes:
- ✅ Check the exit IP before and after connecting; the address changes and its location matches the region of the selected node.
- ✅ None of the resolvers listed on the DNS test page is a local ISP address.
- ✅ The terminal
curland the browser return the same exit address — it's not only the browser that's covered. - ✅ Open each app you actually use and verify it once, instead of only testing the browser's home page.
- ✅ Confirm again after switching between Wi-Fi and cellular; don't carry over the previous conclusion.
If the problem keeps showing up on the same route — sustained packet loss at peak hours, for example, or a UDP-based protocol being blocked long term — then it's no longer something client configuration can fix, and it's time to think about the route type. VPNBF offers 100+ countries and 230+ routes, including IEPL dedicated lines and relay routes, with military-grade encryption end to end, unlimited simultaneous devices, and support for Windows / macOS / iOS / Android / Linux; creating an account only needs a username and password, with no email address required; 7-day no-questions-asked refunds, and data packs that never expire.
- 100+Countries & regions
- 230+Routes available
- UnlimitedDevices online at once
- 7 daysNo-questions-asked refund