How to confirm your VPN is really working: check your exit IP, DNS leaks, and per-app routing

How can you tell whether your VPN is really working? The most reliable method is not simply checking the client’s “Connected” status. Instead, verify your exit IP, DNS resolution path, and the actual traffic from each app. A connection status only shows that the client has established a session with a remote route; it does not prove that your browser, meeting software, download tools, and system background requests all use the same route.

Start by recording a baseline while disconnected, then reconnect and run the same tests. Looking only at a single result after connecting can make carrier addresses, browser caches, or routing rules look like problems. A complete check should answer three questions: Has the public source address changed? Is DNS resolution still handled by the original network? And has the app that needs acceleration actually entered the proxy or virtual network interface?

Separate “Connected” from Traffic is being routed

When a client shows Connected, it usually means the protocol handshake and authentication succeeded and a usable session is being maintained. This reflects the connection between the client and server; it does not directly describe how the operating system sends subsequent traffic into that session. The actual coverage depends on the operating mode, system permissions, routing table, proxy settings, and split-routing rules.

In system-proxy mode, the client often changes only the operating system’s proxy configuration. Browsers and apps that read that configuration use the proxy, while software that ignores it may continue connecting directly. TUN mode creates a virtual network interface and uses routing to handle more TCP, UDP, and DNS traffic, but exclusions, app-bound interfaces, and system permissions can still limit coverage.

The protocol name alone does not describe coverage. Shadowsocks, VMess, Trojan, and VLESS are commonly used by clients as proxy protocols; Hysteria2 and TUIC use QUIC-oriented transport designs suited to different network conditions. Regardless of the protocol, browser proxy settings, global proxy mode, split routing, or TUN interception are determined by the client configuration. A successful protocol connection does not mean every app automatically uses the route.

Use your exit IP to confirm the public path used by the current request

Your exit IP is the source address that external websites actually see. To test it, disconnect the client, open this site’s IP checker, and note the address and its location. Then close the original page, connect to the target route, and run the test again in a new private window. If the address and location change reasonably with the selected route, the browser request is leaving through a new exit.

A private window reduces interference from page caches, site storage, and extensions, but it does not automatically change the network path. If a regular window and a private window produce different results, first check browser extensions, separate proxy settings, and the browser’s own secure DNS rather than immediately assuming the route has failed.

The exit location should also match the selected node. After choosing a Singapore route, for example, the result may show a data-center address associated with that region or network provider. Geolocation databases are not updated in real time, and different test services may report different cities, so do not treat the city field as the only criterion. The more useful checks are whether the public address changed and whether the country or region matches the selected exit.

• ✅ Record the original exit IP and location while disconnected
• ✅ Open a new private window after connecting instead of refreshing an old result
• ✅ Compare the client’s selected region with the detected exit region
• ✅ Cross-check with another network request instead of relying only on the page’s connection message
• ❌ Do not treat page language, time zone, or search-result region as proof of your exit IP
• ❌ Do not declare the connection failed just because the city name differs slightly

If the address is exactly the same before and after connecting, first check whether the client is in rule-based mode. Some rule sets send local websites directly while routing only qualifying international sites through the accelerated route. If the test site is classified as direct, it will keep showing the original exit. Temporarily switch to global or TUN mode and test again, then restore your usual split-routing settings.

Also check whether the browser has its own proxy configured. The system client may be connected while a browser extension still points to another route, in which case the detected exit belongs to the extension. Conversely, if the client provides only a local proxy and the browser does not read system settings, requests may remain direct. During troubleshooting, temporarily disable duplicate proxy extensions and keep one clearly defined traffic entry point.

Check for DNS leaks and inspect the resolution path

Before accessing a domain, a device usually resolves it to a reachable address. If business traffic uses the accelerated route while DNS queries are still handled by the local network’s resolver, public traffic and domain lookups may take different paths. This is commonly called a DNS leak. It may not stop a page from loading, but it can weaken routing consistency and cause region-based resolution to mismatch.

When checking DNS, do not require the resolver’s country to exactly match the exit. A route service may use an independent public resolver, and the browser may enable encrypted DNS, so the resolver’s location does not have to correspond one-to-one with the exit node. A more useful check is whether the resolver changes as expected between disconnected and connected states, whether the original network provider’s resolver still appears, and whether the client says DNS is handled by the proxy or remotely.

