How to Check Whether Your VPN Is Working: Verify Your Public IP, DNS, and App Traffic

To confirm that a VPN is really working, do not rely only on the client’s “Connected” status. That status usually means the client has completed a handshake with the remote route, but it does not prove that your browser, desktop software, command-line tools, or DNS queries are using the expected path. A reliable check covers your public IP, DNS resolution, routing mode, and individual apps in sequence, comparing results before and after connecting.

If your public address changes but an app still shows the previous network location, the problem is usually not the route handshake. Look instead at the system proxy, TUN mode, split-tunneling rules, cached connections, or the app’s own networking implementation. Conversely, a page loading normally does not prove that every request is using the route: rule-based mode may proxy only selected domains while sending other traffic directly over the local network.

What “working” actually involves

A VPN is not a single on/off switch. A complete connection involves the route handshake, system routing, name resolution, and application traffic. If any layer fails to behave as expected, the interface may look normal while the actual path is not.

Different clients offer different levels of control over these layers. On desktop, “system proxy” settings mainly change the operating system’s proxy configuration, and only apps that read those settings will follow it. TUN mode creates a virtual network interface and uses routing tables to handle a broader range of traffic, making it more suitable for software that does not support proxy settings, though it usually requires the relevant system permissions.

Mobile clients generally use the system-provided VPN interface to handle traffic centrally, but per-app exclusions, on-demand connections, private DNS, or app-level encrypted DNS can still affect the result. As a result, the same Shadowsocks, VMess, Trojan, VLESS, Hysteria2, or TUIC configuration may have different coverage on different platforms even when each one says “Connected.”

The right order for checking your public IP

Your public IP is the most straightforward starting point, but you must record the disconnected state first for a meaningful comparison. Opening a lookup page only after connecting and seeing an unfamiliar address is not enough to prove that the result belongs to the current route. Corporate networks, shared networks, and upstream proxies can also make a public address differ from a device’s local-network address.

1. Disconnect the client. Fully end the existing connection and disable on-demand rules that may reconnect automatically.
2. Record a baseline. Note your current public exit, network provider, and approximate region. Do not publish the full address in a public screenshot.
3. Reconnect. Select a route in an easy-to-identify region and wait for the client status to stabilize.
4. Start a new session. Use a fresh browser private window to avoid interference from old pages, caches, and persistent connections.
5. Run the check again. Compare the public address, region, and network ownership to see whether they changed with the route.
6. Recheck after switching routes. Switch to another route group and reload to make sure the result is not coming from the lookup page’s cache.

• ✅ The public address changed, the region matches the selected route, and you can continue by checking DNS and app traffic.
• ✅ The browser and system networking tools show the same public exit, suggesting consistent coverage.
• ❌ The address is unchanged. Check whether the current rules send the lookup domain direct.
• ❌ Only the browser’s address changed while other software stayed the same. This usually means system proxy mode is being used rather than full traffic handling.
• ❌ The old region still appears after switching routes. The cause may be page caching, connection reuse, or an old process that was not closed.

Check IPv4 and IPv6 separately as well. Some local networks provide both address types, while a client may handle only IPv4. In that case, a standard lookup may show a changed public exit even though IPv6-capable apps still prefer the local path. Do not simply disable every networking capability. First confirm whether the client supports IPv6 handling; if it does not, follow the client documentation to decide whether to disable IPv6, block it, or let the rules manage it.

Is DNS resolution being handled as expected?

Before a browser can access a domain, it usually needs to resolve that domain to an IP address. A DNS leak generally means that requests expected to use a resolver inside the route or a specified encrypted resolver continue going to a service provided by the local network. This does not necessarily prevent pages from loading, but it can reveal the range of domains queried and may produce results that do not match the route’s region.

You cannot determine whether DNS is abnormal simply by looking at the resolver names listed on a test page. Modern clients may use public DNS, DoH, DoT, remote resolution, or per-domain routing; browsers may also enable their own secure DNS. These results do not necessarily belong to the same network as the public exit. The key question is whether the results match the current configuration, not whether the resolver name exactly matches the public IP’s network.

