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

To tell whether a VPN is working, you cannot rely only on the client’s “Connected” status. This usually means the local client has completed a handshake with the remote node, but it does not necessarily mean that traffic from your browser, command-line tools, and other apps is using the route. A reliable check should examine the exit IP, DNS resolution path, routing mode, and the results from specific apps.

The most useful order is to record your network characteristics before connecting, establish the connection and check the exit IP, verify DNS next, and then test apps that may bypass the proxy. This narrows the cause to the node, system proxy, virtual network interface, routing rules, or the app’s own settings instead of repeatedly switching routes at random.

First, understand what “Connected” really means

When a client establishes a connection, it first resolves the node address and then negotiates the protocol, encryption, and authentication details with the server. With connection methods such as Shadowsocks, VMess, Trojan, or VLESS, a successful handshake is usually enough for the client to show Connected. How traffic enters the connection channel still depends on the client’s traffic-capture method.

Common capture methods include a system proxy and a virtual network interface. A system proxy changes the proxy settings provided by the operating system. Browsers and desktop apps that follow those settings can usually use the route, while programs that ignore system proxy settings may continue connecting directly. A virtual network interface receives more traffic at the system routing layer and usually covers a wider range, but it can still be affected by exclusion rules, local routing, and an app’s own network stack.

IEPL dedicated lines, relay routes, and direct routes describe how traffic is organized between the node and the destination network. IEPL is generally used for more stable international transmission; a relay sends traffic to an intermediary entry point first, while a direct route connects the local network to the remote node directly. These differences affect connection quality, but not the verification method: check where the exit traffic, DNS requests, and app requests actually go.

Exit IP Test: Confirm Where Web Traffic Goes

The exit IP is the first thing to check because it directly shows which network gateway the test request uses to reach external services. Before testing, disconnect the client, open a page that displays public exit information, and record details such as the provider, region, and network organization. Then connect to the target route, close the original results tab, open the page again, and compare the two results.

1. Disconnect and record the current exit region and network organization.
2. Close the lookup page completely to avoid seeing cached results.
3. Connect to the target node and make sure the client is not repeatedly reconnecting or reporting errors.
4. Open the lookup page again and compare the exit region and network organization.
5. Repeat the check in another browser or with a command-line request to see whether the results match.

If the exit information changes to the region associated with the selected route, the request from the test tool has used that route. If nothing changes, first check whether the system proxy was applied, whether the virtual network interface is enabled, and whether the current routing mode has classified the lookup site as direct.

A changed exit IP still does not mean that all traffic is being captured. The browser may use the system proxy, while terminal tools, game platforms, or sync programs may connect directly. Exit IP testing is therefore best for answering “Did this request use the route?”; by itself, it cannot prove that every connection on the device follows the same path.

Browsers may also retain existing connections. Even after the route changes, a long-lived connection in an open tab may temporarily continue using the previously established session. Open a new tab for testing, and if necessary fully quit and relaunch the browser. A private browsing window can also reduce interference from extensions, caches, and persistent connections, but it does not change system routing automatically.

DNS Test: Check Whether Domain Resolution Bypasses the Connection

Web access usually begins with a DNS lookup that converts a domain name into a connectable address. Web content using an international route does not necessarily mean that DNS queries use the same path. If DNS requests are still handled by the local network, the resolved region may not match the exit region, certain domains may fail to resolve, or websites may keep timing out even though the connection interface looks normal.

When checking DNS, focus on the network and region associated with the resolver rather than only whether a page labels the result a “leak.” Different test pages use different criteria. A more reliable approach is to compare results before and after connecting: if the connection changes the exit but DNS still shows only the local network’s default resolver, check the client’s DNS capture settings.

• Check whether the client has enabled remote DNS or encrypted DNS.
• Check whether routing rules are sending DNS requests around the virtual network interface.
• Check whether the browser has enabled its own Secure DNS and is using a separate resolver.
• Check whether the system still contains manually configured DNS servers.
• After switching routes, clear the system and browser DNS caches, then test again.

A DNS leak generally means that resolution requests expected to use the connection channel are actually sent to the local network or another unintended resolver. It may not prevent webpages from loading, but it makes the exit path and resolution path inconsistent. For content services that rely on region-based resolution, this mismatch may also return addresses unsuitable for the current exit.

A browser’s Secure DNS is a common source of interference. It may bypass the operating system’s default resolution settings and connect directly to the resolver selected in the browser. If only one browser shows an unusual DNS result while other apps work normally, check that browser’s settings first. If every app shows the same result, inspect DNS capture at the client and system levels.

Per-App Testing: Find Programs That Are Not Using the Route

Per-app testing addresses a common situation: the browser test works, but command-line tools, download utilities, game launchers, or desktop clients still use the original network. The node is often fine; different apps simply handle proxy settings differently.

Start with a browser whose exit IP has already been verified as a baseline. Then open the other apps one at a time and check whether they can reach the same destination, whether the displayed region matches, and whether the client connection log shows the corresponding request. Test only one app at a time so background requests do not make the logs difficult to interpret.

