How can you check whether your VPN is working? Compare your public IP before and after connecting, check DNS, then test the app you want to use. A client’s “Connected” status only confirms the connection state; it doesn’t prove that every request is using the selected route. Interpret test results in light of your current mode and split-tunneling rules.
This guide follows a practical troubleshooting sequence. The goal isn’t to make every field on a test page show the same location. It’s to confirm that traffic meant to use the proxy does so, DNS resolution follows your configuration, and direct connections behave as expected.
Define what you’re checking
System tunnels, system proxies, and browser proxies cover different traffic. A system proxy usually affects only apps that follow that setting; a browser extension may handle browser requests alone. Tunnel mode can capture more traffic, but routes, excluded apps, and split-tunneling rules still apply. A VPN icon in your system tray doesn’t mean every app is covered.
With rule-based routing, local sites can connect directly while international sites use the proxy. An IP-checking site may also match a direct-connection rule. In a client, “Global” often means that captured requests all use the proxy; it doesn’t mean every app’s traffic is automatically captured.
| Check | What it can tell you | What it can’t confirm on its own |
|---|---|---|
| Client connection status | The client considers the connection established | That all apps are using the connection |
| Browser public IP | The public IP used for this web request | The route used by other apps or address types |
| DNS test | The recursive resolver used to look up the test domain | The path taken by every DNS request on the device |
| Client connection logs | The rule and routing policy matched by a specific request | That requests absent from the logs were captured |
| Activity in the target app | How that feature works on the current network | That a successful connection necessarily used the proxy |
Before testing, note your current mode, node name, browser Secure DNS settings, and whether tunnel mode is enabled. Change one setting at a time so you can tell what caused any change in the results.
Public IP: compare before and after connecting
Your public IP is the address a remote site sees, not your device’s address on the local network. While disconnected, open a trusted public IP checker in your browser and note the address and network provider. Then connect to your chosen route and run the check again in the same browser. Don’t compare against an old screenshot: your local network’s public IP may have changed.
- Disconnect and note the public IP on your current network. If the test page shows both IPv4 and IPv6, record both.
- Connect to the route and check that the client doesn’t report a handshake failure, authentication error, or configuration issue.
- Reload the test page. If needed, use a fresh private window to rule out page caching.
- Check the client’s connection logs to see which rule matched the test domain and which route was selected.
- Verify the address with another independent checker. Don’t rely only on the city shown on a map.
A changed address, together with logs showing that the request used the selected proxy, provides stronger evidence. Geolocation databases can be out of date, so an inaccurate city doesn’t mean the route has failed. Judge by the address, network provider, and request path—not just a flag or region label.
If the address hasn’t changed, don’t assume the connection failed. Check whether the test domain matches a direct-connection rule, whether the browser bypasses the system proxy, and whether the test page shows only one address type. If you temporarily use a global policy for comparison, restore your original settings when you’re done.
DNS: different resolvers don’t automatically mean a leak
DNS translates domain names into IP addresses. A DNS test page typically uses specially generated test domains to see which recursive resolvers query its authoritative servers. The address shown is often the resolver’s address when it makes an external query—not your device’s public IP—so it’s common for the DNS address and web traffic’s public IP to differ.
Compare the resolver’s provider and your DNS settings; don’t expect every result to be in the same region as your node. Public DNS services may be distributed, and the location shown by a test page is only a database estimate. Clients may use local resolution, remote resolution, or synthetic addresses for different domains, all of which can affect the results.
A result worth investigating is when you expect all relevant DNS queries to use the proxy, but the test repeatedly shows resolvers from your local network—and logs or settings confirm the queries bypassed the intended route. Seeing a familiar public DNS provider alone isn’t enough to conclude there’s a leak.
Encrypted DNS and proxy routing are separate issues. A browser’s DoH can encrypt queries between the browser and its resolver, while that connection still goes direct. Encrypted DNS doesn’t mean DNS traffic uses your selected route.
Check the browser’s Secure DNS settings first, then review the client’s DNS policy and system settings. Some browsers resolve names themselves, bypassing the resolver configured in the client; some clients route DNS queries through an internal module. Don’t copy test results straight into your configuration or replace all your DNS settings at once.
Test apps individually—don’t assume browser results apply to your whole device
A correct browser IP only confirms that requests from the test page behaved as expected. Desktop apps, games, command-line tools, and background services may use different network stacks. Some apps ignore the system proxy, some use UDP, and existing connections may not move immediately when you switch nodes.
To test an app, close it completely, reopen it, and perform a specific network action. At the same time, check the client’s connection logs for the app’s domain, process, or destination address, then verify the matching rule and route. A rise in total traffic alone won’t tell you whether it came from the app or background system activity.
- ✅ Browser: Reload the test page and check the route for its domain.
- ✅ Target app: Restart it, use the feature you want to test, and check for the corresponding connection in the logs.
- ✅ UDP traffic: Check how the client handles it and whether the route supports it. A web page isn’t a substitute for testing UDP.
- ✅ Rule-based routing: Test requests that should use the proxy and those that should connect directly; confirm both behave as expected.
- ❌ Don’t assume everything is working just because a page loads, an app icon lights up, or the traffic counter changes.
On Windows and macOS, distinguish between the system proxy and tunnel capture. On Android, check whether the target app is excluded. On iOS, allowing a VPN configuration only grants system permission; you still need to check the client’s policies and actual connections. Menu names vary by platform, so refer to the documentation for the client you use.
Command-line tools may also be affected by proxy environment variables. If the browser works but a command-line request fails, first check whether it uses the same proxy route instead of switching nodes right away. For setup guidance, see Getting Started for steps to configure traffic capture and import settings.
IPv6 and WebRTC: check routes that are easy to miss
When a network supports both IPv4 and IPv6, an app may prefer one over the other. If the client captures only some traffic, your web traffic’s IPv4 address may change while IPv6 requests still use the local network. Check both address types instead of relying on the most prominent result on the test page.
If your local network has no working IPv6, a failed test doesn’t mean the proxy is malfunctioning. If a test shows your local network’s public IPv6 address, first check whether that request was allowed to connect directly, then review tunnel mode, IPv6 routes, and exclusion rules. Temporarily disabling IPv6 can help with diagnosis, but it isn’t a universal long-term fix.
WebRTC supports real-time browser communication and may discover candidate addresses using a different route from ordinary web requests. A local network address, a hostname with privacy protections, and a public address in the results mean different things; don’t label every address a leak.
The key question is whether an unexpected local public IP appears. If it does, review the browser’s relevant privacy settings and the client’s UDP handling and tunnel policies. Consider the needs of features like video calls before changing settings; don’t disable functionality just to make a test page look tidy.
Connected but not working? Narrow down the cause
The subscription was imported, but the selected configuration hasn’t updated
A subscription link retrieves nodes and configuration; it doesn’t prove the connection works. A failed update, an incompatible client format, or an outdated configuration can leave a node name visible even though requests fail. Check the subscription’s last update and any error messages, then confirm the selected node comes from the current configuration. The client must support the protocols in the subscription; matching node names don’t prove compatibility.
Subscription links usually contain account credentials. Don’t share the full link when asking for help or paste it into an online converter you don’t trust. Redact access tokens from screenshots and logs first.
The public IP changed, but the site is still unavailable
Separate “is the proxy working?” from “is the site accepting this request?” A site may make decisions based on account region, session history, the reputation of the exit IP, or its service policies. An app may also retain an old connection. Restart the app, check the logs for a new request, and review the site’s own message. Not every access failure is a DNS issue.
Results changed after reconnecting or switching networks
Switching networks can change system DNS, the default route, and existing connections. Browser, system DNS, and client resolver caches may also update at different times. Retry the request and restart the relevant apps first. If results still don’t match, follow your platform’s documentation to clear caches. Record each step, and don’t clear caches, switch nodes, change DNS, and change modes all at once.
IEPL dedicated lines, transit, and direct connections describe how traffic travels—not which device traffic the client captures. A dedicated line can’t fix an app that bypasses the proxy or a misconfigured routing rule. See Routes and Protocols for more on protocols and network topologies.
Turn test results into findings you can verify
A useful record includes your network environment, client and mode, node name, public IP before and after connecting, DNS provider, target app behavior, and the rule shown in the logs. Note the time and order of each step, then repeat the test under the same conditions to distinguish an intermittent issue from a configuration problem.
Conclusion: You can say the VPN worked within the scope of your test only when the required requests use the expected route, DNS follows your configuration, and the target app matches the expected rule in the logs. This isn’t a permanent guarantee for every app or future connection.
If you still can’t explain the results, send a redacted report through Customer Support. Describe which requests you expected to use the proxy and what you observed; that’s more useful than simply saying “it won’t connect.” If logs contain full public IPs, visited domains, or subscription credentials, include only what’s needed to troubleshoot.
Restore any settings you changed temporarily during testing, then check your commonly used apps again. A test page is a diagnostic tool, not the end goal. What matters is whether your everyday requests continue to follow your rules.