To confirm your VPN is working, check your public IP, DNS, and app routing together. A connection icon only shows that the client is running; it doesn’t prove that your store dashboard, browser, and desktop apps are using the selected route. Check actual requests before changing settings—this is more useful than repeatedly switching locations.
Connection Status vs. Your Actual Public IP
The client may have started a local proxy port without routing system traffic through it. Or it may have established a tunnel while split-tunneling rules send the target website over a direct connection. A successful subscription update doesn’t prove the VPN is working either: it only means the client retrieved the configuration. You still need to check whether its servers are reachable and which one is selected.
It’s also important to distinguish a system VPN from a proxy client. A system VPN typically routes traffic through a virtual network interface; a proxy client may only enable the system proxy or offer a TUN mode that captures traffic. Not every app follows the system proxy, and TUN coverage depends on routing, exclusions, and DNS settings. Similar labels in the interface don’t mean the same traffic is being captured.
| Check | What it tells you | What it doesn’t prove |
|---|---|---|
| Client shows connected | The client has entered a connected or running state | The target app is using the selected route |
| IP lookup shows a new public IP | That page’s request used a different public IP | Other apps, DNS, and all address families are routed through the VPN |
| DNS test lists resolvers | The test domain was resolved through the listed recursive resolvers | The DNS request was necessarily sent in plaintext, or the resolver is the VPN exit |
| Target request matches a proxy rule | The client selected a proxy route for that request | The remote website is accessible or the account will pass its regional checks |
Check Your Public IP First, Then the Location
Save any store changes in progress before testing, and avoid sensitive actions such as payments or account updates. Use the same browser and IP lookup page for both checks. Note the client mode and selected route so you don’t compare results from different setups.
- Disconnect the client, refresh a public IP lookup page, and note the current IP, network provider, and address family. If your workplace uses a shared internet gateway, this baseline may not be the direct connection from your home broadband.
- Connect to the selected route and confirm that system proxy or tunnel routing is enabled. Reopen the lookup page, using a fresh browser session if needed to avoid cached results.
- Check whether the public IP changed, then review the client’s connection logs. If the lookup site is set to connect directly by a rule, temporarily route its domain through the proxy and test again. Don’t assume the entire route is broken based on this result alone.
- Cross-check with a second, independent lookup service. If both show the same IP but different locations, consider differences between geolocation databases before treating the server as faulty.
A changed IP means that this web request took a different route; it doesn’t mean traffic outside the browser did too. Likewise, the same location label doesn’t prove the VPN failed: your local and VPN exit IPs may be assigned to the same area. Compare the full IP address and request logs first.
The result only applies to the request you tested. Don’t paste subscription links, usernames, or passwords into lookup sites. A public IP check normally doesn’t require this information. Hide subscription URLs and account details before sharing screenshots.
How to Check for DNS Leaks
DNS translates domain names into IP addresses. A DNS leak generally means that DNS requests which should follow the tunnel or specified proxy route are instead sent through an unexpected local network. The key question is whether DNS traffic is following your routing policy, not whether the country shown on a test page exactly matches your VPN location.
Check the client’s DNS mode, your system’s resolver settings, and whether the browser has its own Secure DNS setting enabled. A browser may use an encrypted DNS service to resolve names independently, while the client may use remote resolution or synthetic IPs. A test page shows the recursive resolver it observed; that name alone can’t reveal the full path from your device to the resolver.
If the client is set to route all traffic through the tunnel and DNS should follow it, persistent results showing your local ISP’s resolver are worth investigating. Check whether DNS routing is active, whether any rules bypass it, and whether the browser uses separate settings. Change one setting at a time and rerun the test so you can identify what made a difference.
In rule-based mode, resolving local domains directly through a local resolver may be intentional—not every such result is a leak. Don’t indiscriminately send remote domains to a local resolver and force them through the proxy either: if the returned IP doesn’t work with the selected route, websites may fail to load or load incompletely.
Check IPv6 and Browser Bypasses
A device may connect over both IPv4 and IPv6. If the client only routes one address family, a browser may take a different path when visiting sites that support the other. If your lookup tool reports both, check them separately. No IPv6 result only means the test didn’t detect a usable IPv6 connection at that time; it doesn’t mean your system will never use one.
Where possible, use the client’s full-routing and DNS settings, or follow its documentation to handle any address family that isn’t captured. Don’t leave a bypass route in place and rely on a single IPv4 lookup to claim the entire device is covered.
A browser’s WebRTC test is a separate check. It may show candidate addresses used for real-time communications. A local network address appearing there doesn’t mean public internet traffic is bypassing the proxy, and it isn’t the same as a DNS leak. What matters is whether an unexpected public IP is exposed and whether UDP traffic for real-time communications is covered. If needed, use the browser’s documentation to limit these features, then test an actual call again.
App-by-App Testing: A Working Website Isn’t Enough
If a website opens in your browser, that doesn’t mean your desktop apps are routed through the VPN too. On Windows and macOS, some programs follow the system proxy while others use their own network stack or proxy settings; command-line tools may only read environment variables. On iOS and Android, coverage depends on the client’s tunnel configuration, app exclusions, and system policies. If an Android client offers per-app routing, check whether it proxies only selected apps or bypasses them.
Before testing an app, quit and reopen it so it starts a new connection. Existing long-lived connections may keep using the old route. Then open a page that needs a network connection or perform a real task while checking the client logs for the destination domain, matched rule, and selected route. A logged request is more useful than a rise in the overall traffic counter.
- ✅ Browser: Check the public IP, then test the target site’s login page, page assets, and file uploads—not just whether its home page opens.
- ✅ Store dashboard: Keep to a consistent location that complies with the platform’s rules. Check product editing, image loading, and save confirmations; avoid repeatedly signing in from different locations while troubleshooting.
- ✅ Desktop apps: Check the app’s proxy settings and client logs. Make sure it isn’t excluded or still using an inactive local proxy port.
- ✅ Mobile apps: Test the app in the foreground, then check whether it reconnects after you switch away and return. Distinguish a system-paused background app from a failed VPN connection.
- ❌ Don’t use a browser’s IP result to assume every app is covered, or treat an increase in total client traffic as proof that a particular app is using the proxy.
If the target app’s request matches a proxy rule but the site still says your location isn’t supported, check the account region, payment details, device location permissions, and the platform’s own policies. Your public IP is only one factor a service may consider. A working network connection doesn’t guarantee eligibility to use the service.
Troubleshoot by Symptom, Not by Randomly Switching Protocols
Public IP unchanged, but the client shows traffic: Check whether the IP lookup domain connects directly and whether the counter includes subscription updates, health checks, or other apps. Temporarily proxy the lookup domain and compare the request logs to distinguish a routing-rule issue from a connection issue.
Public IP changed, but the target site won’t load: Check whether the site and its resource domains match the expected rules, whether DNS is working, and whether the client reports a handshake or connection error. If needed, save your current settings and briefly switch to global proxy mode for comparison. If global mode works but rule-based mode doesn’t, check for missing routing rules first. Restore your preferred mode when testing is done.
Websites work, but voice or real-time features don’t: Check whether the client and server support the relevant UDP forwarding, and whether a system firewall or network environment is blocking it. Shadowsocks, VMess, Trojan, VLESS, Hysteria2, and TUIC aren’t interchangeable options; support depends on the client, server, and subscription configuration. Don’t change the protocol name without matching the server settings.
The old location still appears after switching routes: Check for lookup page caching, an app’s existing connection, or the platform’s account region. Fully quit the target app, try again, and verify the new request’s public IP. IEPL, relay, and direct routes describe how traffic is carried or forwarded—not system proxy, TUN, or routing rules. The route type alone can’t prove that every app on your device is covered.
Keep Test Records Before Changing Settings
Troubleshooting notes don’t need to be complicated. Record the device OS, client name and version, selected route, routing mode, target app, public IP result, and error message. Change only one setting per round, then repeat the same test. This makes it easier to roll back changes and explain the issue to support with useful details instead of just saying “it won’t connect.”
When using JiaVPN, check the full guide for setup and connection steps, the server list for route details, and the Help Center for common settings. Import your subscription link using a method supported by your client, then check which route is selected after updating. A successful import is no substitute for testing an actual request.
Bottom line: Check the request path, not just the connection icon. An IP lookup confirms the public IP used by the tested page; DNS checks help identify unexpected resolution paths; and app-level logs show which rules and routes a target program is using. Compare these results with the task you need to perform to confirm that the VPN is working for it. JiaVPN’s no-logs statement describes its privacy policy; it can’t replace connection checks on your device.