To verify that a VPN is really working, you cannot rely only on the client’s “Connected” status. It usually means the local client completed a handshake with a remote node or the system created a virtual network interface. You still need to check the exit IP, DNS resolution path, and routing results for browsers, command-line tools, games, and other apps.
A reliable check should answer several questions: Has the public address changed? Does its location match the selected region? Which resolver handles domain lookups? Is the target app using the proxy? After a disconnect, does traffic quietly return to the original network? Checking just one item can produce a misleading half-answer.
First define what “really working” means
“Working” is not a single state. It means the entire path from the app to the remote exit matches your configuration. A successful client handshake is only the entry point. System routing, proxy mode, DNS settings, and the app’s own network stack can each bypass the configuration and change the final result.
| Check layer | What to observe | Common misinterpretation |
|---|---|---|
| Client connection | The node handshake completes, and the virtual interface or local proxy port works normally | Treating a successful handshake as proof that all traffic is being forwarded |
| Public exit | The target app shows the expected exit address, region, and network owner | Looking only at the map label without checking the operator or address family |
| DNS resolution | Domain requests are sent to the expected resolver according to client or system rules | The exit has changed, but the local network still performs DNS resolution directly |
| Per-app routing | Apps that should use the proxy enter the route, while apps meant to connect directly stay direct | Testing only the browser and assuming every other program behaves the same |
| Failover behavior | Behavior after the node disconnects matches the block or fallback settings | Assuming protection is still active when traffic automatically falls back to a direct connection |
The minimum reliable verification loop is therefore: record the pre-connection state, compare after connecting, recheck each app, and observe what happens after disconnecting. If the exit and DNS are correct but one app still shows the original network, the issue is usually not the route itself. Check the system proxy’s coverage, the app’s proxy settings, or the routing rules.
Use your exit IP to see what the public internet sees
Your exit IP is the most straightforward place to start. Before and after connecting, open a reliable IP lookup page in the same browser session and compare the public address, country or region, autonomous system, and network operator. A matching region with an unexpected operator does not always indicate a problem: data centers, residential broadband, and mobile networks are registered differently. It should at least fit the type of route you selected.
Do not focus only on the map pin. IP geolocation databases are not updated in real time, and the same address range may be assigned to a neighboring city—or show the network operator’s registered location—in different databases. For international routes, the country or region, autonomous system, and whether services are accessible are usually more useful than city-level geolocation.
Check both IPv4 and IPv6
Some clients take over only IPv4 while the device can still send IPv6 requests directly through the original network. A standard lookup page may happen to use the proxied IPv4 and appear correct, while an IPv6-capable app takes a different path. If the test page shows both address families, check them separately. If the client does not handle IPv6, disable that address family if appropriate, or use a mode that can fully take over system traffic.
Rule out browser caches and old connections
A browser may reuse a session created before the connection changed. After switching nodes, an immediate refresh may not rebuild the old connection. A safer approach is to close the relevant pages, wait for the old session to end, and then run the check in a new private window. Command-line tools are also useful for cross-checking because they bypass some browser extensions, caches, and secure DNS settings.
- Disconnect the client, then record the current public address, region, and network owner.
- Connect to the target node and make sure the client is not repeatedly reconnecting or reporting handshake errors.
- Open the lookup page again and compare the exit address and address family.
- Run a second check with a tool that does not share the browser’s configuration.
- Repeat the check after switching nodes to confirm that the exit really changes with the route.
Check whether DNS resolution falls back to the local network
Before accessing a website, a device usually resolves its domain name to an address. Web content can travel over an international route without DNS queries taking the same path. If DNS requests go directly to the resolver provided by the current network, outside parties may still see which domains you query. The results may also conflict with the exit region, causing incorrect content localization or connections to unsuitable service nodes.
DNS test pages usually list the servers involved in resolution and their network owners. If you see the local network operator’s resolver after connecting, investigate further. However, a resolver operated by someone different from the VPN exit is not automatically a leak: public DNS services use distributed nodes, and the page may show the recursive resolver’s exit rather than your actual location.
Browser secure DNS can change the result
Modern browsers can use encrypted DNS independently instead of fully following system settings. As a result, browser and command-line checks may differ on the same device: the browser sends queries to its own resolution service while other apps continue using system DNS. First check whether the browser has independent secure DNS enabled, then decide whether this is expected or bypasses the client’s rules.
Do not judge Fake IP and remote resolution by the visible address
Some TUN clients use Fake IP: they assign a reserved mapping address to a domain, then restore the domain internally and send it to a remote resolver. The app does not see the website’s real address, but the request may still travel correctly through the tunnel. Do not label this abnormal based only on the local resolution result. Check the client logs for domain matching, the DNS upstream, and the final route.
- ✅ Run DNS checks before and after connecting, and record the resolver’s network owner.
- ✅ Compare browser and system tools to see whether they use different resolution paths.
- ✅ Check that the client’s DNS mode, remote resolution settings, and routing rules are consistent.
- ✅ Confirm that both IPv4 and IPv6 queries are governed by the expected policy.
- ❌ Do not assume a leak simply because the resolver’s region differs from the node’s city.
- ❌ After enabling independent secure DNS in the browser, do not treat its result as the system DNS state.
Verify the browser, command line, and apps one by one
A working browser does not mean every app will work. System proxy mode mainly affects software that actively reads the system proxy settings. Programs that ignore them, create their own UDP sessions, or use an independent network stack may connect directly. TUN mode usually covers more traffic because it takes over IP traffic through a virtual interface, but routing tables, exclusions, and system permissions still matter.
Browser
First disable extensions that may rewrite proxy settings, then check the exit and DNS. If the browser works but other apps do not, the node is probably usable; focus on system proxy coverage and app settings. If only one browser is affected, also check its secure DNS, proxy extensions, cached connections, and enterprise policies.
Command line and developer tools
Whether a terminal program inherits a proxy depends on the tool and its environment variables. Some tools read HTTP or SOCKS proxy variables, while others use the system network interface directly. When using a local proxy port, distinguish between an HTTP proxy and a SOCKS proxy, and confirm whether domains are resolved locally or by the proxy. If web browsing works but package downloads connect directly, the command-line tool often simply has not read the system proxy.
Messaging, games, and other independent apps
These apps may combine TCP, UDP, long-lived connections, and custom DNS. Successful login alone cannot verify the entire path. Fully quit the app, connect to the node, restart it, and then review the target domains, addresses, and matched rules in the client logs. If a rule shows direct access, adjust the routing. If it shows proxy access but the app still fails, check UDP support, the node entry point, and restrictions imposed by the target service.
Per-app proxying has another easily missed detail: rules may intentionally send local services through a direct connection. Different apps showing different exits is then a design choice, not a fault. The goal is not to force every request through one path, but to confirm that each type of request matches its intended rule.
Understand the boundaries of protocols and client modes
Shadowsocks, VMess, Trojan, VLESS, Hysteria2, and TUIC can all carry proxy traffic, but none is a switch that automatically takes over every app after installation. The protocol defines how data travels between the client and server. System proxy settings, TUN, routing rules, and DNS modules determine which local requests enter that transport channel.
Shadowsocks is an encrypted proxy protocol that typically exposes a local SOCKS or HTTP entry point. VMess and VLESS are commonly used by clients supporting multiple transport combinations; VLESS itself does not rely on built-in protocol encryption and is usually paired with TLS or another secure transport. Trojan carries traffic over TLS. Hysteria2 and TUIC use QUIC-based transport approaches, behave differently from traditional TCP proxies under jitter or packet loss, and generally place greater emphasis on UDP support.
A protocol name cannot prove that DNS has been taken over, nor that an app is using the proxy. Even after a subscription imports successfully, the client may remain in system-proxy-only mode. Even with TUN enabled, excluded routes or failed permissions can let some traffic bypass it. When diagnosing a problem, separate “is the protocol connected?” from “is the system routing traffic correctly?”
Subscription links and client import
A subscription link typically provides node names, server entry points, ports, authentication details, transport parameters, and TLS-related settings. Successful import only means the client could read the configuration; it does not prove the node is reachable or that it is currently selected. After updating the subscription, check whether the active configuration was replaced, the group selected the correct route, and local override rules still apply.
Windows and macOS clients usually offer both system proxy and TUN options, but their system permissions, route handling, and DNS takeover methods are not identical. Android often creates a local tunnel through the system VPN interface and can include or exclude apps. iOS likewise depends on system network extension capabilities, while background behavior and rule implementation vary by client. When moving a configuration between platforms, do not assume switches with the same name work exactly the same way.
What direct routes, relays, and IEPL dedicated lines change
A route type describes the network path between the client and the exit, not the proxy protocol. Direct means the device connects straight to an overseas node entry point; the path is simple but depends more on public routing quality. A relay first connects to a nearby entry point, which the service then forwards to the final exit, avoiding some unstable public-network segments. An IEPL dedicated line generally refers to a dedicated cross-border transport path, emphasizing how traffic is carried between entry and exit.
Regardless of the route type, the verification method is the same: Is the public exit correct? Is DNS resolving according to policy? Is the app matching the expected outbound? The route name cannot replace result checks. A relay entry point may be nearby, but a public lookup should show the final exit. If it shows the entry address or the original network address, inspect server-side forwarding and client routing.
A reachable route with an unusual browsing experience should not immediately be blamed on the protocol. DNS may return an address unsuitable for the exit region, routing rules may send static assets direct, and the target website may apply different policies based on IP reputation or account region. Recording the exit, DNS, matched rules, and app response separately is more effective than repeatedly switching nodes.
Typical cases that look connected but are not routed
- ❌ The client handshake succeeds, but the system proxy is disabled, so the browser still uses the original network.
- ❌ The browser reads the proxy, but the command-line tool does not read the proxy environment, so the download connects directly.
- ❌ IPv4 goes through the node while IPv6 remains direct, giving dual-stack apps different exits.
- ❌ The exit has changed, but DNS is still resolved directly by the current network, causing a mismatched region result.
- ❌ The routing rules classify the target domain as direct, while the client log only shows that the node is online.
- ❌ After switching nodes, the browser reuses an old connection and continues showing the previous path briefly.
- ❌ The TUN permission request fails, so the client falls back to the narrower system proxy mode.
- ❌ After the node disconnects, traffic automatically falls back to a direct connection and the app keeps working, making the tunnel seem active.
When you encounter these cases, do not change the protocol, node, DNS, and routing rules all at once. Change one variable at a time, then repeat the same exit and DNS checks. Otherwise, even if the problem disappears, you will not know which setting fixed it—and the next failure will be another guessing game.
Recommended check order
- Save the exit and DNS baseline from before connecting.
- Confirm that the subscription has been updated and the target node or policy group is selected.
- Confirm whether you are using system proxy or TUN, and whether the required permissions work normally.
- Check the IPv4 and IPv6 exits and DNS resolution paths.
- Test the browser, command-line tools, and target app separately.
- Review matched rules, outbound selection, and error logs.
- Disconnect the node intentionally and confirm whether the app is blocked or falls back to a direct connection.
A complete self-check is straightforward: first confirm which exit the public internet sees, then confirm who resolves the domain, and finally confirm which rule the specific app matched. A connection icon can tell you that the client has started working; it cannot sign off on the entire network path. Networks do not read minds, and configurations do not either.