How to Check Whether a VPN Is Working: Exit IP, DNS, and Per-App Tests

The key takeaway: a connected status does not prove that traffic is using the route

When a client shows Connected, it usually means that the local client and remote node completed a protocol handshake, or that the system accepted a proxy, virtual adapter, or VPN configuration created by the client. That alone does not prove that the browser, download tools, and other apps are sending traffic through this connection.

Break verification into separate layers: check whether the exit IP changed to see where public requests leave the network; check who handles DNS queries to determine whether domain lookups bypass the expected path; and test whether the target app actually matches proxy or tunnel rules to verify split tunneling. Only when these results align can you conclude that traffic is following the configured route.

Check the exit IP: confirm where web requests leave the network

The exit IP is the most direct thing to check. Disconnect the VPN and use a trusted IP lookup page to record the current public address and approximate region. Close the page, connect to the target route, then run the same lookup in a new private window. If the address or exit region changes to the area associated with the selected route, that browser request reached the remote exit.

Do not simply refresh an old tab. The browser may reuse an existing connection or retain site data. A safer approach is to close the relevant tabs, wait for the client to confirm the connection, and then open a new browser window. If the client provides connection logs, check for a new outbound entry while visiting the lookup page.

Check both IPv4 and IPv6

Some networks provide both IPv4 and IPv6, while a client may take over only one of them. If the lookup page shows that IPv4 changed but IPv6 still points to the local network, IPv6-capable sites may prefer the path that was not taken over. This often looks inconsistent: some sites show the route’s region while others still identify the original network region.

The solution depends on the client’s capabilities. Prefer TUN or system VPN mode when it can fully handle dual-stack traffic. If the current node, protocol, or client cannot handle IPv6, temporarily disable IPv6 on the local network only after understanding the impact, then reconnect and test again. Do not hide an inconsistent protocol stack by repeatedly switching nodes.

Why the exit region may not match the node name exactly

A node name usually describes its intended route or exit region, while IP databases are maintained by different services with varying update schedules and geolocation decisions. An address may have moved to a new data center while a lookup page still shows its former region. When regions differ, consider whether the public address changed, what region the target service actually returns, and what the client logs show instead of relying on one database.

IEPL, relay, and direct routes describe how traffic is transported before reaching the exit node. IEPL generally focuses on dedicated cross-border transport, a relay sends traffic through an intermediate node first, and a direct route connects from the local network to the remote entry point. These route types affect the path and stability, but the website ultimately sees the public address of the exit node. The exit IP alone cannot reveal which transport method was used earlier in the path.

Check DNS: identify whether domain lookups bypass the expected path

Before accessing a website, a device usually resolves its domain name to an IP address. Web content going through a VPN does not necessarily mean DNS requests use the same route. If the system still sends lookups to a resolver provided by the local network, the DNS path and content-traffic path do not match—a situation commonly called a DNS leak.

You can use a DNS test page to inspect the resolver’s network and region, but do not treat an exact match between resolver and exit regions as the only standard. Public resolvers may use nearby access points, and the displayed node name may not reflect the physical location. More importantly, check whether local-network resolvers keep appearing and whether the DNS path changes as expected after connecting.

Browser secure DNS can change the test results

Modern browsers may enable DNS over HTTPS, commonly known as DoH. The browser then bypasses the system DNS settings and sends encrypted queries directly to its configured resolver. A system-level VPN may still carry this connection, but the resolver name will not become the DNS configured in the client. With a rule-based proxy, the browser’s DoH requests may also connect directly because different rules apply.

When troubleshooting, first check the browser’s secure DNS setting, then see whether the client offers DNS hijacking, virtual DNS, remote resolution, or system-resolver options. Avoid changing several settings at once, or it will be difficult to tell which change worked. After testing, choose system DNS, client-side remote resolution, or browser secure DNS based on privacy needs, compatibility, and split-tunneling rules.

DNS caching can make a change appear ineffective

