How to verify that your VPN is working: check your public IP, DNS, and per-app traffic

To confirm that your VPN is working, do not rely only on the client showing “Connected.” That status usually means the local client has completed a handshake with the remote node, but it does not prove that your browser, desktop applications, and system DNS are using the encrypted route as expected. A reliable check covers the public IP, DNS resolution path, routing mode, and individual applications in sequence. Comparing these results helps identify whether the issue lies with the node, system proxy, split-tunneling rules, or the application itself.

Before testing, record the network state without the VPN: the region associated with your public IP, whether commonly used websites open, and whether your browser has a separate proxy or secure DNS enabled. Then connect to the route and repeat the checks on the same device, network, and applications. The comparison is meaningful only when the conditions remain consistent. If you change the node, client, and browser at the same time, it becomes difficult to determine which layer caused the change.

Public IP check: confirm that your public exit address has changed

Your public IP is the address external websites see, making it the first evidence of whether traffic has reached the selected node. Open the IP check page before and after connecting, then compare the address and associated region. If the exit region after connecting matches the selected route, the browser’s web requests have at least passed through that node. If the address has not changed at all, check the proxy mode, system permissions, and split-tunneling rules first.

A changed address alone is not enough to draw a conclusion. Some browsers reuse network sessions created before the connection, and page caches may retain older results. If the results conflict, close the relevant tabs and reopen them, or fully quit and restart the browser before testing again. Do not rely only on a cached IP summary in search results; use a test page that sends a fresh request.

IP geolocation databases are not updated in real time, so the same address may show a different city or carrier in different testing services. A minor city-level discrepancy does not necessarily mean the route has failed. What matters more is whether the public address changed, whether the country or region fits your use case, and whether the destination website sees a stable, consistent exit.

DNS path check: rule out DNS requests taking a separate route

When you visit a domain, the device usually uses DNS to resolve it to an address first. If web traffic passes through a remote node while DNS requests go directly to the local network, a test page may show resolvers associated with your current access network. This is commonly called a DNS leak. It may not prevent pages from loading, but it makes domain lookups inconsistent with the expected tunnel route and can produce conflicting region signals.

Do not judge the result solely by the brand name of a resolver, since public DNS services may use nearby servers in different regions. It is more useful to compare whether the resolution path changed before and after connecting, whether the result matches the client configuration, and whether the browser has enabled its own encrypted DNS. Browser-level DNS, system DNS, client-provided DNS, and remote proxy resolution may all coexist, so first determine which one the current application is actually using.

• ✅ Run the test before and after connecting, and save both results for comparison.
• ✅ Check whether the client offers remote DNS, virtual-adapter DNS, or leak-protection options.
• ✅ Check whether the browser’s secure DNS setting overrides the system configuration.
• ✅ Fully restart the browser after changing settings to avoid using an old DNS cache.
• ❌ Do not assume that DNS requests use the remote route just because the page opens.
• ❌ Do not change multiple DNS options at once, or you will not know which setting took effect.

In system proxy mode, whether DNS is resolved remotely depends on the protocol, client implementation, and application behavior. Some applications resolve domains locally and send the resulting address to the proxy; others send the domain directly to the remote node. With a virtual adapter or system tunnel, the client can usually take unified control of DNS more easily, but browser-level DNS, system exception routes, and local network policies can still affect the result.

Proxy modes and full tunnels: understand what “Connected” actually covers

After the client reports a connection, whether traffic is captured depends on its operating mode. System proxy mode changes the operating system’s proxy settings, so browsers and apps that honor those settings use the proxy; programs that ignore system proxies, some background services, and certain game traffic may continue to connect directly. A virtual adapter or full tunnel captures routes at a lower level and usually covers more traffic, but exclusions and local network routes can still limit it.

Shadowsocks, VMess, Trojan, and VLESS are commonly used by clients built around proxy cores. They describe transport between the client and node; they do not automatically mean that every application will be captured. Hysteria2 and TUIC mainly use UDP-based transport designs, whose performance varies with carrier policies, firewalls, and client implementations. Whatever the protocol, check that the local listener, system proxy, virtual adapter, and routing rules are configured correctly.

Route types also need to be understood separately. Direct connection sends the device straight to the remote node, keeping the path simple but making cross-border link quality more dependent on the current access network. Transit routing first reaches a nearby entry point, then the service forwards traffic to the target exit, which helps coordinate paths across different networks. IEPL usually refers to enterprise-grade international dedicated-line resources supplied by carriers, organized differently from ordinary public-internet routes. A route name describes the transport path; it does not mean that local applications have entered it correctly.

Per-app verification: a working browser does not mean everything works

