How can you tell whether your VPN is working? Start by checking the public IP used by the request you care about, then check the DNS resolution path, and finally test the app you actually use. A connection icon only means the client reports an established connection; it doesn’t prove that your browser, desktop apps, and background processes all use the same route.
Before testing, be clear about your goal: should all network requests use the VPN, or only specific international sites? In rule-based mode, local sites may connect directly by design. Expecting every site to show the VPN location can make normal split tunneling look like a problem.
First, distinguish connection status, egress, and routing
Think of the full request path this way: an app makes a request, the system or client selects a route, and the request reaches the destination server directly or through a proxy. Domains also need to be resolved to IP addresses. That lookup may be handled by the system, browser, or proxy client, and may not follow the same path as the webpage content.
A system proxy provides an entry point mainly for apps that honor the system proxy settings; it doesn’t automatically capture all traffic. TUN mode or a system VPN interface can handle a broader range of network requests, but routing rules, excluded apps, LAN settings, and IP address family handling still matter. The presence of a virtual network adapter alone doesn’t mean every app is covered.
| Check | What it can confirm | What it cannot confirm |
|---|---|---|
| Client connection status | The client reports that a tunnel or session is established | That the target request is definitely using the VPN |
| Public IP shown by a webpage | The source address the server sees for that webpage request | That other apps and domains use the same exit |
| DNS check | Clues about which recursive resolver handled the test domain | That all network traffic passes through an encrypted tunnel |
| Target app logs | The rule matched by an app request and the selected exit | That the target service allows access from that location or account |
Protocol names such as Shadowsocks, VMess, Trojan, VLESS, Hysteria2, and TUIC describe different proxy transport methods; they don’t indicate which device traffic is covered. Dedicated IEPL routes, relays, and direct connections describe network paths, but they can’t replace on-device routing checks. Start with the request, rather than guessing from the protocol name.
Public IP: compare before and after to confirm the route
Choose a trustworthy page that shows the public IP for the current request. Just view the result; you don’t need to grant location access or install an extension. The result reflects only the request being checked. Geolocation databases can be outdated, so the city shown doesn’t prove the physical location of the route.
- Disconnect the client, then note the public IP address and ISP shown by the lookup page in your browser. This is your direct-connection baseline.
- Connect to the route you want to test and note the mode, route name, and whether any app exclusion rules are enabled.
- Reload the lookup page so you’re not relying on a result left in an old tab. Compare the public IP address, not just the country name.
- Look for the lookup domain in the client’s connection logs and check which rule and exit it matched. If the domain is set to connect directly, an unchanged result doesn’t prove that your target international site also connects directly.
- Return to the site you actually want to use, refresh it or start a new connection, then check its request logs.
If your browser shows a different exit but a command-line program still shows your local exit, the program may not use the system proxy. Conversely, setting proxy environment variables in a terminal doesn’t mean your browser inherits them. Test each process separately instead of treating their results as interchangeable.
Also check IPv4 and IPv6. A route may handle IPv4 while IPv6 traffic goes directly. If your lookup service has separate tests for each, check both and review how the client handles each address family. Don’t blindly disable system networking features long-term just to make the results look consistent.
DNS: check the resolution path, not just the country label
A DNS leak generally means that lookups expected to be protected by a tunnel or proxy policy are sent over an unintended path. The key question is whether the path matches your settings, not whether a test page shows your local country. In rule-based mode, using a local resolver for local domains may be intentional.
Browser-based DNS test pages often generate test domains and observe which recursive resolvers receive the lookup requests. The resolver they see may not be the server configured on your device; it could be further along a forwarding chain. Anycast networks used by public DNS and geolocation databases can also make location labels inaccurate.
Check browser and system settings separately
A browser’s Secure DNS, which sends DNS queries over HTTPS or a similar protocol, may bypass the system’s resolver settings. It encrypts the DNS connection but doesn’t automatically ensure that the connection uses the VPN. First check whether the browser uses a separate DNS service, then see which rule the request actually matches.
In Windows PowerShell or Command Prompt, you can use the read-only commands below to check for clues. The example domain is only used to trigger a DNS lookup; it isn’t a VPN19 route-testing endpoint:
ipconfig /all
nslookup example.comipconfig /all can help identify active network adapters and their configured DNS servers. nslookup shows the server it queried and the response it received. The latter makes its own queries, so it doesn’t represent the browser’s, every app’s, or the client’s remote DNS path. Even if the server shown is a local address, it may just be a local forwarding endpoint.
On macOS, use scutil --dns to view DNS configuration. On Linux systems using systemd-resolved, use resolvectl status to check the resolver associated with each interface. These are clues about configuration, not proof that all DNS queries enter the tunnel. Check them alongside the client’s DNS settings and request logs.
Per-app checks: browser success doesn’t mean every app works
If a webpage loads but a desktop app still fails, first check which traffic the VPN captures. Some apps follow the system proxy, others use their own network settings, and some call separate login pages, backend APIs, and update services. Testing only the homepage doesn’t cover the whole workflow.
- ✅ Browser: Visit the target site and check the connection logs for the login page, content pages, and actions you actually perform.
- ✅ Desktop app: Quit and reopen the app, repeat the action that failed, and check which rule matched its process or target domain.
- ✅ Command-line tool: Check for its own proxy settings or proxy environment variables. Don’t assume it uses the system proxy.
- ✅ Mobile app: Check that the VPN configuration is enabled and that the client hasn’t excluded the app or destination address.
- ❌ Don’t treat a successful client node test as proof that every request from the app works.
On Windows and macOS, system proxy and virtual adapter modes cover different traffic; check how your client implements them. Android clients may offer app include or exclude lists. On iOS, check the active VPN configuration and the rule options supported by the client; desktop menus don’t necessarily apply.
Linux desktop settings, terminal environment variables, and background services may also use separate network configurations. A service process won’t normally inherit a proxy just because your desktop browser uses one. If only a background task fails, check the service’s startup environment instead of repeatedly changing browser routes.
To check logs, trigger the target action deliberately, then look for the domain, process, rule, and exit at that time. If the request doesn’t appear at all, check whether the app is covered by the VPN. If it matched a direct-connection rule, review the rule order. If it selected a route but the handshake failed, check the connection error and whether the service is reachable.
If it looks connected but isn’t working, narrow it down by symptom
The exit hasn’t changed
Check whether the lookup site matched a direct-connection rule, whether your browser has its own proxy extension, and whether the client is connected to a node without enabling system-wide routing. Before temporarily changing modes, note your original settings. Change only the relevant option, verify the result, then restore it to avoid conflicting configurations.
Only a specific app fails
Check the app exclusion list and its own proxy settings. Login, file uploads, and media playback may use different domains or transport methods. Don’t assume the rules are complete just because you added the main site’s domain. Use logs and the service’s public documentation to add relevant rules; avoid widening matches without evidence.
The old location still appears after switching routes
An app may keep a long-lived connection open, and a website may retain session state. Reconnect to the target, then check the exit used by the new request. A private browsing window can help identify some session-related issues, but it won’t change your account region or automatically clear the service’s server-side signals.
The route appears after importing a subscription, but requests fail
A successful import only means the client read the configuration; it doesn’t guarantee that the protocol, transport options, and current client version are compatible. Check the specific error and retrieve a valid subscription again from the control panel. Don’t convert the subscription format at random or paste the subscription URL into a public testing site.
A subscription URL may contain account-identifying information. Before sharing screenshots with support, hide the full subscription URL, authentication fields, and private access domains. Keep only the mode, error message, and rule results needed to diagnose the issue.
Record a verifiable conclusion
A useful check should record which app and destination you tested, the mode in use, the matched rule, the selected exit, and whether DNS behaved as expected. Keeping these details together is more useful than saving a screenshot that only says “Connected.” You can repeat the same steps after an OS update, network change, or rule update.
Comparing public IPs helps identify the request’s source, DNS checks reveal unexpected resolution paths, and per-app tests help uncover differences in VPN coverage. These checks complement one another; passing any single one doesn’t mean all traffic on the device is handled as expected.
If you still can’t pinpoint the issue, describe the action, operating system, client mode, and log results you’ve checked in a support ticket. To review your client configuration, see the Guides. For rule or access issues, see the troubleshooting advice in the AI Acceleration Guide.