To tell whether your VPN is really working, don’t rely on the client icon alone. Checking your public IP, DNS, and app routing answers different questions: which public address a website sees, which resolver looks up a domain, and whether a particular app is being routed through the proxy. A reliable assessment compares this evidence with your expected routing rules—not just whether one webpage loads.
“Connected” vs. the Actual Traffic Path
A client’s “Connected” status usually means a connection stage has completed, such as creating a virtual network interface or starting the proxy core. It doesn’t necessarily mean every app’s requests are traveling through the remote route. The exact meaning depends on the client, so check the traffic itself.
A system proxy provides a proxy endpoint to apps that follow the system settings. Some apps ignore it or use their own proxy configuration. Tunnel mode usually routes more traffic through a virtual network interface, but exclusions, routing rules, IPv6 support, and DNS settings can still affect what gets routed. “Global proxy” may simply send every request that reaches the proxy core through the selected route; it doesn’t automatically capture traffic from every app.
A subscription link lets the client import and update nodes and related settings. Successfully importing or updating a subscription only confirms that the client received the configuration—it doesn’t prove that the current node is reachable or that system traffic is being routed through it. Protocol names such as Shadowsocks, VMess, Trojan, and VLESS are no substitute for checking the actual network path.
| Check | What it shows | What it can’t prove on its own |
|---|---|---|
| Client status | Connection status of the interface, proxy core, or route | That every app uses the selected route |
| Public IP | The public address a website sees for this request | That other apps and DNS use the same route |
| DNS check | The recursive resolver shown for a test domain lookup | That the device routes all DNS queries through the VPN |
| App connection logs | The rule, route, and errors matched by a request | That an app missing from the logs is going direct or is being routed |
Establish an Exit IP Baseline
Before checking your public IP, decide which route the test site is supposed to use. If your rules send that site direct, an unchanged IP is the expected result. Use a public IP checker that shows IPv4 and IPv6 separately, and run the same test before and after connecting to avoid mistaking differences between databases for a routing change.
- Disconnect the client, disable any standalone browser proxy extensions, and note your current public IP, network type, and the time of the check. If you’re using another proxy, first confirm whether it’s still active.
- Connect to the route you want to test. Confirm that proxy or tunnel mode is enabled and that the test site matches the intended route. Make a fresh request; if needed, close the old tab and open a new one.
- Compare the addresses before and after connecting. Focus on whether the request’s exit IP matches your expectations, rather than relying only on the country shown on the page. IP geolocation databases can be outdated or inaccurate.
- Disconnect and check again to see whether the address returns to your current local network’s exit IP. Dynamic addresses and shared exits can change, so it doesn’t need to match character for character.
If IPv4 changes but IPv6 still shows your local network’s exit, check whether the client routes IPv6 and which address family the test request actually uses. Adjust IPv6 support and routing based on the client’s documentation, then test again. Disabling IPv6 isn’t a suitable long-term fix for every device.
The result only applies to this request. A browser showing the VPN’s exit IP doesn’t mean your download client, game, or command-line app uses the same route. A site may also load simply because it’s already reachable over your local network.
How to Check for DNS Leaks
DNS translates domain names into IP addresses, but webpage traffic and DNS lookups don’t necessarily take the same route. A browser may use secure DNS to send queries over HTTPS to a resolver of its choice, while the system and other apps use different settings. Treat a browser-based DNS test as a useful clue, not a complete report for your device.
Many DNS test sites generate test domains and check which recursive resolvers handle the queries. Note the provider and location shown, but keep in mind that a resolver’s location doesn’t have to match your VPN exit. Public DNS, forwarding paths, and geolocation database errors can all make the two appear different.
A clearer sign of a problem is when you expect relevant domain queries to go through the tunnel or a specific resolver, but tests consistently show your local network’s resolver—and the client logs confirm that queries bypassed the expected route. Check system DNS, the client’s DNS routing, secure DNS, and any rules that send domains direct.
Test browser and system settings separately
Note the browser’s current secure DNS setting, then compare it with the configuration recommended in the client’s documentation. Change one option at a time. nslookup or a similar system tool can reveal some aspects of DNS resolution, but its queries may differ from a browser’s. The server address it reports also doesn’t prove that the entire device is free of DNS leaks.
DNS caching can also keep old results in use. After changing settings, clear the relevant cache as described in your system or client documentation, then run the test again. Encrypted DNS and VPN routing are separate issues: encrypted DNS doesn’t automatically send queries through your selected international route.
Check App-Specific Routing Rules
Write down what you expect before judging the results. For example, if international websites should use the VPN while local network traffic stays direct, test each separately. Seeing the same exit IP for every request isn’t the only correct outcome; the right result is for each type of request to follow the route you set.
- ✅ Browser: Check proxy extensions, standalone proxies, and secure DNS settings to make sure the browser and system apps aren’t using different configurations.
- ✅ Target app: Find the relevant process or domain in the client’s connection logs and confirm whether it matched a VPN route, a direct route, or a block rule.
- ✅ Background requests: Restart the app before testing again. Existing connections may keep using their original route, and simply refreshing the interface may not create a new connection.
- ✅ Per-app list: Make sure the target app is included, not accidentally added to an exclusion list. The launcher and the app that actually runs may also be separate processes.
- ❌ Don’t assume that a successful browser test means every app is working, or that a missing entry in the connection logs means the network is fine.
On Windows and macOS, browsers may follow the system proxy settings, while command-line programs may need their own configuration or proxy environment variables. Tunnel mode covers a different range of traffic. On Android, VPN permissions, per-app lists, and background restrictions can affect whether the connection stays active. On iOS, check the rules supported by the client and the system VPN status rather than assuming the settings have the same names as on other platforms.
On Linux, desktop proxy settings don’t usually reflect the proxy configuration of background services. Check the settings used by the specific process and whether the client established the expected routes. If the app uses UDP, confirm that the client and route support that traffic; a browser request alone isn’t a sufficient test.
When You Appear Connected but Traffic Isn’t Routed
Only the browser is using the proxy
If a browser extension connects successfully but nothing changes in other apps, the proxy may only cover browser traffic. Check whether you enabled an extension proxy, system proxy, or tunnel mode. Confirm the coverage first, before troubleshooting remote nodes or switching routes without addressing the cause.
The node works, but the request is routed direct
A successful client latency test only means that the probe received a response; it doesn’t guarantee that your app’s traffic uses the same exit. Find the target domain in the connection logs and check which rule it matched. Also check rule order: an earlier match can take precedence over a broader rule later in the list.
The website still shows the same location
A website may determine your displayed location from your account details, previous sessions, location permissions, or content preferences—not just your current IP. Use an IP checker and request logs to assess the network path instead of relying on the homepage language or recommendations. Conversely, a change in page language alone doesn’t prove the proxy is working.
The status still says connected after switching networks
After switching from Wi-Fi to mobile data or waking a device from sleep, the interface status and actual connection may briefly get out of sync. Make a fresh request, then check the client logs and system VPN status. If you need to reconnect, run the full set of checks again afterward rather than just confirming that the icon reappears.
Troubleshooting Steps and Conclusions
When something goes wrong, narrow it down in this order: traffic coverage, rule matching, exit IP, DNS, and target app. Change one setting at a time and record the results before and after. If you temporarily switch to global rules to rule out a routing issue, first confirm that system traffic is reaching the proxy core. Restore your original routing settings when the test is done.
VPNJazz accounts use a username and password; no email address is required. Get the client from the download page in the user panel, and check the user guide for subscription imports and platform settings. Subscription URLs often contain access credentials. Don’t paste them into public testing sites or share your full configuration with strangers for testing.
For help, use the support ticket system to describe your device’s operating system, client mode, network when the issue occurred, target app, and matching rule. Before sharing screenshots, hide your subscription URL, password, and any unnecessary personal information. Domains in diagnostic logs may also reveal your browsing activity.
How to interpret the results: You can reasonably conclude that a tested scenario is working when the target request uses the expected exit, DNS behavior matches your configuration, and the app that should use the VPN actually matches the intended route. Don’t extend that conclusion to every app, network, or future connection.
VPNJazz states that its service is anonymous and keeps no logs. This is a statement of service policy, not a substitute for checking traffic paths on your device. Manage account sign-in, browser permissions, and the data practices of the websites you visit separately. Keeping a consistent before-and-after test method is more useful for assessing the actual connection than relying only on a “Connected” status.