Is Your VPN Working? Check the Connection and Traffic Route
To check whether your VPN is working, start with your public IP, then check DNS, and finally test the apps you use. Your public IP shows where a request exits the internet, DNS shows which resolver looks up a domain, and app testing confirms whether a specific program uses the expected route. Compare these results; a green connection icon alone isn’t enough.
A client’s “Connected” status might mean its proxy core is running, a system tunnel is established, or a connection to a server is active—the exact meaning varies by client. It doesn’t necessarily mean your browser, command-line tools, or other apps are using the VPN, nor does it confirm that the website you’re trying to reach has responded successfully.
Before testing, note your current network, selected server, operating mode, and target app. Close other proxy clients and extensions that may override system proxy settings. Avoid switching networks during the test, and change one setting at a time so you can tell what made a difference.
Check Your Public IP: Record a Baseline, Then Compare
Your public IP is the internet-facing address a website sees, not your device’s local address on a home network. The local address shown in your system’s network settings won’t tell you whether a proxy is working. In a browser, search for “what is my public IP” and use a page that reports the source address of your current request.
- Record a baseline without the VPN. If a brief direct connection is appropriate and you aren’t handling sensitive tasks, disconnect the client, open a new test page, and note your public IP and internet provider. If a kill switch is enabled, losing internet access after disconnecting may be expected; you don’t need to disable it for the test.
- Connect to the selected server. Confirm the configuration is enabled, then reopen the same test page. If needed, force-refresh it to avoid seeing a cached result.
- Check the actual exit IP. Compare the addresses, then review the client’s connection log to confirm the test domain matched a proxy rule and used the expected server.
- Check each IP version. If the test page reports separate IPv4 and IPv6 results, check both. Seeing only one address doesn’t verify the route for the other.
A changed address usually means the browser request took a different route, but it doesn’t prove that every app is using the VPN. An unchanged address doesn’t automatically indicate a problem either: a rule may send the test domain direct, the browser may not use the system proxy, or it may still be reusing an existing connection.
Location labels are only a rough guide. IP geolocation databases may be out of date, and a registered location may not match the server’s actual location. If the reported region doesn’t match the server name, check the IP address, internet provider, and client logs rather than relying on the map alone.
Check DNS: A Different Resolver Doesn’t Automatically Mean a Leak
DNS translates domain names into IP addresses. A browser connection may use a proxy while domain lookups still go through your local network. The client may handle DNS instead, or the browser may use encrypted DNS. That’s why a changed public IP and an expected DNS route are separate things to check.
With the same operating mode enabled, search for a “DNS leak test,” run the test, and note the resolver providers shown. These sites typically use dedicated test domains to identify recursive resolvers. The results usually show the resolver’s exit point, not the complete path taken by your device’s DNS traffic, so interpret them alongside your client settings.
First check whether the client uses DNS interception, remote resolution, or rule-based DNS. Then check whether the browser has its own Secure DNS setting enabled. Whether the browser’s encrypted DNS connection uses the proxy depends on routing and the client’s implementation; encryption alone doesn’t prove it uses the selected server.
| What you see | Possible cause | What to check next |
|---|---|---|
| Public IP changed, but DNS still shows your local internet provider | Local DNS, separate routing rules, or DNS not handled by the client | Review the DNS policy and check whether proxy destinations are resolved as expected |
| Public IP changed, and DNS shows a public resolver | The client or browser is using a public resolver | Check the route taken by the DNS request, not just the provider name |
| DNS test looks normal, but the target app still can’t connect | The app isn’t using the proxy, the connection failed, or the destination account is restricted | Check the app’s connection log and the specific error message |
| Different IP versions show different exit addresses | IPv4 and IPv6 use different routing or proxy settings | Check the tunnel, IP version settings, and client support |
Here, a DNS leak means DNS requests have taken a route other than the protected path you intended to use. If your rules deliberately send local services direct and use local DNS, that isn’t automatically a problem. But if traffic to a destination is supposed to use the proxy throughout and DNS still goes through your local network, investigate further.
After changing DNS settings, reconnect and, if needed, clear the DNS cache according to your operating system or client’s instructions. Don’t enter an unfamiliar DNS server just to make the test page “look consistent.” Incorrect settings can prevent domains from resolving or make the problem harder to diagnose.
Test Each App: Browser Access Doesn’t Prove Other Apps Work
System proxy and tunnel modes cover traffic differently. A system proxy provides proxy settings to apps, but whether an app uses them depends on its implementation; some programs have their own network settings. Tunnel mode can route more traffic through a virtual network interface, but exclusions, routes, permissions, and platform limitations still apply. It doesn’t automatically cover every request.
On Windows or macOS, first confirm that the system proxy points to the current client, then check whether the target app has its own proxy settings. Command-line tools may use proxy environment variables or require specific options. A webpage loading in your browser doesn’t prove that downloads or developer tools in your terminal use the same route.
On iOS or Android, a VPN indicator means the relevant network configuration is active, but check the client’s per-app settings, rules, and exclusions. On Linux, check desktop proxy settings, terminal environment variables, and tunnel routes separately; don’t assume desktop settings apply to every program.
- ✅ Browser: Open a new page to check your public IP, then find the domain in the connection log.
- ✅ Target app: Quit it completely, reopen it, and try the relevant sign-in, loading, or sync action.
- ✅ Client logs: Confirm the request matched the expected rule, proxy group, and server—not just that total traffic increased.
- ✅ Command-line tools: Check the tool’s proxy options and environment variables, then retry the operation that failed.
- ❌ Don’t treat a cached page, previously viewed content, or an existing sign-in state as proof that the current connection is working.
When testing an app, trigger a fresh request—for example, refresh remote content or sync again. A cached page may still appear even when you’re offline. If the request doesn’t show in the logs, the app may not have connected yet, or a log filter may be hiding it. Consider what you did in the app when reviewing the results.
Connected but Not Using the VPN? Narrow It Down by Symptom
The subscription was imported, but its configuration isn’t enabled
A subscription link is just a way to retrieve configuration; a successful import doesn’t mean a server has been selected or enabled. Check the active configuration, server selection, and subscription update status. Don’t change protocol fields at random: the protocol and subscription format must be supported by the client.
Names such as Shadowsocks, VMess, Trojan, and VLESS refer to proxy protocols or related configurations; they don’t determine whether a particular app uses the proxy. Likewise, IEPL, transit, or direct routes don’t replace checking the device’s rules: transport routes and app routing are separate issues.
A rule sends traffic direct, or a temporary override is still active
Check the logs to see which rule matched the destination domain. Some apps rely on multiple domains, so routing the main page through the proxy doesn’t mean sign-in, attachments, or API requests use the same route. Temporarily switching to global proxy mode can help isolate a rule issue, but avoid doing so for activities that shouldn’t change exit locations. Restore your original settings after testing.
An existing connection, browser extension, or app-specific proxy is interfering
After changing servers, existing connections may continue to be reused, and browser extensions can override the system proxy. Disable conflicting extensions, quit the target app completely, and reconnect. Change one thing at a time and note the results so you can reproduce the issue.
The request uses the proxy, but the destination still denies access
If the logs show the expected server and the request was sent successfully, check the destination’s status, account region, subscription permissions, and any risk-control messages. A CAPTCHA, access denial, or region notice doesn’t necessarily mean the client isn’t working. Switching servers repeatedly may trigger more account checks, so read the specific error first.
Keep a test record before troubleshooting persistent issues
A useful test record includes the time, device operating system, client name, network type, operating mode, server name, public IP result, DNS result, and what happened in the target app. “The browser’s exit IP changed, but the target app’s log shows a direct connection” is more useful than simply saying “the connection doesn’t work.”
Before sharing screenshots, hide subscription links, access tokens, account details, and unrelated domains. Subscription links may contain credentials for retrieving your configuration, so don’t post them in public forums. If you need help from VPNJG, provide the relevant details through the customer panel ticket system. You can also compare basic settings with the client setup guides.
How to assess the result: You can be reasonably confident that this request followed the configured route when its exit address matches expectations, the DNS policy makes sense, and the target app’s logs show the correct path. If the results don’t line up, identify the specific app and request first, then check the rules, DNS, or route. Reinstalling the client without a clear reason isn’t necessary.