Is your VPN working? A complete guide to checking your public IP, DNS, and app-by-app traffic

You cannot tell whether a VPN is working simply by looking for “Connected” in the client. That status usually means the client has established a session with a remote node; it does not mean your browser, desktop apps, and system DNS are all using the tunnel. A reliable check has three layers: compare your public IP before and after connecting, confirm where DNS requests go, and then verify the actual traffic path app by app.

Run these three checks in order. Your public IP is the clearest evidence of the result, DNS testing can reveal cases where name resolution and web traffic take different paths, and per-app testing identifies local detours caused by system proxies, TUN mode, or split-tunneling rules. Checking only one layer can make partial coverage look complete.

Public IP: Confirm where the request leaves your network

Your public IP is the address websites see as the source of your connection. In full-tunnel mode, requests to public testing pages typically leave through the selected node, so the result should differ from the disconnected state and broadly match the route’s country or region. Compare the change itself rather than focusing only on the location label shown on the page.

1. Disconnect the VPN, close the testing page, reopen it, and record your baseline public IP, location, and network operator information.
2. Connect to the target route, wait for the client to show that the connection is established, then visit the same testing page in a new browser tab.
3. Compare the two results. If the address and network attribution change as expected, this browser request has passed through the remote exit.
4. Check again after switching to another route to confirm that the result follows the node instead of remaining stuck on an old cached result.

Location databases are not updated in real time. The same address range may appear as a nearby city in different databases, and corporate networks may show a registered address rather than the data center’s location. A small location discrepancy is therefore not immediate evidence of failure. More useful signals are whether the address differs from the baseline, whether the network operator changed, and whether the result follows the route when you switch nodes.

If the address has not changed at all, do not keep switching nodes immediately. Check whether the browser has an independent proxy extension, whether the client is proxying only selected apps, and whether the destination is being sent direct by a split-tunneling rule. In rule mode, some clients access local sites directly by design; that does not mean the tunnel failed to establish.

DNS resolution: Identify split paths for web traffic and name lookups

Before accessing a domain, the system or browser must resolve its name to a network address. Web requests may use the VPN while DNS queries still go to the local network; alternatively, the client may take over DNS and send queries through the tunnel. A DNS leak generally means that resolution requests have left the controlled path you expected, but you must first understand the client’s DNS policy.

Encrypted DNS in the browser, secure DNS in the operating system, enterprise network policies, and a client’s built-in resolver can all change the result. A test page showing a resolver different from the VPN exit operator does not automatically indicate a leak. For example, if the browser is deliberately configured to use a public encrypted resolver, a different DNS and exit-network name may be expected. The key questions are whether the resolver matches your settings and whether queries unexpectedly returned to the local path used before connecting.

On desktop systems, first inspect the current interface and resolver, then decide whether to clear the cache. The commands below only read status or refresh the local cache; they do not replace the client’s DNS configuration:

Windows
ipconfig /all
ipconfig /flushdns
route print

macOS
scutil --dns
sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder
route -n get default

Linux
resolvectl status
resolvectl flush-caches
ip route

Mobile devices usually cannot show the full routing table directly, so use a comparison test: test once while disconnected, connect and close and reopen the browser before testing again, then use another app to access the same destination. If only one browser behaves unusually, check that browser’s own secure DNS, content filtering, and proxy settings first rather than changing the entire system.

Per-app testing: Confirm whether each program enters the tunnel

Public IP checks usually run in a browser, but real-world use also includes desktop clients, terminal tools, collaboration software, download programs, and background system services. They may not follow the same proxy settings. A browser can use the system proxy, while some desktop programs connect directly; TUN mode generally covers more traffic, but exclusions, LAN bypasses, and custom routes can still affect it.

Do not repeatedly refresh the same webpage as your only test. Choose the app you want to check, perform the same action once while disconnected and once while connected, and observe the exit, connection result, or client logs. If the app has proxy options, confirm whether it uses system settings, a manual proxy, or a direct connection. An app-specific proxy can override the system VPN path.

• ✅ Browser: Open a new private window to avoid interference from old connections, cached pages, and extension state.
• ✅ Terminal tools: Make a new network request and compare its exit information with what the browser shows.
• ✅ Desktop apps: Quit completely and reopen them so they do not keep reusing long-lived connections created before the VPN connected.
• ✅ Client logs: Check whether the target domain or connection is marked as proxied, direct, or rejected.
• ✅ Split-tunneling rules: Confirm that the destination matched the expected rule instead of being redirected by a region, domain, or process rule.
• ✅ Disconnect and retest: Disconnect the route and repeat the same action to confirm that the result changes with the connection state.

If the VPN works in the browser but not in a desktop app, a common cause is that the client only configured the system proxy while the app ignores system proxies. Check whether the client supports TUN mode, or specify a supported proxy in the app itself. Conversely, if the desktop app works but the browser does not, check browser extensions, independent proxy settings, and encrypted DNS.

