How can you tell whether your VPN is really working? Do not rely only on the client’s “Connected” message. That status usually means the client completed its handshake, opened a proxy port, or created a virtual network interface. It does not necessarily mean that traffic from your browser, download tools, and other apps is using the selected route. The most reliable approach is to check your exit IP, DNS resolution, system routes, and the actual results from each app in order.
First, define what “working” means for your setup. In full-tunnel mode, most public internet traffic is generally expected to leave through a remote exit. In split-tunnel mode, direct connections to local addresses, LAN resources, or selected apps may be normal. Proxy-only mode affects only apps that actively use that proxy. The correct result depends on the mode. Looking at one IP-check page without considering the current configuration can easily make normal split tunneling look like a failed connection.
Start by identifying what the client actually connected
Common clients offer system proxy, virtual network adapter, app proxy, and split-tunneling modes. A system proxy mainly affects software that follows the operating system’s proxy settings. Browsers usually do, but some games, command-line tools, and apps with their own network stack may bypass it. Virtual adapter mode takes control at the system routing layer and generally covers more traffic, though LAN exclusions, route priority, and security software can still affect the final path.
Shadowsocks, VMess, Trojan, VLESS, Hysteria2, and TUIC are different transport or proxy protocols. The protocol name alone cannot tell you whether the entire system’s traffic is being handled. The same protocol may run through a system proxy in one client and a virtual adapter in another. During testing, check the client’s current mode, split-tunneling rules, and connection targets in the logs instead of drawing conclusions from the protocol name alone.
Another common case is that the client connects successfully to a local proxy core, while requests from the core to the remote node are not forwarded correctly. The interface may remain connected even though actual requests time out or fall back to the original network. A successful handshake is only the starting point; end-to-end testing is still required.
| Check | Expected result | Possible issue | Priority check |
|---|---|---|---|
| Client status | The node is connected and the logs continue to show normal forwarding activity | There is only a connection message, with no app requests at all | Confirm that system proxy or virtual adapter mode is enabled |
| Public exit | The exit network changes as expected after connecting | The original network’s exit is shown throughout | Check routes, split-tunneling rules, and the browser proxy |
| DNS resolution | The resolution path matches the current mode and configuration | Domain requests are still handled by an unexpected local resolver | Check system DNS, client DNS, and the browser’s secure DNS |
| Individual app | The target request appears in the client connection log | The browser works, but other programs still connect directly | Confirm that the app follows the system proxy and check per-process routing |
Compare your exit IP before and after connecting
Your exit IP is the most straightforward thing to check. Disconnect the client, open a trusted public IP lookup page, and record the network operator and approximate region associated with your current address. Then connect to the target route and refresh the same page. If the route is forwarding requests from that browser, the page should show the remote exit rather than the exit provided by your original network.
Comparing only whether the address text changed is not enough. Some access networks assign addresses dynamically, so the address may change after reconnecting even without a proxy. It is more useful to compare the network operator and exit region with the selected node. Conversely, geolocation databases may be slow to update, so a different region name alone cannot prove that the route has failed. Consider the address attribution, client logs, and actual request path together.
For the before-and-after check, use the same browser window and lookup page whenever possible. This avoids differences between address databases used by different sites. If the page is cached, force a refresh or repeat the lookup in a private window. Do not post the public IP shown on the page in a public discussion; troubleshooting usually requires only whether the attribution changed, not the full address.
- ✅ Record the original network’s exit attribution while disconnected as your baseline.
- ✅ Connect to the target node and refresh the same lookup page to see whether the exit changes.
- ✅ Confirm in the client logs that the browser request actually entered the proxy connection.
- ✅ Switch back to the original network and check again to rule out page caching or database inaccuracies.
- ❌ Stop after seeing “Connection successful” without verifying the actual exit.
- ❌ Check only the region shown on the page without confirming the network operator and request logs.
Check whether DNS is resolving as expected
DNS converts domain names into network addresses that can be reached. Web content using a remote exit does not automatically mean DNS resolution follows the same path. If the system still sends queries to the original network’s resolver, the local resolution path may be exposed and access may fail because the returned results differ. A DNS leak generally means that resolution requests bypass the intended tunnel or proxy policy—not simply that the resolver’s region differs from the node’s region.
The process is similar to checking your exit IP: inspect the current resolver attribution while disconnected, then run the same test after connecting. Interpret the result alongside your configuration. If the client explicitly uses a remote resolver or sends DNS through the proxy, requests should not continue through the original network’s resolver. If the configuration deliberately specifies a separate encrypted DNS service, a resolver on another network may be completely normal.
The browser’s secure DNS can also change the result. Some browsers bypass system DNS and connect directly to the resolver selected by the user. The resolver shown by a test page may therefore come from the browser configuration rather than the client settings. For troubleshooting, temporarily make the browser follow the system settings, complete the comparison, and then restore your preferred secure DNS configuration.
Caching can also distort the result. A previously visited domain may be resolved from the browser or operating system cache without sending a new query. Use a test domain you have not visited before, or clear the system and browser DNS caches before testing again. On Windows, check the current resolver in the network settings; on macOS, inspect the system DNS status; on Linux, check both the system resolver service and the configuration generated by network management tools.
Verify the traffic path app by app
A successful browser test proves only that requests from that browser have entered the route. Desktop software, game platforms, download tools, and command-line programs may use different proxy mechanisms. In system proxy mode, apps that follow system settings can usually be handled; apps that ignore them may continue connecting directly. Virtual adapter mode covers more traffic, but bypass lists, LAN exclusions, and per-process routing can still apply.
When checking apps individually, close unrelated programs first, open the client’s live connection log, then launch the app under test and perform a specific network action. If the log shows the domain or address accessed by that app, the request has usually entered the proxy core. If the app can connect but there is no matching client log entry, check whether it connects directly, uses its own proxy settings, or is excluded by a split-tunneling rule.
On Android and iOS, also check per-app proxy settings, always-on connections, and local network permissions. On desktop platforms, common causes include browser extensions overriding system settings, other proxy software competing for the port, and security software rewriting network filtering rules. When multiple network tools are running, temporarily keep only the current client active. Rule out proxy-chain and routing conflicts before restoring the others one by one.
- Confirm whether the client is using a system proxy, virtual adapter, or app-only proxy.
- Open the live log and clear it, or note where the existing entries end.
- Launch the app under test and perform an action that generates a new network request.
- Check the target domain, connection method, and matched split-tunneling rule in the log.
- Switch routes or disconnect, then repeat the same action for comparison.
If the client supports rule logging, check whether each request is marked as proxied, direct, or rejected. Under split tunneling, a direct connection is not necessarily an error. LAN devices, internal domains, and explicitly designated local resources should usually remain direct. The cases that need attention are requests expected to use the proxy but marked direct, or apps that never enter the client at all.
Understand the limits of testing direct, relayed, and IEPL routes
A route’s transport topology and its final exit are separate layers. Direct usually means your network connects straight to a remote exit node. A relay route first reaches an intermediate relay, which then forwards traffic to the exit. IEPL commonly describes an access segment or backbone transport design. Regardless of the intermediate path, the destination website usually sees the final exit address rather than the relay’s internal address.
That is why a public IP lookup cannot distinguish direct, relayed, and IEPL routes on its own. It can confirm the final exit, but it cannot show the complete path in between. Client node details, server configuration, and route information provided by the operator are better sources for identifying the topology. Traceroute can offer clues, but some relays hide responses and network operators may filter probes. An incomplete route should not be treated as a definitive conclusion.
Transport design should not be confused with the proxy protocol. Trojan or VLESS can run over different transport routes, and Hysteria2 and TUIC may also use different access designs. The protocol governs connection and transport behavior, while direct, relay, and dedicated routes describe the lower-level path organization. To verify that a setup works, first check whether the app is handled, the exit changes, and DNS follows policy. Identifying the route type requires a separate review of the configuration details.
Common cases where the VPN appears connected but is not working
A browser extension overrides the system proxy
When a browser has a proxy extension installed, the extension may use its own node or connect directly, overriding the operating system proxy. Temporarily disable the relevant extensions, then test with system proxy or virtual adapter mode. If the exit becomes correct afterward, the problem is inside the browser configuration rather than the remote route.
A split-tunneling rule marks the target as direct
Rules may choose a path based on domains, addresses, processes, or rule sets. Outdated rules or overly broad domain matches can send requests that should use the proxy directly instead. Checking the matched rule in the live log is more effective than switching nodes at random. After correcting the rule, make a new request because an existing connection may continue using its previous path.
The subscription was updated, but the active configuration was not refreshed
A subscription link retrieves nodes and configuration. After the client finishes updating it, the current node may not switch automatically, and the running proxy core may not reload immediately. If the configuration and interface do not match, save the current settings, select the node again, and reconnect. A subscription link is a sensitive credential and should never be pasted into a public lookup page or public log.
Another proxy or stale route remains on the system
Another client, debugging proxy, enterprise networking tool, or security utility may also modify system proxy settings and routes. Even when the current client shows as connected, traffic may be captured by a higher-priority rule. After closing conflicting software, check the system proxy, default route, and virtual network interfaces again instead of simply restarting the browser.
An old connection was not re-established
After switching nodes, some apps continue reusing existing long-lived connections. If the lookup page does not send a new request, the result may remain associated with the previous exit. Close the relevant tabs or app sessions, reopen them, and refresh to reduce false results caused by old connections.
A repeatable end-to-end verification sequence
When a connection behaves unexpectedly, keep the test conditions stable. Do not change the node, protocol, browser, and DNS at the same time. Adjust one variable at a time so you can identify which setting caused the change. The sequence below works for a first connection, a client switch, or a change to split-tunneling rules.
- ✅ Disconnect the client and record the original public exit and DNS resolver attribution.
- ✅ Connect to the target node and confirm that the client logs show no recurring errors.
- ✅ Use the same browser to check the public exit again and verify the network operator.
- ✅ Run a new DNS resolution test to rule out cache and browser-specific DNS.
- ✅ Open the live log and test the apps you actually need, one at a time.
- ✅ Confirm that each request’s proxy, direct, or reject rule matches your expectations.
- ✅ Switch back to the original network and repeat the comparison to confirm the result is not caused by page caching.
- ❌ Change several settings at once, making the source of the problem impossible to identify.
If the exit does not change, first check proxy mode, virtual adapter status, and routes. If the exit changes but DNS does not match expectations, check client DNS, the system resolver, and browser secure DNS. If the browser works but other apps do not, check whether those apps follow the system proxy and whether per-process routing applies. If all requests enter the client but access still fails, then investigate node status, protocol compatibility, or upstream network restrictions.
Confirming that the connection works does not complete every privacy and security setting. Depending on your use case, decide whether to enable kill switch protection, allow LAN access, choose which domains should connect directly, and determine whether DNS should follow the system or use the proxy. The goal is not to force every request through one path, but to make each type of traffic follow clear, testable rules.