To confirm that a VPN is working, do not rely only on the client's “Connected” status. That usually means the client has established a session with the node, not that browser, office, and other app traffic is using the intended route. A reliable check compares exit IP, DNS requests, per-app traffic, and the actual access path before and after connecting.

If the exit address does not change after connecting, check the system proxy, virtual network adapter, and split-tunneling rules. If the address changes but DNS still follows an unexpected resolver path, check browser Secure DNS, the system resolver, and the client's DNS settings. Each signal answers a different question and cannot replace the others.

Connection success does not mean traffic is routed

A Connected status means the node handshake, authentication, or tunnel setup has broadly completed. The actual traffic path still depends on app proxy settings, the system network stack, routing tables, and DNS resolution. If any layer is not properly engaged, the status may look normal while web traffic continues over the original network.

You can group checks into several types of signals. The exit IP shows where web requests leave the network; DNS shows who handles domain lookups; per-app tests reveal whether split-tunneling rules cover the target program; and client logs help identify handshake failures, unmatched rules, or unreachable nodes.

Check What it confirms What it cannot prove alone
Client connection status A session has been established between the client and the selected node That every app is using the route
Exit IP The public exit used by the current web request That other apps not included in the test are covered
DNS results Whether the domain lookup path matches expectations The exit used by web content traffic
Per-app verification Whether a specified program matches a proxy or tunnel rule All programs on the system automatically
Access experience Whether the target service works normally over the current route Technical checks of the exit IP and DNS
How to interpret the result: “Connected” is only a starting point. You can judge the route with greater confidence when the exit IP changes, the DNS path matches your settings, and the target app clearly matches the intended rule.

Compare your exit IP before and after connecting

Your exit IP is the most direct place to start. Do not check it only after connecting: first disconnect the client and record the current public address and approximate region, then connect to the target node, reopen the lookup page, and compare the results. The site's My IP page can be used for this step.

  1. Fully disconnect from the current route and confirm that the client is no longer handling the system proxy or virtual network adapter.
  2. Open an IP lookup page and record the address, network provider, and region shown before connecting.
  3. Connect to the node you want to test, wait for the client status to stabilize, and refresh the lookup page.
  4. Compare the exit addresses and check whether the post-connection region matches the selected route.
  5. Visit a site again from the target app and confirm that its detected region does not materially conflict with the browser test.

If the address changes, the browser traffic used for the lookup has most likely passed through the route. If it does not, do not immediately keep switching nodes. More common causes include the browser not reading the system proxy, the client exposing only a local proxy port, virtual adapter mode being disabled, or split-tunneling rules classifying the IP lookup site as direct.

Do not treat the displayed region as the sole deciding factor. IP databases can update slowly, and a city label that differs from the node label does not necessarily mean the route is inactive. More important are whether the address and network provider changed, and whether the target service detects a region appropriate for your use.

Check whether DNS requests are taking the wrong path

DNS converts domain names into addresses the network can use. Web content passing through the target route does not mean domain lookups use that same path. The system resolver, the client's built-in DNS, browser Secure DNS, and enterprise network policies may all participate, so check DNS separately from the exit IP.

For a self-check, stay connected to the route and open a trusted DNS test page that sends several groups of random domain queries. Review the resolver name, network, and region after the test. If the results still clearly point to the local network while the client is configured to handle DNS through the route, check for out-of-path resolution.

Seeing a third-party public resolver does not by itself indicate a leak. With Secure DNS enabled, the browser may send queries directly to its chosen resolver; the client may also intentionally use a public resolver. The key question is whether the result matches the current configuration and whether the local network is still processing queries without your knowledge—not whether the resolver name exactly matches the node.

Dual-stack networks can also send different protocol families along different paths: traffic for one address family may pass through the tunnel while the other follows the system's default route. Some clients fully handle dual-stack traffic; others disable the unproxied family. If an exit test shows conflicting results, check the virtual adapter, routing rules, and system network interfaces rather than changing only the DNS address.

Verify each app separately to rule out split-tunneling gaps

A successful browser test does not mean meeting software, download tools, or command-line programs use the same route. System proxy mode generally affects apps that actively read proxy settings; virtual adapter mode takes over traffic at a lower level but can still be affected by route exclusions and split-tunneling rules. Some apps also create direct connections or use a different transport from web traffic.

The browser works, but other software does not

This is common when the client sets only the system proxy and the target software ignores it. Check whether the software has its own proxy option, then confirm whether the client supports virtual adapter mode. If the software requires UDP but the current node, protocol, or client mode does not forward UDP correctly, login may work while calls, syncing, or real-time features fail.

Only some websites show an unchanged exit

This is usually related to rule mode. A rule set may mark local-region traffic, frequently used sites, or specific domains as direct while sending other requests through the node. Review the client's connection records or rule matches to see whether the target domain ultimately uses proxy, direct, or reject policy. For testing, briefly switch to global mode, then restore split tunneling to avoid sending unrelated traffic through the route long term.

