How can you tell whether your VPN is working? Compare your public IP before and after connecting, check the DNS resolution path, and then test the apps you actually use. A client showing “Connected” usually means only that a connection or local proxy has been established. It does not, by itself, prove that your browser, office software, and other apps are all using the intended route.
The goal is not to make “all traffic change,” but to ensure that requests meant to use the proxy do so, while requests meant to connect directly follow the rules. That is why you should first check whether the client uses a system proxy, rule-based routing, or a virtual network adapter. The steps below follow a verifiable sequence rather than drawing conclusions from a single test screenshot.
First check the coverage: connection status does not reveal the traffic path
A system proxy generally provides a proxy address to software that follows system settings; it does not take over every network request. Some apps use their own networking components and may ignore the system proxy. Browser extensions have a narrower scope, often affecting only that browser, so they cannot show whether desktop apps also use a different egress route.
Virtual network adapter mode routes more traffic through the client, commonly under names such as TUN or VPN mode. However, exclusions, process rules, and protocol support can still affect what gets routed. On mobile devices, a VPN indicator in the status bar does not rule out per-app exclusions or on-demand connections. Check the actual client configuration.
- ✅ Note the current route, proxy mode, rule group, and whether the virtual network adapter is enabled. Keep these conditions unchanged during testing.
- ✅ Pause other proxy extensions or similar clients to reduce conflicts from multiple proxies or routes.
- ✅ Stop background downloads and sync tasks. Verify the route first, then investigate speed.
- ✅ List the browsers, office apps, and other apps you need to test. Do not assume a browser result applies to the whole device.
A subscription link provides configuration to a client; it is not a web proxy address. After importing it, confirm that the subscription updated, the intended route is selected, and the relevant routing options are enabled. The names of protocols such as Shadowsocks, VMess, Trojan, VLESS, Hysteria2, and TUIC do not tell you whether a particular app is using a proxy; the client’s routing and traffic-capture settings matter too.
Check your egress IP: compare before and after connecting
Disconnect first, then open the IP check page in the same browser. Record the public address, provider, or network information shown. Next, connect to the intended route, reload the page, and compare the results. Do not switch networks during the test, or you will not know whether the change came from the proxy or your local network.
A changed public address means the path for that test request changed; it does not prove that every request on the device is being routed. Conversely, in rule-based mode, a test domain may be set to connect directly. An unchanged address alone does not prove the entire route has failed. Check which rule matched the domain and which outbound route was used.
The country or region associated with an address is not an exact location. Databases may be out of date, and a route name, data center location, and registered address region may differ. Prioritize the actual address and the client’s connection records. Treat regional labels as supporting information, not the sole measure of success.
Check both IPv4 and IPv6. If the test tool supports separate checks, confirm that requests of both types follow the expected route. Seeing one address type change does not rule out the other connecting directly. Do not treat disabling IPv6 as a universal fix; first check client support and routing settings.
Old browser pages and existing app connections can also affect comparisons. After switching routes, make a fresh request and restart the target app if needed. A private window can reduce some cache and extension effects, but it does not automatically change system routing or replace a DNS check.
Check for DNS leaks: distinguish the resolver from the access route
DNS translates domain names into network addresses, and DNS requests may take a different path from connections to websites. A DNS leak generally means that a lookup that should be covered by proxy or tunnel settings is sent through an unexpected local network instead. An unfamiliar resolver name in a test result does not, on its own, prove there is a leak.
Use a DNS test tool that generates new test domains. Run it while disconnected and connected, and note the network associated with each resolver. If DNS capture is enabled, a local network resolver that continues to appear after connecting is worth investigating. Some tests, however, show the upstream resolver used by a recursive DNS service rather than the server contacted directly by your device. Interpret ownership details in light of your configuration.
Why browser Secure DNS can change the result
A browser’s Secure DNS setting may use an encrypted resolver and bypass the system resolver selection. Whether its connection goes through a proxy still depends on how the browser’s requests are routed. “Using encrypted DNS” and “routing DNS requests through a proxy” are different things; one does not guarantee the other.
Note the browser’s Secure DNS setting, then compare it with the client’s DNS mode and connection logs. To isolate variables, you can temporarily adjust the setting for a comparison and restore the intended configuration afterward. Avoid repeatedly changing DNS settings in the system, browser, and client without keeping notes; otherwise, it is hard to tell which change made a difference.
A cache or virtual address is not necessarily a fault
Systems and apps can cache DNS results, so it is normal not to see a new DNS request immediately after switching routes. Some clients also use Fake-IP, returning an internal virtual address that the client maps to the target domain. These addresses are not the website’s actual public IP, and their presence alone does not indicate a leak.
Verify apps individually: check which rules their requests match
After testing the browser, open the app you actually want to use and trigger a clearly new request, such as refreshing a remote document, reloading content, or starting a sync. In the client’s connection panel, find the corresponding process or domain and check the matched rule, outbound route, and any connection errors.
A log showing that an app request used the expected outbound route is important evidence, but check the app’s actual response too. An app may contact several domains, with login, content, and downloads taking different paths. Confirming that the home page opens does not prove that login or file transfers are working.
| Routing mode | Check first | Common misinterpretation |
|---|---|---|
| Browser proxy extension | Extension scope, excluded domains, and browser egress | Assuming the browser result also applies to desktop apps |
| System proxy | Whether the app follows system settings or has its own proxy configuration | Assuming that enabling the system proxy routes every app |
| Virtual network adapter mode | Routes, DNS capture, exclusions, and protocol support | Overlooking excluded processes or traffic using the other address type |
| Per-app or rule-based routing | Target process, domain rules, and actual outbound route | Mistaking an expected direct connection for a route failure |
On Windows and macOS, distinguish the system proxy setting from the virtual network adapter toggle. On Linux, desktop proxy settings may not match proxy environment variables used by terminal programs. On iOS and Android, check whether the client offers app exclusions or on-demand connections. Available features depend on the system and client, so instructions for another platform may not apply.
Apps that use UDP also require the client, selected configuration, and route to support the relevant forwarding. If web pages work but voice or games do not, the cause may be a difference in protocol support or routing coverage, rather than a completely inactive connection.
Connected but not using the route? Troubleshoot in this order
- Confirm the configuration is active. Check that the subscription updated and the intended configuration is selected. Make sure you are not editing an inactive rule group.
- Check the routing controls. Distinguish connecting to a route from setting the system proxy, and confirm that permission for the virtual network adapter was granted.
- Inspect the matched rules. Check whether the test domain or target app is set to connect directly, or whether an earlier exclusion rule applies.
- Isolate other network tools. Pause browser extensions, other proxy clients, or software that may rewrite routes, then repeat the comparison.
- Reconnect the app. Close the existing connection and reopen the app. If needed, check the DNS cache and Secure DNS settings.
- Collect evidence before asking for help. Share the system, client, mode, symptoms, and redacted logs. Do not send the full subscription link.
For diagnosis, you can temporarily switch to the client’s global proxy rule and see whether the target request uses a different outbound route. “Global” usually describes rule selection; it does not necessarily expand which traffic the client captures. An app that ignores the system proxy may still be unaffected. Restore the rules that suit your actual use after the comparison.
Subscription links may contain access credentials, and logs may reveal domains and addresses. Before sending materials to Help & Support, redact them and keep only what is needed for troubleshooting. Do not upload a complete configuration to an online test site from an unknown source.
Verification results: a correct route does not guarantee every service is available
A changed egress address, DNS resolution that matches your settings, and the target app using the expected route together provide a more complete indication that the connection is working. Whether a website allows access may also depend on account region, permissions, service status, cookies, and policies tied to the egress address. A working connection and an available platform are not the same conclusion.
Likewise, speed tests do not determine whether a connection is working. A route type describes the transmission path, not the result on your device. Names such as IEPL, relay, or direct connection do not prove that local DNS or routing rules are configured correctly. Verify the path first, then troubleshoot speed, stability, and app compatibility separately.
How to assess it: Compare the egress route before and after connecting to verify the test request changed, check DNS to confirm resolution matches expectations, and use app requests and client records to verify routing. Draw conclusions only about apps and requests you have tested; “Connected” does not prove the whole device is routed as intended.
VPNCB supports Windows, macOS, iOS, Android, and Linux. Get the client and subscription after signing in to the panel. For a walkthrough of importing a configuration and connecting, see Quick Start. An email address is not required to create an account; use a username and password. Verify the connection in your own network environment using the steps in this guide.