How can you tell whether a VPN is really working? You cannot rely only on the client showing “Connected.” That status usually means the local client completed a handshake or established a session with an entry node; it does not prove that your browser, command-line tools, and other apps are all using that route. A reliable method is to save a network baseline before connecting, then check the exit IP, DNS resolution path, and actual traffic from each app.

Before testing, define the expected result. A global proxy should route most public internet traffic through the selected exit; rule-based routing handles only requests that match its rules; per-app mode takes over only the specified programs. Each mode has different correct results. Mistaking split tunneling for global routing often creates the impression that “the browser changed, but other programs did not,” which is not necessarily a fault.

Establish a comparable before-and-after baseline

The key is not one isolated result, but the difference before and after connecting on the same device, network, and test site. Before you begin, disable old proxy extensions, quit other network tools, and check that the system clock is correct. Record the public exit region, network ownership, and DNS results while disconnected. After connecting, repeat the checks through the same test page.

VPNFe’s IP Test page shows your current network exit. Do not focus on one address remaining unchanged over time: node scheduling, exit-pool changes, and reconnections can all change it. What matters more is whether the exit belongs to the selected region and whether disconnecting restores the original network.

What to check Before connecting Expected after connecting Warning sign
Public exit IP Exit of the current access network Changes to the selected route’s exit Address and ownership remain unchanged
Exit region Local access region Matches the node’s target region Shows an unexpected region or changes frequently
DNS resolution path Default path from the local network Matches the client’s DNS and routing settings Queries still go to the local network
Individual app Direct-connection result Matches global, rule-based, or per-app policy Only some programs change
  1. Disconnect all routes and record the current exit ownership and DNS results.
  2. Remove browser proxy extensions that could affect the test, and close old test-page tabs.
  3. Connect to the target route, wait for the client status to stabilize, and reopen the test page.
  4. Compare the exit, DNS, and app behavior—not just whether the page loads.
  5. Disconnect and test once more to confirm the result returns to the baseline.
Baseline conclusion: If the exit matches the target region after connecting and returns to the original network after disconnecting, the public traffic from the tested browser has switched routes. This still does not mean every app on the device is being handled.

Step 1: Confirm that the exit IP really changed

Your exit IP is the request source visible to external services. When the route is working, a test site will usually see the remote node’s exit rather than the public exit of your local access network. Check the address, network ownership, and region together; do not rely only on a map label. Geolocation databases can lag, and the same exit may appear as a neighboring city in different databases, so the city name is not decisive.

Verify the result through different test sites

A browser may retain page cache or use a separate proxy extension. Open a new tab and force-refresh when comparing results, then verify with another browser that has no proxy extension installed. If the browsers show different results, the issue is more likely the extension, browser-specific DNS, or how the system proxy is inherited than the node itself.

Command-line programs deserve a separate test. Some clients set only the system proxy, which command-line tools may not read; others enable TUN and take over more traffic at the system routing layer. If the browser shows the target exit but terminal requests still show the local exit, first check whether the client is using the system proxy, TUN, or browser-extension-only mode.

Step 2: Confirm that DNS follows the expected path

DNS converts domain names into addresses that can be reached. Even when web requests use a remote exit, domain lookups may still be handled by the local network; this mismatch is commonly called a DNS leak. It can expose the domains being queried or cause a content delivery network to return addresses unsuitable for the current exit, leading to slow pages, conflicting region detection, or failed resources.

However, seeing a resolver near your local area does not automatically prove a leak. Public DNS may use anycast routing, and test databases may record only the operator rather than the actual query path. A safer approach is to compare resolver ownership before and after connecting, then confirm it against the client’s DNS settings, the browser’s secure DNS setting, and the routing rules.

Browser secure DNS may bypass the client’s settings

Some browsers send encrypted DNS requests independently. If the client controls only system DNS, those requests may continue to go to the resolver selected by the browser. The system test may look normal while the browser returns unexpected DNS results. Temporarily make the browser follow system settings and test again; if the results align, review the browser configuration instead of repeatedly changing nodes.

Split DNS requires checking domain rules too

A mature rule-based setup may use different resolution paths for direct and proxied domains. That is intentional DNS splitting, not necessarily a leak. The test is whether domains that need international routes use the corresponding resolver, direct domains keep local resolution, and the resulting connections follow the same rules. If a domain lookup uses the proxy but the connection is classified as direct, the paths can still diverge.

DNS conclusion: DNS verification is complete only when the exit path is correct, the resolution path matches the client configuration, and proxied and direct domains each match their expected rules. Checking the exit IP alone cannot rule out a DNS-path problem.

Step 3: Test the browser, terminal, and individual apps separately

Apps do not all read network settings the same way. Browsers usually inherit the system proxy but can be overridden by extensions; command-line tools may read only environment variables; games, meeting apps, and sync tools may open UDP connections directly; some programs use their own DNS or bypass the system proxy. Therefore, “the browser works” does not mean “every app works.”

Define the goal before testing: must an app use the route throughout, or should only certain domains be split-routed? Keep other variables unchanged and perform one observable network action in the app. Use the client connection log, rule-hit records, and exit test together. Focus on whether requests matched proxy, direct, block, or fallback rules; do not mistake an “established local port” for a successful remote request.

System proxy and TUN cover different traffic