How to make DNS results interpretable

Open the client’s DNS settings first and identify the active policy: system resolution, resolution through the remote route, a specified encrypted DNS service, or per-domain handling. Then clear old caches and run the query again. Different desktop systems provide corresponding commands for refreshing the cache:

Windows:
ipconfig /flushdns

macOS:
sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder

Linux with systemd-resolved:
resolvectl flush-caches

After refreshing the system cache, close and reopen the browser as well, because it may maintain its own cache and connection pool. If the browser uses its own encrypted DNS, a system command will not clear all of its state. Check the resolution policy in the browser’s network settings.

• ✅ The resolver matches the client’s configuration, and query results change when the configuration changes.
• ✅ Local domains use local rules and international domains use remote rules, matching the split-routing design.
• ❌ The client is configured for remote resolution, but the test consistently shows only local-network resolvers.
• ❌ Browser and command-line resolution results remain different. Check the browser’s independent DNS settings.
• ❌ Domains still return clearly outdated addresses after switching routes. Clear the system, browser, and app caches.

Split DNS is more complex than using a single resolution path. For example, local domains may be handled by a local resolver and accessed directly, while other domains are resolved remotely and sent through the route. In this situation, seeing requests from different sources on a test page does not necessarily indicate a leak. Focus on whether the rules behave as intended and whether domains that require remote resolution are being incorrectly sent to the local resolver.

Verify the traffic path app by app

Once the public IP and DNS look correct, verify the software you actually use one app at a time. A browser using the route does not mean that games, downloaders, terminals, sync tools, and desktop clients will read the same proxy settings. In system proxy mode especially, some apps establish connections directly and ignore the operating system proxy completely.

Browsers

Browsers are usually the easiest apps to test, but they are also affected by extensions, independent proxy settings, secure DNS, and connection reuse. Disable extensions that modify the network path, then test in a fresh private window. If one browser works and another does not, compare their proxy and DNS settings instead of immediately switching nodes.

Command-line and developer tools

Whether a command-line tool uses a proxy depends on the tool itself, environment variables, and the system implementation. Some tools read proxy environment variables, some require an explicitly specified proxy, and others are transparently handled only in TUN mode. During testing, review the client connection log as well to confirm whether the request matched a proxy, direct, or reject rule.

Desktop software and mobile apps

Desktop software may use its own networking stack, and mobile apps may establish independent QUIC or other UDP sessions. If the current node protocol or client mode handles only TCP, these requests may continue directly or fail outright. Hysteria2 and TUIC use UDP as their transport foundation, but enabling either protocol does not mean that all app UDP traffic will automatically be handled; whether traffic enters the tunnel still depends on the client’s routing and TUN configuration.

Per-app and bypass rules

Some clients let you choose which apps use the route and which remain direct. During troubleshooting, check both the included and excluded lists. App updates may change executable paths or package identifiers; if a rule still references the old path, the new version may no longer match the original policy.

Why traffic may not use the route even when the client says Connected

The most common cause is that the client connected to the node but failed to update the system proxy or routing successfully. Insufficient permissions, a failed virtual adapter initialization, or another networking tool overwriting the settings can leave the control plane online while the data plane remains untouched. Check the client log first instead of repeatedly clicking Connect.

Choosing the wrong system proxy or TUN mode

When you only need a browser and apps that support proxies, system proxy mode is usually simpler. When you need to handle apps that do not read proxy settings, TUN mode is more suitable. These are not speed tiers; they are different traffic entry points. After enabling TUN, confirm that the virtual interface exists and that the default or policy routes have been added.

Split-routing rules sent the request direct

Rule-based mode chooses a path based on domains, IPs, processes, or rule sets. If the site used to check your public exit is classified as direct, its result will naturally remain unchanged. Switching briefly to global proxy mode can provide a useful comparison: if global mode works, the route itself is probably available and the problem is concentrated in the rules. Restore the split-routing mode you need after testing.