The most common mistake is to see that the browser’s IP has changed and assume the entire device is covered. In reality, the browser may be using a proxy extension while a desktop client connects directly; or the opposite may be true: the system tunnel works, but a separate browser proxy sends traffic along another route. Test each application according to its real use case rather than checking only one page.

1. Start by checking the public IP in your usual browser and make sure no separate proxy extension is enabled.
2. Then open the desktop application you need for cross-border access and check whether its network settings include “Use system proxy,” “Auto-detect,” or a separate proxy option.
3. If the application provides connection logs, confirm that the destination connection matches a client rule rather than a direct-connection rule.
4. Test domain access and direct-connection behavior separately to determine whether the issue occurs during DNS resolution or subsequent transport.
5. Disconnect and repeat the test to confirm that the observed difference comes from the current route rather than caching or the application’s own region settings.

Traditional desktop programs and store apps on Windows may use different network interfaces. On macOS, network-extension permissions affect virtual-adapter capture. Android clients often provide per-app include and exclude lists. iOS and iPadOS rely mainly on system VPN configuration, so browser-extension proxy behavior differs from desktop platforms. On Linux desktop environments, system proxies are not necessarily read by command-line programs; terminal tools often need separate environment-variable settings or unified capture through a system tunnel.

A subscription link only provides the client with nodes and parameters. Successfully importing it does not mean the system proxy is enabled or that the selected node is connected. After importing, choose a route, start the connection, and confirm that the client has the required system permissions. If the node list changes after an update, also check whether existing groups or automatic-selection rules still point to an available route.

Split-tunneling rule check: find requests that are connecting directly by mistake

Split tunneling is not designed to send every request through one path. It assigns traffic to proxy, direct, or blocking policies based on domains, addresses, regions, or applications. In rule mode, an IP test page may use the proxy while another website still uses the local exit because it matches a direct rule. That is not necessarily a fault, but if the rules do not match the intended destination, the result may look like a working connection with no change at the target service.

For troubleshooting, temporarily switch to a mode with clearer coverage and compare the results. If the target app works under global mode or virtual-adapter capture but fails in rule mode, the issue is likely in the rule set, rule order, or domain-resolution method. Once confirmed, return to the mode suited to daily use and correct the rules; repeatedly switching modes is not a good long-term substitute for fixing the configuration.

Request enters the client
Check app exclusion rules
Check domain and address rules
Choose proxy, direct connection, or blocking
Establish a connection using the selected path
Record the matched rule and exit

Rules generally proceed from specific conditions to broader fallback entries, with actual priority determined by the client implementation. A domain resolved locally may become an address-rule match, while remote resolution may preserve the domain information; the two approaches can produce different matches. If the same domain switches between proxy and direct connection, check whether it uses multiple subdomains, content-delivery addresses, or a separate login endpoint.

Common failure scenarios and the recommended fix order

When a connection appears active but does not work as expected, there is usually more than one possible cause. Troubleshoot in a fixed order to avoid making the configuration harder to understand. First confirm that the client connected, then verify the local capture method, followed by the exit, DNS, rules, and application. Change one thing at a time and repeat the same test after each change.

• ✅ Exit unchanged: confirm that the system proxy or virtual adapter is enabled and that the client has the required system permissions.
• ✅ Browser works but desktop app fails: check whether the app ignores the system proxy and use a supported tunnel mode if necessary.
• ✅ Exit changed but DNS is inconsistent: check secure DNS in the browser, the system cache, and the client’s remote-resolution settings.
• ✅ Rule mode fails while global mode works: inspect the split-tunneling rule matched by the request and verify the rule order.
• ✅ No traffic after importing the subscription: confirm that a node has been selected and the connection started; importing alone does not capture network traffic.
• ✅ Results do not update after switching routes: close the old session and restart the app to rule out connection reuse and caching.
• ❌ Do not run multiple clients that modify the system proxy or routing at the same time.
• ❌ Do not judge the status of all traffic from a client icon, notification badge, or single webpage.

If no applications can connect, first check whether the current network allows the selected protocol to establish a connection, then try another route from the same subscription or another protocol supported by the client. If only a specific destination fails, the cause is more likely split tunneling, DNS, the destination service’s region detection, or app caching. If the issue occurs on only one platform, also check that platform’s permission model and app exclusion list.

After fixing the issue, repeat the complete verification process: record the connection state, check the public IP, check the DNS path, and test the applications used in practice. Finally, disconnect and test again to confirm that the exit and access path have returned to their pre-connection state. This proves that the route works when connected and can also reveal leftover issues, such as the system proxy not being restored after the client exits.