VPN connected but not working? Check your exit IP, DNS, and per-app routing

A VPN connection that appears active but does not work is usually not caused by a single failure. “Connected” in the client only means that the local client and remote node have established some form of session; it does not mean all traffic from your browser, download tools, and other apps has entered that session. An unmanaged system proxy, missing TUN permission, a split-tunneling rule matching direct access, or the browser resolving DNS on its own can all make the connection status differ from the actual exit path.

A reliable diagnosis cannot rely only on the client icon or on whether a particular website opens. Break network requests into three layers—exit address, name resolution, and the specific app—and observe what changes before and after connecting. The process below does not depend on advertised speed figures; its goal is a repeatable verification workflow.

First, understand what “Connected” actually confirms

Clients do not all define “connection successful” in the same way. When using a system VPN interface or TUN virtual adapter, a client typically creates a virtual network interface, writes routes, and configures DNS. With a system proxy, it may only start a local proxy port and ask the operating system to forward requests from proxy-aware apps. Browser extensions cover a narrower scope and generally handle only requests within that browser that the proxy interface can intercept.

The protocol name therefore cannot answer whether all traffic is being handled. Shadowsocks, VMess, Trojan, and VLESS are commonly used with a system proxy or TUN mode; Hysteria2 and TUIC are known for UDP-based transport, but they still require the client to route app traffic into the tunnel correctly. The protocol defines how data travels between the client and node; system mode and routing rules determine which requests enter that transport path. These are separate layers.

IEPL private routes, relay routes, and direct routes describe how traffic is organized between nodes or between the user and the exit. A direct route generally means the client connects straight to the exit node; a relay route enters through an intermediary before being forwarded to the exit; an IEPL private route emphasizes dedicated transport over a specific cross-border segment. Whatever the route type, the result must still be verified through local routing and app behavior. The route label itself cannot replace an exit-IP test.

Step 1: Check your exit IP and its location

The exit IP is the most direct check. First disconnect the client and open this site’s My IP page in the same browser window. Record the location of your current network exit. Then connect to the target node, refresh the page, and check again. You do not need to memorize the full address; compare whether it changed and whether the country or region after connecting matches the selected exit.

If the exit does not change at all, first check whether the client is using global, rule-based, or direct mode. Global mode usually sends more requests through the proxy; rule-based mode decides where traffic goes based on domains, address ranges, or app rules; direct mode may keep the node session alive without actively proxying ordinary requests. Some clients also allow LAN traffic or specific addresses to bypass the proxy. That can be appropriate, but overly broad rules may also let the test site go direct.

A changed exit does not finish the check. The browser may be using a separate proxy extension while other apps on the system remain on the local network. Conversely, when the system VPN is handling traffic, a browser extension may send requests through a different exit. During testing, reduce the number of proxy layers and avoid running the system client, browser extension, and in-app proxy at the same time.

• ✅ Record the baseline exit location after disconnecting, rather than capturing only the connected result.
• ✅ Refresh the lookup page after connecting to the target node and confirm that the location matches the selected exit.
• ✅ Cross-check in a regular window and a private window to rule out cache or extension differences.
• ✅ Check whether the client is currently in global, rule-based, or direct mode.
• ❌ Do not treat an accessible website as a substitute for comparing exit IPs.
• ❌ Do not draw conclusions while multiple proxy tools are running at once.

Step 2: Check whether DNS resolution follows the expected path

DNS converts domain names into network addresses. Sending a web request through a tunnel does not necessarily mean that DNS resolution uses the same path. If resolution still comes from the local network, an outside observer may be able to see which domains were queried; regional differences in the results may also point requests to unsuitable content nodes. This is often described as a DNS leak, but troubleshooting should distinguish between system DNS, the client’s remote DNS, the browser’s secure DNS, and app-level resolution.

Secure DNS in a browser can bypass the resolver supplied by the operating system and send queries directly to the service configured in the browser. Even if the system-level DNS settings have changed, browser tests may continue to show a different path. Browsers based on Chromium or Firefox commonly offer these options under names such as Secure DNS, encrypted DNS, or DNS over HTTPS. Record whether the feature is enabled instead of assuming that one result must be wrong.

System command-line tools also require careful interpretation. The system may pass a query to a local stub resolver, which then forwards it through a network service; a command showing a local interface address does not prove that recursive resolution occurred on the device. Conversely, the browser may cache an earlier result and fail to trigger a new query immediately after a node switch. A safer approach is to clear relevant browser cache, reopen the target page, and compare the result with DNS handling records in the client log.

If the exit IP has changed but DNS still clearly comes from the local network, first check whether the client offers an option such as “remote resolution” or “proxy DNS,” then see whether routing rules send DNS requests direct. In TUN mode, also confirm that virtual-adapter permissions and DNS takeover were enabled successfully. Do not stack multiple DNS tools casually, because a network filter installed later may overwrite settings written by the client.

Step 3: Test traffic in each app

Exit-IP and DNS tests usually happen in a browser, but the actual problem may affect a game, downloader, terminal tool, or desktop client. A system proxy works only for apps that read system proxy settings, while some apps establish connections directly. TUN mode usually covers more traffic, but exclusions, route priority, and system permissions can still affect it. The final step must therefore return to the app that actually needs the route.

Choose one target app first and close other software that generates substantial network activity. Check whether the app has its own proxy address, whether it offers an option such as “ignore system proxy,” and whether the client’s per-app list marks it for proxying, direct access, or rule-based routing. Then inspect the proxy client’s connection log: launch the target app, make one clear request, and look for the corresponding domain, destination address, or process entry.

