First, define “working”: does the request use the expected exit?
How can you tell if your VPN is really working? Check your public IP first, then test for DNS leaks, and finally verify apps individually. A connected icon only shows that the client is connected; it doesn’t prove that requests from your browser, terminal, and work apps all use the same route.
Start by clarifying what you need. With split tunneling, direct access to local sites and proxy access to selected international sites may be exactly what you want. If you expect all supported traffic to go through the tunnel, check whether the client offers that mode and whether it covers the apps, DNS, and IPv6 you use. Don’t assume split tunneling is broken just because every website doesn’t show the same location.
A system proxy usually affects only apps that honor that setting. TUN mode can capture more traffic, but its actual coverage still depends on routing, exclusion rules, and the client’s implementation. “Global” mode in a client may simply route all requests handled by its proxy core through the proxy; it doesn’t automatically capture all traffic from the device.
| Check | What it tells you | What it doesn’t prove on its own |
|---|---|---|
| Client shows connected | The client has enabled the connection or proxy configuration | The app you’re checking is actually using that configuration |
| Public IP shown by a website | The source address seen by the test site for this web request | That your terminal, game, or other apps use the same exit |
| DNS test result | Which resolver ultimately handled the test domain lookup | The full path each DNS request took across your local network |
| Client connection log | The rule, exit route, or handling method matched by a request | That the remote website will accept traffic from that exit |
Set a baseline, then compare your exit IP
Don’t change routes and browser settings at the same time. Save your work and pause tasks that continuously transfer data, then establish a direct-connection baseline on a trusted local network. If a direct connection isn’t appropriate in your current environment, skip that step and use trusted records you already have. There’s no need to expose sensitive activity just to test your connection.
- Note the client mode, selected route, and target website. Open a trusted IP-checking site and record the public address and address type it reports—not just the city shown on its map.
- Enable the client and keep the same network and browser. Confirm that the test domain is routed through the proxy as expected, then reload the page. If needed, use a new tab to avoid stale results.
- Compare the addresses and look for the test domain in the client’s connection log. If the rule shows a direct connection, an unchanged IP doesn’t mean the proxy has failed for international websites.
- Visit the service you actually intend to use and check its corresponding connection too. Verify the test site and the real service request separately; one can’t stand in for the other.
IP geolocation databases can lag behind, and different test sites may report different locations. A mismatch between the registered location and route name doesn’t by itself indicate a problem. More useful questions are whether the request matched the expected rule, whether the remote service saw the expected exit address, and whether you could complete the task on the service.
Check IPv4 and IPv6 separately. A test page showing one address type doesn’t mean the other follows the same route. If your browser prefers IPv6 and the client doesn’t capture that traffic, the result may differ from an IPv4-only test. Check the client’s IPv6 support and routing settings first; disabling IPv6 isn’t a universal fix.
A changed public IP proves only that this request used a different exit. It doesn’t prove that the entire device is covered or that you’re anonymous; websites can still identify a session through account sign-ins, cookies, and other information.
Test for DNS leaks by checking whether DNS queries follow the expected route
DNS translates domain names into addresses, while website connections carry application data. They may take different routes, so your web traffic can use a new exit while DNS queries are still handled by your local network. If a domain that should be resolved through the tunnel is unexpectedly sent to a local resolver, that’s worth investigating.
Use a trusted DNS test with the client mode unchanged. Run a fresh test and note the resolver names and their ownership. These pages typically use dedicated test domains to identify recursive resolvers. They show services in the resolution chain, not every hop taken by your device. A resolver appearing in your local region doesn’t by itself confirm a leak; one in another region doesn’t prove every app is routed correctly.
A browser’s secure DNS feature, which resolves domains over encrypted connections such as HTTPS, may use a resolver separate from the system’s. Its queries may still go through the proxy, or they may connect directly depending on the app and domain rules. Encrypted DNS protects how queries are transmitted; it doesn’t automatically route web traffic through the proxy or guarantee that DNS follows the client’s split-tunneling rules.
- Check whether secure DNS is enabled in your browser and whether it uses a separate provider. Note the original setting before changing it temporarily and testing again. Restore any settings you want to keep afterward.
- Check whether the client enables DNS interception, remote DNS resolution, or split DNS. Names vary between clients, so refer to the actual settings and documentation.
- Distinguish direct-connection domains from proxied domains. With split tunneling, local DNS resolution for direct-connection domains may be expected; not every local lookup is a problem.
- Check whether the app has its own DNS resolution behavior. A browser test can’t replace testing a desktop app or command-line tool.
On Windows, use the command below to inspect network settings or clear the system DNS cache after changing DNS settings. DNS servers listed in the configuration are clues, not proof of the traffic path; browsers and apps may also keep their own caches.
ipconfig /all
ipconfig /flushdnsDon’t treat a successful standard DNS lookup as proof that there are no leaks. It only shows that the tool resolved a domain; it doesn’t mean your browser uses the same method. Check DNS settings, test results, and the client’s connection log together.
Verify each app instead of testing only your browser
Browser access doesn’t mean your terminal, editor, or games can connect too. Apps on Windows and macOS may use the system proxy or their own network settings; Linux desktop proxy settings also don’t control every program. Mobile devices generally route traffic through the system VPN interface, but per-app exclusions, work profiles, and other network extensions can still change what’s covered.
Command-line tools often read HTTP_PROXY, HTTPS_PROXY, or ALL_PROXY, but support varies by tool. The proxy type in the variable should match the local listener provided by your client. Get the address and port from the client you’re using; don’t rely on defaults found online. The HTTPS in a variable name doesn’t mean you can arbitrarily change the proxy address scheme to HTTPS.
- ✅ Browser: Open the target page and complete the task that requires a connection. Check the matching rule for the relevant domain, and note that a proxy extension may override system settings.
- ✅ Terminal: Make a network request with the command you actually plan to use. Check the proxy variables in the current terminal session and see whether the tool has its own proxy settings.
- ✅ Editors and AI tools: Try a real completion, chat, or dependency download. Check connections for the main app, extension processes, and sign-in page separately.
- ✅ Office apps: Test sign-in and file syncing. A successfully loaded embedded webpage doesn’t prove that background transfers also use the proxy.
- ❌ Games and voice apps: Don’t use a browser speed test as a substitute. Apps may use UDP, and whether the client can route it depends on its mode, route capabilities, and app rules.
For tools that support SOCKS, check whether domain names are resolved locally or by the proxy server. Even when tools use the same proxy address, their DNS behavior may differ. Restart the target app after making changes so new connections use the updated settings; existing connections may not switch routes immediately when you change modes.
Common reasons a VPN appears connected but isn’t working as expected
A rule sends traffic directly, or proxy settings override one another
Search the connection log for the target domain and check the rule and exit route that actually matched. Successfully importing a subscription only means the configuration was read; it doesn’t mean the rules are right for your target. A browser extension, old proxy settings, or another networking client can also change the traffic path. Save your configuration, then disable conflicting sources one at a time, changing only one setting per test so you can compare results.
The route connects, but the target service blocks access
A target website may restrict access based on account region, the reputation of the exit IP, or its own policies. If the connection log and IP check match expectations but the service still reports a restriction, distinguish a working network route from the website accepting access. Trying another route can help you compare, but it doesn’t guarantee access to every service.
WebRTC results don’t match your public IP
Browser real-time communication can collect candidate network addresses. What’s visible depends on browser privacy settings, proxy mode, and connection method. A test page showing a local network address or a masked hostname doesn’t mean your real public exit IP has been exposed. Look for unexpected public addresses and check the client’s coverage. If you change browser settings, make sure calls and meetings still work.
A network change or sleep leaves the connection in a stale state
After switching from wired to wireless or waking from sleep, the client may still appear enabled even though its original connection is no longer working. Recheck the route, target request, and DNS instead of repeatedly refreshing the same page. Before sharing troubleshooting details, consult the user guide and include only the necessary error excerpt. Don’t share subscription links, credentials, or full connection logs.
Retest and keep a reusable record
Once verification passes, note the working client mode, route name, target app, and rule result. If you disconnect manually, check that system proxy settings are restored and direct access works. If the client offers a kill switch, verify it according to the client’s instructions; a working connection doesn’t prove that traffic will be blocked if the route fails.
Keep privacy policies separate from local testing. VPNVJ’s security statement is “no logs”; it describes the service’s policy and can’t be independently verified by an IP test. Local diagnostic records from a client are not the same as the service’s policy, so be mindful of what you share while troubleshooting.
Your current setup is working for the scenario only when the exit IP is as expected, DNS handling matches your split-tunneling goals, and the app can complete its task. If one check fails, first find out whether the test site connected directly, DNS followed a different policy, or the app didn’t use the proxy. Then decide whether to change a rule or switch routes.
Ready to continue configuring your setup? See the client guides and route list. Establish a repeatable test before comparing routes. It’s more useful than relying on the connection icon and helps distinguish a real failure from expected split tunneling.