A VPN connection can appear active without working as expected. The issue is usually not the status icon itself, but confusion between tunnel establishment, route takeover, and whether a specific app uses the route. A connected client only confirms communication with a node; you still need to verify whether web traffic, DNS requests, and other apps pass through it.
The most reliable test is not repeatedly checking the client color or running a speed test on one website. Save a baseline before connecting, then check the public IP, DNS resolution path, and app traffic in order. Together, these results help distinguish route failures from routing rules, browser settings, and system network caches.
Why connection status does not mean traffic is routed
Most clients define “connection successful” as establishing a usable session between the device and a node. The session may use Shadowsocks, VMess, Trojan, VLESS, Hysteria2, or TUIC, or it may run through a system VPN network extension. After the protocol handshake succeeds, the client still needs to write system routes, enable a virtual network interface, or open a local proxy port before app traffic can enter the route.
In global mode, a client generally attempts to take over a broader range of traffic. In rule mode, domains, IP addresses, processes, or app rules determine whether traffic connects directly or uses the proxy. Browsers may also have separate proxy settings, while some apps use their own network stack. This can result in a connected client where one website works but another app still connects directly.
| What to check | What it proves | What it does not prove by itself |
|---|---|---|
| Client connection status | The device can establish a session with the selected node | That every app has entered the route |
| Public IP | Which public exit the current test request uses | That other apps and DNS requests use the same path |
| DNS test | Which side handles domain resolution requests | That web content traffic definitely uses the route |
| In-app verification | Whether the specified app matches the current rule | That every process on the system uses the same rule |
Step 1: Check the public IP
The public IP is the clearest first piece of evidence. When disconnected, a test page usually shows the public exit provided by the local access network. After connecting, if the request passes through the selected node, the page should show the route’s exit rather than the original access-network exit. Focus on whether the IP changed and whether the displayed region broadly matches the selected route.
- Fully disconnect the client, open a network testing page, and note the exit region and network provider.
- Connect to the target route, wait for the client status to stabilize, and refresh the testing page.
- Close and reopen the testing page, or use a new browser session, to avoid interference from an old page cache.
- Use the target app’s own network diagnostics or region information to confirm that its result matches the browser result.
The exit region and node name do not need to match the same city exactly. IP geolocation databases may lag behind updates, and a route may complete its final exit in a nearby region. The key questions are whether the original exit was replaced and whether the country or region is reasonable—not whether the city field identifies the physical data center.
If the exit has not changed at all, first check the client mode. Proxy-only mode usually handles only apps explicitly using the local proxy port; virtual network interface or system VPN mode covers more programs. Also check whether the browser has its own proxy enabled, whether an old proxy address remains in the system, and whether the rules mark the testing domain as direct.
- ✅ Use the same network environment before and after connecting so the results are comparable.
- ✅ The new exit broadly matches the selected route region, and the original access-network exit no longer appears.
- ✅ The browser and target app produce consistent exit results.
- ❌ Check only the client’s node name without querying the public exit.
- ❌ Switch local networks before comparing results and mistake the access-network change for a working route.
Step 2: Check the DNS resolution path
Before accessing a domain, the device usually resolves it to a reachable address. Web content using the route does not mean DNS requests automatically use the same path. If resolution is still handled by the local network, the DNS path and content exit may differ; in domain-based routing scenarios, this can also cause unexpected rule matches.
When testing, check both who performs the resolution and how the current client handles DNS. If the client explicitly uses remote DNS, encrypted DNS, or route-side resolution, the test should match that design. If the browser has its own secure DNS enabled, it may bypass system DNS, but that does not necessarily mean there is a leak. The key is whether it matches your expectations and whether it is exposed to a party you do not want handling resolution.
Do not label a result as a leak simply because the DNS provider name differs from the route brand. Public resolvers, browser-based resolution, and client-specified resolvers may all appear as separate providers. What matters is whether DNS remains exactly the same before and after connection, still clearly uses the local access network, and conflicts with a client configuration that requires remote resolution.
How to handle unusual DNS results
- ✅ Check whether the client offers remote resolution, proxy DNS, or leak-prevention options, and confirm they are enabled as expected.
- ✅ Check whether the browser has independent secure DNS enabled, so it does not override the system policy.
- ✅ Reconnect to the route and run a completely new domain query instead of reusing an already open page.
- ✅ In rule mode, confirm that DNS requests themselves have a matching rule, not just the web domains.
- ❌ Assume all traffic is leaking merely because the resolver name looks unfamiliar.
Step 3: Verify per-app routing rules
After the browser passes its test, check the apps that actually need to use the route. Desktop clients, game platforms, command-line tools, and system services may each use different network paths. Rule mode may assign traffic by domain, destination address, app process, or rule set, so a working browser does not mean the entire device is using the route.
A practical approach is to fully close each target app, connect to the route, then restart it and check its in-app region, connection logs, or client connection records. If the client shows matched rules, determine whether the request ended up in the proxy, direct, or rejected category. Do not rely only on traffic counters, since background updates, connectivity checks, and DNS requests also generate traffic.
Per-app proxying also varies by platform. On Windows and macOS, virtual network interface mode usually covers more traffic than setting a system proxy alone, although some programs may bypass the system proxy. Android’s VPN interface can include or exclude apps; an excluded target app continues using the local network. On Apple platforms, network extensions are managed by the system, so reopen the target app after changing configurations to establish fresh connections.
- Quit the target app to avoid reusing long-lived connections established before connecting.
- Connect to the route and confirm that the public IP has changed.
- Restart the target app and perform an action that clearly requires network access.
- Check the client connection records or matched rules to confirm that the target request was not direct.
- Switch back to the disconnected state and compare again to rule out app caching and account-region settings.
Streaming services, stores, and content platforms also consider account region, cache, location permissions, and payment details. Content may therefore remain unchanged temporarily even after the exit changes. This does not by itself prove that the VPN is not working. First confirm the exit and DNS using network-layer evidence, then handle app caching or account-side region logic separately.
How to verify subscription links and protocol settings
A subscription link provides the client with node and rule configurations. A successful import only means the client read the configuration; it does not mean every node is reachable or that system traffic has been taken over. After an update, node names may change, old nodes may stop working, or rule sets may not refresh, leaving the client with an apparently normal but outdated configuration.
When something looks wrong, update the subscription first and confirm that the selected node comes from the latest configuration. Then check that the protocol parameters are complete. Shadowsocks depends on matching encryption and connection parameters; VMess, Trojan, and VLESS commonly work with transport, TLS, and domain settings; Hysteria2 and TUIC use different transport designs and require client versions that support the corresponding protocols. Do not manually apply fields from one protocol to another.
Protocols define how communication is established, while route types describe how traffic reaches the exit. A direct route connects the device to the remote node directly; a relay route enters an intermediate access point before forwarding to the final exit; IEPL is a dedicated line for carrying international traffic across a specific segment. Regardless of the path, verify actual operation through the public IP, DNS, and app rule results rather than inferring it from the route name.
Common cases where a connection is active but traffic is not routed
The testing website is set to direct in the rules
Some rule sets mark local services, LAN addresses, or specific testing domains as direct. The client may be working normally while the testing page intentionally bypasses the route. Temporarily switch to global mode and test again; if the exit changes in global mode, the issue is usually in the rules rather than the node.
The app reused an old connection
Browser tabs, download tools, and messaging apps may keep long-lived connections open. After switching routes, old sessions do not immediately rebuild under the new routing. Fully quit and reopen the app; this reflects the current path more reliably than simply refreshing the page.
System proxy and virtual network interface are overriding each other
When multiple network tools run on the same device, a proxy, route, or DNS setting written later may override an earlier configuration. During troubleshooting, keep only one client responsible for handling traffic, confirm the result, and then restore other network tools one at a time.
The rules cover domains but not directly connected addresses
Some apps do not resolve a domain again and instead connect directly to a cached address. If rules match domains only, these requests may fall into the default direct route. Check the rule logs to confirm whether the request matched the expected entry, then decide whether to add address rules or adjust the default policy.
The browser and system use different proxies
Browser extensions, local proxy settings, and a system VPN can coexist. A testing page may use the browser extension while other apps connect directly, or the reverse may happen. During verification, identify which layer is handling traffic instead of treating the result of stacked proxies as the behavior of a single client.
Complete verification checklist
If the checks above produce conflicting results, narrow the issue from the network layer toward the app layer in the order below. Change one thing at a time and retest after each change so you can identify which setting actually affects the result.
- ✅ Disconnect the route and save the baseline public IP and DNS results.
- ✅ Update the subscription and confirm that the node, protocol, and client version work together.
- ✅ Connect to the route and check that the exit has changed to a reasonable route exit.
- ✅ Verify that DNS matches remote resolution or the intended secure DNS design.
- ✅ Quit and restart the target app, then check the actual matched rule.
- ✅ Temporarily switch to global mode to distinguish a node issue from a routing-rule issue.
- ✅ Rule out other running proxies, network extensions, and old system proxy settings.
- ❌ Stop verifying as soon as the client displays “connected.”
- ❌ Change the protocol, DNS, node, and rules at the same time, making the variables impossible to isolate.
After verification, save the working combination of node, mode, and DNS. When access problems occur later, use the same method to distinguish between a missing tunnel, a route that was not taken over, and an app rule that did not match before deciding whether to switch nodes, update the subscription, or adjust routing. Review the service’s privacy policy separately; when privacy is a priority, choose a service that clearly states its anonymous, no-logs position and continue checking actual connection behavior in your own network environment.