No log entry does not necessarily mean the route is faulty. In system proxy mode, the app may never hand its request to the client; in rule-based mode, the request may match a direct rule; or the app may reuse a long-lived connection opened earlier. Fully quit and reopen the target app so it creates a new connection, then test again. For real-time apps that support UDP, also confirm that the client mode and selected protocol allow UDP traffic to be forwarded according to the rules.

1. Choose the app and scenario. Select the software you actually need to check and define whether you are testing sign-in, page loading, file connectivity, or real-time communication.
2. Clear old connections. Fully quit and relaunch the app to avoid reusing a session established before the change.
3. Review per-app settings. Confirm that the app is not excluded, and check whether it follows global rules or uses a separate policy.
4. Compare with the client log. When the app sends a request, check the domain, destination address, protocol type, and final matching rule.
5. Retest with another mode. For diagnosis only, compare global and rule-based modes; restore the required configuration after identifying the cause.

Platform differences can also affect the diagnosis. Windows clients may switch between a system proxy and virtual-adapter mode, while network-filtering software can change route priority. On macOS, using a system network extension requires the relevant system authorization; if permission is denied, the client may start only a local service without taking over traffic globally. Mobile platforms generally build tunnels through the system VPN interface, but battery-saving policies, per-app VPN, and always-on settings can affect background behavior. Do not apply findings from one platform unchanged to another.

Typical “connected but not routed” cases

Another app has overwritten the system proxy

When multiple network tools modify the system proxy at once, the software that writes the settings last usually affects subsequent requests. The client can keep its node session active while the browser reads a different proxy address. The practical fix is to quit other software that changes proxy or network-filter rules, reconnect, and check that the system proxy matches the current client.

TUN or the system network extension lacks permission

The client may log in and connect to a node successfully while virtual-adapter creation fails or the system network extension has not been authorized to run. A local proxy port may work even though global traffic takeover has not completed. Check the client error log and system network permissions; repeatedly importing a subscription will not fix an authorization issue. A subscription link only supplies nodes and configuration to the client and cannot replace operating-system permission.

A routing rule sends the target direct

Rule sets may decide based on domains, destination addresses, regions, or processes. The same service often uses multiple domains: its main page may use the proxy while images, APIs, or sign-in requests match a direct rule. During troubleshooting, identify the specific request in the log instead of focusing only on the main domain in the address bar. If switching temporarily to global mode restores normal behavior, the node session is probably usable and the issue is more likely in the rule layer.

The subscription was updated, but the client still uses the old configuration

After importing a subscription, some clients require a manual update and a new node selection. Identical-looking configuration names do not guarantee that node parameters have been refreshed. If the server configuration changed while the old local entry remains, you may see repeated reconnects or some protocols becoming unavailable. Use the client’s subscription update function, then confirm that the selected entry is the updated one.

The app bypasses the system proxy or reuses an old connection

Downloaders, development tools, and some desktop apps may have their own proxy settings or connect directly. Apps opened before the VPN connection may also retain existing sessions, so the new exit may not apply immediately. Fully quitting and relaunching the app is a low-cost, effective verification step.

A browser extension creates a different exit

A browser proxy extension affects only the browser itself, which can create the impression that the browser works while other apps remain unchanged. If the system client and extension run together, the extension’s rules may determine the final exit. During troubleshooting, keep only one primary proxy path active, then restore other settings gradually.

• ✅ The exit IP changes as expected before and after connecting.
• ✅ The DNS path matches the client and browser configuration.
• ✅ A new request from the target app appears in the client log.
• ✅ The log shows the request matched the expected proxy rule rather than a direct rule.
• ✅ The result remains reproducible after restarting the app.
• ❌ Do not judge whether it works solely by the client color, icon, or connection timer.

How to tell whether the issue is the route, protocol, or local configuration

The key is to change only one variable at a time. Keep the same node and protocol, then compare global and rule-based modes. If global mode changes the exit but rule-based mode does not, inspect the rules first. If neither mode changes the exit, check system takeover permissions and proxy settings. If the exit changes but the target app still fails, check the app’s own proxy, UDP support, and DNS path.

Next, keep the client mode unchanged and compare nodes of the same type. If a direct node fails while a relay node works, the issue may involve the local path to the node. If several nodes establish sessions but none can take over traffic, the problem is more likely local configuration. The path characteristics of an IEPL private route will not automatically fix an overwritten system proxy or an app that bypasses the proxy, so do not attribute every issue to route quality.

Protocol switching should come after checking routing and permissions. Shadowsocks, VMess, Trojan, VLESS, Hysteria2, and TUIC differ in transport mechanisms and client support, but “connected with no change to the exit” is more commonly caused by takeover mode or routing rules. Protocol comparisons become more useful only when logs show a failed handshake, persistent transport interruptions, or a specific network clearly restricting a type of transport.

After verification, keep reproducible records

If you need to describe the issue to technical support, keep the connection time, client platform, selected mode, protocol type, node name, exit location before and after connecting, DNS settings, and relevant log excerpts. If logs contain a subscription link, authentication details, or access tokens, remove sensitive fields before submitting the necessary excerpts.

A useful issue report should answer these questions: Did the client establish a session? Did the exit change? Does DNS match the configuration? Which app is not working? Is there a difference between global and rule-based modes? This quickly separates node connectivity, system takeover, routing rules, and app behavior instead of reducing several distinct issues to “it won’t connect” or “it doesn’t work.”

In everyday use, repeat this process after changing clients, updating system network permissions, or adjusting routing rules. The exit lookup confirms the outer path, the DNS check confirms name resolution, and per-app logs confirm actual service traffic. Together, these provide a more reliable connection assessment than the status bar.