How can you tell if your VPN is working? First check the public IP used by the request you want to test, then check its DNS path, and finally verify traffic app by app. A “Connected” status usually confirms only that a session is active—it doesn’t verify the browser, terminal, or other apps.
Start by defining what you expect: should all internet traffic use the VPN, or only specific sites? With split tunneling, local services may intentionally connect directly. Here, “working” means the request follows your configured rules and reaches the expected exit—not that every test page shows the same location.
Check the connection mode and scope
Common connection methods include system proxy settings, VPN-style virtual network adapters, and in-app proxies. A system proxy registers settings with the operating system, but apps may or may not use them. A virtual adapter can route more traffic, though exclusions, app-specific rules, and system permissions may affect what it captures. Browser extensions usually affect only some browser requests, so don’t assume other apps use the same route.
“Global” mode in a client also has a scope: it may mean that every request entering the proxy core uses a proxy, not that every operating-system app is covered. Before testing, note the selected route, rule mode, and connection method. If the client shows matched rules or connection logs, keep that view open so you can match requests to their exits.
| What to check | What it can confirm | What it cannot confirm on its own |
|---|---|---|
| Client connection status | The session or route status reported by the client | Whether the target app uses the proxy |
| Public IP shown by a webpage | The address seen by the destination for this webpage request | That the terminal, other apps, and DNS all use the same route |
| DNS test | Clues about the recursive resolver used for the test domain | How every app resolves domains and routes its traffic |
| Connection and rule logs | Requests observed by the client and the policies they matched | Whether requests exist that never reached the client |
Public IP: compare results under the same conditions
Your public IP is the source address seen by the destination server. Disconnect from the VPN, open the network test page, and note the public IP it displays. Then connect to a route and run the same check in the same browser. Compare the IP address itself, not just the country name or flag. IP geolocation databases can lag behind changes, and city labels are especially unreliable for determining where a route is hosted.
- Save your work, then temporarily disable other proxy extensions or network clients running at the same time to prevent them from interfering.
- Note your public IP and network setup before connecting. After connecting, stay on the same network; don’t switch Wi-Fi networks during the test.
- Make sure the test domain matches the expected rule. If it’s set to connect directly, an unchanged result doesn’t prove that international websites are also connecting directly.
- Send the request again and compare it with the client logs. If needed, restart the browser so existing connections don’t keep using a previously established route.
- When possible, cross-check with a separate test and review IPv4 and IPv6 results independently.
If your IPv4 address changes but IPv6 still shows an address from your local network, at least some test traffic may not be routed as expected. Check the client’s IPv6 support, system routes, and bypass settings before changing anything. Disabling IPv6 isn’t a universal fix. On dual-stack networks, apps may choose different address families.
DNS leaks: check resolver rules, then test
DNS translates domain names into IP addresses before an app connects to a server. DNS requests and webpage traffic can take different routes, so a correct public IP doesn’t mean DNS is routed as expected. Whether a DNS result is a leak depends on your rules: investigate when a domain that should use a proxy or a specified resolver is instead sent to an unexpected resolver.
DNS leak tests typically use dedicated test domains to see which recursive resolvers make the lookup. The displayed location and provider are clues, not a complete view of the route between your device and the resolver. Public DNS services may use distributed endpoints, so a resolver location that differs from your VPN location doesn’t by itself prove a leak.
Check each DNS resolution source
- Client DNS: Check whether built-in DNS, remote resolution, or domain-based routing is enabled. Proxied and direct domains may use different resolution rules.
- Browser secure DNS: A browser may resolve domains itself using encrypted DNS. Whether those requests use the proxy depends on browser proxy behavior and client rules; check the connection logs.
- System and app caches: Cached DNS results may persist after switching routes. Run the test again and, if needed, clear the cache using your operating system’s documentation. Don’t draw conclusions from an old page.
- App-specific DNS: Some apps connect directly to their own DNS services. A browser test cannot tell you how those apps resolve domains.
With Fake-IP enabled, the address shown to the system or an app may be a synthetic address the client uses to map a domain—not the website’s actual IP. This is one way to handle DNS and isn’t, on its own, evidence of a leak. Instead, check the domain’s rule, where its DNS request goes, and whether the final connection succeeds.
App-by-app checks: browsers, terminals, and desktop apps
If a website works in your browser but not in a terminal, first check the proxy’s scope rather than switching routes. Command-line tools vary in their support for system proxy settings: some use environment variables, while others require their own configuration. Even when a terminal is configured to use a proxy, a background process in an editor may have inherited older settings at startup. Restarting the terminal won’t update a process that’s already running.
- ✅ Browser: Check extensions, custom proxy settings, and secure DNS. Reopen the site and confirm the request appears in the client’s connection logs.
- ✅ Terminal: Check the tool’s proxy documentation, verify the proxy address, protocol, and local listening port, then send a request to the same destination.
- ✅ Editors and desktop apps: Check the app’s network settings. After changing them, fully quit and restart the app, then observe a real request.
- ✅ Mobile devices: Check app-specific routing and exclusion rules, and make sure you’re testing the app you actually use in the foreground.
- ❌ Don’t treat a successful browser test as proof that every app is covered. And don’t assume a route is broken just because one app doesn’t appear in the logs.
On Windows and macOS, system proxy settings and virtual network adapters work differently and may require different permissions. On Linux, desktop proxy settings may not carry over to command-line processes. Mobile platforms are limited by their network extensions and client capabilities; available options depend on the client. When reproducing an issue across platforms, use the same test destination rather than comparing setting names.
HTTP and SOCKS proxies can also differ in where domain names are resolved. When troubleshooting a terminal, don’t copy an unknown port from the internet. Check the local listening settings shown by your client and make sure the tool supports that proxy type. If the tool offers remote DNS resolution, check its documentation to confirm how to enable it.
Common reasons a connection can look successful when it isn’t
The rule chose a direct connection, or the subscription hasn’t updated
Importing a subscription gives the client routes and configuration, but doesn’t guarantee that a request will use a proxy route. Check that the active configuration is the one you just imported, the policy group has a working route selected, and the destination domain hasn’t matched a direct-connection or exclusion rule. Treat subscription links like credentials: don’t include them in public screenshots, online parsing tools, or public discussions.
Requests appear in the connection log, but the app still fails
Continue troubleshooting beyond the route: check DNS results, connection errors, the destination service, your account session, and regional restrictions. A changed exit IP doesn’t guarantee platform access, available content, or a successful login. Avoid repeatedly switching locations to reproduce the issue; testing with the same exit makes it easier to distinguish a network problem from account-session checks.
Web pages work, but calls or other real-time features don’t
Different features may use different transport methods, so a successful webpage request doesn’t prove that UDP traffic is routed correctly. First check whether the client mode covers that traffic and whether the app is excluded, then review the relevant connection logs. Protocol names such as Shadowsocks, VMess, Trojan, VLESS, Hysteria2, and TUIC don’t replace hands-on testing; check protocol support, client implementation, and system routing together.
IEPL, transit, and direct connections describe route paths and transport, not whether an app is covered by the proxy. Changing route types won’t necessarily change the path used by an app that doesn’t use the system proxy. Check whether traffic reaches the client before evaluating route performance, so you don’t mistake a configuration issue for a route issue.
Gather evidence before changing settings
When retesting, change one thing at a time—for example, switch only the routing mode or adjust only the rule for the destination domain. Keep the before-and-after IP results, matched rules, and error messages. If the issue occurs mostly during peak hours, note when it happens and the network conditions, then retest with the same app and destination. Without observations, don’t assume congestion is the cause.
To contact customer support, provide your operating system, client name, connection mode, selected route, destination domain, and exact error message. Before sharing screenshots, hide any part of your public IP you don’t want to disclose, as well as subscription links, access tokens, and account details. Client connection logs are for local troubleshooting; they don’t describe the service’s server-side logging policy.
How to reach a conclusion: A test is complete only when the target request uses the expected exit, DNS resolution follows the intended rules, and the app you actually use matches the correct route. A connection icon is the starting point, not the final answer.
If only the browser passes, limit your conclusion to the browser. If your rules intentionally allow direct connections to local services, check against those rules. Define exactly what you tested instead of saying “everything works”—it will make future issues easier to pinpoint.