How can you tell whether a VPN is really working after the client says “Connected”? That status usually means only that the client has established a session with the remote endpoint, or that the system has created a proxy, virtual adapter, and routing rules. What you actually need to verify is which public IP websites see, which DNS resolver handles domain lookups, and whether each app’s traffic enters the expected route.
The most reliable approach is not to keep clicking Connect. Record a network baseline while disconnected, connect to the target route, then check the public IP, DNS, and app traffic in order. Comparing all three helps distinguish normal split tunneling from browser-only proxying, unmanaged system routes, and client configuration problems.
What “Connected” actually means
A client showing Connected does not mean every app is using the same route. Different clients may use a system proxy, browser extension, virtual adapter, or TUN mode. A system proxy mainly affects apps that follow proxy settings; virtual adapters and TUN mode can usually handle more traffic, but the final scope still depends on the routing table, split-tunneling rules, and each app’s behavior.
Shadowsocks, VMess, Trojan, and VLESS are common in proxy clients. They describe the protocol or transport used between the client and the endpoint; they do not automatically ensure that every connection on the device is handled. Hysteria2 and TUIC focus more on UDP-based transport, but they still require correct client settings for the system proxy, TUN, routing, and DNS to provide the intended coverage.
A subscription link is not proof of a working connection either. It distributes endpoints and configuration to the client. A successful import only means the client read the configuration; an established session only confirms that the connection stage succeeded. You still need to verify whether the public IP changed, whether DNS follows the intended path, and whether apps obey the split-tunneling rules.
| Observed behavior | What it usually indicates | What it still does not prove |
|---|---|---|
| The client shows Connected | A session has been established between the client and endpoint, or the local proxy has started | It does not prove that every app uses the route |
| The browser’s public IP has changed | The current browser request used a new exit route when loading the test page | It does not prove that other apps and DNS use the same path |
| The DNS resolver has changed | The current test request used a different resolution path | It does not by itself prove that websites and desktop apps are covered |
| Some websites work while others are unchanged | The difference may come from domain, address, or app-based routing | It does not directly prove that the connection failed |
Step 1: Compare your public IP before and after connecting
Your public IP is the public source address that a website’s server actually sees. While disconnected, open a trusted IP-check page and record the network operator or organization, country or region, and address type. Then connect to the target route, refresh the page, and see whether these fields change with the exit.
Do not focus only on the region name. IP databases can be slow to update, and city labels for a given address range may be imprecise. More important is whether the public address and network organization changed, and whether the result broadly matches the selected route’s exit region. If the address changed but the city is shown in a nearby area, the route is not necessarily failing.
Start with a normal browser window, then verify the result in another browser. If the browsers disagree, a common cause is that one has its own proxy extension or different encrypted DNS settings, or that the browser process did not reconnect after the system proxy changed. Disable the extensions, fully quit the browser, and open it again.
- ✅ Record the public exit details before connecting, not just the region shown on the page.
- ✅ Reload the test page after connecting; if needed, close the old tab and open a new one.
- ✅ Verify with another browser to rule out the effect of a single extension or browser setting.
- ❌ Do not treat the region shown in the client as the actual exit result.
- ❌ Do not assume all traffic is covered just because a page loads faster or one website opens.
If IPv4 and IPv6 are both enabled, check whether the test page shows both types of public address. Some configurations handle only one address family, allowing an app to prefer the path that remains unmanaged. If one result changes while the other stays on the original network, check whether the client supports that address family, whether TUN handles the relevant routes, and whether the system has a higher-priority direct route.
Step 2: Check the DNS resolution path
DNS converts domain names into network addresses. A changed public IP does not mean that DNS lookups use the same route. If the system still sends queries to the resolver provided by the original network, DNS leakage may occur. If the client is intentionally configured with split DNS, different domains may use different resolvers by design, so interpret the result together with the rules.
Use a test page that shows the resolver’s network organization and approximate region. Disconnect and record a baseline, then connect and run the test again. The expected result depends on the client configuration: full routing usually sends queries through the client’s selected remote or encrypted resolver path, while split rules may keep direct domains on a local resolver and send proxied domains through another path.
A browser’s built-in encrypted DNS can complicate the diagnosis. It may bypass the operating system’s DNS or select a resolver based on network conditions. If browser and system results differ, do not immediately conclude that the client is leaking DNS. First check whether the browser has its own secure DNS enabled, then confirm whether the client is supposed to handle browser queries.
Keep caching in mind during DNS tests. The system, browser, and apps may all cache previously resolved domains, so repeated tests for the same domain may not send a new query. Before comparing results, close and reopen the relevant app or use a fresh query name supplied by the test page to ensure that this request triggers resolution.
- Disconnect and record the resolver’s network organization and approximate region.
- Connect to the target route, reopen the DNS test page, and trigger a new query.
- Compare the result with the client’s DNS mode to determine whether it uses full routing or split rules.
- If browser and system results differ, check the browser’s independent encrypted DNS and proxy extensions.
- Test again after accounting for cached data so an old resolution record is not mistaken for the current path.
Step 3: Confirm that each app’s traffic enters the route
Public IP and DNS checks usually run in a browser, but the software you actually need may be a desktop app, command-line tool, game, media app, or development environment. Apps do not all support system proxies the same way, so verify them one at a time instead of using one browser page as a test for the entire device.
First check the client’s current mode. Full proxy mode generally tries to send eligible traffic through the endpoint; rule mode chooses direct or proxied access based on domains, destinations, apps, or regions; bypass-LAN mode keeps printers, router admin pages, and local devices reachable. Names vary by client, but the core question is always: which rule matched this traffic?
When testing a desktop app, fully quit it before connecting, then start it again. Some programs read the system proxy only at launch and may not respond to changes while running. Apps that ignore the system proxy may need their own proxy settings, or a client mode that supports a virtual adapter and TUN.
Games and real-time communications often use UDP. If the client has only a TCP proxy configured, websites may work while game login, voice, or real-time connections still go direct or fail. Check that the endpoint protocol, client mode, and UDP forwarding match instead of repeatedly changing browser settings. Hysteria2 and TUIC can carry these types of traffic, but success still depends on the server configuration, client implementation, and routing rules.
| Use case | Check first | Common mistaken conclusion |
|---|---|---|
| Regular browser | System proxy, browser extensions, secure DNS | Assuming every app works because the browser does |
| Desktop productivity software | Whether it reads the system proxy and whether the process must restart | Assuming the route is unchanged because an old connection is still open |
| Development tools | App-level proxy, terminal environment, certificates, and persistent connections | The command line and graphical interface use different network settings |
| Games and real-time communications | UDP support, TUN handling, and app routing rules | Assuming real-time traffic uses the route because websites work |
| Media apps | Actual exit region, app cache, and domain routing | Judging the exit location from the home screen alone |
Common reasons a connection looks active but traffic is not routed
The system proxy is enabled, but the app does not use it
This is one of the most common cases. A browser follows the system proxy, so its exit changes; some desktop programs create network connections directly and continue using the local network. Check whether the app offers its own proxy settings, or switch to a client mode that supports a virtual adapter, TUN, and system-route handling.
A split-tunneling rule sends the destination direct
In rule mode, the client chooses a path based on domains, addresses, apps, or rule sets. If the target matches a direct rule, the client can still show Connected while the request bypasses the endpoint. Open the client’s connection log or rule-match record to see whether the target matched a proxy, direct, or reject rule. Do not infer the request path from endpoint status alone.
A browser extension overrides the system settings
A proxy extension may select another endpoint or restore direct access when disabled. This can make the browser’s exit differ from the system exit. Disable all network-related extensions, quit the browser process, then test again through the system proxy or TUN mode. If the results match afterward, the issue is the browser’s independent configuration, not the endpoint.
A route priority or virtual adapter problem
TUN mode depends on a virtual adapter and routing. Other network tools, enterprise security software, virtual machines, container networks, or an old client may also modify routes, causing traffic to use an interface with higher priority. Quit other programs that change network settings and restart the client. If that fails, recreating the virtual adapter configuration is usually more targeted than switching endpoints repeatedly.
The DNS path does not match the exit path
If domain lookups still use the local network, resolution may not match the selected route, access may be directed to a different address, or the test page may report a different resolver. Check whether the client’s DNS mode, the browser’s encrypted DNS, and the system resolver settings override one another. If split DNS is intentional, verify that the target domain matched the correct resolution rule.
The subscription configuration is outdated
After importing a subscription, the client usually keeps a local copy of the configuration. When endpoint details change on the service side, the old configuration may remain in the list while connection quality or exit behavior becomes abnormal. Update the subscription from a trusted source and confirm that the client completed the refresh. Do not paste a subscription link into an untrusted page; it usually contains access configuration and should be handled like a credential.
A kill switch is preventing reconnection
A kill switch prevents traffic from returning to the local network when the route is interrupted. After the endpoint reconnects, traffic may remain blocked if the firewall or routes do not recover correctly, leaving the client online while apps cannot connect. Check whether the kill switch is still blocking traffic, then reconnect or restart the network components as the client recommends. Do not leave the protection disabled just to hide the problem.
The route type is being confused with the actual exit
Direct routing connects the device straight to the remote endpoint; transit routing first enters an intermediate gateway and then reaches the exit; IEPL describes how the link between the entry and exit is organized. These affect the transport path but do not replace exit verification. Whether the setup uses direct, transit, or IEPL routing, websites ultimately see the exit endpoint’s address, so verify it with IP and DNS results.
- ✅ Check rule matches and connection logs to confirm which path handles the target request.
- ✅ Quit other network tools that modify the proxy, virtual adapter, or routes.
- ✅ After updating the subscription, verify the selected endpoint so an old configuration is not still in use.
- ✅ Check that the kill switch, system firewall, and virtual adapter have returned to a normal state.
- ❌ Do not switch protocols and endpoints at random; this can hide the real configuration problem.
- ❌ Do not treat IEPL, transit, or direct labels as proof that the exit is working.
How checks differ across platforms
Windows clients commonly use either a system proxy or TUN. A system proxy suits apps that follow system settings, while TUN is better for broader traffic handling. Check the virtual adapter status, whether an old system proxy remains enabled, and whether other network software has changed the routes. Restart the target app after switching modes, then test again.
macOS requires explicit permissions for network extensions and proxy configuration. The first time a client enables these features, macOS may ask for confirmation. If permissions are incomplete, the interface may show the endpoint as connected while some traffic is not handled by the network extension. Check the extension status in System Settings rather than relying only on the client window.
Android clients usually handle traffic through the system VPN interface and may also offer per-app routing. If only certain apps fail, check whether they are excluded or use a network path unsupported by the current mode. Battery-saving policies can also restrict background operation and interrupt the route after the screen locks.
iOS and iPadOS likewise rely on system network-extension capabilities. On-demand connections, Low Data Mode, and app switching can affect what you observe. Keep the client connected, restart the target app, and check the browser exit and in-app access separately. If the configuration came from a subscription, confirm that its configuration type is supported by the current client.
Linux environments vary more widely. Desktop proxies, terminal environment variables, container networking, and system routes may be independent. A graphical browser working does not mean command-line tools use the same settings; a working host does not mean a container inherits them. Identify which network namespace sends the test traffic and whether it reads proxy variables or system routes.
A repeatable final checklist
After making changes, run one verification pass in a fixed order. This reduces interference from caches, old connections, and multiple settings changing at once, and makes the process reusable when you switch endpoints or clients.
- Disconnect and save baseline details for the current public IP and DNS resolver.
- Quit the browser and apps you need to test, and stop other tools that modify network settings.
- Connect to the target route and confirm that the client is not repeatedly reconnecting or reporting errors.
- Reopen the browser and compare the public address, network organization, and approximate region.
- Trigger a new DNS lookup and compare it with the current full-routing or split-DNS policy.
- Start the apps you actually use one by one, then review rule matches, connection logs, and access results.
- Switch networks or let the device sleep briefly, then test again to confirm that reconnection behaves as expected.
If the public IP, DNS, and target app all match the rules, the connection is working as configured. If only one is abnormal, return to that layer: an unchanged exit points to the proxy and routes; incorrect DNS points to resolver settings and the browser’s secure DNS; a single failing app points to its proxy, UDP handling, split rules, or process restart.
The goal of verification is not to make every result look identical, but to ensure that each type of traffic follows its intended path. Full mode should generally show consistent exit and resolution behavior; rule mode may combine direct and proxied traffic, but every path should be explainable, reproducible, and supported by a rule or log.