1. Disconnect the route, open a DNS test page, and record the resolver name and network owner.
2. Close the test page and clear the relevant site data in the browser to avoid reusing an old result.
3. Connect to the route and confirm that the client’s remote DNS, proxy DNS, or TUN DNS option is enabled.
4. Run the test again and compare whether the resolver still points to the original network.
5. Test in both a regular browser and a browser with secure DNS enabled to determine whether the difference comes from the browser’s own settings.

DNS caches can also create misleading results. The system, browser, and apps may cache earlier resolutions, so a cached domain is not queried again on every visit. Use a fresh test session and have the test page generate an uncached query. Simply refreshing the same ordinary webpage is usually not enough to determine whether DNS has taken a different path.

If resolution still returns to the original network, first check the client’s DNS interception settings, TUN permissions, and split-routing rules. Some rules proxy business connections but leave DNS direct; others send selected domains to the local resolver so local-network resources remain accessible. Do not blindly delete every rule. First identify which policy matched the affected domain.

Verify browsers, desktop software, and terminals app by app

An exit-IP page can verify only the browser request that opened it. If your use case includes video meetings, chat tools, gaming platforms, command-line downloads, or sync software, verify each app separately from its own settings or the operating system’s connection records. An app may have a built-in proxy, ignore the system proxy, or send only some connections through the proxy.

Browser: rule out extensions and independent network settings

Browsers are easy to test but also highly susceptible to extension interference. Disable other proxy extensions first, check whether the browser follows the system proxy, and compare the exit results from regular and private windows. If one browser changes its exit while another does not, the cause is usually the browser proxy, extension permissions, or secure DNS—not the remote route itself.

Also watch for connections established through browser real-time communication features. Some pages use more than ordinary HTTPS requests and may try other network interfaces. If a test page displays multiple candidate addresses, do not look only at the prominent primary result. Consider whether the client has TUN enabled, whether the browser limits local-address exposure, and how the actual calling app behaves.

Desktop apps: confirm whether they read the system proxy

Support for system proxies varies across office software, downloaders, and sync tools. Some apps inherit the operating system settings automatically, some require an in-app “Use system proxy” option, and others can be fully intercepted only in TUN mode. If the browser’s exit changes but a desktop app still connects directly, check the app’s network settings before repeatedly switching nodes.

Video meetings may also use several transport methods at once. A login or messaging API working through an HTTP proxy does not mean audio and video use the same path. In system-proxy mode, “messages work but calls are unstable” may indicate that real-time traffic is not being proxied or that the proxy client has not intercepted the relevant UDP traffic. With the required system permissions, test again in TUN mode and confirm that the rules do not exclude the meeting app.

Terminal tools: environment variables do not equal global interception

Command-line programs generally do not automatically inherit every setting from a graphical client. Some tools read proxy environment variables, some use their own configuration files, and others send traffic according to system routes. A successful request in the terminal proves only that the path used by that command is available; it cannot replace testing other software.

If the client provides a local SOCKS or HTTP endpoint, point the terminal tool to that endpoint explicitly. In TUN mode, check whether the default and policy routes send the target address through the virtual interface. Do not keep environment-variable proxies, in-app proxies, and TUN interception enabled at the same time, or multiple layers will make the exit source difficult to identify.

• ✅ Check the exit IP in the browser and disable duplicate proxy extensions
• ✅ Check the “System proxy” or in-app proxy settings in desktop applications
• ✅ When real-time communication fails, confirm whether UDP traffic is intercepted by the current mode
• ✅ Check proxy environment variables and routing paths separately for terminal tools
• ❌ Do not use one browser’s test result as a substitute for every app
• ❌ Do not enable multiple proxy entry points with the same purpose during testing

Identify normal differences caused by split-routing rules

The purpose of split routing is not to make every request show the same exit. It selects a suitable path by domain, address, app, or region. Local services may connect directly, international websites may use the accelerated route, and local-network addresses may remain on the local network. Seeing different websites use different exits in rule-based mode may therefore mean the configuration is working as intended.

