How to Check Whether Your VPN Is Really Working: A Beginner’s Guide to Checking IP and DNS

To check whether your VPN is really working, do not look only at whether the client says “Connected.” That status usually proves only that the client completed a handshake; it does not by itself prove that traffic from your browser, command-line tools, and other apps is passing through the tunnel. A reliable check starts with a baseline while disconnected, then verifies the exit IP, DNS, IPv6, system routes, and app routing in sequence.

The most practical method is not to look for a single “pass” result, but to compare identical conditions before and after connecting. Use the same device, network, and test page, and record the differences between the disconnected and connected states. If the exit address changes but DNS is still provided by the local network, web traffic and name resolution may be taking different paths. If the browser changes while other apps do not, the cause is usually the system proxy, TUN mode, or per-app rules.

Establish a network baseline before connecting

Before testing, fully disconnect the client and make sure no other proxy, browser extension, or old connection is still running. Open this site’s IP check page and record the network operator, country or region, and address type associated with your current exit IP. The key here is comparison, not deciding whether the baseline address itself is normal.

Next, check the DNS resolver currently in use. Different testing tools may identify resolver names and locations differently, so do not focus only on the map location. More useful clues are whether the resolver clearly belongs to the local network provider, a router, or a public DNS service configured earlier.

✅ Refresh the IP check page after disconnecting the client and record the exit network and region.
✅ Disable browser extensions that may proxy traffic independently so the baseline is not affected by old settings.
✅ Record the DNS resolver name, but do not treat a geographic mismatch as proof of a leak.
✅ Confirm that the device is connected to the expected network and rule out an exit change caused by switching networks.
✅ Keep the test page open and run the test again on the same page after connecting.

Check whether the exit IP changes after connecting

Start the client, select a route, and wait for the status to stabilize. Then return to the original test page and reload it. In global tunnel mode, the public exit normally changes from the local network’s exit to the network associated with the selected route. If the address, network operator, and region do not change as expected, treat the connection as not working until checked further instead of relying on the client icon.

A changed exit IP is a necessary check, but it is not the complete answer. A browser may use the route through an extension or system proxy while other apps continue connecting directly. Conversely, after TUN is enabled, most system traffic may enter the tunnel while sites designated for direct access still show the local exit. Before testing, determine whether the client is using global, rule-based, or direct mode.

Check	Common result in global tunnel mode	Possible normal exception	Signs that need further investigation
Exit IP	Changes to the route’s exit	The rules set the test site to direct access	Remains the local network exit
DNS resolution	Handled by the tunnel side or a specified resolver	A trusted public DNS service was configured manually	Unexpectedly returns to the local network resolver
IPv6	Enters the tunnel or is handled properly by the client	The current network does not provide IPv6	IPv4 uses the route while IPv6 goes directly out
Individual app	Follows the current global or split-routing rules	Explicitly configured to bypass the tunnel	An app that should use the proxy still shows the local exit

Why checking just one website is not enough

A system proxy mainly affects apps that honor system proxy settings. Some command-line tools, games, updaters, and software with its own network stack may ignore them. TUN mode creates a virtual network interface and uses system routes to handle more traffic, but exclusion rules, interface priority, and system permissions can still affect the result.

Browser extensions have a narrower scope and usually handle requests only within that browser. Seeing the browser’s exit change does not prove that the entire device has entered the tunnel. To protect other apps, check whether the client has enabled a system proxy or TUN, and whether the target app is on a bypass list.

Stage conclusion: If the exit IP, network operator, and route region change as expected, the current test request is leaving through the route’s exit. To confirm the device-wide connection state, continue by checking DNS, IPv6, and individual apps.

Check whether DNS follows the expected path

When you visit a website, the device usually sends the domain to a DNS resolver before connecting to the resulting server address. Even when web data is already passing through the tunnel, DNS queries may still be handled separately by the browser, security software, operating system, or local network. A DNS leak concerns whether those resolution requests unexpectedly leave the intended path.

Run a DNS test after connecting to the route and compare the result with your baseline. If the resolver still belongs to the local network provider while the client says DNS should be handled by the tunnel, investigate further. If the result shows a public DNS service or a resolver provided by the route, do not assume there is a problem solely because its location differs from the route region. Public DNS services widely use anycast networks, and test databases may assign the same service to different locations.

