How to confirm your VPN is really working: check your exit IP, DNS, and app-by-app verification
Use public IP checks, DNS tests, and app-specific checks to verify your connection and troubleshoot cases where traffic bypasses the proxy despite showing as connected.
How can you tell if your VPN is actually working? Don’t rely on the client’s “Connected” status alone. Compare your public IP before and after connecting, check where DNS requests go, then test the apps you actually use. These results should match your routing rules to confirm that the traffic you intend to proxy is taking the expected path.
A webpage loading in your browser doesn’t mean your work apps are using the VPN too. And a change in your apparent location doesn’t mean every DNS request is going through the tunnel. Follow these straightforward checks in order; there’s no need to start by changing a bunch of advanced settings.
Connection status vs. actual operation
“Connected” usually means the client has established a tunnel, started a local proxy, or completed a connection stage—the exact meaning depends on the client. That status alone doesn’t prove that every app is using the connection or that the destination website accepts your current exit IP.
Start by identifying the mode in use. A system proxy usually affects only apps that follow the system proxy settings. TUN or system VPN mode routes traffic through a virtual network interface, but coverage also depends on routing, exclusion lists, and app settings. Browser extensions typically affect the browser only, so their results don’t represent the whole device.
Public IP: establish a baseline, then compare
Your public IP is the address destination websites see. For a meaningful comparison, use the same browser, the same lookup page, and the same local network before and after connecting. Try our IP lookup tool or another check you trust. First make sure your lookup site isn’t set to bypass the proxy by a custom rule.
- Record your baseline. If it’s safe to briefly disconnect the proxy, note your public IP, its reported location, and the network provider. Don’t mistake a local network address shown in your system settings for your public exit IP.
- Check again after connecting. Select your intended route and enable the proxy mode you need. Run the lookup again instead of relying on a result left on the page from an earlier check.
- Check the client logs. If your client provides a connection log, see which rule matched the lookup site, which outbound group it used, and whether a new connection was established.
- Restore your usual routing and check again. Switching modes temporarily is only for troubleshooting. Once you restore your settings, confirm that your usual websites still follow the expected routes.
If your IP hasn’t changed, first check whether a rule sent the lookup request directly; don’t assume the route has failed. If it has changed but the reported location doesn’t match the route name, don’t rely on the map alone. IP databases can lag behind updates, and different databases may label the same address differently. Route names, exit IPs, and geographic labels don’t always line up exactly.
DNS tests: check the resolution path, not just the location
DNS translates domain names into IP addresses. When your browser visits a site, the domain may be resolved by the system resolver, the client’s built-in resolver, or the secure DNS service configured in your browser. Web requests and DNS requests can take different routes, so a changed public IP alone doesn’t confirm that DNS is following the expected path.
Common DNS test pages trigger new domain lookups and show the recursive resolvers they detect. These are usually not your web traffic’s exit IP, and may not be the first DNS address configured on your device. Public DNS services may also use distributed infrastructure, so a resolver appearing in a different region from your exit IP doesn’t by itself prove a leak.
The more useful question is: Are DNS requests you expect to go through the proxy being resolved via your local network? With split tunneling, local sites resolving directly may be completely normal. But if you expect all DNS lookups to go through the tunnel and the test keeps showing your local provider’s resolver, check your settings.
- Check your browser’s secure DNS settings. Your browser may use DoH instead of the system resolver. Encrypted DNS protects DNS traffic in transit; it doesn’t automatically make DNS requests go through the proxy.
- Check the client’s DNS mode. See whether DNS interception is enabled, whether proxied domains have the right resolution policy, and which route the upstream DNS connection takes.
- Keep caching in mind. After changing settings, old DNS results or existing connections may still be reused. Restart the relevant app and run the test again; that’s more useful than repeatedly refreshing an old page.
If websites load but the DNS test won’t complete, the test script, an extension, or the test domains themselves may be affected. Cross-check with another trusted test rather than treating an error on one test page as proof of a DNS leak.
Test each app: a browser result doesn’t cover every app
Keep the same route and test your browser, work apps, and any other apps you need. Change only one setting at a time and watch the client’s connection log. This helps distinguish a route issue from an app that ignores the system proxy.
| Symptom | Possible cause | Check first |
|---|---|---|
| Browser IP changes, but desktop apps still have issues | The app ignores the system proxy or is excluded | App proxy settings, TUN coverage, and process rules |
| Lookup page IP is unchanged, but other sites work | The lookup domain matches a direct-connection rule | The matching rule and outbound group for that request |
| IP changes, but some domains won’t load | DNS issues, a missing rule, or a site restriction | DNS results and connection logs for the failing domains |
| Old exit IP still appears after switching routes | The app reused an existing connection, or the page didn’t run a new lookup | Close old connections, restart the app, and test again |
| Exit IP looks right, but account access is restricted | The site’s location, account, or exit-IP risk controls | The site’s error message and account requirements—not just the proxy mode |
On Windows and macOS, a system proxy and virtual network interface mode route traffic differently. Some games, command-line tools, and work apps have their own network settings. On Linux, desktop proxy settings aren’t guaranteed to be used by every program; check the app’s documentation for environment variables or its own proxy settings.
On Android and iOS, a system VPN indicator only shows that traffic interception is enabled. Check the client’s app exclusions and routing rules, and make sure they don’t conflict with other network tools. If an app can’t check its own IP, review the client’s connection log while it makes a network request, then confirm the result using the app’s actual features.
Connected but not working? Troubleshoot step by step
Don’t change your route, DNS, rules, and client mode all at once. If several variables change together, it’s hard to know what fixed the issue—even if things start working again. Save your current settings, then check each item below in turn.
- ✅ Make sure your subscription is up to date and the node configuration isn’t outdated. A successful import only means the configuration was read; it doesn’t mean the route is connected.
- ✅ Confirm that the system proxy or TUN mode is actually enabled, and check whether the target app is excluded.
- ✅ Check which rule matched the failed request. Identify whether it was set to direct, proxy, or reject, and note the outbound group.
- ✅ If your permissions and network policies allow it, temporarily compare with global proxy mode. If that fixes the issue, check your routing rules first.
- ✅ Check DNS and address-family handling, then close old connections, restart the target app, and test again.
- ✅ If every target fails, try another available route for comparison and save the error message in case you need to submit a support ticket.
“Global proxy” in a client doesn’t necessarily mean the entire device is covered. It may only route through one exit the traffic that has already entered the proxy client; apps outside it may still connect directly. To cover more traffic, check the client’s documentation for system proxy or virtual interface mode instead of just switching routing rules.
Protocol names aren’t a substitute for testing. Shadowsocks, VMess, Trojan, and VLESS configurations require a compatible client. Hysteria2 and TUIC rely on UDP transport, so network restrictions on UDP may affect the connection. Before changing protocols, check client compatibility and network conditions; no protocol guarantees that the connection will work.
Common misconception: a site loading doesn’t mean traffic took the right route
Is reaching an international website enough to confirm your VPN is working?
No. The site may already be reachable directly, or you may be seeing cached content. Check a fresh public IP lookup, the connection log, and an actual network operation together. Conversely, a site denying access doesn’t prove the VPN failed: the site may restrict certain exits or make decisions based on your account’s region.
Does an address appearing in a WebRTC test always mean there’s a leak?
It depends on the address type. A local network address or a masked local host identifier isn’t the same as exposing your public IP. If a test shows your local public IP in a situation where traffic should go through the tunnel, check the browser’s WebRTC behavior, the UDP route, and the client’s traffic coverage.
Can a dedicated or relayed route eliminate the need to test?
No. IEPL, relay, and direct routes describe how a connection is set up. They don’t mean an app is using the proxy correctly, and they don’t resolve DNS configuration issues automatically. Route selection determines the transmission path; client settings determine whether traffic enters it. Check both.
Final check: keep results you can verify
Note your current network, client mode, route name, public IP result, DNS test result, and any affected apps. There’s no need for a complex report—just record “which request took which route under what conditions” to avoid guesswork. Repeat the key checks after switching local networks or updating your rules.
If you’re unsure how to import a subscription or enable traffic routing in your client, start with the setup guide. To compare protocols and routing concepts, see the protocol reference. When something goes wrong, keep the specific error message—it’s more helpful than saying “it shows connected, but it doesn’t work.”