How can you confirm your VPN is working? Check your exit IP and DNS with this complete guide

To verify that a VPN is working, don’t rely only on the client’s “Connected” status. This usually means the client has completed a handshake with the node or started a local proxy port; it does not by itself prove that browser, desktop app, IPv6, and DNS traffic use the intended route. A reliable check starts with a baseline before connecting, followed by checks of your exit IP, DNS resolution path, and each app’s actual behavior.

Separate “the tunnel was established” from “application traffic entered the tunnel.” The client can indicate the former, but the latter requires external checks alongside local routing information. System proxies, TUN mode, split-tunneling rules, and an app’s own network settings can all change the result. On the same device, a browser may use the route while a command-line tool connects directly.

First check your exit IP: see where web traffic leaves

Your exit IP is the most direct verification point. Open the IP Check page on this site and compare the public address, region, and network owner while disconnected and connected. If the address and region change to those associated with the selected node, the browser request used to open the check page is going through the route.

However, an IP change only proves that the tested request took a different path; it does not automatically cover every app on the device. A browser may follow the system proxy while a desktop app opens its own direct connection. IPv4 may use the proxy while IPv6 still exits through the local network. Interpret the result together with the client mode.

• ✅ Record the public address and network owner while disconnected as your comparison baseline.
• ✅ Reload the check page after connecting to the target node and confirm the expected change in public address and region.
• ✅ Check both IPv4 and IPv6. If IPv6 is available locally but is not managed by the client, continue by inspecting the routes.
• ✅ Recheck in a private window or after clearing the check page’s cache to avoid reused content.
• ❌ Do not judge by page language, time zone, or search-result region alone; account settings and cached data can affect them.

Why is my IP unchanged after connecting?

A common cause is that the client started a local proxy but the system proxy is disabled, so the browser was never explicitly configured to use it. Another possibility is that rule mode classified the check site as direct. The client is online, but the request bypasses the node according to the split-tunneling rules. Temporarily switch to global mode and test again. If the address changes in global mode, the issue is usually rule matching rather than the node handshake.

Also check that the proxy type listened to by the client matches the app’s settings. For example, the app may be configured for an HTTP proxy while the client exposes only a SOCKS interface, or the proxy address and port may not match the active listener. Either case can cause a silent fallback to a direct connection. Rather than repeatedly guessing and switching nodes, check the client log for the relevant domain or connection entry.

Then check DNS: is domain resolution handled as expected?

Before connecting to a website, a device usually resolves its domain name into a reachable address. If DNS queries still go to the local network’s default resolver, the domains being queried may be exposed, and results that do not match the node’s region may affect access. A DNS leak is not simply “any unfamiliar resolver appearing on a test page”; the key question is whether queries bypass the expected encrypted, proxied, or remote resolution path.

After connecting, run a DNS test and check whether the resolver’s network and region match the client configuration. If the client is set to use remote resolution, the result should generally align with the route-side policy. If local encrypted DNS is enabled, the test may show the selected public resolver, which does not necessarily indicate a leak. The correct standard is the actual configuration, not a requirement that the DNS region exactly match the exit IP.

Browser Secure DNS can change the test result

Some browsers can enable Secure DNS independently. When enabled, the browser may send domain queries directly to the selected resolver instead of handing them to the operating system or client. In that case, the exit IP test may be normal while the DNS test shows a different resolver. This does not necessarily mean traffic left the local network unencrypted, but it does show that the browser’s resolution path differs from the client’s unified DNS policy.

For troubleshooting, temporarily disable the browser’s independent resolver and let it follow the system settings, then compare the results. If the result changes, decide whether to keep browser Secure DNS or let the client handle resolution centrally. The goal is consistent configuration, not several overlapping resolution layers.

Check IPv6 and per-app traffic: avoid proxying only part of the device

Many cases where the test page looks normal but an app does not are caused by incomplete traffic interception. When a device has both IPv4 and IPv6, apps choose a route based on the results returned by the system. If the client configures only IPv4 routes, IPv6-capable apps may use the local IPv6 exit directly. As a result, some connections in the same browser may use the node while others still leave through the local network.

Check both types of public address and inspect the virtual adapter, routing table, and IPv6 handling options in the client. If the client explicitly does not manage IPv6, adjust the system or client settings for your use case. Do not treat a changed primary web address as proof that the entire protocol stack is being managed.

Where system proxies and TUN mode take effect

System proxies mainly affect apps that read the operating system’s proxy settings. Common browsers usually follow them, but command-line programs, games, some store apps, and software with its own network stack may ignore them. TUN mode uses a virtual network interface and routes to intercept a broader range of IP traffic, making it useful for programs that do not support traditional proxy settings. It can still be affected by exclusions, local-network rules, and an app’s bound interface.

When checking per-app traffic, do not simply refresh the same webpage repeatedly. Use the software you actually need and watch the client’s connection log while it operates: does the target domain, address, or connection entry appear, and did it match a proxy rule or a direct rule? A rule-match result in the log is usually more reliable than a region label shown inside the app.

