How can you tell whether a VPN is working? The client showing “Connected” is not enough. This usually means only that the client has established a session; it does not prove that every request from your browser, desktop software, and target app is using the expected route. A reliable check starts by recording your local network baseline, then verifying the exit address and DNS query path, checking split-tunneling rules, and finally testing the app you actually need to use.
This approach also helps diagnose a common pattern: the client connects normally, but websites still show your original region; the browser works, while a standalone app is unchanged; or the exit address changes, but the target platform continues showing content for the old region. Each symptom points to a different network layer. Treating every issue as a failed node can overlook more direct causes, such as caching, proxy scope, or the app account’s region.
Compare the results with your pre-connection baseline. Seeing an unfamiliar exit address alone does not show whether it belongs to the selected route, nor does it prove that every app is using the same path.
Connected does not mean app traffic has been rerouted
After reading the route configuration from a subscription, the client establishes a connection using the selected protocol. Shadowsocks, VMess, Trojan, VLESS, Hysteria2, and TUIC use different handshake and transport methods, but troubleshooting has one common principle: a successful protocol session only shows that the client can communicate with the remote entry point. Whether app requests enter that session also depends on the system proxy, virtual network interface, routing table, and split-tunneling rules.
In system-proxy mode, browsers and software that follow the system proxy settings will generally use the proxy; apps that ignore those settings, use their own network stack, or connect directly may bypass it. In virtual-network-interface mode, the client can usually take over a broader range of system traffic, but exclusions, local network rules, and operating-system permissions may still apply. The status icon is therefore only a starting point, not a substitute for further checks.
Establish a local network baseline, then verify the exit address
Before checking the exit address, disconnect the client and close any other proxy tools that could affect the route. Then visit a trusted IP lookup page and record the current provider, region, and address family. This is your local network baseline. Next, connect to the route for the target region, reopen the lookup page, and compare the exit region and network provider.
Do not simply refresh a tab that is already open. The browser may reuse an existing connection, and the service may retain a short-lived regional assessment. A safer approach is to use a new private window or fully close the relevant pages before visiting again. If the browser supports more than one address family, check whether both are rerouted as expected; checking only one can miss another path that is still connecting directly.
- Disconnect the current connection, pause other tools that can change the network route, and record the local exit baseline.
- Connect to the route for the region you want to verify and wait for the client status to stabilize.
- Use a new browser session to check the exit again instead of reusing pages opened before the connection.
- Compare the exit region, network provider, and address family; do not treat the map location shown on a page as the only evidence.
- Keep a record of the result, then move on to DNS and target-app checks.
If the exit has not changed at all, first check the client mode and whether the system proxy is enabled instead of repeatedly switching routes. If only one browser is unchanged, check whether it has a separate proxy, encrypted DNS, or extension rules. Slightly different city names across lookup pages do not necessarily indicate a routing problem: IP databases update at different rates and use different levels of location detail. Judge the result using the country or region, network ownership, and actual app behavior together.
DNS checks are about the query path, not just the displayed region
DNS translates domain names into connectable addresses. A DNS leak generally means that while app traffic is expected to use an encrypted route, domain queries are still sent directly through the local network to the original resolver. This can make the DNS result inconsistent with the exit region and may cause a target site to choose an unsuitable content-delivery endpoint. A changed exit address does not automatically prove that DNS queries use the same path.
For testing, use a DNS test page to make fresh queries for random domains, then see which resolvers handle the responses. The key is not to require the resolver and exit to show the same city, but to confirm that queries have not clearly returned to the local resolution path used before connecting. Public resolvers may use proximity-based routing, so their displayed region may differ from the exit. An unfamiliar name or different city alone is not proof of a leak.
A browser’s built-in encrypted DNS can also change the result. It may bypass the system resolver specified by the client and connect directly to the resolver selected in the browser. During troubleshooting, record the browser’s current settings first, then compare system and browser resolution separately. Do not change several switches at once, or it will be difficult to tell which adjustment caused the change.
| Observed symptom | Possible cause | Verify first |
|---|---|---|
| Exit address unchanged | System proxy not active, app bypassing the proxy, or missing virtual-network permissions | Check the client mode, then retest in a new browser session |
| Exit changed, but DNS still resembles the local path | System resolution not taken over, or the browser is using separate encrypted DNS | Test system and browser resolution paths separately |
| Browser works, but a standalone app still connects directly | The app does not follow the system proxy, or a split-tunneling rule marks it for direct access | Check virtual-network mode, process rules, and the app’s proxy settings |
| Address is correct, but content region is unchanged | Cache, account region, location permissions, or platform policies are still affecting the result | Clear site state and distinguish network identification from account conditions |
| Some websites work, while others connect directly | Different domain rules, address rules, or rule priorities | Review rule-hit logs and temporarily test full traffic handling |
Split-tunneling rules decide which requests enter the route
Split tunneling is not a fault; it is how the client chooses a path based on domains, destination addresses, app processes, or rule sets. Common actions include proxying, direct access, and rejection. Problems usually arise when the rules do not match expectations: the target domain is placed in a direct-access set, the app calls another uncovered API domain, or an earlier matching rule overrides a later proxy rule.
When troubleshooting split tunneling, first check whether the client provides connection logs or rule-hit records. Use logs only to see which rule a target domain matched; never publish subscription URLs, authentication details, or complete connection credentials. If the client supports temporary full traffic handling, compare it while keeping the same route: if global mode works but rule mode does not, the route itself can communicate and the issue is more likely rule matching.
Domain resolution can also affect split tunneling. Some clients make decisions by domain first, while some requests may be resolved inside the app and then connect directly by address. If a rule covers only the domain and not the corresponding address, the actual path may differ from expectations. Content-delivery services also use multiple related domains, so adding only the main site may not cover media, API, and login requests. Use client logs to add the necessary rules rather than sending an unrelated block of the network through the same path.
- ✅ Use the same test page and network environment before and after connecting.
- ✅ Check which proxy, direct-access, or rejection rule the target domain actually matched.
- ✅ Keep the route unchanged and compare rule mode with full traffic handling.
- ✅ Check whether the app accessed API or media domains beyond the main domain.
- ✅ Create a new connection after changing rules so the old session does not keep reusing the original path.
- ❌ Do not publish subscription URLs, authentication fields, or logs containing complete credentials.
- ❌ Do not infer long-term stability or continued platform availability from one successful visit.
App checks must distinguish browser, system, and account state
Even when the exit and DNS match expectations, verify the actual app. Browsers usually follow the system proxy more readily, but extensions, separate proxy settings, encrypted DNS, site storage, and existing connections can produce different results. Start by visiting in a private window without old site state, then check whether the browser proxy is managed by the system. If the private window works but the regular window does not, the likely causes are cache, cookies, extensions, or an old session.
Standalone desktop apps and game launchers do not necessarily read the system proxy. Some provide their own proxy settings, some require a virtual network interface to be handled, and others always use a particular transport method. A successful browser test therefore does not prove that the app works. Check the client connection records for requests from the app, and review process rules or the app’s own proxy configuration.
The region shown by a target platform is not determined entirely by the network exit. Account creation region, payment details, device location permissions, language preferences, and previous sessions may all influence the result. If the exit check is correct but the content catalog or service message does not change, sign out, clear that site’s state, and disable location access before retesting. Do not change account and network settings at the same time just to obtain a particular result, or you will not know which layer caused the restriction.
A regional catalog is not a guarantee that the target platform will be available. A correct network exit proves only that the request path changed; the platform may still determine content and access based on account conditions, authorization scope, or its own policies.
Platform differences change the scope of traffic handling
On Windows and macOS, the system proxy and virtual network interface are different ways to handle traffic. A system proxy depends more on apps actively following the setting; a virtual network interface usually covers more traffic but requires the relevant system permissions. If only the browser works, first identify the current mode, then check whether the target app is bypassing the system proxy.
Android and iOS usually carry the connection through the system VPN configuration. The client may offer per-app routing or options to bypass the local network, but the exact capabilities depend on the system version and client implementation. If some apps do not work, check whether they are excluded and whether the system is retaining another network configuration. Do not enable multiple clients that compete for the system VPN configuration.
On Linux, it is especially important to distinguish desktop proxy variables, app-specific proxies, and system routing. Command-line tools may not read proxy settings from the desktop environment, and background services may run in a different environment. If the browser works but terminal requests connect directly, check whether the command-line tool reads proxy variables, or use a client mode that can handle system routing. After testing, restore temporary variables so later programs do not continue using the old port.
A subscription URL only provides route configuration to compatible clients. Successful import does not mean the current client supports every field, and a failed subscription update may leave the client using an old configuration. Before troubleshooting, update the subscription in the client, confirm that the selected route comes from the current configuration, and check that the protocol is supported by the client version. Do not paste the subscription URL into public testing sites or expose the complete address in screenshots.
Complete verification narrows the cause from baseline to target app
When the source of a problem is unclear, the most effective approach is to change one variable at a time. Keep the local network, client, route, and test app unchanged; verify the exit first, then DNS, then rule matches, and finally app cache and account conditions. If you switch routes, change protocols, edit split tunneling, and clear the browser at once, you may restore service without knowing the real cause.
Use the checklist below to record your results. The record need not include connection credentials; note only the connection mode, target region, whether the exit changed, whether DNS returned to the local path, which rule matched the target domain, and the app result. When testing again during the same period, follow the same order to distinguish an occasional network fluctuation from a persistent configuration issue.
- ✅ The local exit baseline is recorded, and the access network was not changed during testing.
- ✅ The post-connection exit region matches the direction of the selected route.
- ✅ DNS queries did not clearly return to the local resolution path used before connecting.
- ✅ The target domain and app process matched the expected split-tunneling rules.
- ✅ The browser and standalone app were tested separately rather than substituting for each other.
- ✅ Site cache, account region, and location permissions were assessed separately from network issues.
- ✅ The subscription configuration is updated, and the current client supports the selected protocol.
If the exit never changes, check the client’s traffic-handling mode and system permissions first. If the exit changes but DNS is abnormal, check system resolution and the browser’s encrypted DNS. If the browser works but the app does not, check process rules, the app proxy, and the virtual network interface. If all network checks pass but the platform result is unchanged, turn to cache, account conditions, and platform rules. Layered troubleshooting is more likely to produce a repeatable conclusion than repeatedly switching routes.