An old connection was not released

Browsers, chat apps, and sync tools maintain persistent connections. Switching routes does not always force these connections to reconnect immediately, so an app may temporarily continue using the old path. Fully quitting and reopening the app is more reliable than simply refreshing the page. For background processes, also confirm that the process has actually ended.

Multiple networking tools are competing for settings

When a corporate VPN, debugging proxy, network filter, or another route client runs at the same time, the routing and proxy settings written later may overwrite earlier ones. During troubleshooting, keep only the necessary tools active, pause programs that modify the network path, and restore them one at a time to identify the conflict.

The subscription configuration was not updated

The subscription link supplies nodes and rules to the client. After a server-side change, the local client may still retain an old copy. Update the subscription in the client, confirm that the update succeeded, and then select the route again. A subscription link is an access credential and should not be pasted into public testing sites or screenshots of an issue.

How route types affect troubleshooting

Direct, relay, and IEPL routes describe the network path between the route’s entry and exit points; they are not the same as the client’s traffic-handling method. A direct route connects the device to the remote node itself, keeping the path simple but relying more heavily on public-network quality between the local network and the destination region. A relay route first connects to a nearby entry point and then sends traffic through an intermediate network to the exit, which may improve routing stability in some network environments.

An IEPL dedicated route generally means that a dedicated or controlled link carries traffic between the entry and exit points, with the focus on the cross-region transport path. Regardless of the route type, the device still needs correct system proxy, TUN, DNS, and split-routing settings. A dedicated route does not automatically fix apps that bypass the proxy, nor does it replace public IP and DNS verification.

The protocol alone cannot determine whether the connection is working. Shadowsocks, VMess, Trojan, and VLESS provide different transport and authentication methods, while Hysteria2 and TUIC focus on UDP-based transport. What determines whether an app request enters the route is still how the client creates its local entry point and applies routing rules. If the node handshake succeeds but the app connects directly, check the local traffic-handling layer before assuming that the remote node has failed.

A repeatable end-to-end verification workflow

A temporary lookup page gives you only a momentary result. A more reliable approach is to follow a fixed checklist every time you change clients, import a subscription, adjust DNS, or modify split-routing rules. This makes it easier to identify which layer changed.

1. Update the configuration. Update the subscription in a trusted client and confirm that routes and rules loaded successfully.
2. Record the disconnected baseline. Save the exit region, address family, and current DNS policy without exposing the full network identifier.
3. Connect. Check the logs for a completed handshake, repeated retries, or virtual-interface errors.
4. Check the public exit. Use a new session to compare the IP before and after connecting, checking IPv4 and IPv6 separately.
5. Check DNS. Confirm that the resolver matches the client policy and rule out system and browser caches.
6. Check rule matches. See whether the test domain and app were classified as proxy or direct.
7. Test apps individually. Cover browsers, terminals, desktop software, and the mobile apps you need to use.
8. Recheck after switching routes. Confirm that apps establish new connections and that the public exit changes with the route.
9. Restore everyday mode. If you temporarily used global proxy mode for troubleshooting, restore the required split-routing configuration afterward.

• ✅ The client handshake is stable, with no repeated reconnect loop in the logs.
• ✅ The public exit matches the selected route, and no address family bypassed it unexpectedly.
• ✅ DNS queries follow the local, remote, or encrypted resolution policy.
• ✅ Every app that needs the route matched a proxy rule.
• ✅ Local services that should remain direct still follow the rules.
• ❌ You checked only the connection icon and did not verify the actual public exit or rule logs.

If only one app fails during the complete workflow, first collect its name, operating system, client mode, node protocol, matched-rule result, and error log. If no app can switch its public exit, check the system proxy, TUN interface, routing conflicts, and subscription configuration first. Narrowing the issue to a specific layer is much more efficient than repeatedly switching nodes.