How to Check If Your VPN Is Working: A Beginner’s Guide to IP, DNS, and App-by-App Testing

How can you tell whether your VPN is working? The connection icon isn’t enough: check your public IP, DNS resolution path, and the traffic from the app you want to test. Accessing a website only confirms that request succeeded. To verify the route, compare results before and after connecting, then check the client’s rules and logs.

Connection Status vs. Actual Traffic

A client’s “Connected” status may mean a system tunnel is established, or simply that a local proxy process has started. Clients define this status differently. Successfully importing a subscription or seeing a node in the list only confirms that the configuration was obtained—not that the remote node is reachable or every app uses it.

First, define what you want to verify: should a specific international website use the proxy, or should all traffic handled by the client go through its exit? Rule-based modes typically allow some websites to connect directly, so a local website showing your usual exit isn’t necessarily a problem. Conversely, seeing the node’s exit on one check page doesn’t prove that chat apps, meeting software, or terminal tools use it.

What Common Signs Actually Tell You
What you observe	What it can tell you	What it cannot tell you by itself
The client shows “Connected”	The client has entered the running state as it defines it	That the remote node is available or every app is using the proxy
Your public IP has changed	The public exit used for that specific lookup has changed	That other apps or address families are also being routed through the client
A DNS test shows an unfamiliar resolver	The test domain was queried through that DNS service	That the name alone proves a leak or complete privacy protection
The log shows a proxy rule match	The client selected a proxy route for that connection	That the request ultimately succeeded or the service works as expected

Public IP: Compare Before and After Connecting

Keep the device and network unchanged. Temporarily disconnect the client, open a trusted public IP lookup page in your browser, and note the exit address and network provider. Then connect the client, check the selected node and mode, and refresh the same page. Treat the displayed region as a rough guide; the address and network provider are usually more useful to verify.

Save the result from before connecting as a baseline for your current network. Avoid switching Wi-Fi at the same time, or you won’t know what caused the change.
Run the lookup again after connecting instead of relying on a page that was already open. If needed, use a new browser window to minimize the effects of caching and existing connections.
Check which client rule matches the lookup domain. If it’s set to connect directly, an unchanged result is expected and doesn’t mean the node has failed.
If the client supports it, temporarily change the rule for that domain or test in global proxy mode, then restore your original settings.
Cross-check with an independent lookup service. Note the node, mode, and result, rather than relying on a region label from a single site.

IP geolocation databases may be out of date. A displayed region that differs from the node name doesn’t necessarily mean the connection isn’t working; a node name isn’t a geolocation result. Check the exit address, network provider, and client logs together. A lookup service may also check only the address family currently in use, so one result can’t prove that all network traffic follows the same route.

DNS: Check the Resolution Path, Not Just the Region

DNS translates domain names into addresses; your public IP indicates where a request exits to reach its destination. They may follow different paths. A DNS leak generally means lookup requests went outside the intended protection path—for example, when you expect DNS queries to use the tunnel but they still go to a resolver on your local network.

Many DNS test pages generate unique test domains and check which recursive resolvers handle the lookups. The results show information about DNS services, not a complete list of devices. Public DNS providers may use distributed infrastructure, so a resolver’s region may differ from the node’s; that alone doesn’t prove a leak. Likewise, a familiar-looking name doesn’t prove everything is working as intended.

Start by checking the client’s DNS settings to see whether it uses local resolution, remote resolution, or rules to decide. Then check whether your browser has its own Secure DNS setting enabled. A browser may use encrypted DNS instead of the system resolver, but encryption describes how data is sent—it doesn’t guarantee that the request uses the current node.

Use the same test service while disconnected and connected, then compare the results with the client’s DNS logs. If the connected test still shows a local provider’s resolver when your configuration requires remote resolution, check traffic capture and DNS routing. If the configuration explicitly allows direct-connect domains to resolve locally, assess results based on the domains involved rather than expecting every result to match.

Built-in system lookup tools can check whether the system resolver responds, but they may not reproduce the resolution path used by a browser or app. For troubleshooting, you can temporarily align the browser and client DNS settings for comparison. Don’t enter an unfamiliar DNS address just to make a test result look better.

Test Apps Individually: Don’t Stop at the Browser

