How to check if your VPN is working: IP, DNS, and app tests

To check whether a VPN is working, compare your public IP, DNS resolution path, and the target app’s connection logs before and after connecting. A “Connected” status only confirms that one part of the connection is established; it doesn’t prove that your browser, command-line tools, and other apps are using the expected route.

First, define what you expect: should only international websites use the proxy, or should most of your device’s network traffic go through the tunnel? In split-tunnel mode, local websites may still show your local IP—that can be normal. Check in this order: confirm the mode, then test real requests. There’s no need to keep switching routes right away.

Confirm the proxy mode and what you’re testing

A system proxy provides a proxy endpoint to apps that follow your system settings; it doesn’t take over the entire device. A browser may use the system proxy, while command-line tools may need separate configuration. TUN or a system VPN tunnel routes traffic through a virtual network interface, but exclusions, destination rules, and routing settings can still affect which traffic it handles.

Rule-based routing determines which destinations connect directly, use the proxy, or get blocked. The “Global” mode in a client also depends on how it’s implemented: it may route all requests that reach the proxy core through a selected exit, without capturing apps that never send traffic to the core in the first place.

Public IP: compare real requests before and after connecting

Your public IP is the source address a destination website sees—not your device’s address on the local network. The local address shown in your system network settings can’t tell you whether an international route is working. Use a reputable public IP lookup site and compare results in the same browser and on the same network.

1. Pause sensitive activity, disconnect the client, and note the public IP and network location shown by the lookup site. Don’t switch Wi-Fi networks at the same time, or the comparison won’t be reliable.
2. Connect to the route you want to test and confirm the mode and rules in use. Reload the lookup page, or open a new private window if needed, to avoid drawing conclusions from stale page content.
3. Compare the exit IPs and check the client’s connection logs to see how the lookup domain was handled. If the logs show a direct connection, check the rules before concluding that the route has failed.
4. Next, open the service you actually want to use and check its connection logs. The lookup site and the target service may match different rules, so a successful lookup doesn’t verify the service’s connection.

Geolocation databases can be out of date or assign the same exit IP to different locations. If the route name and the lookup site’s location don’t match, consider the IP’s registered location, route details, and actual access results. Don’t rely on a map alone.

Check IPv4 and IPv6 separately, too. A lookup site may show only one address type while connections using the other still go through your local network. If the client offers relevant settings, check its supported address types and routing behavior. A change in one address doesn’t prove the other is going through the tunnel.

DNS checks: separate the resolution path from the traffic path

DNS translates domain names into addresses that devices can connect to. Routing a web request through a proxy doesn’t necessarily route its DNS lookup the same way. Likewise, a resolver showing a local location doesn’t prove there’s a leak: public DNS services may use nearby entry points, and a test site may show the location of a recursive resolver’s exit.

A “DNS leak” means DNS requests have gone outside the protection scope you explicitly set—for example, when you expect lookups to be handled inside the tunnel but your local network’s resolver receives them instead. Assess this using your configuration, client logs, and test results, not just a country name.

• Start with the client’s DNS settings. Check whether direct and proxied domains use different resolution policies, whether DNS interception is enabled, and whether the settings loaded successfully.
• Then check your browser’s secure DNS. A browser’s built-in encrypted DNS may bypass the system resolver. Encryption protects DNS traffic in transit, but doesn’t guarantee it’s using the current proxy.
• Use a reputable DNS test site. Compare the resolvers shown before and after connecting with your expected configuration. A test site only checks the current browser session; it can’t verify every app.
• Finally, rule out cached results. Existing connections and cached DNS records may remain in use after you change settings. Restart the app you’re testing or clear its cache as instructed by your system, then test again.

Command-line tools have limitations, too. For example, nslookup example.com typically queries the selected resolver, but that’s not the same as a browser’s secure DNS request, and it may not be controlled by the system’s HTTP proxy. A successful command only confirms that the query received a response; on its own, it doesn’t prove the browser is using the expected DNS path.

Some clients use mechanisms such as Fake-IP, giving apps synthetic addresses for the proxy core to handle. In that case, your device’s DNS result may not resemble the website’s real address—and that isn’t necessarily a problem. Check how the mode works before changing your DNS settings just because an address looks unfamiliar.

Test individual apps: a working browser doesn’t mean everything works