1. Keep the target node connected, then open the client’s connection log or live connection list.
2. Fully quit and restart the app under test so it does not reuse a long-lived connection created before connecting.
3. Trigger a clear network action in the app, such as refreshing content or reloading a page.
4. Return to the client and check whether the request appears and whether it matched a proxy, direct, or reject rule.
5. If there is no record, check whether the app bypasses the system proxy or is bound to a network interface that is not being managed.

Review split-tunneling rules: direct connections are not necessarily a fault

Rule mode is not designed to send every request through the same route. The client chooses proxy, direct, or reject based on domains, destination addresses, processes, or rule sets. Services in mainland China, local device addresses, and LAN resources may be configured for direct access, while international sites enter the node according to the rules. Seeing a local exit and a node exit at the same time does not necessarily mean the connection failed; the key is whether each request follows the intended policy.

To judge whether split tunneling is working, start by asking which path the target should use. If the check site is mistakenly included in a direct rule, the exit IP will not change. If a service meant to connect directly is sent through the node, its login region may change or access may slow down. Temporarily using global mode can help isolate a rule issue, but its result should not be treated as the normal behavior of rule mode.

Rule order affects the result

Many clients match rules from top to bottom or according to a preset priority. If a broad direct rule appears before a more specific proxy rule, the latter may never match. After changing rules, confirm that the configuration was reloaded, and close old connections before testing again. Saving the text without reloading the core may leave the old rules active.

During diagnosis, first check the rule name in the log, then determine whether it comes from local configuration, a remote rule set, or a client default. Do not change several switches at once. Otherwise the symptom may disappear without revealing whether DNS, routing, or the rule change actually fixed it.

• ✅ The test site should match the expected proxy rule, rather than being intercepted first by a general direct rule.
• ✅ Reload the configuration after changing rules, and close old connections from the test app.
• ✅ Access LAN resources according to local rules; do not use an unchanged exit IP to judge whether they work correctly.
• ❌ Do not switch nodes, DNS, TUN, and rule modes at the same time; this removes control over the troubleshooting variables.
• ❌ Do not treat every direct connection record as a leak; expected direct access is normal in rule mode.

Check subscription links, nodes, and protocol compatibility

Successfully importing a subscription does not mean a usable node is currently selected. The client may read the subscription successfully while remaining on an old configuration, an automatic selection group, or a direct-access policy. Confirm that the subscription update time, current node name, policy-group selection, and configuration loaded by the running core all match. A subscription link is an account credential; keep it secure and never paste it into public test sites, screenshots, or shared log pages.

Shadowsocks, VMess, Trojan, and VLESS are common proxy protocols or protocol families, and client cores differ in what they support. Hysteria2 and TUIC depend more heavily on UDP reachability and client implementation. A node that imports into one client may not be fully recognized by another; “imported without errors” does not mean that the handshake, authentication, and traffic forwarding have all completed.

If the log shows an unrecognized protocol field, missing transport parameters, or an unsupported core version, address client compatibility first instead of continuing to inspect browser cache. Conversely, if the handshake is complete but the business request does not appear in the log, the issue is more likely to involve the system proxy, TUN interception, or split-tunneling rules.

How IEPL, relays, and direct connections affect testing

A direct line usually connects the device straight to a remote entry point, so the path is more visibly affected by the local network and international link. A relay line first connects to a nearby entry point, then uses the relay network to reach the exit. An IEPL dedicated line emphasizes a dedicated international Ethernet connection across a specific segment, while the path from the user’s device to the entry point still relies on local access. Whatever the topology, verify the result through the exit IP, DNS, and app logs; a node name alone cannot prove that traffic is being forwarded as expected.

Line topology also affects which addresses appear in logs. In a relay architecture, the entry address used by the client may differ from the exit address seen by websites; that is normal. Check whether the public exit matches the node description and whether business requests enter the correct policy group, rather than requiring the entry and exit to display the same address.

Common cases where a VPN looks connected but traffic goes direct

Combining the checks above can quickly identify most false-connection and partial-interception issues. Each situation below can occur while the client still shows Connected, so eliminate the possibilities one by one using evidence.

Recommended complete recheck sequence

1. Disconnect from the route and record the exit IP, DNS resolver, and IPv6 status.
2. Connect to the target node and confirm that the client log shows no handshake or configuration-loading errors.
3. Check the exit IP again and compare it with the disconnected state and the node’s region.
4. Run a DNS test to determine whether the resolution path matches the client settings.
5. Check IPv4 and IPv6 separately, and confirm that requests from key apps appear in the connection log.
6. If the results do not match, temporarily compare global and rule modes, then identify the specific split-tunneling rule.
7. After correcting the configuration, close old connections and restart verification from the baseline to avoid cache interference.

If the exit IP has changed but DNS, IPv6, or an app still behaves unexpectedly, preserve the timestamp, target domain, matched rule, and error details from the client log, then adjust one item at a time. Testing with a single variable is easier to diagnose than repeatedly changing nodes, and helps distinguish expected direct rules, browser-level DNS, and stale connections from a route failure.