How can you tell whether your VPN is really working? A reliable answer means more than seeing “Connected” in the app: check your public IP, DNS resolution path, and actual app traffic. The connection status only shows that the client established a session with the remote server; it does not prove that your browser, meeting software, download tools, and other apps are using the route as expected.
Before connecting, record a baseline with the VPN off, then reconnect to the target route and run the same checks again. Opening a single test page only after connecting gives you nothing to compare and can make cache, split tunneling, or browser network settings look like a routing problem. Follow the checks below from basic to advanced.
What “Connected” Really Means
When a client shows Connected, authentication, the handshake, and the remote session have usually completed. The device may have enabled a system proxy, a virtual network interface, or an in-app proxy, or it may have configured split tunneling for only certain domains. Each method covers a different range of traffic.
| Traffic handling method | Usually covers | Commonly misses | What to check |
|---|---|---|---|
| System proxy | Browsers and apps that follow the operating system’s proxy settings | Apps that ignore the system proxy, some real-time communications, and standalone network services | Test the browser and standalone apps separately |
| TUN mode | IP traffic routed through the virtual network interface and matched by the rules | Excluded processes, local network traffic, and destinations set to connect directly | Review routing rules, the virtual interface, and the bypass list |
| Browser extension | The current browser or browsers configured to use it | Other system apps and background requests outside the browser | Do not treat a browser result as a result for the whole device |
| In-app proxy | Only apps with proxy parameters configured | The operating system and other unconfigured apps | Check the app’s proxy type and port |
Shadowsocks, VMess, Trojan, VLESS, Hysteria2, and TUIC describe the protocols or transport methods used between the client and server. The protocol name alone does not determine whether the entire device is covered. Coverage depends on the client mode, system permissions, routing table, and split-tunneling rules. Even though Hysteria2 and TUIC are designed with real-time transport in mind, that does not mean traffic from every app automatically enters the route.
Check Your Public IP: Compare Before and After Connecting
Your public IP is the address websites see as your network’s source. Before testing, disconnect the client, disable browser extensions that may handle traffic separately, and open a trusted IP-check page. Record the current network operator, region, and address. Then connect to the target route, refresh the page, and record the results again.
- Disconnect and establish a baseline. Record the current public IP details instead of relying on memory.
- Connect to the target route. Wait for the client status to stabilize before checking, so you do not capture an old result during route changes.
- Check again in a private window. This reduces interference from page cache, extension settings, and old sessions.
- Use a separate testing source. Different databases may label regions differently, but the public address itself should provide a useful cross-check.
- Check once more after disconnecting. The public IP should return to the original network path, completing the comparison.
If the address changes after connecting, the request from that page most likely went through the remote exit. The region label may not exactly match the route name, however. IP databases can identify the same address range as a nearby city, a data-center registration location, or the network operator’s location, so do not judge the result by the city name alone.
If the public IP does not change at all, do not start by switching protocols repeatedly. More common causes include the browser not reading the system proxy, the current domain being routed directly by a rule, the app not using the proxy port, or TUN mode failing to create its virtual interface. Checking each traffic-handling mode is more effective than cycling through routes.
Check DNS: Separate Resolver Changes from Actual Leaks
Before connecting to a domain, a device usually resolves it to an address. If application traffic uses the remote route while DNS queries are still sent directly to the resolver provided by the local network, domain information may leave through an unintended path. This is commonly called a DNS leak.
The process is similar to checking your public IP: run a DNS test with the route disconnected and record the resolvers identified by the page; reconnect, run it again, and compare whether the resolver network matches the client configuration. If the local network’s resolvers still appear clearly after connecting even though the client should handle DNS, check the DNS mode, system cache, and split-tunneling rules.
Seeing a third-party public resolver does not necessarily mean there is a leak. Your browser may have Secure DNS enabled, or the operating system may use a resolver you selected manually. In that case, it is normal for the resolver and VPN exit operator to differ. The key question is whether DNS queries travel through the expected encrypted or tunneled route, not whether the resolver name exactly matches the exit name.
- ✅ Save the resolver results while disconnected, then check what changes after connecting
- ✅ Check browser Secure DNS, system DNS, and the client’s DNS settings together
- ✅ Clear the DNS cache after changing settings, then start a completely new query
- ❌ Declare a leak just because you see an unfamiliar resolver name
- ❌ Test in only one browser and extend the conclusion to the entire device
The command line can also help you inspect the current DNS configuration. Windows has built-in commands for network configuration and DNS queries, macOS can show the system resolver state, and Linux requires checks tailored to the network management service in use. Command output mainly tells you “which resolver the system is prepared to use,” while an online DNS test is closer to “which resolver external services ultimately saw.” Together, they provide a more useful picture.
nslookup example.com
scutil --dns
resolvectl statusThese commands apply to different platforms, so you do not need to run all of them. If the system result differs from the online test, first check browser Secure DNS, container or virtual-machine networking, enterprise policies, and whether the client handles only some queries.
Per-App Verification: Confirm the Apps That Matter Use the Route
Many cases where a VPN looks connected but traffic is not using it come from split tunneling. A client may send sites in mainland China directly while routing international sites through the remote route; it may also choose paths by process, domain, address range, or rule set. Different exits at the same time are therefore not necessarily a contradiction.
Test Browsers and Desktop Apps Separately
Start by checking the public IP in a browser, then open the app you actually need to verify. If the app offers network diagnostics, connection details, or a proxy settings page, check whether it follows system settings. Some software ignores the system proxy and connects directly; other software lets you configure a separate proxy, and a mistake can still leave it online without using the client route.
Video meeting and voice apps often use several transport methods at once. A web meeting page may use the browser proxy, while audio and video media are carried by a separate process or a different path. Therefore, “the meeting page opens” does not prove that the media stream is covered. If the client provides connection logs, watch for the relevant destinations and traffic changes while starting a call or playing media.
Use Connection Logs to Check Rule Matches
Client logs typically show the destination domain, destination address, policy used, and final exit. Before testing, clear or pause old logs, then operate the target app so new connections are easier to identify. If a log is marked DIRECT, bypass, or direct, the rules intentionally skipped the remote route; if there is no record at all, the app may be outside the client’s traffic-handling scope.
A “proxy” label in the log is not the end of the investigation. You must also confirm that the request reached the remote side successfully, did not fall back to a direct connection because of a rule, and did not use a separate DNS path. For apps that need stable communication, observe connection establishment, sustained traffic, and what changes after disconnecting—not just one page load.
Split Tunneling Is Not a Failure
Proper split tunneling can keep local-network devices, printing services, and sites that do not need international access on a direct connection while sending selected destinations through an international route. The issue is not that direct connections exist; it is whether the rules match your goal. Before testing, define which apps should use the route. Otherwise, mixed results are impossible to evaluate.
Common Misreadings: Why Results Change from Test to Test
Occasional differences between public-IP and DNS tests are often not caused by one specific fault. Browser cache, persistent connections, rule updates, and network changes can all preserve an old state. After switching routes, established connections may not move immediately to the new path, and refreshing a page may not close every background connection.
| Symptom | Possible cause | What to do |
|---|---|---|
| Client connected, public IP unchanged | The app ignores the system proxy, a rule matched direct access, or TUN is not working | Check the traffic-handling mode, rule logs, and virtual interface |
| Browser public IP changes, other apps do not | A browser extension or browser proxy is working independently | Disable the extension and test again; check the app’s own proxy settings |
| Public IP changes, but DNS still shows the local network | DNS is not being handled, the system cache was not refreshed, or a split-tunneling rule is missing | Check the client DNS mode and clear the cache |
| Old public IP remains after switching routes | Page cache, connection reuse, or an old session has not closed | Close the relevant apps and establish a completely new connection |
| Different test pages show different cities | IP geolocation databases update at different speeds and use different labeling standards | Use the public address and network operator as the primary comparison |
| Some local services stop working after enabling TUN | The local-network bypass rules or route priority do not match expectations | Check local-network access options and routing rules |
Direct connections, relays, and IEPL dedicated routes should also be distinguished. A direct connection sends the device straight to the remote entry point and is more affected by public routing; a relay connects to a nearby entry point first, which then forwards traffic through an intermediate network to the exit; an IEPL dedicated route generally emphasizes dedicated carriage across the international segment. Whichever route you use, the verification method is the same: check the target app’s actual exit, DNS path, and connection logs rather than inferring behavior from the route name.
If your subscription offers multiple protocols, do not treat switching protocols as the first troubleshooting step. First confirm that the subscription link was imported correctly, node information is up to date, the system clock is correct, and the client has permission to create a virtual interface. Only then consider protocol compatibility. A subscription link contains access configuration and should be protected like account credentials; do not paste it into an untrusted testing page.
Troubleshoot in a Fixed Order Instead of Guessing
When results do not match expectations, start with checks that have the narrowest scope and fewest variables. Change one setting at a time and establish a new connection after each change. If you switch the route, protocol, DNS, and split-tunneling rules together, even a successful outcome will not tell you which change fixed the issue.
- ✅ Confirm the subscription is updated and the target route can establish a session
- ✅ Disconnect and record the public IP and DNS baseline
- ✅ Connect the route and recheck the public IP in a single private browser window
- ✅ Check the DNS results and review the browser Secure DNS setting
- ✅ Open the target app and use the client logs to confirm the rule match
- ✅ If the app is not using the route, check the system proxy or TUN permissions
- ✅ After changing settings, close old connections and complete another disconnect-and-reconnect test
- ❌ Judge the route only by the region name when you have no baseline
Platform differences also affect where to begin. Windows and macOS desktop clients commonly let you choose between a system proxy and TUN, but creating a virtual interface may require additional system permissions. Android and iOS generally use the system VPN configuration to handle traffic, and the operating system shows the connection state; software excluded by per-app settings will still connect directly. Linux depends more heavily on the specific network manager, routing table, and DNS service, so inspect the client configuration together with the system network state.
After testing, use this simple standard to wrap up: the public IP changes consistently between disconnected and connected states, the DNS path matches the configuration, the target app matches the expected rule in the logs, and disconnecting restores the original network path. These conditions provide stronger evidence that the VPN is working as expected than a connection icon alone.