Testing the apps you actually use is more reliable than relying on a lookup site alone. Browsing, signing in to developer tools, command-line downloads, and audio or video calls may use different proxy settings, transport methods, and connection lifetimes. Each test should trigger a new network request, which you can then check in the client logs.

Browsers and extensions

Check whether you have a proxy-control extension installed and whether the browser uses its own proxy settings. For now, use just one clearly defined control method to avoid the system proxy and extension overriding each other. Loading a cached page doesn’t count as a successful test: request fresh content and check the exit used for the relevant domain.

Command-line tools and developer apps

Terminals, editors, and their child processes may not inherit the same proxy environment. Check whether HTTP_PROXY, HTTPS_PROXY, ALL_PROXY, and NO_PROXY apply to your tool; consult its documentation for supported settings. Command-line options or the tool’s own settings may override environment variables.

To test an explicit proxy, copy the actual listening address and port from the client and enter them as the tool’s documentation specifies. Don’t rely on default values you found online. When accessing a domain through a SOCKS proxy, also check whether DNS resolution happens locally or on the proxy, as this affects DNS test results.

Mobile devices and real-time communication

Android clients may offer lists of apps to include or exclude. iOS typically uses a system network extension to establish the connection, but the client’s settings determine what it handles. System proxies, tunnel permissions, and app support also vary across Windows, macOS, and Linux, so don’t assume a setting has the same name or behavior on every platform.

Audio, video, and real-time communication may also use UDP and WebRTC. A web page loading successfully doesn’t mean these types of traffic are working. A local candidate address in a WebRTC test doesn’t automatically mean your public IP is exposed; check the address type, the connection path actually selected, and what the client supports.

Common signs of a false connection and how to troubleshoot

“False connection” isn’t a single technical state. The client may still show a connection icon even though the remote route is unreachable, or the local proxy may be listening while the route is down. The route might also be working perfectly while the target app isn’t using it. Note what failed, then narrow down the cause one step at a time.

• ✅ Check that the configuration has loaded. A successful subscription update only means the configuration was retrieved. Confirm that you’ve selected a working route and can make a real request.
• ✅ Check that system traffic capture is active. Review the proxy switch, tunnel permissions, and exclusion list, and see whether another networking tool has changed the settings.
• ✅ Check which rule matched. If the target domain was routed directly or blocked, review the relevant rule before treating it as a route failure.
• ✅ Check whether the remote route is reachable. Try another available route for the same destination and see whether the error changes. Avoid changing several settings at once.
• ✅ Check the target service. Account region, login security checks, service outages, and content licensing can all cause access issues. A correct exit IP doesn’t guarantee the service will allow access.
• ✅ Check a new request after recovery. After switching networks or waking the device, reconnect the app, then check the exit IP and connection logs again.

A subscription link is a way to import configuration, not proof that a connection works. Importing it successfully also doesn’t mean the client supports every protocol, transport option, or rule syntax in the configuration. If you see an unknown-field or unsupported-protocol warning after importing, check the client version and configuration format. See the Guides rather than repeatedly resetting your network settings.

Slow speeds don’t necessarily mean the VPN isn’t working. Even with the right exit IP and rules, congestion, the destination’s response time, and Wi-Fi quality can affect performance. The connection type’s name isn’t proof, either: whether it’s direct, relayed, or a dedicated route, verify the actual path used by your request.

Check separately whether traffic falls back to a direct connection after a disconnect

A working route and protection against direct connections after it drops are two different things. Some system proxies make apps return an error if the remote connection is lost; others may try a different path. What happens when a tunnel ends also depends on the system and client settings. Don’t assume the client has built-in disconnect protection, and don’t run your first test during a sensitive session.

If the client explicitly offers a relevant feature, close sensitive apps first, then disconnect intentionally. Use a standard lookup site to see whether it’s still reachable and whether your exit has returned to your local network. Reconnect afterward and confirm that routing rules and DNS are working again. An intentional disconnect may not reflect a process crash or network switch, so the result only applies to the scenario you tested.

If you still can’t find the cause, note your operating system, client name, current mode, time of failure, target domain, and a redacted error message. Work through the troubleshooting guide or report the issue through Contact Us. Identifying which type of request failed is more useful than simply saying, “It says connected, but nothing works.”