How can you tell if your VPN is working? First, compare your public IP before and after connecting. Then check your DNS resolution path and test the apps you actually use. A “Connected” status usually means only that the connection is established or the proxy core is running—not that every request from your device is using the selected route.
The goal isn’t to make every address change; it’s to confirm that traffic behaves as your configuration intends. In rule-based mode, local websites may be expected to connect directly. With a global proxy, apps that aren’t routed through it may still connect directly. Follow the checks below in order, rather than treating an accessible website, normal node latency, or a changed location as proof that everything is working.
First, define what you’re checking: the connection, your public IP, or individual apps
A subscription link provides access to nodes and configuration. Importing it into a client and updating successfully only confirms that the client retrieved the configuration; it doesn’t mean the proxy is enabled. Shadowsocks, VMess, Trojan, VLESS, Hysteria2, and TUIC are different proxy protocols. Protocol support and a complete configuration can affect connectivity, but the protocol name alone doesn’t prove that traffic is routed through the proxy.
Also distinguish the network route from how traffic is handled on your device. IEPL dedicated lines, relay routes, and direct connections describe how the server-side or access path is set up. System proxies, in-app proxies, and TUN mode determine which device traffic enters the proxy. A dedicated line won’t automatically route apps that aren’t configured to use a proxy, and TUN mode doesn’t replace checks of routing and DNS behavior.
| Check | What it confirms | What it doesn’t confirm |
|---|---|---|
| Client connection status | The client reports an established connection or a running proxy core | That every app is using the connection |
| Browser public IP | The address used by this browser request | The public IP used by desktop software, games, or background services |
| DNS test | Clues about the resolvers handling domain lookups | The complete resolution path for every domain and app |
| Client connection logs | The rule matched by a request and its selected outbound route | Whether the destination website allows access or the region associated with an account |
How to check your public IP: keep a before-and-after comparison
Use a trusted public IP lookup site to check your address and approximate location. You don’t need to share your account password or subscription link. First, disconnect the proxy and note your current public IP, ISP, and whether the page shows an IPv6 address. Then enable the client, select a node, and revisit the same test page in the same browser. Keep both results for comparison.
- Set a baseline. Keep your network unchanged, pause other proxy tools and browser extensions that may route traffic, and check your public IP while disconnected.
- Check the client mode. Note the selected node and whether you’re using rule-based, global, or direct mode. Confirm that the system proxy or TUN switch is enabled.
- Run a fresh test. Reload the test page, using a private window if needed to reduce cache interference. A private window doesn’t bypass the system proxy or make you anonymous.
- Check the actual route. Find the test page’s domain in the client connection logs and check its matched rule, policy group, and final node.
- Cross-check the result. Try another independent lookup site. If the reported location differs, compare the IP addresses before concluding that the node isn’t working.
If your public IP changes and the logs show the request going through the selected node, that browser request is using the proxy. If the address hasn’t changed, check whether the test domain matches a direct-connection rule or whether the browser has its own proxy settings. The same result alone doesn’t prove that the node failed to connect.
IP geolocation comes from databases, not real-time tracking. Different databases may associate the same address with different cities or regions, and IP registration details don’t necessarily reflect a server’s physical location. Streaming platforms and other sites may also use account region, payment details, or activity history to determine location. A changed public IP doesn’t guarantee access to a particular service.
A DNS leak isn’t determined by the resolver’s country alone
DNS translates domain names into IP addresses, while application connections reach the destination. They can take different routes, so it’s worth checking DNS behavior even when your public IP looks right. A DNS leak generally means queries that should be covered by your proxy rules are sent through the local network or an unintended resolver. Assess this against your configuration, not just the country shown by a test.
Run a trusted DNS leak test while disconnected and note the resolver names and ISPs. After connecting, repeat a similar test and check the client’s DNS settings and logs. Test sites typically use dedicated domain lookups to identify the public-facing recursive resolver; they don’t show every link between your device and that resolver.
If a local ISP resolver still appears after connecting, and your configuration is supposed to use remote DNS, investigate further. Conversely, seeing a public resolver overseas doesn’t prove that queries went through the proxy: your system or browser may use it even when connecting directly.
Check browser Secure DNS and client DNS together
Browser Secure DNS commonly uses DoH, and your operating system may also be configured for encrypted DNS. This encrypts the relevant DNS traffic but doesn’t guarantee that it goes through the proxy. A browser may bypass system DNS settings and connect to a resolver on its own; whether that connection is proxied depends on the system proxy, TUN mode, and split-tunnel rules.
If the results don’t match, note your current settings first. Then temporarily configure the browser to use the system DNS settings and retest alongside the DNS configuration recommended by your client. Don’t turn off all Secure DNS settings just to make a test page show “green.” Rule-based setups may intentionally resolve local domains locally and other domains remotely; that’s different from an unintended leak.
DNS caching can reduce new lookups, so make sure the test page sends fresh requests. If the client uses Fake-IP, an app may receive a synthetic address for internal mapping. That address isn’t the final public IP, and its geolocation doesn’t indicate where the node is located.
Test apps individually: a working browser doesn’t mean everything works
On Windows and macOS, the system proxy usually affects only apps that follow system settings; it doesn’t route all device traffic through the tunnel. Some desktop apps have their own proxy settings, command-line tools may rely on environment variables, and other apps connect directly. TUN mode can capture more traffic, but you still need to check permissions, route exclusions, and client support.
Android clients may let you include or exclude specific apps. iOS clients generally handle traffic through a system network extension, and the exact coverage depends on the client and its configuration. Don’t assume settings with similar names work the same way across platforms. For platform-specific steps, see the client setup guide.
- ✅ Browser: Check your public IP and confirm the test domain’s outbound route in the connection logs.
- ✅ Desktop apps: Close existing connections and make a new request. Check logs by time, destination domain, or process; don’t draw process-level conclusions if the client doesn’t show process details.
- ✅ Command-line tools: Check whether the tool supports the system proxy or its own proxy settings, then compare with the client logs. Don’t assume the browser’s result applies.
- ✅ Mobile apps: Check the per-app proxy list and system permissions, then reopen the app and test the feature you need.
- ❌ Don’t assume an app is using the proxy just because its home screen loads. The content may be cached locally, with no new network request.
For apps without a public IP lookup feature, check whether new connections appear in the client logs and match the expected outbound route. No visible log entry doesn’t necessarily mean the app connected directly: logging may be too limited, the connection may be reused, or the client may not display that type of entry. Cross-check with the app’s own network diagnostics and your system settings.
Connected, but traffic isn’t using the route? Troubleshoot in this order
Check the mode and rules first, then traffic capture
Make sure the client isn’t in direct mode and that the destination domain isn’t on a bypass list. In rule-based mode, traffic may match a region, process, or fallback rule, and a policy group may select a direct route. Check the final outbound route, not just the highlighted node in the list. Temporarily switching to global proxy can help identify a rule issue, but it only changes how traffic already entering the proxy core is routed; it won’t automatically capture apps that weren’t using the proxy.
If the browser and other apps behave differently, check whether another program has overwritten the system proxy, a browser extension has set a separate route, TUN has the required permissions, or per-app exclusions are taking effect. During testing, use only one client to capture traffic so it’s easier to isolate the cause.
Then check existing connections, protocol support, and network changes
After switching nodes, existing long-lived connections may continue using their original route. Reopen the app or disconnect its existing connection before making a new request; this is more useful than repeatedly refreshing a status icon. After switching between Wi-Fi and mobile data, check the connection status and routes again.
If web pages work but voice calls, games, or other real-time features don’t, check UDP support and the relevant rules separately. That doesn’t necessarily mean the entire proxy is failing. Likewise, a successful node latency test only confirms that the test request completed; it doesn’t guarantee that the destination service connection, authentication, or regional access will work.
Finally, check that the subscription is up to date, that your client supports the protocols it contains, and that your plan and traffic status look normal in the account panel. Don’t paste your subscription link into an unfamiliar conversion site to troubleshoot; it may contain access credentials. If you need help, use the support contact page and share your client name, operating system, the issue you’re seeing, and a redacted log.
Final verdict: use multiple checks to confirm it’s working
A public IP comparison shows where a request went, a DNS test checks whether name resolution follows your configuration, and app-by-app testing confirms whether your everyday software is actually routed through the proxy. Together, they’re more reliable than a “Connected” status alone. Each test covers only the request made at that time; it can’t prove ongoing anonymity or that every app is always protected.
You don’t need to keep changing settings during everyday use. Save a baseline of your public IP, mode, and DNS configuration under normal conditions. If something goes wrong, compare against it and change one setting at a time. This helps pinpoint the issue without disrupting split tunneling that’s already working. For protocol and route terminology, see the protocol and routing reference.