The system, browser, and apps may all cache previously resolved domains. After switching routes, an app may use a cached result when you revisit a recently opened site instead of making a new DNS query. If the DNS test log shows no request, that does not necessarily mean the configuration failed. Close the browser process, clear the system DNS cache, or test a domain you have not visited before, then check the result again.

DNS in a split-tunneling setup must work with the rules

Rule mode chooses direct or proxied paths based on domains, IPs, processes, or rule sets. If a domain is resolved through the local DNS first, the client may see only the resulting IP, preventing some domain-based rules from matching. Conversely, sending every domain to a remote resolver may return unsuitable addresses for local sites. More mature clients preserve this mapping with domain sniffing, virtual IPs, or rule-based resolver selection.

When the issue affects only a specific domain, check whether its domain rule appears after a broader direct rule, whether the rule set is up to date, and whether the app performs encrypted DNS on its own. If DNS results are correct but the page still cannot load, continue with routing, protocol handshakes, and target-service restrictions instead of repeatedly changing resolvers.

Per-app verification: confirm whether programs beyond the browser use the route

Many cases where a VPN is connected but an app does not work are caused by differences between proxy modes. A system proxy affects only programs that follow the system setting; TUN mode takes over more system traffic through a virtual adapter; an in-app proxy affects only the configured program. A browser reaching the target site does not mean games, command-line tools, sync software, or store apps use the same path.

Run the same test in each app

1. Disconnect and record the observable exit or access result separately in the browser and the target app.
2. Connect to the route, confirm that the client has no handshake errors, and keep the network environment unchanged.
3. Check the exit IP again in the browser, then make the same type of network request in the target app.
4. Review the client connection log to confirm that the target domain, address, or process appears and whether it matched a proxy or direct rule.
5. If the browser changes but the target app does not, switch to TUN mode or configure a separate proxy for that app if the client supports it.

Some apps ignore the system proxy, some use UDP, and others establish a long-lived connection at startup and reuse it continuously. After switching routes, an old connection may remain on the original path. Fully quit the target app before testing, then connect and restart it. Closing the window may not stop background processes, so confirm in the system task manager that the program is no longer running.

Rule mode, global mode, and direct rules

Global mode generally sends all traffic the client can take over to the node, making it useful for quickly checking whether split-tunneling rules are the cause. Rule mode selects a path based on the destination address, domain, or app and is better suited to daily use. If global mode works but rule mode does not, focus on rule order, rule-set versions, process matching, and DNS mapping rather than the protocol itself.

Local networks, printers, LAN file shares, and some local services usually need to stay on a direct path. If they stop working after global takeover is enabled, that does not mean the VPN has failed; the LAN bypass option may simply be disabled. Verifying international access and maintaining local-network connectivity are separate goals and should be checked separately.

System proxy vs. TUN mode

A working protocol and subscription do not prove that system routing is correct

Shadowsocks, VMess, Trojan, VLESS, Hysteria2, and TUIC can be used as protocols or transport methods when a client connects to a node, but they address how the client and server establish and carry the connection. Whether app traffic enters that connection is still determined by the client’s system proxy, TUN, routing, and split-tunneling configuration.

For example, a Shadowsocks, VMess, Trojan, or VLESS node may show a successful handshake in the client log, but if the system proxy is disabled and the browser has no proxy configured, web traffic may still connect directly. Hysteria2 and TUIC commonly use UDP-based transport; if the local network handles UDP poorly, a session may be established while actual requests remain unstable. Compare other protocol routes and check the log for timeouts, retransmissions, or handshake failures instead of judging only by the connection button’s color.

A subscription link only delivers node configuration

A subscription link typically imports node addresses, ports, protocol parameters, and route names into the client. A successful import means the client can read and parse the subscription; it does not mean the node is connected or that operating-system traffic has been taken over. After updating the subscription, select a node, enable the appropriate takeover mode, and run an actual exit test.

