Exit IP: the first thing you can confirm
Once connected, open the IP lookup page and check the current exit IP and its location. There is only one criterion: the location should be where the node is, not your local ISP. If the location is still your local city and the organisation is still your local broadband provider, traffic never entered the tunnel — the status light in the client only proves the process is running.
Two details matter for the exit IP as well. The first is IPv6: browsers and operating systems prefer IPv6 by default, so if the client only captures IPv4, the page may show your local IPv6 address directly — it looks like the IP changed, but only half of it did. The second is WebRTC: some browsers expose the device or local network address through WebRTC regardless of whether the proxy works, so restrict or disable it in the browser settings.
A connection that only covers IPv4 falls back to the local network as soon as a destination supports IPv6. Start by checking whether the IP lookup page returns both IPv4 and IPv6 results, then confirm the two locations match.
If a browser proxy extension is also installed on the same device, the extension usually takes priority over the system proxy. The system level is already captured, yet the browser still uses the route inside the extension; the two exits differ and it is easy to draw the wrong conclusion. Disable the extension while testing, or compare against a browser profile with no extensions installed.
DNS leak self-check
DNS queries decide who resolves the domain you visit. By default the system sends queries to your local ISP; once the proxy is active, queries should go out from the node side instead. If queries still reach the local DNS, the lookup itself reveals the destination, and you may get a CDN result that is closer to you but wrong for the target site.
To check, open a DNS leak test page; it lists the IPs and owners of the servers involved in resolution. A passing result means the resolvers sit where the node is, or at least in the same region as the exit IP. If every resolver listed belongs to your local ISP, resolution is not going through the proxy.
The matching switch in the client is usually called Remote DNS, DNS over proxy or Leak protection. Wording differs between clients, the effect is the same: hand resolution to the resolver at the other end of the tunnel. Reconnect once after enabling it before checking again — changes often do not apply until you reconnect.
In rule mode, resolving local-region domains through local DNS and connecting directly is the intended design. To judge a leak, look at the domains that are proxied: a target site going through the proxy while its resolution stays local is the case worth fixing.
There is another case: encrypted DNS built into the application. Once a browser or the operating system enables DoH / DoT, queries travel over a separate HTTPS connection and may bypass the DNS set by the client. These options live in the browser privacy settings; turn them off while testing, confirm the baseline, then decide whether to restore them.
Per-app and split routing checks
Even with the exit IP and DNS both correct, individual apps may still skip the proxy. There are two reasons: the app does not read system proxy settings, or a routing rule classifies the destination as direct.
The system proxy (HTTP / SOCKS proxy) relies on apps reading the system settings. Browsers, system updates and most command-line tools do; some desktop apps and game clients do not. Covering those requires a TUN or virtual network adapter mode in the client, which captures traffic at the network layer — at the cost of higher privileges and, on some systems, an extra network component.
To verify routing: first use global mode to confirm the basic path works, then switch back to rule mode and open the services you actually use one by one. If global mode works and one service fails in rule mode, the problem is the rules, not the route. The rule list usually shows which entry matched and where traffic went; add a rule for the domain or IP range.
Per-app proxying is available on some platforms. Once enabled, only the selected apps go through the tunnel and everything else connects directly. This suits keeping work software out of the tunnel, but it is easy to misread while testing: an unselected app showing a local IP is expected behaviour, not a fault.
Check the subscription import as well. After the subscription link updates, the node list in the client should refresh; if the names and count stay the same for a long time, the subscription may not have been fetched, or the client is still using the old profile. A node showing a timeout means the handshake never completed — switch to another route and test again.
Six cases where it looks connected but nothing is proxied
The cases below come up most often in troubleshooting, and they share one thing: the client interface says Connected.
- The system proxy was never written. Some clients require you to enable Set system proxy manually; connecting the route alone does not change system settings, so everything outside the browser goes direct.
- A browser extension overrides the system proxy. The extension has higher priority and both exits exist at once, so the IP lookup result depends on which one is currently in use.
- IPv6 takes priority. When the tunnel only captures IPv4, destinations that support IPv6 are reached by the browser directly over the local network.
- A routing rule matched direct. Rules match by domain, and the destination domain falls into the direct group, so the exit is naturally still local.
- The app ignores the system proxy. Desktop apps, game clients and some sync tools do not read system proxy settings and must be covered by TUN mode.
- The app ships its own encrypted DNS or network stack. Neither resolution nor connections pass through system settings, so the system proxy has no effect on it.
Client differences across platforms
Windows: system proxy and TUN modes
System proxy mode changes the system proxy entry, which browsers and most apps follow; TUN mode creates a virtual adapter and can capture programs that ignore the system proxy, but needs administrator rights. After switching modes you must reconnect, otherwise settings left over from the old mode are still in effect.
macOS and iOS: no permission means no connection
On macOS, clients that use a network extension request authorisation in System Settings; without it the connection appears to succeed but never captures traffic. iOS uses Network Extension, and the first connection must be confirmed in the system dialog — once denied, the switch inside the client does nothing.
Android: check the per-app list yourself
Android builds on the system VpnService and also needs dialog authorisation. Its per-app proxying is more granular, so during verification check the selected list item by item rather than trusting the main switch alone.
Protocol differences: TCP and UDP behave differently
Shadowsocks, VMess, Trojan and VLESS are mainly TCP, with UDP support depending on the implementation; Hysteria2 and TUIC are built on QUIC and run entirely over UDP. The ss://, vmess:// and trojan:// prefixes you see in the client correspond to different protocols. When the network restricts UDP strictly, the symptom is a node you can select but never connect to; switching back to a TCP-based protocol tells you which layer the problem is on.
A self-check table and criteria
Combine the checks above into one table and work through it by symptom.
| Symptom | Likely cause | Fix |
|---|---|---|
| IP lookup shows the local ISP | System proxy not written, or TUN not started | Check the proxy mode and reconnect |
| IP is correct, resolver is still local | DNS is not going through the proxy | Enable Remote DNS / leak protection and reconnect |
| Only the browser is proxied | System proxy mode cannot reach other programs | Switch to TUN / virtual adapter mode |
| The destination still sees you as local | A routing rule matched direct | Check the rule list and add a domain rule |
| The IPv6 address is still local | The tunnel only captures IPv4 | Disable system IPv6, or enable IPv6 proxying |
| Node selectable but always times out | Protocol or port is restricted | Switch routes, or use a TCP-based protocol |
All of the following must hold before the connection is genuinely working.
- ✅ The exit IP is located where the node is, and the IPv4 and IPv6 results match.
- ✅ The resolvers on the DNS test page sit in the same region as the exit IP.
- ✅ The target service works in global mode and still works after switching back to rule mode.
- ✅ Desktop apps that ignore the system proxy also show the node IP in TUN mode.
- ❌ Only the browser shows the node IP while system-level apps still show a local address — the system proxy was written, but global traffic was never captured.
- ❌ The test page says you are proxied, yet every resolver belongs to the local ISP — DNS is not following the tunnel.
The criteria: ignore the status light in the client and require three pieces of evidence at once — the exit IP is on the node side, DNS resolution is on the node side, and the apps you actually use really go through the tunnel. If any one is missing, work through the table above; the problem is usually the proxy mode or the routing rules, not the route itself.
When you need to compare several routes, the range covers 100+ countries and 220+ routes; unlimited devices means a computer and a mobile device can be online at the same time for comparison — keep one on default settings and switch the other to split routing, and the difference is obvious. If a route keeps timing out during your subscription period, switching routes saves more time than reinstalling the client.
If every check passes and the target service still misbehaves, the problem is most likely a policy on the destination side rather than your local connection. Switching to another route in the same region for cross-checking is more efficient than repeatedly changing settings in the client; if you need to reproduce the steps item by item, see the client configuration notes in the Guides.