How can you tell if your VPN is working? Check your public IP and DNS, then test apps individually—it’s more reliable than relying on the client’s connection icon. Check your split-tunneling rules too: are requests meant to use international routes going through the proxy, while direct-connection traffic stays direct? These checks apply to specific requests, not as a blanket “security passed” stamp for your whole device.
First, distinguish “connected” from traffic actually using the VPN
A connected status usually means the tunnel is established, the proxy core is running, or system traffic interception is enabled, depending on how the client works. It doesn’t prove that your browser, meeting app, and command-line tools all use the same route. A successful node connectivity test only shows that the test request can reach its destination.
With a system proxy, apps must honor the system proxy settings; software that connects to the internet independently may bypass them. TUN mode routes traffic through a virtual network interface and usually covers more, but routing rules, exclusion lists, permissions, and client implementation still matter. Mobile VPN interfaces may also exclude specific apps, so the system status icon doesn’t prove that every request is proxied.
With split tunneling, local websites can connect directly while international websites use the proxy. Seeing the same exit IP for every website isn’t the only correct outcome. Before testing, define the app and expected route; otherwise, normal split tunneling can look like a failure.
| Check | What it tells you | What it can’t prove on its own |
|---|---|---|
| Public IP address | The public exit IP used by the request to reach the website | That other apps, DNS, or other address families use the same route |
| DNS test | The recursive resolver egress involved in resolving the test domain | That all domains are resolved the same way |
| Client connection logs | Rule matches and exit selection for captured requests | That apps missing from the logs definitely didn’t connect to the internet |
| Test in the target app | How that app behaves with the current network and settings | That account region, content access, and network egress are all aligned |
Check your public IP: compare before and after connecting
Record the direct-connection state first, then the VPN state. Don’t change nodes, networks, and rules at the same time, or you won’t know what caused a change in results. Pause other proxy extensions during testing to avoid a confusing mix of browser-extension and system-proxy routes.
- If it’s safe to test a direct connection, disconnect the client. Visit a trusted public IP lookup tool in your browser, then note the IP address, network provider, and time of the check.
- Connect to the route you want to test. Confirm whether you’re using rule-based or global proxy mode, and check whether the IP lookup site is set to connect directly.
- Run the check again, using a private window if needed to rule out cached page content. Compare the actual IP addresses, not just the countries or regions shown on a map.
- Check the client’s connection logs and confirm which rule matched the lookup domain and which exit was used. If the tool shows separate results for different address families, check each one.
- Keep everything else the same and switch back to the original state for another check. If you can reproduce the change, you’ll have stronger evidence about the request’s route.
A changed IP supports the conclusion that this lookup request used a different exit, but check the rules to confirm it’s the expected route. If the IP hasn’t changed, don’t assume the connection failed: a direct-connection rule may apply to the lookup site, or the page may not have made a fresh request.
IP geolocation databases can take time to update, and different tools may assign the same address to different regions. Account settings, cookies, and other factors can also affect the account region, search results, and video catalog shown by content platforms. Changes in these results aren’t a substitute for checking your exit IP.
Check DNS: focus on the resolution path, not just the country
DNS resolves domain names to network addresses, and its route may differ from the route used for subsequent connections. A website request may use the proxy while DNS queries go through your local network. Browsers may also use their own encrypted DNS service, bypassing the DNS settings you expected the client to use.
Most DNS leak test pages generate test domains, then check which recursive resolvers query the test service. The listed addresses often belong to resolver infrastructure—not necessarily the DNS server your device connects to directly. Public resolvers may also use anycast and multiple egress points, so their displayed locations aren’t enough to draw a conclusion.
- Start by checking the client’s DNS settings: how are proxy and direct-connection domains resolved, and is DNS interception or remote resolution enabled?
- Check whether your browser has its own secure DNS setting. Note the current setting first, then adjust it according to the client’s documentation to avoid competing DNS mechanisms.
- Run a DNS test with the same configuration and compare the results with the client logs. If a test domain that should resolve through the proxy uses a local resolver, investigate further.
- Test again after changing settings. Old DNS results may remain in the system, browser, or app cache, so follow your platform’s instructions to clear the cache or restart the relevant app.
Encrypted DNS queries don’t necessarily go through the VPN, and DNS results showing an overseas location don’t prove that the target app is using the proxy. Encryption in transit, the resolver, and the request’s exit route are separate issues.
Using local DNS for local domains that are meant to connect directly may be normal. Focus on whether queries that should follow the proxy policy are using an unexpected resolution path. Don’t paste subscription links, account credentials, or complete connection logs into public testing pages.
Test each app: a working browser doesn’t mean your whole device is covered
After testing your browser, check the apps you actually plan to use. Start with the client’s connection list: filter by process name or destination domain, perform a new network action in the app, and check whether it appears in the logs, matches the right rule, and uses the expected exit.
Desktop and command-line apps
System proxy settings on Windows and macOS mainly affect apps that honor them. Some games, updaters, and command-line programs need an in-app proxy, environment configuration, or TUN routing. How a terminal tool behaves depends on its implementation and launch environment; don’t assume it shares your browser’s proxy settings.
If your browser works but a particular program doesn’t, first check whether it supports proxies and how it actually connects to the internet. Don’t copy local proxy port numbers from random online guides; use the settings shown in your client. With TUN mode, also check that the virtual interface is running, whether the app is excluded, and whether other networking software has taken over routing.
Mobile apps and in-app connections
Android clients may let you include or exclude apps; on iOS, traffic routing also depends on the client’s VPN configuration and rules. The VPN indicator is only a clue about system status, not a substitute for testing the app you want to use. Recheck the connection and rules after switching between Wi-Fi and mobile data.
Existing connections may keep using their original route. After changing rules, fully quit and reopen the app, then make a new request. A signed-in session, offline content, or local cache can make an app appear to work, so test an action that genuinely needs an internet connection instead of just checking whether the home screen loads.
- ✅ Make a new internet request in the target app instead of refreshing a cached page.
- ✅ Compare the process, domain, matched rule, and exit; keep only the logs needed to explain the result.
- ✅ Test your browser and the apps you actually use separately; don’t generalize one app’s results to your whole device.
- ❌ Don’t treat “the app didn’t show an error” as proof of the exit route, or assume a content access error is automatically a network issue.
Connected but not working? Troubleshoot by symptom
Subscription updated, but the client is still using an old node
A subscription link gives the client access to nodes and related configuration; opening it doesn’t automatically route your device’s traffic. After updating, confirm the import succeeded, select a working node, and enable the appropriate system proxy or tunnel mode. Some clients require you to reload the configuration, and similarly named old profiles can be easy to select by mistake.
Shadowsocks, VMess, Trojan, VLESS, Hysteria2, and TUIC each have their own configuration requirements. The client must support the relevant protocol and parameters. Being able to import a profile doesn’t guarantee that the connection will work. If the logs report an unsupported protocol or handshake failure, check client compatibility and subscription status before changing DNS repeatedly.
Browser uses the expected exit, but other apps connect directly
Check system proxy support, app exclusion lists, and split-tunneling rules first. Browser extensions that only proxy browser traffic are another common cause. Global proxy mode generally routes traffic intercepted by the client through the proxy; it doesn’t automatically capture programs that weren’t being intercepted in the first place.
Some requests connect directly while others time out
Check for an IPv6 route that isn’t covered, and whether DNS results match the actual routes. IPv6 support itself isn’t the problem; what matters is whether the client handles it as expected. Don’t permanently disable a networking feature at the first sign of trouble. Check the documentation and logs, then run a reversible comparison test.
IEPL, relayed, and direct routes describe how network traffic is carried; they don’t replace checks for traffic interception on your device. Even a reachable route can send requests through the wrong exit if the split-tunneling rules are incorrect. Conversely, the right exit doesn’t guarantee that account or content restrictions on every website will be resolved.
Turn your results into conclusions you can verify
Record the test network, client mode, selected route, target app, exit result, and matched rule. If something goes wrong, change one setting at a time and test again. When contacting support, share redacted error messages and relevant logs. Don’t include subscription tokens, account credentials, or unrelated browsing records.
What the results mean: You can be reasonably confident the VPN is working in this scenario when the target request uses the expected exit, DNS follows the split-tunneling design, and the target app’s connection logs show the correct exit. This doesn’t guarantee the same results for other apps, networks, or future configuration changes.
Recheck key apps after switching networks, updating the client, or changing subscription settings. For help with importing a profile, see the Quick Start Guide; for connection and routing issues, continue troubleshooting in the Help Center. Identifying the request’s route first usually makes it easier to diagnose speed and usability issues.