Split-tunneling rules may choose a path by domain, address range, process, or destination region. In rule mode, it is normal for some sites to connect directly while others use a node. The goal is not to make every request show the same exit, but to confirm that each request follows the expected rule. For a full-tunnel check, temporarily switch to the client’s global mode, then restore the original split-tunneling policy when testing is complete.

Protocols and subscription imports: Why a connected client may still carry no traffic

Shadowsocks, VMess, Trojan, and VLESS are commonly used by general-purpose clients to take over traffic through a local proxy or TUN mode. A successful protocol connection only means that the client can communicate with the remote service. If the system proxy is off, the TUN interface is disabled, or an app bypasses the local proxy, its traffic may still connect directly.

Hysteria2 and TUIC generally use QUIC and UDP transport. Some networks restrict UDP, causing the client to repeatedly retry the handshake, show no data after connecting, or lose its usable path after a network change. Check the client logs first to see whether data continues to flow, then confirm that the current network permits the required transport and compare with an alternative configuration actually provided by the service. Do not assume configurations are interchangeable just because they use the same protocol name; authentication details, transport parameters, and server capabilities must match.

A subscription link is essentially the client’s entry point for retrieving node configurations. A successful import does not mean the node list will always remain current. After server-side updates, an older client may still retain cached data, and clients may differ in their support for subscription fields and advanced parameters. If a node appears normal but cannot access the target, update the subscription, select the node again, and verify that the client supports the configuration instead of guessing at unknown fields and editing them manually.

1. Confirm that the subscription update succeeded and that the list shows no obvious parsing errors or unsupported-feature warnings.
2. Choose a route with a complete configuration and check the client logs to confirm that it connects and continues transferring data.
3. Confirm that system proxy or TUN takeover is enabled, then compare the public IP.
4. Check DNS and split-tunneling rules to confirm that the test destination is not configured for direct access.
5. Compare it with another available configuration from the same service to distinguish network restrictions from a single-node issue.

IEPL dedicated lines, relays, and direct connections: Route type does not determine the final path

A direct connection usually means the client connects straight to the remote entry point, with the path determined mainly by the current network and public routing. A relay route first connects to a nearby or more suitable relay node, then forwards traffic to the remote exit. An IEPL dedicated line generally indicates dedicated backbone resources across the international segment, but the product label alone cannot prove that every app on your device has entered that route.

Regardless of the route type, the verification method is the same: check the target request’s exit first, confirm that DNS follows the policy, and then verify that the app matched the corresponding rule. Route type mainly affects transport and network performance; it cannot replace a local routing check. Even when the remote route works normally, an unenabled system proxy or a destination configured for direct access will make the exit check show your local network.

A relay route may also have different entry and exit attributions. The client connects to the entry point, while public websites see the final exit; these are not contradictory. During troubleshooting, do not treat the access address in client logs as the exit address a webpage should display. Evaluate the service configuration and the final request result separately.

Common false positives: Connected at a glance, but traffic is not using the tunnel

Another common false positive comes from long-lived connections. Collaboration software, browser tabs, and background sync programs may continue using sessions established before the VPN connected, so they do not choose a new path immediately. Fully quit the target app, then reopen it after the connection is established. Refreshing the interface alone may not close the underlying connection.

IPv4 and IPv6 both need to be considered. Some networks and clients take over only one protocol, allowing an app to prefer the path that was not intercepted. If a testing tool shows separate exits for the two protocols, confirm that both match the client’s policy. If the client explicitly supports only one, configure the system network according to its documentation to prevent the other type of traffic from bypassing the tunnel.

Troubleshooting order: From local configuration to route status

Troubleshoot from the nearest layer outward. First confirm local takeover and rules, then inspect the protocol session, and only afterward assess the remote route. This avoids repeatedly changing nodes before the system proxy is enabled and helps separate app, DNS, and route issues.

• ✅ Establish a baseline for your public IP and DNS while disconnected.
• ✅ Update the subscription and confirm that the selected configuration is fully recognized by the current client.
• ✅ Check that the system proxy, TUN interface, or platform VPN interface is enabled.
• ✅ Recheck the public IP in a new browser session, ruling out cache and extension effects.
• ✅ Verify system DNS, browser secure DNS, and the client’s DNS policy.
• ✅ Review split-tunneling logs to confirm that the test domain or process matched the expected rule.
• ✅ Fully restart the target app so it cannot keep reusing a long-lived connection from before the VPN connected.
• ✅ Try another available route from the same service to determine whether the issue is limited to one route.
• ✅ Rebuild the tunnel after switching networks and check whether routing and transport have recovered.

If the public IP, DNS, and app routing all match expectations but the target service remains unavailable, the issue may be with the target service’s policy, account status, app cache, or current network quality rather than the VPN. Keep the client logs, test time, selected route, and exact app behavior, then submit them to service support for investigation. If logs contain a subscription link, authentication fields, or connection credentials, remove that sensitive information first.