How to Check Whether a VPN Is Working: Exit IP, DNS, and Per-App Tests

A connected client does not mean all traffic has been rerouted

The client’s connection status usually means only that the local app has completed a handshake with a remote node, or that its local proxy port or virtual network interface has started. It does not by itself prove that your browser, download tools, games, or background system services all use the same route. The actual path also depends on the client mode, operating-system routes, per-app proxy settings, DNS configuration, and traffic-routing rules.

Common operating modes include system proxy, virtual network interface, and in-app proxy. A system proxy mainly affects programs that honor system proxy settings. A virtual network interface can usually handle a broader range of traffic, but exclusions and local routes may still apply. An in-app proxy affects only configured apps. Browser extensions are also local proxies and do not automatically change the exit used by other programs.

The check should therefore answer three separate questions: Is the connection established? Has the target app entered the proxy path? Which network exit does that path ultimately use? If any one of these differs from expectations, the client may show “Connected” while websites still see the same network location.

Compare your exit IP first to confirm where web traffic leaves the network

Your exit IP is the most direct check. It represents the network source seen by the destination website, not the local address of your device on a home or office network. Do not check only the post-connection result: record the disconnected state first, then connect to the target node and repeat the check with the same service. Run both tests in the same browser environment to avoid interference from extensions, separate proxies, or cached results.

Recommended sequence

1. Disconnect the client, disable any proxy extension configured separately in the browser, then open a trusted IP lookup page and record the exit address, network provider, and approximate region.
2. Connect to the required route, wait for the client status to stabilize, then open a new private window or clear the lookup page’s cache.
3. Check the exit information again. If the address and network provider have changed and broadly match the selected route’s region, the browser request most likely used the remote exit.
4. Test another ordinary webpage to confirm the path instead of relying on a single checking site. Some pages may cache earlier results, and geolocation databases can take time to update.

A displayed region that does not exactly match the node name does not necessarily mean the route has failed. IP geolocation databases are maintained by different organizations and update at different speeds. A route may also exit through a nearby city or a data center in the same region. Focus on whether the exit address and network ownership changed, rather than expecting every lookup page to show the same city.

If the exit address has not changed at all, first check whether the browser is bypassing the system proxy. Some browsers can use their own secure DNS, proxy extensions, or enterprise policies, and some apps keep long-lived connections established before the connection changed. Fully quit and reopen the app; this is usually more effective than simply refreshing the page when ruling out stale connections.

Check the DNS path to make sure name resolution follows the expected route

DNS converts domain names into network addresses that can be reached. Web content using a remote exit does not automatically mean that DNS queries use the same path. If the system still sends queries to a resolver provided by the local network, a test page may flag the result as a DNS leak. This can reveal where queries for domains originate and may affect geolocation, rule matching, and content access.

After connecting, use a DNS test page and examine the network ownership of the resolvers handling your queries. The ideal result depends on the client design: queries may be handled by a resolver provided by the route service or sent to an encrypted DNS service you selected. The resolver name does not need to match the node name. What matters is that it matches the current configuration and does not unexpectedly fall back to the local resolver path used before connecting.

Why browser secure DNS can affect the result

Modern browsers can bypass the operating system’s traditional DNS settings and send queries directly to the encrypted resolver selected in the browser. As a result, system-level and browser-level tests may show different results. This does not necessarily indicate a leak, but it does show that the browser controls DNS separately. If the client should handle DNS centrally, check whether the browser’s secure DNS setting overrides the system configuration. If you intentionally use separate encrypted DNS, make sure the routing rules and destination service support that path.

An unfamiliar resolver alone is not enough to draw a conclusion. Public resolvers may use distributed nodes, so the displayed region and organization may differ from the actual access point. A more useful comparison is to run one test while disconnected and another after connecting, then review the client’s DNS rules to see whether requests use direct or proxy resolution.

Per-app testing: a working browser does not prove other apps are working

A commonly overlooked issue is that different apps use different network paths. Browsers often read system proxy settings, while games, command-line tools, downloaders, and some desktop clients may connect directly. Conversely, a browser extension can proxy web pages while other traffic on the system remains direct. To determine whether a VPN covers the scenario you actually need, test each relevant app separately.

Cross-check with the same destination

First open an exit lookup service in your browser, then inspect connection details using the target app’s available network diagnostics. If the app has no exit check, review the client connection log: when the app starts or refreshes content, do corresponding domains, destination addresses, or connection records appear? Log results such as “proxy,” “direct,” and “reject” usually reveal more than the connection animation on the main screen.

Pause other background traffic during testing when possible so new log entries are easier to identify. If the browser produces records but the target app does not, the app may not read system proxy settings, or its traffic type may not be captured by the current mode. Testing again in virtual network interface mode can help distinguish an app that does not support the system proxy from a problem with the node connection itself.

Routing rules may intentionally keep traffic direct

Rule mode commonly keeps local services, LAN resources, or specified sites on a direct path while sending requests that need international routes through the proxy. Different exits may therefore indicate that the rules are working, not that something is broken. Open the client’s connection details and confirm which rule matched the target domain. When rules overlap, the result is usually determined by the first match or the most specific rule; exact behavior depends on the client’s rule engine.

