Check VPN Traffic Routing, Not Just Connection Status
To check whether a VPN is working, verify your public IP, DNS, and app routing separately. A connection indicator only tells you the client is in a particular connection state. To confirm that the target app is covered, see where its DNS requests go, and check whether traffic exits where expected, you need to test real requests.
Proxy clients and system-level VPNs may cover different traffic. A system proxy gives apps that follow the setting a way to connect through a proxy; it doesn’t force every program to use it. Browser extensions usually affect only that browser. TUN mode uses a virtual network interface and routing rules to capture matching traffic, but exclusions, route rules, and IP address family settings can still affect what gets through. Treating a working browser as proof that the whole device is covered can overlook these differences.
Before testing, define your goal: should a particular app use an international route, or should all default traffic enter the tunnel? Rule-based modes may allow specific sites to connect directly; that isn’t a fault. Troubleshoot further only when the actual route differs from what you configured.
Public IP: Compare Before and After Connecting
Your public IP is the source address a destination website sees. It isn’t your device’s local network address, and it may differ from the server address in your subscription configuration. That address might be an intermediary entry point, with the final exit elsewhere. For a reliable comparison, use the same tool and browser on the same network.
- Disconnect the client and temporarily disable any browser proxy extensions. Use a trusted public IP lookup tool to note your current exit IP, network provider, and whether the tool reports IPv4 and IPv6 separately.
- Connect to the route you selected and confirm that the system proxy or TUN is enabled as intended. In rule mode, check that the lookup tool’s domain actually matches a proxy rule.
- Run the lookup again. Don’t rely on a result left open in an old tab; if needed, start a fresh browser session to rule out cached pages and existing connections.
- Check the client’s connection logs to see which rule and policy group matched the lookup request and which exit route it used. Compare that with the lookup result.
- Try another route with a different exit region and run the lookup again. If the result doesn’t change, check traffic coverage and routing rules before assuming the route is down.
Country and region labels are only supporting clues. IP geolocation databases can be out of date, and lookup tools may disagree. Different routes in the same region may also share an exit IP. Stronger evidence is a request log showing that the selected policy handled the request, together with a network attribution that matches the route’s exit. Latency alone can’t verify your exit IP.
If IPv4 changes but IPv6 still shows your local network, check whether the client handles IPv6 and whether the app prefers it. For full-traffic routing, configure IPv6 routes according to the client’s documentation or use its relevant protection option. A page that checks only IPv4 can’t tell you how IPv6 traffic is routed.
DNS Leaks: Check Whether Resolution Follows the Intended Route
DNS translates domain names into addresses. A browser request can go through a proxy while domain lookups are still handled by your local network’s resolver; alternatively, the proxy may resolve them. Whether this counts as a DNS leak depends on your intended setup: if DNS queries are supposed to go through a controlled tunnel but are sent to a local resolver, they’re taking a different path than intended.
After connecting, run a test with a trusted DNS leak testing tool and note the resolvers it detects and their network attribution. These tools typically use dedicated test domains to identify the source of recursive DNS queries. They show the servers involved in resolution, not the exit IP for website requests. A resolver in a different region from your exit IP isn’t, by itself, proof of a leak.
Browser secure DNS, system DNS, client DNS, and an app’s built-in resolver may all be active at once. Secure DNS usually encrypts the connection to a resolver, but encryption doesn’t automatically route it through the VPN. A browser may also bypass the system resolver, so its test results don’t represent every app.
- Save your current client and browser DNS settings first. Decide which resolver you expect to use and whether DNS requests should go through the proxy or connect directly.
- Check whether the client configures separate DNS routes for direct and proxied domains. In split-routing mode, sending local domain lookups to a local resolver may be intentional.
- To isolate differences, you can temporarily change the browser’s secure DNS setting and run the test again. Change only one setting at a time, then restore your preferred configuration when you’re done.
- Check whether the client provides DNS logs. Distinguish cached results, lookups handled by the proxy, local client resolution, and queries actually sent over the network.
Per-App Checks: A Working Browser Isn’t Enough
To check routing for an app, generate a new request from that app. Open the client’s connection log, restart the app you’re testing, and visit a page or use a feature that genuinely needs the proxy. Check the request time, destination domain, matched rule, and policy. Without logs, a page loading successfully doesn’t prove which route it took: the service may be directly reachable, or you may be seeing cached content.
On Windows and macOS, some programs don’t follow the system proxy setting. Use the program’s own proxy settings or enable TUN according to the client’s documentation. Creating a virtual network interface may require permission; check the documentation for your client. Command-line tools may also need their own proxy arguments or environment variables—a working system proxy doesn’t guarantee that terminal requests use it.
On Android, a client may use the system VPN interface and let you allow or exclude specific apps. Check that the target app is in the right list, and review the system VPN settings and work profile. iOS clients typically establish a tunnel through a system network extension. Routing capabilities depend on the client and its configuration, so Android’s per-app menu steps won’t necessarily apply.
| Test target | What to check | What you can’t conclude |
|---|---|---|
| Browser | Exit IP, proxy extensions, secure DNS, and logs for the relevant requests | Desktop apps and terminal tools use the same route |
| Desktop app | App-specific proxy settings, TUN coverage, and domain or process rules | Enabling the system proxy automatically captures all traffic |
| Mobile app | App allow or exclude lists and requests made after reconnecting | The system’s connected indicator means every app uses the route |
| Command-line tool | Proxy arguments, environment variables, and the resolver path the tool actually uses | The terminal and browser share all network settings |
Check the final rule match, not just the text of an individual rule. An earlier matching rule may override a later choice, and a policy group may still point to a direct connection or a different route. After making changes, start a new connection: existing sessions may not switch to the new route straight away.
What to Check When Connected Traffic Isn’t Using the VPN
First, make sure the subscription was imported and updated successfully. Then check whether the current policy is using the route. A subscription link is an entry point for configuration, not a webpage test address or an installer link. Successful import only confirms that the client received a configuration; protocol support, connection success, and app coverage are separate steps.
Shadowsocks, VMess, Trojan, and VLESS are common proxy protocols; Hysteria2 and TUIC typically use QUIC-based transport. A protocol name alone won’t automatically route an app through a proxy. The client must support the protocol and its configuration parameters, and your local network must allow the relevant transport. IEPL, relay, and direct routes describe network paths; they’re a separate layer from protocols and how your device captures traffic.
- ✅ Browser exit IP hasn’t changed: Check whether the system proxy is enabled, whether an extension is overriding the settings, and whether a direct rule matches the lookup domain.
- ✅ Browser works but an app doesn’t: Check the app’s own proxy settings, per-app exclusions, and TUN routes before repeatedly replacing the subscription.
- ✅ No apps work: Check the client’s error logs, selected route, and protocol support, then make sure your local network allows the transport in use.
- ✅ It only works after a restart: Check existing connections and how the client reloads its configuration. Note whether you need to restart the client or the target app.
- ✅ The exit IP is correct but the service reports an error: Separate routing problems from account region, content licensing, risk controls, or a service-side issue. An error alone doesn’t prove the VPN isn’t working.
- ✅ A DNS test shows an unexpected resolver: Compare browser secure DNS, system resolution, and client rules. Identify which component made the query before changing settings.
WebRTC tests need to be interpreted separately too. Real-time communication features may expose additional network information through candidate addresses, but seeing a local network address doesn’t mean public traffic bypassed the tunnel. If you find an unexpected public candidate address, check browser policies and UDP routing. A standard webpage IP check can’t prove that every real-time communication route matches your intended setup.
Recheck After Disconnecting or Changing Networks
“Works while connected” and “still meets your privacy expectations when disconnected” are different questions. A configuration that allows automatic direct connections may fall back to your local connection if a route becomes unavailable. Even clients with a connection-blocking option require you to confirm that it’s enabled and covers the traffic you need. Don’t assume every client includes this feature.
Use a non-sensitive test page to check what happens when a route becomes temporarily unavailable. See whether new requests fail, switch policy, or connect directly. Manually quitting the client and an unexpected disconnection may trigger different behavior, so record which scenario you tested. After waking the device or switching networks, repeat the exit IP and target-app checks to confirm the connection was re-established.
If you need to submit a support ticket, include the client name, OS version, connection mode, time of the issue, target domain, and relevant error details. Before sharing a screenshot, hide subscription links, tokens, account details, and unnecessary browsing history. Don’t post your full configuration in a public forum to reproduce the issue. VPNHO users can send diagnostic details through Support Tickets.
Bottom line: A VPN is working for a specific scenario only when the target request’s exit IP, DNS route, app coverage, and routing rules all match your intended setup. A successful browser test proves only the route taken by that browser request; check disconnect protection and other apps separately.
Keep a simple troubleshooting record: local network, selected route, traffic-capture mode, target app, exit IP result, DNS result, and behavior on disconnect. When an issue comes up again, compare it with your notes; that’s easier than changing protocols, DNS, and rules all at once. For client setup and import steps, see the Guides. For route types and protocol details, see the Route List and Protocol Guide.