Encrypted DNS in the browser can change the result

Some browsers can enable encrypted DNS independently. Once enabled, domain requests may bypass the operating system’s default resolver and go directly to the service configured in the browser. This does not necessarily indicate a leak, but it means the browser and other apps may use different resolution paths. During troubleshooting, check the browser’s secure DNS setting and confirm that it matches your needs.

If you want the client to handle DNS consistently for all apps, temporarily disable the browser’s independent resolver and test again. If the result returns to normal, the issue is usually in the browser settings rather than the route protocol. If the result still points to the local network, continue by checking the client’s DNS interception, TUN permissions, and system network configuration.

Check IPv6, WebRTC, and split-routing rules

Some networks provide both IPv4 and IPv6. If the client takes over only IPv4 while the system continues to prefer IPv6 for connections, testing may show two exits: IPv4 from the route and IPv6 from the local network. This is commonly called an IPv6 leak.

The solution depends on the client’s capabilities. Clients with full dual-stack TUN support can route both types of traffic. Some clients disable IPv6 that they cannot take over while connected, while others require separate handling in the system network settings. Do not permanently change system configuration without understanding the impact. A safer order is to update the client configuration, check its TUN and DNS options, and then adjust the system network according to the client documentation.

WebRTC provides real-time communication in browsers. A test page may sometimes show a local interface address, a virtual interface address, or an anonymized candidate address. Seeing a local-network address does not mean the public exit has been exposed, because a local address does not by itself represent the external access path. The key question is whether an unexpected public direct exit is exposed.

Split routing can give different websites different exits

Rule mode decides whether traffic uses the route or connects directly based on domains, IPs, apps, or rule sets. For example, local services may connect directly while international websites use the route. If two test pages show different exits, that is not necessarily a fault; they may simply match different rules.

When troubleshooting split routing, temporarily switch the client to global mode and repeat the exit and DNS checks. If global mode works but rule mode does not, the connection and route are probably usable, and the issue is more likely rule matching. Then review the client connection log to confirm whether the test domain matched a proxy, direct-access, or reject rule.

Disconnect the current connection and record the IP and DNS baseline.
Enable global mode and reconnect to the same route.
Refresh the same test page and check the exit, DNS, and IPv6.
Restore rule mode and observe whether the result changes.
Review domain matching and the final outbound route in the connection log.
Test again after correcting the rules; do not use an old page result as a substitute for a new request.

Decision guide: If global mode works but rule mode does not, check split routing first. If the browser works but other apps do not, check the system proxy, TUN, and app bypass settings first. If IPv4 works but IPv6 does not, check dual-stack routing first.

Confirm on each platform that routing has really changed

Network permissions and inspection points differ across platforms. Windows and macOS commonly use both system proxy settings and virtual network interfaces. Linux more often requires checking the routing table, policy routing, and DNS service directly. iOS and Android mainly work through the VPN interfaces provided by the system, so less low-level routing information is visible to apps.

Windows

Confirm the current mode in the client. If only the system proxy is enabled, the browser may work while programs that ignore proxy settings continue connecting directly. For broader coverage, check whether the client supports and has enabled TUN, and confirm that security software is not blocking the virtual interface. Run the following command in a terminal to view the routing table:

route print

Check whether the client created a virtual interface and whether the default route or target network points to it. Routing-table details vary by client implementation, so do not judge by the interface name alone; confirm with the connection log and exit test as well.

macOS and Linux

On macOS, you can view proxy status in the system network settings and check the routing table for a tunnel interface. Linux has many combinations of desktop environments, network-management services, and command-line clients, so pay particular attention to whether policy routing and the DNS service are updated together.

netstat -rn
ip route

macOS typically uses the previous command to view routes; Linux can use the following one. If the client uses a transparent proxy, it may also redirect traffic through system firewall rules. In that case, viewing only the default route may not show the complete path, so use the client log as well.

iOS and Android

Mobile devices usually show a system-level VPN status, but the status icon still indicates only that the system interface has been established. Compare the same IP test page before and after connecting, and check whether the client enables per-app bypass, proxies only selected apps, or allows direct access to the local network.

If the connection still appears active after switching networks but websites cannot load, disconnect and establish the tunnel again. A network-interface change may invalidate the old session before the client interface updates. If one app always connects directly, check whether it has been excluded by a per-app rule.