If the target app accesses several domains, you may see a mixed state: the main page uses the proxy while images or media resources connect directly. Check the resource domains associated with failed requests, not just the page’s main domain. In streaming, downloads, and real-time communications, authentication, content, and media delivery may use different addresses. Missing one category of rule can make login work while content fails to load.

Use system routes and client mode to confirm whether traffic is being captured

When exit test results change repeatedly or only some apps have problems, inspect the system layer. Virtual network interface mode creates a new network interface and uses routing rules to send matching traffic into the client. System proxy mode mainly changes proxy settings and may not change the underlying default route. Both can support cross-border access, but their coverage and compatibility differ.

What to check on each platform

• Windows: Check whether the current client manages the system proxy, whether the virtual network interface is enabled, and whether an old interface remains after waking from sleep. Use route print in the command line to view route entries.
• macOS: Check the proxy settings for the current network service, system extension permissions, and virtual interface status. Use scutil --dns in the command line to view the system DNS configuration.
• Linux: Confirm that proxy environment variables, desktop network settings, and command-line programs use the same configuration. Use ip route to view the current route selection.
• iOS and Android: A connection indicator in the system status bar only shows that the configuration is enabled. Use client logs, an exit lookup, and results after restarting the app to assess the connection. Battery-saving policies may also affect background connections.

When viewing the routing table, you do not need to interpret every system entry. Focus on whether default traffic or the target address is sent through the expected interface. If local network access must remain available, the client will usually preserve direct LAN rules. Deleting them manually can make printers, gateway management pages, or local file services unreachable, so save the original configuration before making changes.

A successful protocol connection does not mean the system is fully covered

Shadowsocks, VMess, Trojan, and VLESS commonly use a proxy core to establish a transport channel to a remote node; Hysteria2 and TUIC focus more on UDP-based transport designs. The protocol determines how the client communicates with the node, but it does not by itself determine which local apps enter the channel. Full-system coverage still depends on the system proxy, virtual network interface, transparent proxy support, and routing rules.

A subscription link imports nodes and related settings into a compatible client. A successful import only means that the client read the subscription content; it does not mean that a node has been selected, a connection started, or the correct rules applied. Troubleshooting should confirm, in order, that the subscription was updated, a node was selected, the operating mode matches expectations, and the connection log shows no handshake failure, resolution failure, or route rejection.

Direct, relay, and IEPL routes change the transport path, not the testing method

A direct route usually connects from the local network straight to a remote entry point, so the path is more affected by public-network routing. A relay route first connects to an intermediate entry point, which then forwards traffic through the service to the destination exit; this can improve routing quality in specific directions. An IEPL route generally uses dedicated transport to connect network resources in different regions, so its access and exit design differs from an ordinary public-network connection.

Regardless of the route type, the checks are the same: confirm that the target app enters the client, confirm that the DNS path matches the configuration, and confirm that the final exit changes as expected. The route name cannot replace practical testing. Even when remote transport works, a local app may connect directly because the system proxy is disabled. Even with the correct exit address, incorrect DNS or routing rules can still cause the destination service to identify the connection unexpectedly.

Latency is not reliable as sole evidence either. A distant node, network congestion, or a slow destination website can make access take longer after connecting. Conversely, a smooth relay path may be faster. A speed change shows only a difference in experience; it cannot independently prove which exit handled the request.

Troubleshooting order when the client says connected but traffic is unaffected

Effective troubleshooting should begin with the smallest-scope, easiest-to-reverse checks. Avoid resetting all network settings at the outset. The sequence below reduces variables and helps identify whether the issue comes from web caching, app settings, routing rules, or the node connection.

1. Confirm the operating mode: Check whether the client is using global, rule, or direct mode, and whether the target app is expected to use the proxy.
2. Try another test app: Recheck the exit in a private browsing window, then fully quit and restart the target app to rule out stale connections and cached data.
3. Check connection logs: Search for the target domain or address, confirm whether the rule result is proxy or direct, and look for resolution, handshake, or timeout messages.
4. Check DNS settings: Confirm that browser secure DNS, system resolution, and the client’s DNS policy are not overriding one another.
5. Change the capture method: If the system proxy works only in the browser, test virtual network interface mode when supported by the client.
6. Try another route: Test another available node in the same region to distinguish a single-route issue from a local configuration problem.
7. Check security software and old settings: A local firewall, another proxy app, or a leftover virtual interface may alter routing. Disable or adjust one item at a time, then restore it after testing.

If only one app still fails after changing nodes, the issue is more likely related to app compatibility or routing settings. If no app produces a new exit, first check whether the client is actually capturing system traffic. If the exit has changed but the target website still identifies the original region, continue by checking DNS, browser location permissions, account-region settings, and site cache. The network exit is only one signal of location; not every service relies on IP alone.

A reliable conclusion requires all three checks: exit, DNS, and the target app

The most reliable way to determine whether a VPN is working is to combine several pieces of evidence rather than rely on the client’s single status indicator. A changed exit IP suggests that the test request may have reached a remote exit. A DNS check confirms that name resolution did not take an unexpected path. Per-app testing confirms that the program needing the route actually entered the proxy path. When results conflict, use logs, system routes, and the client mode to narrow down the cause.

For everyday use, simplify the process to: record the disconnected state, connect and check again, retest the target app, then confirm DNS. If split tunneling is configured intentionally, compare direct results with the expected rules. This avoids mistaking normal routing for a failure and helps reveal cases where the browser works but other apps still use the original network.