How can you tell if your VPN is working? First check the public IP used for the request you care about, then inspect the DNS resolution path, and finally test the apps you actually use. A client showing “Connected” may only mean that a local proxy has started or a tunnel interface has been created. It doesn't necessarily mean all traffic is taking the intended international route.
The goal isn't to make every test show the same region. With split tunneling, local sites can connect directly while international sites use a proxy. This guide helps you check whether traffic follows your configuration—not treat the color of a test page as a verdict.
First, distinguish connection status from traffic routing
What people generally call a VPN client may use a system VPN tunnel or simply configure a proxy in the operating system. System proxies usually work with apps that respect those settings; games, command-line tools, and apps with their own network settings may not. TUN or system VPN mode can capture more traffic, but the actual scope still depends on routes, app exclusions, and protocol support.
A proxy protocol name doesn't tell you which route traffic takes. Shadowsocks, VMess, Trojan, VLESS, and other protocols rely on correct client and server configuration. Whether DNS is captured, UDP is forwarded, or specific apps connect directly depends on the implementation and settings. Seeing node names after importing a subscription doesn't mean system permissions, the proxy switch, or routing rules are all in place.
| What you see | What it tells you | What still needs checking |
|---|---|---|
| The client shows Connected | The client reports a connection or that its local service has started | Whether the request reached the client and was successfully forwarded |
| The browser's public IP changes | That web request used a different exit IP | Whether other apps and address families follow the same rules |
| A DNS test shows resolvers outside your region | Those resolvers participated in resolving the test domain | Whether the route to those resolvers matches your expectations |
| An app can open an international website | The service is accessible under the current conditions | Whether the connection used the intended route, rather than working directly already |
Public IP: use the same setup for a comparison
Choose a public IP lookup site you trust and note the address, address family, and network provider before and after connecting. A public IP is not your device's local network address; the private address assigned by your router usually won't change when you turn on a proxy. Don't install browser extensions from unknown sources just to run a check.
- Record a baseline. Disconnect the client temporarily, turn off other proxy tools, and open the lookup page in the same browser. Save the current public IP details.
- Connect to the route you want to test. Make sure the client has the required permissions, then check whether it's in rule-based, global proxy, or tunnel mode.
- Send the request again. Refresh the lookup page. If needed, close the old tab and open a new one to avoid misleading results from cached pages or long-lived connections.
- Check which rule matched. Review the client's connection list to see whether the lookup domain used the proxy or connected directly, then interpret the IP change accordingly.
- Test what you actually use. Open the website or app you need and check its connection too—not just an IP lookup site.
If a rule sends the lookup site direct, an unchanged IP doesn't prove the client isn't working. You can temporarily route that domain through the proxy you're testing, then restore your original settings. “Global proxy” may simply send all requests that reach the client through the proxy; it doesn't necessarily capture every app on the device.
If the displayed region doesn't match the node name, first check the IP itself and its network provider. Geolocation databases can lag behind, and different sites may report different locations. The node entry point, forwarding route, and public exit IP are also distinct, so a region label alone can't diagnose a route failure.
DNS leaks: check the route, not just the region
DNS translates domain names into IP addresses. A leak occurs when a DNS request that should follow a protected route takes an unintended path—for example, when a lookup you expected to go through the tunnel is sent directly to your current network's resolver. Whether that's a problem depends on your routing and privacy goals.
DNS test sites typically ask your browser to look up temporary test domains, then show which recursive resolvers took part. This reports resolver information; it isn't a full capture of every DNS request from your device. A resolver in your local region doesn't automatically mean the query bypassed the tunnel, and a resolver elsewhere doesn't prove that the connection to it used the proxy.
Browser secure DNS may differ from the client's DNS
With secure DNS such as DoH enabled, a browser may send encrypted DNS requests itself instead of fully following the operating system's resolver settings. Encryption protects query contents in transit, but doesn't guarantee the request uses a proxy. Check the browser policy, client rules, and the actual route to the DNS service.
- Note the current DNS settings in your operating system, browser, and client so you can restore them after testing.
- Connect to the route, run a DNS test, check the resolver network, and review the client logs to confirm how related requests were routed.
- If the results look wrong, temporarily align the browser and client DNS settings and test again. Avoid changing several unrelated options at once.
- After changing settings, restart the relevant apps or clear their DNS caches so old results don't hide the change.
Some clients use Fake-IP, returning synthetic addresses to apps and then matching the domain inside the client before forwarding traffic. In that setup, the address shown by the operating system may not be the destination server's real IP, so a standard DNS result alone may not reveal a problem. Command-line DNS tools may also use a different route and don't necessarily reflect a browser's DoH behavior.
App-by-app testing: a working browser isn't enough
Desktop browsers, apps, and terminal tools may use the system proxy, their own proxy settings, or a direct connection. On Windows and macOS, enabling the system proxy doesn't guarantee every program will use it. Linux desktop settings, terminal environment variables, and app-specific options can also work independently. Test the software you actually use.
Android clients may let you include or exclude individual apps, so check that the app you want to test isn't excluded. On iOS, distinguish a system VPN configuration from proxy settings that apply only to certain networks. The actual scope depends on the client, its configuration, and system policies. Don't assume that behavior on one platform will be the same on another.
- ✅ Browser: Open the website you actually need and compare its domain, matched rule, and outbound route with the client's connection list.
- ✅ Desktop collaboration app: Reconnect, then sync or load content and check whether the relevant process or domain appears in the client.
- ✅ Command-line tool: Check whether the program reads proxy environment variables or is captured by the tunnel. A browser test can't verify it on the tool's behalf.
- ✅ Real-time communications and games: Test sign-in, voice, and an active session separately. A successful web login doesn't prove that UDP traffic is routed too.
- ❌ Checking total traffic only: Background updates also generate traffic, so an increasing counter doesn't prove the target app used the intended route.
If the client shows domains but not processes, close unrelated apps first, trigger the action you want to test, and watch for new connections. Existing long-lived connections may keep using their old route, so reconnect after switching nodes. Recording the test time and exact action is usually more useful than cycling through lots of nodes.
Common issues: troubleshoot using the evidence
Connected, but no requests from the target app
First check whether another app has overridden the system proxy, whether tunnel permissions were granted, whether the target app is excluded, and whether it has its own proxy settings. The problem may be between the device and the client, so switching remote nodes may not help.
Requests appear, but the connection fails
Check the selected outbound route, DNS results, and the specific error. An expired subscription, a failed configuration update, protocol incompatibility, or the destination service refusing access can all look similar. Subscription links distribute configuration and may contain access credentials. Get them from a trusted account panel and import them into a compatible client; don't post them publicly.
Web pages work, but voice or games don't
First check whether the client mode and route support the required UDP forwarding, then review the app's proxy support and network permissions. A successful TCP web request doesn't prove that real-time media uses a working route. Even when traffic goes through the proxy, packet loss, jitter, server load, or your local wireless network can still affect a session.
The IP changed, but the service is still unavailable
The issue may involve account region, content licensing, the reputation of the exit IP, server-side risk controls, or caching—not necessarily a VPN that isn't working. Assess whether the request used the route separately from whether the service allows access. Repeatedly refreshing a test site can't replace the error message from the service itself.
Verification results and privacy limits
A browser's WebRTC test can provide additional clues, but distinguish local network candidates from public exit addresses. Browsers may use mDNS names to hide local addresses; seeing a local candidate doesn't mean a site has obtained your original public IP. If an unexpected public candidate appears, check browser settings, UDP handling, and the actual connection path.
Likewise, IP and DNS tests can't verify a provider's logging practices or stop sites from identifying visitors through signed-in accounts, cookies, or browser fingerprints. VPNTee's “no logs” statement describes its service policy; a single test can't prove anonymity.
Bottom line: To check whether a VPN is working, compare the public IP, DNS route, and connections from the apps you actually use. Traffic matching your split-tunneling rules matters more than every test showing the same region. If results conflict, check what traffic the client captures first, then review rules and DNS, and finally investigate the remote route and destination service.
Repeat these checks after operating system updates, client upgrades, subscription updates, or network changes. For help importing a client configuration and setting permissions, see the Quick Start Guide. If you still have questions about your setup, continue troubleshooting on the Support page.