If the client offers Global, Rules, and Direct modes, temporarily switch to the mode with broader coverage for comparison. If the app works after expanding traffic capture, the node is usable and the issue is more likely in the routing rules. Do not rely on indiscriminate global forwarding long term; check whether the destination domain, address range, or app process was incorrectly assigned to Direct.

Routing rules commonly select a path by domain, destination address, geographic database, app process, or protocol type. Rule order also matters: a broad Direct rule near the top may match first, preventing later proxy rules from running. Restart the affected app after making changes because existing connections do not automatically move to the new path.

A subscription link only supplies node and configuration updates to the client; it does not mean that system traffic is already being captured. After importing a subscription, select a node, enable the connection, and choose a proxy mode. If the subscription updates successfully but the exit remains unchanged, check local traffic-capture settings instead of repeatedly importing the subscription.

Troubleshooting Order When the Client Shows Connected but No Traffic Passes

When you see “Connected but unable to access,” check from the local device toward the remote end in order. This is usually more effective than switching protocols at random. First confirm that the device itself has a working network connection, then watch whether the client keeps reconnecting. If the underlying network is unavailable, the client may retain its previous status without producing any effective forwarding.

1. Confirm the basic connection: Disconnect the client and open a regular website to rule out an interruption in the current network.
2. Choose another node: Refresh the subscription and select another available route to rule out an expired configuration on a single node.
3. Check the clock: An incorrect system time can cause certificate validation or authentication to fail. Enable automatic time synchronization.
4. Check the capture mode: A system proxy suits apps that follow proxy settings; test a virtual network interface when broader coverage is needed.
5. Check routing: Temporarily broaden traffic capture to determine whether the destination was mistakenly classified as Direct.
6. Check DNS: Switch to the remote resolution method provided by the client and clear old caches.
7. Check for conflicts: Quit other programs that modify proxies, routes, or network filtering, then try again.

Switching protocols should come after the basic checks. Shadowsocks primarily provides encrypted proxy transport; VMess and VLESS are commonly used for client-side rule-based forwarding; Trojan combines authentication with encrypted transport and is often paired with transport-layer security settings. The client and server configurations must match for each protocol. Changing only the client-side protocol name while keeping an incompatible port, transport method, or authentication detail will not work.

Connection logs can show which stage is failing. A domain-resolution failure usually points to DNS or the underlying network; a timeout connecting to the remote end may involve an unreachable node, route quality, or local network restrictions; an authentication failure is more likely to mean that the subscription has expired or the configuration does not match; a successful handshake with no app requests points back to the system proxy, virtual network interface, and routing rules.

Avoid changing the node, protocol, DNS, and routing at the same time. Change one setting, then repeat the exit IP and DNS checks so you can identify what made a difference. If several things change together, even a temporary recovery will be difficult to reproduce.

Verification Differences Across Windows, macOS, iOS, and Android

Windows desktop programs do not all support the system proxy consistently. Browsers usually read system settings, but some command-line programs and apps with their own network components require explicit proxy parameters or depend on a virtual network interface. If the browser’s exit changes but the terminal’s does not, check this difference first.

macOS also provides a system proxy, but apps may use their own networking implementation. After enabling a virtual network interface, check whether the system requests network-extension approval and whether the client extension remains enabled. After a system update or client reinstall, these permissions may need to be confirmed again.

On iOS, clients usually capture traffic through the VPN configuration provided by the system. The status-bar icon only shows that the system configuration is connected; it is still best to use a browser to check the exit and DNS. If one app behaves differently, check whether the client has enabled on-demand connection, per-app rules, or local-network exclusions.

Android clients usually rely on system VPN permission to create a virtual interface. Always-on settings, bypass permissions, battery-saving policies, and background restrictions can all affect connection persistence. If the route drops after switching to the background, check whether the system is restricting the client instead of assuming the remote node has failed.

Client interfaces differ across platforms, but the verification logic is the same: confirm the handshake, check the exit, inspect DNS, and finally test each app. Platform differences mainly affect how traffic enters the route, not the verification standard itself.

How to Tell When Testing Is Complete

Complete verification does not require every app to show exactly the same interface; it requires the path results to match expectations. Apps intended for international access should show an exit associated with the selected route; local services configured for direct access should continue using the local path; DNS resolution should not unexpectedly use a conflicting resolver; and after switching routes, newly established connections should use the new exit.

• Exit information clearly changes before and after connecting.
• The exit region matches the currently selected route.
• The DNS resolution path matches the client configuration.
• The browser, terminal, and target app have each been tested.
• The routing rules explain which requests connect directly and which use the route.
• After switching nodes, old connections are closed and repeated tests produce consistent results.

If the exit, DNS, and target app all behave as expected, the connection is confirmed to be working in practice. If only one layer is abnormal, troubleshoot that layer: an unchanged exit points to the capture method, abnormal DNS points to resolution settings, and a single affected app points to its proxy and routing rules. Breaking connection status into these separate layers is usually more effective than watching only the client button.