Protocols, subscriptions, and route types do not replace verification

Shadowsocks, VMess, Trojan, VLESS, Hysteria2, and TUIC can all carry proxy traffic, but the protocol name itself cannot prove that system traffic has entered the tunnel. Shadowsocks is an encrypted proxy protocol. VMess and VLESS are commonly used by clients supporting multiple transport methods. Trojan typically carries connections with a TLS-like appearance. Hysteria2 and TUIC use QUIC-oriented transport designs with greater emphasis on performance across challenging networks.

These protocols determine how data travels between the client and server. System proxy settings, TUN, DNS handling, and split-routing rules determine which requests are handed to that connection. A successful node handshake proves only that the client can communicate with the server. If an app is not routed to the relevant outbound, it may still use the local network.

A subscription link is only a configuration-delivery entry point. After importing a subscription, the client receives nodes, names, and related parameters, but you still need to choose an available node, establish a connection, and enable the correct system-level traffic handling. A successful subscription update does not mean the current node is connected, and selecting a node does not mean the system proxy or TUN is enabled.

IEPL dedicated lines, relays, and direct connections describe the upstream path between the client and the route exit. With a direct connection, the device connects to the remote entry point itself. A relay first connects to an intermediate node and then forwards traffic to the exit. IEPL typically emphasizes the provider’s cross-border transmission link. Regardless of the upstream path, local verification is the same: check whether the client has taken over the request, whether the exit matches expectations, and whether DNS is handled according to configuration.

Common reasons a connection looks active but is not working

If the client shows Connected while tests still show the local exit, work through the following list in order. Change only one setting at a time, then reconnect and test again. Changing several settings at once makes the cause difficult to identify.

❌ A node was selected, but the system proxy or TUN was not enabled.
❌ A browser extension is connected, but other apps are outside its scope.
❌ The test website was assigned to direct access by a routing rule.
❌ The target app is on the per-app bypass list.
❌ An old proxy setting remains in the system, sending traffic to another local port.
❌ The required TUN permission was not granted, so the virtual interface was not established correctly.
❌ IPv4 has entered the route, but IPv6 is still leaving through the local network.
❌ The browser’s independent DNS setting conflicts with the client’s DNS policy.
❌ The old session became invalid after switching networks, but the client status has not refreshed.
❌ Multiple clients are modifying the system proxy or routes at the same time, overwriting one another’s settings.

When multiple clients conflict, disconnect everything first, quit the clients you are not using, clear the system proxy, and reconnect. Disconnect the current connection before switching clients to reduce interference from old virtual interfaces, DNS settings, and residual proxy state.

If only a specific website is inaccessible, do not immediately assume that the entire route has failed. Test other websites first, then check whether DNS resolves, whether the connection log matches a reject rule, and whether the site is restricting the current exit. A route-wide failure usually affects multiple destinations; an issue with one site is more likely related to routing, resolution, exit restrictions, or the site’s own status.

Build a repeatable end-to-end self-check

A reliable verification process should be repeatable, with a clear conclusion at every step. Disconnect first to establish a baseline, then use global mode to verify the route’s basic capability before restoring everyday split routing. This separates node issues from system traffic-handling and rule issues.

Close other proxies and extensions, then disconnect the client.
Record the local exit network, region, DNS, and IPv6 status.
Connect to the target route and confirm that the system proxy or TUN is enabled.
Check the exit IP again on the same page.
Run a DNS test and verify who the resolver belongs to.
Check whether IPv6 enters the tunnel or is handled correctly.
Test the browser and the apps you actually plan to use separately.
Restore split-routing rules and check the outbound route matched by the target domain.
Repeat the key checks after switching networks; do not carry over old conclusions.

The final judgment should not depend on a single green indicator, but on whether multiple results agree. The exit IP shows where the current request leaves the public internet, DNS shows who resolves the domain, IPv6 completes the dual-stack path check, and app testing verifies the scope of split routing. Only when all four match the current configuration can you confidently conclude that the VPN is working as intended.

Complete conclusion: A Connected status in the client is only the starting point. You can conclude that traffic has entered the intended tunnel when the exit IP has changed, the DNS path matches the configuration, IPv6 is not unexpectedly connecting directly, and the target app is using the correct outbound route.