A system proxy, virtual network adapter, and in-app proxy are not interchangeable. Software must follow the system proxy settings to use them. A virtual network adapter typically captures matching traffic at the system routing layer, but exclusions, app settings, and client implementation still matter. An in-app proxy is configured separately by that software. Don’t assume coverage based on a mode’s name alone.

Windows, macOS, and Linux

Desktop browsers often use the system proxy, but extensions or in-app settings may override it. Terminal tools, developer tools, and some desktop apps may need their own proxy settings. If the browser works but a terminal doesn’t, first check whether its requests appear in the client logs; don’t immediately blame the route. On Linux, desktop environment and command-line proxy settings may also be separate.

iOS and Android

Mobile clients often use the system VPN interface to capture network traffic, but the actual scope depends on the client configuration. Android clients may let you include or exclude apps; route exclusions and client rules can also affect results on iOS. A VPN icon in the system status bar only means the relevant configuration is active—it doesn’t replace testing the apps themselves.

✅ Browser: Reopen the target website and check the logs for its domain and selected outbound route.
✅ Work apps: Reopen a document or sync it, then verify the actual result—not just whether the home screen loads.
✅ Video calls: Check the media connection. A successful sign-in doesn’t mean the call route works; some media traffic uses UDP.
✅ Terminal and developer tools: Check their proxy settings, environment variables, and bypass lists to confirm requests reach the client.
❌ Don’t use one browser lookup to conclude that every other app is working.

Before retesting, quit and restart the app to avoid existing connections continuing to use the previous route. When checking logs, perform only the action you’re testing to reduce interference from background sync. If an app uses multiple domains, check login, content, and media requests—not just one domain.

Common Issues: Narrow Down the Cause

The exit hasn’t changed, and there are no requests in the logs

First check the system proxy switch, virtual network adapter permissions, and app exclusions. Browser proxy extensions, other network clients, or work VPNs may also change the route. If you’re authorized, pause conflicting components and test one at a time. On managed devices, don’t bypass your organization’s network policies.

The log shows a direct connection, or the old exit remains after switching nodes

For a direct connection, check rule order, domain matching, and the default outbound route. If the old exit remains after switching nodes, reconnect the app. Rules are often evaluated in order, so an overly broad direct-connect rule may match first. Don’t change every rule at once; adjust only the relevant setting and keep a copy of the original configuration so you can restore it.

The proxy rule matches, but the website still fails

“Proxy selected” only describes the routing decision; it doesn’t mean a remote connection was established. Check the logs for connection, DNS, and certificate errors, then verify that the subscription is valid and traffic is available. If the app’s requests never reach the client, switching nodes repeatedly is unlikely to fix the traffic-capture issue.

Websites work, but live audio or video doesn’t

Web and media traffic may use different transport methods or match different rules. Check whether the client and selected node support the traffic involved, then review the media domains and UDP route. A protocol name alone doesn’t guarantee that every feature works, and you shouldn’t leave the system firewall disabled to troubleshoot.

Limits of Testing and Records You Can Review

A changed public IP doesn’t make you anonymous or mean all communications on your device have the same protection. Browser features such as WebRTC may reveal additional network candidate addresses; some are local or have their names obscured. Distinguish local addresses from your real public exit, and don’t treat every unfamiliar address as a leak.

A test page can only see the requests it triggers and observes. A more reliable conclusion is specific: “On this device, network, and mode, this request from this app used the expected exit.” Retest important apps after changing networks, updating rules, or switching clients instead of relying on an old result indefinitely.

When saving test results, note the device platform, client mode, node name, test domain, change in exit, and outbound route shown in the logs. Before contacting support, redact subscription links, credentials, and unnecessary personal information. Subscription links may contain access credentials, so don’t post them in public forums.

Conclusion: Check the Exit, DNS, and Apps Separately

First establish a baseline while disconnected, then check your public IP. Next, use your configuration to assess the DNS path, and finally test the apps you actually use. Useful evidence comes from results that match your rules, logs that show the relevant requests, and successful app tasks. A connection icon or region label alone isn’t enough.

When using VPNKM, start with the getting started guide to check client setup and subscription import. The client requires a login and an active paid plan to access; subscriptions are available after login. If problems persist after setup, use the troubleshooting guide to document what’s happening, then send feedback through the dashboard. Troubleshoot your route separately from choosing a plan; upgrading won’t identify the cause.