To judge whether split routing is correct, match each test target to the purpose of the rule. For an international route, choose a domain expected to enter the proxy. For a local direct connection, choose a service explicitly allowed by the rules. For app-based routing, send requests separately from an app that should be proxied and one that should be excluded. Testing only one IP page cannot cover different rules.

Route type and routing coverage are not the same thing. A direct route means the device connects directly to the remote entry point; a transit route first reaches a relay node and is then forwarded to the exit; IEPL typically describes a route whose cross-border segment uses dedicated-line resources. These options affect routing, congestion, and stability, but they do not automatically change whether a local app reads the proxy. If the browser has not entered the proxy, changing the route type cannot fix the local interception problem.

Common reasons it looks connected but isn’t routing traffic

Most problems do not mean the remote route is completely unavailable. They usually come from duplicate settings, insufficient permissions, or inconsistent test conditions. Troubleshoot in the order below; it is often more effective than repeatedly reinstalling the client.

1. The test site is set to direct in the rules. The client is connected, but the test domain is not entering the proxy. Temporarily switch to global mode to confirm.
2. The app ignores the system proxy. The browser changes its exit, but the desktop app still uses the original network. Check the in-app proxy or use a mode capable of intercepting system traffic.
3. A browser extension overrides the client settings. The extension points to an old route, another local port, or a direct rule, causing the browser result to differ from the system.
4. TUN permissions are not active. The interface shows a completed connection, but the virtual interface lacks the required permissions and the system route has not actually switched.
5. DNS still uses the local path. Business traffic enters the route, but DNS resolution is not intercepted. Check remote DNS and split-routing rules.
6. Cache makes the before-and-after results look identical. An old page, DNS cache, or site storage continues to show previous information. Use a fresh test session.
7. Multiple proxies are running at once. The system proxy, browser extension, in-app proxy, and TUN mode overlap, so the final exit is determined by whichever path takes effect last.
8. The network interface switched automatically. After the device moves from Wi-Fi to another available network, the old session may keep showing a connection icon even though the route has changed.

The checks that matter also vary by platform. On Windows, focus on the system proxy, virtual adapter, and whether apps read proxy settings. On macOS, check network-extension permissions and the active network service. On Android, review the system VPN indicator, per-app exclusions, and battery restrictions. On iOS, watch for on-demand rules and session state after switching apps. On Linux, proxy environment variables, desktop network settings, and routing configuration matter more.

Mobile operating systems may rebuild the connection after the screen locks, power-saving activates, or the network changes. When you return to the app and see “Connected,” run the exit check again instead of relying only on the status-bar icon. If the issue affects one app, inspect per-app routing first. If every app has returned to the original exit, check the system session and network permissions.

Build a repeatable verification workflow

A reliable test should be repeatable, not based on opening one page by chance. Keep the sequence fixed: baseline, exit, DNS, apps, then routing. Change only one condition at a time—for example, switch only the operating mode or disable only one extension—so you can identify which setting affects the result.

• ✅ Establish an exit-IP and DNS baseline while disconnected
• ✅ Recheck the exit location in a fresh session after connecting
• ✅ Compare whether DNS resolution still returns to the original network
• ✅ Test browsers, desktop apps, and terminal tools separately
• ✅ In rule-based mode, test different targets that should be proxied and connected directly
• ✅ Record the operating mode, node, and app settings so the issue can be reproduced
• ❌ Do not treat the client’s connection icon as the only evidence

If the exit IP, DNS, and the target app’s path all match expectations, the current configuration can be considered active. If only one layer is abnormal, troubleshoot that layer: an unchanged exit points to proxy interception or rules; a DNS issue points to resolution policy; and a single-app issue points to the in-app proxy or per-app exclusions. Breaking the problem into layers is more accurate than broadly concluding that “the VPN does not work.”

Finally, distinguish between a route being active and the experience being stable enough. Exit verification tells you where traffic goes, but it does not replace tests for latency, packet loss, bandwidth, or peak-time stability. IEPL, transit, and direct routes can perform differently, but those advantages cannot appear in apps if local interception is misconfigured. Confirm the path first, then evaluate the experience for a clearer troubleshooting order.