Web and app results conflict

First check whether both use the same network interface. A browser extension may proxy only browser tabs, while the system client handles other programs; an enterprise network tool may handle only office domains; containers, virtual machines, and subsystems may have independent network stacks. Be explicit about which app you are testing—one app's successful result cannot determine another app's status.

Split-tunneling conclusion: Global mode is useful for brief diagnosis, while rule mode is better for everyday use. If global mode works but rule mode does not, check domain matching, process rules, protocol support, and rule order before suspecting the node.

Check subscription nodes, protocols, and the route

A subscription link is only the client's entry point for obtaining node configuration; it is not a continuously active network tunnel. After importing a subscription, the client still has to resolve the server address, read the port and authentication details, and establish a connection using the specified protocol. An expired subscription, failed configuration update, or unsupported field can leave a node visible in the list but unusable in practice.

Shadowsocks, VMess, Trojan, VLESS, Hysteria2, and TUIC differ in handshake methods, transport layers, and client support. Their configurations cannot be substituted by changing names, nor can you expect a successful connection by copying only the server address. For persistent handshake failures, update the subscription, confirm protocol support, and then check time settings, certificate validation, transport settings, and the specific log error.

The route type also affects troubleshooting. A direct route connects the device straight to the remote node, making the path simpler but more dependent on the quality of the local-to-remote connection. A relay route first enters a relay point and then forwards traffic to the exit node, which can adjust the cross-network path. IEPL generally refers to a route design using a dedicated link for a key cross-border segment; its name alone does not mean every local access segment is identical.

These labels describe network paths, not application-layer configuration. Even with a relay or dedicated route, traffic may leave directly through the local network if the system proxy is disabled or the virtual adapter is not handling the target app. Conversely, a correctly changed exit IP with poor access may result from the target service's policy, node load, link quality, or local network fluctuations. Not every problem means the route is inactive.

Troubleshooting order for “connected but not routed”

Start with checks that have the broadest impact and the lowest cost to change. Do not change the node, protocol, DNS, and proxy mode at the same time; even if service returns, you will not know the real cause. The sequence below works for most desktop and mobile clients.

  1. Clear conflicts: Quit other proxies, enterprise network tools, and browser proxy extensions, leaving only the client under test.
  2. Reconnect: Disconnect from the node and establish the session again, watching for a clear client error.
  3. Compare exits: Record the exit IP before and after connecting to confirm whether browser requests changed.
  4. Switch modes: Temporarily use global mode for verification. If global mode works, the issue is usually in split-tunneling rules or app detection.
  5. Check system takeover: Verify that the system proxy, virtual adapter permissions, routing table, and network interface match the client's instructions.
  6. Check DNS: Confirm that the system, browser, and client are not using conflicting resolution policies.
  7. Update the subscription: Fetch the node configuration again instead of continuing to use parameters that may have been changed.
  8. Change one variable: Change only the node or the protocol, then repeat the exit and app tests.
  9. Review logs: Narrow the fault area using handshake, resolution, routing, and rule-match details.

On mobile, also check battery-saving policies and background restrictions. If the virtual network process is paused after the client goes into the background, the interface may retain a connection status temporarily while the actual tunnel is unavailable. On desktop, sleep/wake cycles, switching from wired to wireless, or another app overwriting the system proxy are more common causes. After a network change, rebuilding the connection is usually more effective than simply refreshing a page.

If the failure occurs only on one network—for example, home works but a public network does not—compare resolution results, available protocols, and node handshake logs. Some networks restrict particular transports or force their own sign-in page. Complete the network's access authentication first, then start the client to prevent the sign-in page and proxy takeover from interfering with each other.

What else to check after the route works

After confirming the exit and DNS paths, check disconnect handling and rule boundaries. If the client offers disconnect protection, understand what it does when a node unexpectedly drops: some clients block direct traffic from continuing, while others only stop proxying. Decide whether to enable it based on your work context and need for uninterrupted connectivity.

Split-tunneling rules should also remain explainable. Domains related to a target service may be spread across login, content delivery, API, and static asset addresses, so adding only the main domain may not cover the full workflow. If the homepage loads but login fails, or text works while media does not, identify unmatched related domains in the connection records and adjust the rules.

Privacy cannot be judged from the exit IP alone. A changed exit only shows that the test request used a different network exit; it does not mean every device data flow followed the same path or that you automatically have an anonymous identity. Account logins, browser storage, and information uploaded by apps may still identify a session. Assess route behavior, DNS settings, app permissions, and the service's own privacy policy separately.

Final conclusion: The most reliable way to determine whether a VPN is working is to compare before and after connecting, then cross-check the exit IP, DNS, and target app. If the exit is unchanged, inspect system takeover; if it changes but the app fails, inspect split tunneling and protocol support; if DNS does not match the settings, inspect browser and system resolution paths. This order usually finds the cause faster than repeatedly switching nodes.