How can you tell if your VPN is working? Check your public IP first, then review the DNS resolution path, and finally test the apps you care about. A client’s “Connected” status is only a starting point. Traffic is using the selected route only when actual requests follow the expected path.
Don’t rely only on a page loading, a lit status icon, or rising traffic counters. Cached content can make a page seem available, and background updates can generate traffic. Start by comparing your connection before and after; there’s no need to switch protocols or reinstall the client first.
Connection status vs. actual coverage
Clients don’t all mean the same thing by “Connected.” Some indicate that a system tunnel is up, others that a local proxy is running, and some also check a remote service. A normal status doesn’t prove that your browser, chat app, or other programs are using the proxy.
In particular, distinguish between system proxy settings and tunnel mode. A system proxy is available mainly to apps that honor those settings; programs that ignore them may still connect directly. Tunnel mode can usually handle more network requests, but routing rules, excluded apps, DNS settings, and system permissions still matter. The mode name alone isn’t proof.
| Check | What it tells you | What it doesn’t prove on its own |
|---|---|---|
| Client shows “Connected” | The connection or local traffic capture has started; the exact meaning depends on the client | That every app is using a remote exit IP |
| The IP check page shows a different IP | This particular check used a different exit IP | That other sites, protocols, and apps use the same route |
| DNS test shows the resolvers | Which resolvers handled lookups for the domains tested | That the resolver’s location is where your traffic exits |
| The target app appears in proxy logs | The request matched a logged route and outbound connection | That the remote platform will accept your account or location |
| The requested feature works | The connection works for this particular use case | That all traffic is captured or will always work |
Exit IP: compare before and after connecting
Disconnect, then open the IP check page in the same browser. Note the public IP and location it shows. Connect to the selected route, run the check again, and compare the results. Keep the device, browser, and local network the same where possible, so a network change doesn’t look like a VPN route change.
- Note your exit IP before connecting, along with the client’s current traffic-capture mode.
- After connecting, confirm that the selected route matches your expectations, then reopen the check page. If the result looks cached, close the page and open it again.
- If the IP changes, check whether the location matches your expectations. If it doesn’t, first check whether a routing rule sends that check site directly.
- After changing a rule or traffic-capture mode, run the check again. Change one setting at a time and keep a before-and-after record so you can interpret the results.
IP geolocation databases can take time to update, and different lookup sites may show different cities. A route name, IP owner, and database location may not match exactly; that doesn’t automatically mean the route is broken. First check whether the public IP changed, then review the client’s request logs to see which outbound connection was used.
If your test tool checks IPv4 and IPv6 separately, see whether both follow the expected routes. If one address family isn’t captured, apps that support it may take a different path. Check the client’s address-family support and routing policy first; don’t treat permanently disabling a system feature as the default fix.
DNS: check the resolution path, not just the location
DNS translates domain names into IP addresses. A DNS leak generally means lookup requests are taking a path other than the one intended by your privacy or routing policy—for example, going to your local network’s resolver. Before testing, decide what you expect: all lookups through the tunnel, or direct-connect domains resolved locally.
Stay connected and run a DNS test that identifies the resolvers handling its queries. Compare the results with your client settings. If you see a resolver from your local network provider, check whether that matches your split-routing setup. A test usually reveals only the resolvers involved in its own test domains, not the DNS behavior of every app on your device.
A resolver in another location doesn’t necessarily mean there’s a leak. Public DNS services may use distributed infrastructure, so an address’s registered location, where the request is actually handled, and your exit IP’s location can differ. Conversely, a resolver in the expected location doesn’t prove every app’s data requests are using the proxy.
Browser Secure DNS May Differ from System DNS
Browser Secure DNS can send encrypted queries to a chosen resolver. That connection is still affected by proxy and routing policies, but it may not use the system resolver configured in your client. A successful browser test doesn’t replace a system-level check, and results from a system lookup tool don’t necessarily represent the browser.
The command-line tool nslookup can help you inspect DNS responses in your system environment, but it isn’t a complete DNS leak test. Some clients also use synthetic IP addresses or remote DNS resolution, so the returned address may not be the website’s final server address. Check the client documentation to interpret those results.
Verify apps individually: one working browser doesn’t mean everything works
Pick the apps you actually need and trigger a fresh network request in each one. Check the client logs for the relevant domain, process, or connection. Look for whether the request matched a direct, proxy, or blocked rule, and which outbound connection it used. Log fields vary by client, so don’t expect identical labels or screens.
- ✅ Browser: Open a page that hasn’t loaded before and actually load an image or submit a routine search. Don’t rely on a cached homepage.
- ✅ Desktop apps: Quit and relaunch the app, then try an online feature to avoid reusing an existing connection that took the old route.
- ✅ Mobile apps: Confirm the system has allowed the VPN connection and that the app isn’t on an exclusion list. Reopen it and test again.
- ✅ Persistent connections: Check real features such as sending and receiving messages or continuous loading—not just the login page—and watch for repeated reconnects.
- ❌ Don’t treat one page loading, a normal-looking app icon, or background traffic as proof that every app is using the VPN.
Windows, macOS, and Linux
On desktop, check whether the system proxy is enabled and whether the app uses its own proxy settings. Terminal tools may read proxy environment variables or ignore desktop system settings; browser extensions may affect only the browser. Tunnel mode often requires additional permissions. If authorization isn’t complete, follow the client’s guidance and check that its virtual network interface has been created correctly.
Android and iOS
On mobile, check that the system allows the VPN connection and that no other tool is capturing network traffic. Android clients may let you include or exclude apps; the traffic an iOS client captures depends on its implementation and system configuration. If disconnections happen only in the background, check the client logs and background activity restrictions instead of relying on the foreground icon.
If the target platform still says your location isn’t supported, don’t assume DNS is the cause. Platforms may consider your exit IP, account location, previous sessions, and their own policies. A verified network route only shows that requests are being sent as expected; it doesn’t guarantee that the destination service will be available.
Connected but not working: narrow down the cause
All apps have connection issues
Disconnect first and make sure your local network works. Then check that the subscription imported successfully, your account and traffic are in good standing, and the selected route is still included in your subscription. A subscription link lets the client fetch route settings; it doesn’t prove the connection works. After updating the subscription, connect and test it. Don’t post the full subscription link publicly.
Browser works, but other apps don’t
First check the scope of the system proxy, app-specific proxy settings, and exclusion lists. Temporarily switching to a broader traffic-capture mode supported by the client can help identify a coverage issue. When you’re done testing, restore the split-routing setup that suits your everyday use; there’s no need to send every request through the same route long term.
Apps still show the old location after switching routes
Check the exit IP again, then close the target app’s existing connections and retry. Account location, page caches, and server sessions may not update immediately when your exit IP changes. Clearing site data affects your sign-in state, so do it only when needed; repeatedly clearing the cache isn’t a core routing troubleshooting step.
Web pages load, but images or live features fail
An app may connect to several domains at once and use different transport methods. A proxy rule matching the homepage doesn’t mean image domains or live connections match the same rule. Check the logs from when the action failed, review the domain rules and outbound connection, and confirm the client supports that traffic before deciding whether to switch routes.
Shadowsocks, VMess, Trojan, VLESS, Hysteria2, and TUIC are names for different proxy protocols or setups; the protocol name alone doesn’t tell you which traffic the system captures or how DNS is routed. Likewise, direct, relayed, and IEPL describe how a route is organized, not whether it’s working on your device. See the route list and your client’s current configuration for VPNBack’s available routes.
Keep verification records you can review
During troubleshooting, note your device’s operating system, client, traffic-capture mode, selected route, exit IP before and after connecting, and the app and action that failed. Include only the relevant log excerpts. Hide account details, access tokens, and subscription URLs before sharing. If you need help, send these details to support; they’re more useful than “it says connected, but it doesn’t work.”
Bottom line: Confirm the route by checking that your exit IP, DNS behavior, and app traffic all tell the same story.
Use the exit IP to check the request path, DNS tests to review resolution policies, and app activity and logs to confirm what traffic is captured. If results conflict, check routing rules and old connections first, then permissions, routes, and account status. Retest after each change; a status icon isn’t the final word.