To check whether your VPN is working, compare your public IP before and after connecting, inspect the DNS resolution path, and test the apps you actually use. An IP check shows the route for that request; DNS and app-specific checks provide additional evidence. Don't rely on the connection icon alone.
Confirm it’s working by defining what to check first
“Connected” usually means the client has established a connection or enabled a proxy configuration. It doesn't necessarily mean every app is covered. System proxy, browser proxy, and virtual network adapter modes have different scopes, and routing rules may send local sites directly while routing international traffic through the VPN.
The goal isn't to make every site show the same IP. Confirm that traffic meant to use the VPN follows the expected route, direct connections follow your rules, and DNS requests aren't unexpectedly bypassing your configuration. Before testing, note the current mode, selected route, and app you're checking.
| Check | What it can confirm | What it can't confirm on its own |
|---|---|---|
| Client connection status | Whether the client reports a connection or an enabled proxy | Whether all traffic from the app you're testing is routed through the VPN |
| Public IP address | The apparent source of the request made to the IP-check site | The IP and DNS routes used by other apps, or the service's privacy practices |
| DNS test | The resolver's observed exit for this test | How every app resolves domains or the full resolution path |
| Test in the app you use | Whether the feature you need works with the current configuration | Whether other routes or future connections will work |
Public IP check: compare before and after connecting
Disconnect the client, open the IP lookup page, and note the public IP, approximate location, and network provider shown. This is usually the public-facing address of your home, office, or current network—not your device's local IP address. If the page doesn't return a result, don't treat that alone as evidence of a connection problem.
- Close other proxy tools, browser proxy extensions, or additional tunnels that could change your network route. This prevents configurations from overlapping.
- Connect to the route you want to test. Check that the client doesn't report a failed connection or expired authorization, then reopen the lookup page.
- Check whether your public IP has changed and whether its approximate location matches the selected route's listed exit location.
- If you use routing rules, check whether the lookup site is set to connect directly or use the proxy. If needed, temporarily switch to a proxy-first test mode, then restore your original rules.
If the IP hasn't changed, first check whether a direct-connection rule is allowing the lookup site through. Don't assume the VPN has failed. If the IP changed but the location looks wrong, don't rely on the city label alone. IP geolocation databases may lag behind, and different databases can show different locations. Consider the client information, network ownership data, and what actually works.
Check IPv4 and IPv6 as well. A test site may show only one address, while traffic using the other follows a different route. If the client doesn't route a particular type of traffic, your browser may still use your regular network connection. Check the client's IPv6 support and routing settings first; disabling system networking features isn't a general-purpose fix.
DNS leaks: check the resolution path, not just the location
DNS translates domain names into addresses your device can connect to. A webpage can use the VPN even if its DNS queries take a different route. A DNS leak generally means that queries expected to use a specified route are instead sent over the local network to an unintended resolver. Whether that's a leak depends on your routing goals.
When using a trusted DNS test, run it while disconnected and note the resolver name and network ownership. Then connect and repeat the test in the same browser. These pages typically use dedicated test domains to observe the recursive resolver's exit. The result may differ from the DNS server configured on your device or the VPN server itself.
If the resolver belongs to your local network provider after connecting, and your rules say this test domain should use the proxy, investigate further. On the other hand, a public DNS provider—or a resolver in a different region from your exit—doesn't by itself prove a leak. DNS services may use distributed servers, and your client may intentionally resolve direct and proxied requests differently.
Why can secure DNS in your browser change the results?
Browsers can send DNS queries over encrypted connections instead of relying entirely on your system's DNS settings. As a result, different browsers on the same device may show different results. Encrypted DNS protects part of the query's path, but doesn't automatically route it through the VPN. Check which route the browser uses to reach the DNS service.
During troubleshooting, note your browser's secure DNS status and the client's DNS mode. Change one setting at a time, then repeat the same test. Some proxy clients also return synthetic addresses for internal mapping; these aren't a site's actual public IP and can't be used on their own to diagnose a leak. If you're unsure what a setting does, restore the client's recommended configuration and consult the user guide.
App-by-app checks: browser success doesn’t mean every app is covered
System proxy settings generally rely on apps choosing to honor them. Some apps use their own network stack, separate proxy settings, or specialized transport methods, so they may not follow the system proxy. Virtual network adapter modes usually cover more traffic, but routes, permissions, and exclusion rules still matter. Don't assume the mode's name guarantees a particular result.
- ✅ Browser: Check proxy extensions, secure DNS, and client rules, then reload the page you need to use.
- ✅ Desktop apps: Check the app's proxy settings, quit and reopen it, then test the feature you actually need.
- ✅ Mobile apps: Make sure the system allows the client to establish a connection, and check per-app proxy settings and exclusions.
- ✅ Background tasks: Test independent processes such as sync and downloads separately. A browser test isn't a substitute.
- ❌ Don't assume the VPN is working just because a site opens. The site may allow direct connections, or the page may have loaded from cache.
Command-line tools on Windows, macOS, and Linux may use their own proxy environment settings, so their traffic can take a different route from your browser. On iOS and Android, traffic routing depends on the client, system permissions, and app rules. Don't blindly stack multiple proxy tools to get consistent results; it makes problems harder to diagnose.
Test the feature you actually need, such as loading a webpage, making requests after signing in to an app, syncing files, or using real-time communications. A feature can fail because of account permissions, the app's own service, or restrictions on the destination site; that doesn't mean the entire connection has failed. Don't use the region shown in a signed-in account to determine your exit location, as account regions can remain unchanged for a long time.
Connected but not working? Troubleshoot by symptom
The lookup page still shows your original IP
First check that the proxy is actually enabled, then see which rule applies to the lookup domain. If the client has request logs, check only the outbound rule and any error for your current test request. No log entry doesn't necessarily mean a failure; logging may be disabled. If the request was sent directly, check your routing rules first.
The browser works, but an app still can't connect
Check whether the app supports the system proxy, still has an old proxy address configured, or is excluded from VPN routing. Real-time communications may use a different route from web requests, so check the client's coverage. Don't disable your firewall just to test; first look for a specific blocking message.
Nothing seems to change after switching routes
Existing connections may continue using the same session, and DNS or browser caches may preserve old results. Close and reopen the app you're testing, then run the checks again. Clearing the cache can be a later step, but record your results first so you don't mistake a cache change for an improvement in the route.
Domains won't resolve after connecting
If the client reports a DNS failure, check whether the configured DNS service is reachable and whether the proxy and DNS settings depend on each other. Restore the recommended configuration first, then check the system proxy and virtual network adapter status. Don't copy DNS addresses or certificate settings from untrusted sources, or ignore certificate warnings to “fix” web access.
Draw a conclusion from a controlled comparison
Network conditions are easy to overlook during testing. Switching from Wi-Fi to another network, or changing the route, mode, and DNS settings at the same time, makes comparisons unreliable. Keep the device, browser, and network the same where possible. Change one setting at a time and note what happens before and after.
Use the format below to keep a local record. It's for troubleshooting only; there's no need to share full addresses, account details, or subscription links.
Network: keep unchanged
App under test: the browser or app you actually use
Before connecting: public IP and resolver ownership
After connecting: public IP and resolver ownership
Client mode: current traffic-routing method
Rule match: direct connection or proxy for the request
Feature tested: works, fails, or partly fails
Change made: record only the setting changed this timeHow to tell: You have good evidence that the VPN is working for your current use case when the target request takes the expected route, DNS behavior matches your rules, and the app feature you need passes its test. If you only checked your public IP, limit your conclusion to “this request from the current browser used a different exit.”
A connection test checks the current state; it doesn't prove long-term availability or anonymity. JinVPN's privacy policy is anonymous, no-logs service. You should still protect your credentials and be mindful of site permissions and account sign-in risks. If these steps don't identify the issue, send redacted diagnostic details through Support.