If every node suddenly becomes unavailable after a subscription update, first check that the system time is accurate, the client supports the protocols in the subscription, old settings are not overriding the new ones, and the network is not blocking the node entry point. Do not repeatedly import the same subscription into multiple clients and enable them all at once; competing system proxies or virtual adapters make routing results harder to interpret.

What to check on different platforms

Windows

On Windows, check the system proxy, virtual adapter, and routing table together. Some desktop programs read the system proxy, while others open network connections directly. With TUN mode, the client usually needs to create a virtual adapter and add routes. If permissions are insufficient, security policies block driver loading, or another network tool changes the routes, the interface may show a successful connection while traffic does not enter the tunnel as expected.

macOS

On macOS, a client may take over traffic through a system VPN configuration, network extension, or system proxy. The required system permissions must be granted the first time it is enabled. If an old VPN configuration or another network extension exists in System Settings, avoid enabling them simultaneously. When the browser works but command-line tools connect directly, check whether the active setup is a system proxy or a full-tunnel mode.

iOS and Android

Mobile platforms usually carry the connection through the system VPN interface, but power-saving policies, background restrictions, and network changes can interrupt the tunnel. After switching from Wi-Fi to a mobile network, check the VPN indicator in the system status bar and test the exit again. Android clients may also offer per-app proxy settings or a bypass list; an app added to that list will continue to connect directly.

Linux

Linux has many combinations of network stacks and desktop environments, so distinguish between proxy environment variables, desktop proxy settings, TUN devices, and policy routing. A graphical browser may follow the desktop proxy, while terminal programs may read their own proxy environment variables. With TUN, check that the device was created, the default route and policy rules were added, and the DNS management service has not overridden the client settings.

Connected but traffic is not using the route: troubleshoot in order

The key is to change only one variable at a time. Start with the basic connection and exit checks, then move to DNS, split tunneling, and the protocol layer. Changing the node, protocol, DNS, and client all at once may make the issue disappear temporarily without revealing the real cause.

1. Confirm that the basic network works. Disconnect the client and visit a familiar website. If the underlying network is down, restore the local connection first.
2. Rebuild the client connection. Disconnect the current node, close potentially conflicting network tools, reconnect, and review the handshake log.
3. Switch to global takeover for comparison. If global mode works but rule mode does not, inspect rule matching and DNS configuration.
4. Restart the target app. End its background process so an old connection cannot continue reusing the original path.
5. Check IPv4, IPv6, and DNS separately. Confirm that traffic is not split between the route and a direct connection because of a dual-stack issue.
6. Check system time and permissions. Clock differences can affect certificate validation, while insufficient permissions can prevent a virtual adapter or system VPN configuration from taking effect.
7. Compare different route types. If a specific entry point cannot connect on the current network, compare direct, relay, or IEPL routes, then confirm the result with an exit test.
8. Re-import the subscription. Remove failed or duplicate configurations first, then import from a trusted source to avoid confusion from old parameters and duplicate node names.

Common symptoms and what to check

If the log shows a successful node handshake and the exit IP has changed, but only one website or app is unavailable, the issue is usually no longer whether the VPN is working. Check the target service’s regional rules, account region, cache, app version, and compatibility with the selected route. Do not treat one service’s result as proof that the entire route has failed.

Final checklist

• The exit IP is clearly different when connected and disconnected.
• IPv4 and IPv6 both use the route as expected, or an unsupported protocol stack has been explicitly handled.
• The DNS resolution path matches the current setup and has not unexpectedly returned to a local resolver.
• The browser and target app were tested separately, so the result is not caused by a setting in only one app.
• The client log shows the target request and confirms that it matched the expected proxy or direct rule.
• The subscription is up to date, and the node protocol is compatible with the current client.
• No other tool is running in the system and competing for the proxy, routes, or virtual adapter.

After these checks, you can distinguish node connection issues from system takeover, DNS, and app split-tunneling issues. The exit IP confirms the public exit, DNS checks confirm the resolution path, and per-app tests confirm whether the actual program matches the rules. Together, they are far more reliable than looking only at a Connected status.