First, define what “working” means
How can you tell if a VPN is working? Don’t rely on the connection icon alone. Check your exit IP, DNS resolution path, and the actual connection used by the app you care about. Passing a test in your browser only tells you about that browser request—not the whole device.
When a client says “Connected,” it usually means a tunnel or proxy has been established, or local traffic capture has started. Whether a request uses the VPN also depends on proxy mode, routing rules, app settings, and network conditions. In rule-based mode, some sites may connect directly while others use the proxy—that can be expected.
Before testing, be clear about your goal: do you want a particular work app to use an international route, or do you want the client to handle most network requests on your device? The right test depends on the goal. Don’t assume every test page must show a different location for the VPN to be working.
A meaningful result means the request matches the intended rule, uses the expected exit, and follows the configured DNS path. A green icon alone can’t confirm all of that.
Exit IP: record a baseline, then compare
Your exit IP is the address a website sees as the source of a request—not your device’s address on the local network. The address shown in your system’s network settings can’t tell you whether a remote website is being accessed through a proxy. You can use our IP lookup, but keep in mind that your routing rules may send the lookup site’s traffic direct.
- If it’s safe to briefly disconnect, turn off the client connection, open an IP lookup page, and note the exit address and network provider. This is your local-network baseline.
- Connect to the route you want to test and confirm the node and mode selected in the client. Run the lookup again rather than relying on a page that was already open.
- Compare the address and network provider, then check which rule matched the lookup domain. If it’s set to connect directly, an unchanged result is expected.
- To test the proxy path, you can temporarily make sure the lookup request uses the proxy. Restore your usual rules afterward and note which mode you used for the test.
IP geolocation comes from databases that may be out of date or may show the data center’s registered location. A node name, the city shown by an IP database, and the actual network path are not the same thing. A changed address shows that this request used a different exit, but the city label alone can’t tell you the route’s quality or physical location.
Check IPv4 and IPv6 separatelyYour network may support both IPv4 and IPv6. A test for one address family doesn’t prove the other is covered too. If the client doesn’t handle a type of traffic, check its documentation and adjust the configuration rather than assuming every request uses the same exit.
DNS: check the resolution path, not just the country label
DNS translates domain names into addresses used to make connections. DNS test pages typically use specific test domains to identify which recursive resolvers handled the lookups. Resolver addresses are not the same as the exit used for web traffic; they don’t have to match or belong to the same network.
Whether DNS is leaking depends on your configuration goals. If you want DNS lookups to use a controlled path but they’re actually sent to a resolver provided by your local network, investigate further. On the other hand, using local DNS for local sites may be intentional in a split-tunnel setup and doesn’t automatically mean the configuration has failed.
Browser secure DNS, encrypted DNS at the system level, DNS built into the client, and an app’s own resolution method can all use different paths. Encrypted DNS protects the relevant DNS traffic, but doesn’t guarantee that lookups use your selected proxy. A browser test also can’t tell you how a mail or meeting app resolves domains.
| What you see | Possible explanation | Next step |
|---|---|---|
| Website exit has changed, but the resolver still appears to be on the local network | Web traffic and DNS lookups are using different paths | Check the client’s DNS routing, secure DNS, and split-tunnel settings |
| Resolver belongs to a public DNS service | It may be configured by your browser, system, or client | Find out which component made the lookup and how the request was routed |
| Resolver and exit show different regions | This may reflect database differences or the public resolver’s network architecture | Check your configuration and logs; don’t judge a DNS leak by location alone |
| Client logs show a mapped address | An internal mapping feature such as Fake-IP may be enabled | Check the client documentation; don’t mistake an internal address for a public exit |
After changing DNS settings, clear the relevant cache as directed by your client or system, then try the request again. Keep the original settings and change one thing at a time so you can tell what affected the result. Don’t enter an unfamiliar DNS address just to make a test page “look consistent.”
Test apps individually: what to check after your browser
On desktop, “System Proxy” usually configures the proxy entry provided by the operating system; it doesn’t force every program to use it. A browser that follows the system setting may work while an app that ignores it connects directly. Modes such as TUN, which use a virtual network interface, can capture more traffic, but coverage still depends on routing, exclusions, permissions, and how the client is implemented.
VPN settings on mobile devices may also include app exclusions, on-demand connections, or per-app rules. Android battery and background restrictions can affect whether a connection stays active; iOS on-demand settings, system permissions, or managed configurations can affect how it’s enabled. Don’t assume the same settings screenshot applies across platforms.
- ✅ Browser: Test in a clean browser profile first and check whether a proxy extension conflicts with the client.
- ✅ Mail and collaboration apps: Check for a separate proxy setting in the app, reconnect, and review the client’s connection log.
- ✅ Meeting apps: Check sign-in, joining a meeting, and audio/video traffic separately. A website loading doesn’t mean media uses the same route.
- ✅ Background apps: Test again after switching networks or waking the device to make sure the app isn’t reusing an earlier connection.
- ❌ Don’t treat “the page loads” as the only proof; it may be accessible over your local network anyway.
Clients with connection logs may show some details such as domains, processes, matched rules, or outbound names. Open the app you’re testing and perform a specific action, then look for the corresponding log entry. That’s more useful than watching total traffic counters. If there’s no entry, consider the log level or feature limitations before concluding the app isn’t connecting.
A practical troubleshooting order when connected traffic isn’t using the VPN
Start with the subscription and active configuration
A subscription link lets the client retrieve nodes and configuration; it doesn’t automatically route every app through them. After updating, make sure the updated configuration is active—not an older one or a different profile. A node appearing in the list doesn’t mean it was selected for this connection.
Protocol names alone don’t prove anything either. Options such as Shadowsocks, VMess, Trojan, VLESS, Hysteria2, and TUIC require a client that supports the relevant protocol and settings. Importing a configuration is only the first step: check protocol compatibility, connection establishment, and traffic routing separately.
Then check routing rules and proxy conflicts
Rules may match domains, destination addresses, or processes, and they often have a priority order. Even a correct domain rule can be overridden by an earlier direct-connection rule. If an app uses a separate connection component or process, a single process rule may not cover all its requests.
Temporarily disable other proxy extensions or duplicate network clients, then test again. Don’t change the node, DNS, mode, and browser all at once; even if access returns, you won’t know why. Global mode can help narrow down the cause, but it shouldn’t be treated as a permanent fix for every problem.
Finally, check the local network and existing connections
Hotel and airport networks may require you to complete a web sign-in first. If the underlying network isn’t available yet, the client may keep trying to connect or may only have started its local service. Confirm that the local network works before establishing the proxy connection, and don’t leave system protections disabled to troubleshoot.
Apps may reuse existing connections. After changing rules, finish the current activity, then restart the app or reconnect the client if needed. If you switch from Wi-Fi to another connection type, test again rather than relying on results from before the switch.
Privacy checks: what they can and can’t tell you
A changed exit IP doesn’t clear website accounts, cookies, or app identifiers. A site may still show local content based on your signed-in status, account region, or location permissions. Unchanged recommendations don’t prove the proxy has failed, and an account still being recognized doesn’t mean the exit IP test was wrong.
A WebRTC test can supplement browser checks, but distinguish between local addresses, masked address representations, and public addresses. Seeing local network details doesn’t by itself mean your public exit IP is exposed. If a test shows an unexpected public address, investigate your browser settings, the client’s UDP routing support, and your routing configuration.
Protect your troubleshooting detailsDon’t share a full subscription link, access token, or QR code containing credentials publicly. Before sharing logs, redact authentication fields and personal information. When asking for help, details such as your platform, client, connection mode, symptoms, and steps to reproduce the issue are usually more useful.
Keep a brief record of your current network, selected route, connection mode, test results, DNS settings, target app, and matched rule. When the problem happens again, comparing these details can reveal what changed more easily than reinstalling everything. For further help, see Troubleshooting or use the support option in the dashboard to submit a redacted description of the issue.
First confirm which path the request actually used, then decide whether that meets your needs. An exit-IP check shows the source, a DNS check shows the resolution path, and app testing shows what traffic is covered. These checks complement one another; none can replace the others.