How can you tell if your VPN is really working? Don’t rely on the “Connected” status alone. Compare your public IP before and after connecting, check the DNS resolution path, then test the apps you actually use. A connection icon only shows that the client has entered a connected state; it doesn’t mean your browser, desktop apps, and background traffic all use the same route.
The key question is: Do new requests from the app you’re testing follow the expected rules and use the selected route? Rule-based modes may send some sites directly, so a local site showing your original IP isn’t necessarily a problem. Conversely, a changed IP in your browser doesn’t prove that every app is using the VPN.
Connection status, public IP, and app traffic routes
Proxy clients may route traffic through system proxy settings, a virtual network adapter, or per-app rules. A system proxy usually relies on apps honoring the proxy settings. A virtual adapter can handle more traffic, but routing, exclusion lists, and protocol support still matter. Check the active mode before interpreting test results so you don’t mistake normal split routing for a failure.
| Check | What it confirms | What it can’t confirm on its own |
|---|---|---|
| Client shows “Connected” | The connection function has started; the exact meaning depends on how the client works | Whether the app being tested uses the VPN route |
| Public IP has changed | The public IP used for this particular request has changed | Whether other apps and DNS use the same route |
| DNS test | Which recursive resolvers handled the test domain’s lookup | Whether all domain lookups are handled the same way |
| App requests and rule logs | Which rule matched that connection and which outbound route was selected | What untested apps will do next |
Public IP: record a baseline, then compare a new request
Disconnect from the VPN, open the IP lookup page, and note your current public IP and network provider. Keep the same network connection, connect to the route you want to test, and check again. If you switch networks in between, your original public IP may change on its own, so the comparison alone won’t show that the VPN is working.
- Disconnect and check your current public IP. Keep the result for your own comparison; there’s no need to share the full address.
- Connect to the route you want to test. Confirm the client shows the expected server and operating mode, not just that a server is selected.
- Run the check again to get a fresh result instead of relying on an old page. If needed, close the existing tab and open a new one.
- Find the lookup request in the client’s connection log and check which rule matched and which outbound route it used.
- If the lookup domain is set to connect directly by a rule, retest with a temporary proxy rule supported by the client, then restore your original settings.
A changed IP is useful evidence, but the displayed region isn’t a precise location. Databases may update at different times and classify addresses differently, so a city mismatch doesn’t mean the VPN failed. Check the address, network provider, and client’s outbound logs first rather than relying on a map pin.
Also check IPv4 and IPv6 separately. A lookup page may show only one address type while the other still uses a different route. Use a tool that tests both and review the client’s IPv6 routing settings. Disabling IPv6 isn’t a universal long-term fix for every device.
DNS checks: a resolver is not the same as a traffic exit
DNS translates domain names into IP addresses; your browser then uses those results to connect to the destination. These steps are related, but they’re not the same. DNS test pages typically use specially configured domains to identify recursive resolvers. They don’t show the route taken by every data packet, so a resolver in a different location from your VPN exit doesn’t by itself prove a leak.
A DNS leak means queries that should follow your proxy privacy settings are unexpectedly sent over a local or otherwise unintended route. To assess whether there’s a problem, consider the client’s DNS mode, the browser’s secure DNS settings, the resolver’s network, and the active routing rules together. If your split-tunneling policy intentionally resolves local domains locally, that’s a policy choice—not automatically a leak.
Why encrypted DNS in your browser can affect test results
Your browser may use DNS over HTTPS and its own resolver instead of the system’s DNS settings. Encryption protects the query in that part of the connection; it doesn’t prove that the query went through the VPN. Routing and proxy rules determine the exit for DNS requests made directly by the browser, too.
If a DNS test looks unexpected, first note whether secure DNS is enabled in your browser. Then check whether your client can route or coordinate those lookups. You can temporarily change the setting to compare results, but restore the configuration you want to use afterward. Don’t change the browser setting and switch servers at the same time, or you won’t know which change affected the result.
DNS caching can also keep old results in use. After changing settings, run a fresh lookup and handle the cache according to your operating system or client’s instructions. A page still loading after a refresh doesn’t prove the new DNS settings are active: resources may be cached, and connections may be reused.
App-level checks: a working browser doesn’t prove every app is covered
A browser may honor the system proxy while a desktop app ignores it, a common reason websites work but an app doesn’t. A browser extension may also give the browser a separate proxy route. When testing, distinguish between an extension proxy, system proxy, and virtual network adapter; they aren’t interchangeable settings.
What to check on desktop and mobile
On Windows and macOS, check whether the app supports the system proxy or has its own proxy settings, and whether the client’s virtual network adapter mode is enabled. Command-line tools may also rely on proxy environment variables, so their results don’t prove what your browser is doing. Enabling a virtual adapter doesn’t guarantee that it’s handling traffic; check permissions and routing as well.
Android clients may let you include or exclude specific apps, so make sure the app you’re testing isn’t excluded. On iOS, check the routing options and rules supported by your client instead of assuming the menus match other platforms. A VPN status indicator on mobile still doesn’t replace testing the app’s actual traffic.
- ✅ Close and reopen the app, then trigger a new network request.
- ✅ Find the relevant domain or process in the client’s connection log and check its rule and outbound route.
- ✅ Check the app exclusion list, browser proxy extensions, and any other network tools that are still running.
- ✅ Test web browsing, image uploads, and app messages separately. Don’t treat a cached page as proof of a live connection.
- ❌ Don’t assume that a successful browser test means every app uses the selected route.
Messaging apps and sync tools may keep long-lived connections open. An existing connection may not reconnect as soon as you switch routes, so restarting the app is often more informative than repeatedly refreshing a page. If uploads, audio or video, or real-time messages are affected, check UDP support and routing rules instead of testing web access alone.
Connected but traffic isn’t using the VPN? Narrow it down by symptom
Public IP unchanged, but the client shows traffic
First check whether the lookup request matched a direct-connection rule, then confirm the system proxy or virtual adapter is actually active. The client may be showing subscription updates, latency checks, or other background requests—not traffic from the browser you’re testing. If the target request doesn’t appear in the logs, check which traffic the client handles before switching servers repeatedly.
Public IP changed, but the service still won’t load
This usually means the test request used the VPN route; it doesn’t prove the service you want is reachable. A service may apply restrictions based on account region, payment details, IP reputation, or session status. Check the target request’s actual route and then review the error. A matching region doesn’t guarantee access, and DNS isn’t the cause of every access issue.
Browser works, but a standalone app doesn’t
Check whether the app bypasses the system proxy, then review its process rules, built-in proxy settings, and connection reuse. If only one feature fails, compare the domains and transport methods it uses with those used by working features. Seeing protocol names such as Shadowsocks, Trojan, or VLESS in a subscription only identifies the configuration type; it doesn’t prove the client is routing the app’s traffic.
Everything loses internet access after traffic interception is enabled
Check virtual adapter permissions, the default route, DNS settings, and whether another network tool is changing them at the same time. First restore a working baseline, then enable features one at a time. Don’t leave system protections disabled just to run a test. If you’re unsure where a setting came from, keep a record of the error and contact support rather than repeatedly importing unfamiliar configurations.
Retest and draw a conclusion: keep evidence that corroborates
For a useful retest, keep the network and target app the same and change only one factor at a time. Record the test time, client mode, selected route, target domain, and any error, then compare the IP, DNS results, and rule logs. This helps distinguish changes caused by the server, routing rules, or the app’s own state.
If you need help, share these details through the Help page or your user dashboard. Before sharing screenshots, hide subscription links, access tokens, and personal information. Connection logs may include the domains you visit. A no-logs policy describes the service’s privacy practices; it doesn’t mean local client logs are safe to share publicly.
Bottom line: A strong indication that the VPN is working comes from new requests in the target app matching the expected proxy rules, an IP consistent with the selected route, and DNS behavior that fits your chosen policy.
A single web test only verifies that particular request. To check other apps, address types, or what happens after a disconnection, test each separately. “Connected” and a matching region aren’t substitutes for those checks.
If you’re setting things up for the first time, follow the Quick Start guide to import your configuration and choose a mode, then run the checks in this article. A subscription link is used to update servers and related settings; it doesn’t route traffic by itself. Successful import, a visible server, and requests actually using the route are separate things to verify.