A system proxy generally suits HTTP and HTTPS apps that follow the operating system’s proxy interface. It is clear and requires fewer changes, but it does not guarantee coverage for every program. TUN uses a virtual network interface to handle a broader range of IP traffic and suits unified routing; it also depends more heavily on system permissions, the routing table, and DNS configuration. Neither is universally better—choose based on the apps that need coverage.

Per-app mode requires checking exclusion lists

Mobile platforms and some desktop clients support per-app selection. If the target program is not on the coverage list or has been added to the exclusion list, it will continue using a direct connection. Conversely, routing a service that should stay direct through the proxy can cause access failures. Confirm that the app identifier matches the installed version, then fully quit and reopen the app after changes so it does not reuse an old connection.

Subject Common coverage method What to verify Common mismatch
Browser System proxy, extension, or TUN Exit, browser DNS, and extension priority Extension overrides the system proxy
Command-line tool Environment variables, explicit proxy, or TUN Whether the process reads proxy settings Browser uses the route but terminal connects directly
Desktop app System proxy, in-app proxy, or TUN Protocol type and rule match App bypasses the system proxy
Mobile app System VPN interface and per-app policy Coverage list, background limits, and old connections Target app is on the exclusion list

Common reasons traffic does not follow the route despite appearing connected

A successful client connection only means that a session may have been established between the local device and the entry node. Subsequent traffic still depends on the subscription configuration, node parameters, routing rules, DNS, system permissions, and the app’s own settings. Any mismatch can produce a normal status with an incorrect traffic path. Start with the smallest and easiest-to-verify scope.

The subscription was imported, but the active configuration is outdated

A subscription link retrieves node and rule settings. Successful import does not guarantee that a later refresh completed; the client may still use old nodes, certificate details, or rules. Update the subscription manually first, then confirm that the selected configuration came from the refreshed group. If the update fails, read the error instead of repeatedly importing the same subscription and creating several similarly named configurations.

The protocol connects, but transport parameters do not match

Shadowsocks, VMess, Trojan, VLESS, Hysteria2, and TUIC are different proxy protocols or transport schemes, so their fields cannot be mixed. Shadowsocks requires matching encryption and credentials; VMess, Trojan, and VLESS may also depend on transport, TLS, and the server name; Hysteria2 and TUIC are mainly UDP-based, so networks that restrict UDP may behave differently from TCP-based solutions.

The protocol name itself says nothing about link quality. Check whether the client supports the protocol, whether the configuration is complete, whether the handshake succeeds, and whether actual requests enter the intended outbound. If the issue began after updating the client, also confirm that the configuration format was migrated correctly.

Rule priority sent the test request direct

Split tunneling usually matches domain, address, process, or region rules from specific to fallback. If an earlier direct rule covers too much, later proxy rules never run. Conversely, an overly broad proxy rule may capture services that should remain direct. In the logs, find the rule that actually matched the target request rather than merely confirming that a proxy rule exists in the rule file.

Relay, direct connections, and IEPL are being treated as the same layer

A direct connection typically connects the client straight to the remote node; a relay route first connects to a nearby entry and then forwards traffic to the target exit; IEPL describes a dedicated transport path between the entry and remote side. These are carriage paths, not the same as application-layer proxy protocols such as Shadowsocks or VLESS. When testing, check the public exit and matched rule; do not assume traffic reached the target exit merely because the configuration name contains “relay” or “dedicated line.”

What to check on each platform

On Windows, first distinguish the system proxy from TUN. When the system proxy works, apps that follow system settings will usually change exits, but some programs may still connect directly. If TUN behaves unexpectedly, check the virtual network interface, routing conflicts, and permissions. If other network components are running on the device, quit them temporarily and rebuild the baseline.

macOS clients often use a network extension or system proxy to handle traffic. If network-extension permission was not confirmed on first use, the client may retain its configuration while failing to take over traffic fully. Confirm that the relevant configuration is enabled in Network settings, then test the browser and terminal separately. Closing the window alone usually does not quit a background network extension.

Android and iOS mainly use the system VPN interface. Check the per-app list, system background limits, auto-connect policy, and whether an app reused a session established before connecting. If only one app shows the old result after switching routes, fully terminate and reopen it before assuming the node has failed.

Linux environments vary widely. Desktop apps may read the system proxy, terminal programs may depend on environment variables, and service processes may have their own runtime environment. With TUN enabled, also check the routing table, DNS management service, and permissions. When testing a background task, use the user and environment under which that task actually runs; an interactive terminal result does not automatically represent the service process.

Complete the final checks in a fixed order

A reproducible troubleshooting process should answer three questions: which exit external services see, which path resolves the domain, and which rule the target app ultimately matched. Without evidence for any one of these, you can say only that it may be connected—not that it is fully working.

  1. Disconnect the route and record the exit and DNS baseline.
  2. Update the subscription and confirm the active node, protocol, and configuration group.
  3. Connect to the route and compare the public exit through the same test site.
  4. Check system DNS, browser secure DNS, and split DNS.
  5. Test the browser, terminal, and target app separately.
  6. Review rule matches and outbound results in the client log.
  7. Disconnect and test again to confirm the network returns to its original baseline.
Final assessment: You can confirm that the relevant traffic truly uses the selected route only when the exit changes as expected, the DNS path matches the configuration, the target app matches the correct routing rule, and disconnecting restores the baseline. If only the client status changes, continue checking the coverage mode, system permissions, and app-level configuration.