VPN connected but not working? A complete guide to checking your exit IP, DNS, and per-app routing

When a VPN connects but does not work, “the node is broken” is rarely a complete explanation. The connected status only shows that the client established some kind of session. Whether your browser, download tool, or other apps actually send traffic through that route also depends on proxy mode, system routing, DNS settings, split-tunneling rules, and each app’s own network implementation. The most reliable approach is to record a baseline while disconnected, then verify the exit IP, DNS, and individual apps separately.

This guide follows a practical troubleshooting sequence. Keep the result after each step, and avoid changing several settings at once. Otherwise, if the connection suddenly works, it will be difficult to tell which change helped, and a temporary network fluctuation may look like a permanent fix.

First, distinguish connected from working

Different clients do not all use “connected” to mean the same thing. In system tunnel mode, it may mean that a virtual network interface was created, routing rules were added, and the client completed a handshake with the remote server. In system proxy mode, it may only mean that a local proxy port is listening. A browser extension usually controls requests inside the browser only; it does not take over other programs.

That is why troubleshooting should separate the connection into layers: whether the client can communicate with the server, whether the operating system sends target traffic to the client, whether the client selects a node according to its rules, and whether the remote side can reach the target service. Success at one layer does not guarantee success at the next.

Establish a network baseline while disconnected

Before checking the route, fully disconnect the client and confirm that the system proxy and tunnel interface have been removed. Then open a new private browser window and visit this site’s IP check page. Record the current exit region and network provider. The goal is not to save an exact address, but to understand how external services identify this network while disconnected.

Next, observe how the target site behaves while disconnected: does the connection fail completely, does the page open with the wrong account region, or do only images, video, or login APIs fail? Each symptom points to a different troubleshooting path. A complete timeout is more consistent with a routing or handshake issue. If the main page works but some resources fail, check split tunneling, DNS, or separate resource domains. If the account region does not change, also check cached data, the login session, and region information stored by the service.

• ✅ Fully exit the client before recording the original exit IP; do not rely only on clicking Disconnect.
• ✅ Use a new private window to reduce the effect of old cache, site storage, and existing sessions.
• ✅ Record the target service’s specific error instead of writing only “it won’t open.”
• ✅ Keep the current network unchanged so you can compare the exit IP and DNS later.
• ❌ Do not reinstall the client as your first step. Reinstallation can remove rules and logs that would help locate the problem.

If the exit region still shows the region associated with the previous node after disconnecting, the browser may still be using a separate extension, another proxy process may be active, or the old connection may not have been released. Clear these variables before establishing the baseline. Without a reliable baseline, there is no sound reference for deciding whether the IP changed.

Check the exit IP: confirm where the request goes

After establishing the baseline, connect to the node you plan to use, wait for the client status to stabilize, then open a new private window and visit the IP check page. If the exit region and network provider change reasonably compared with the baseline, this test request went through a new exit. That proves only the path used by the check page; it does not show that every app has been taken over.

If the exit details do not change at all, first check the client’s mode. In rule mode, commonly used local sites may be classified as direct, and the IP check page may happen to match a direct rule. Global mode usually sends more requests through the proxy, but it can still be affected by system permissions, a failed virtual-interface setup, or conflicts with other network tools. Browser-extension mode applies only to the browser controlled by the extension; other browsers and apps on the system may still connect directly.

Also consider connection reuse. A browser may keep long-lived connections opened before disconnection, and apps may maintain their own connection pools. After switching nodes, refreshing an old page does not necessarily test a newly created connection. Closing the relevant tabs or app and opening it again is more reliable than repeatedly refreshing when checking for a path change.

Check for DNS leaks: identify who resolves the domain

Before opening a website, the device resolves its domain to a reachable address. If web traffic uses the route but DNS queries still go directly to the local network’s resolver, the target domain may remain visible on the local resolution path, or the site may fail because the result does not match the exit region. This is commonly referred to as a DNS leak.

For the test, first record the resolver network shown while disconnected, then connect to the node and test again. If the result still follows the local network’s resolution path exactly, check whether the client has enabled remote DNS, encrypted DNS, or DNS resolution inside the tunnel. If the resolver changes in a way that matches the client configuration, the DNS path changed with the connection as expected.

However, seeing a public DNS service does not by itself prove a leak. Some clients intentionally use public encrypted DNS and send queries through the route. A system or browser may also have its own secure DNS setting that bypasses the resolver selected by the client. The key questions are whether queries enter the intended controlled path and whether the results align with the routing policy—not whether the resolver name matches the node brand.

WebRTC tests in the browser also require careful interpretation. Seeing local interface information on a page does not mean public traffic necessarily bypasses the route. Conversely, if WebRTC exposes no additional address, that cannot replace exit IP and DNS tests. Treat it as a supplementary check, not the sole conclusion.

• ✅ Compare the DNS resolution path before and after connecting, rather than checking only the post-connection result.
• ✅ Check whether the browser has its own secure DNS enabled and whether that setting fits the current setup.
• ✅ Check for conflicts between the client’s remote, rule-based, and local DNS options.
• ✅ After changing DNS settings, close old pages and trigger a new domain lookup.
• ❌ Do not judge a leak solely by the resolver’s region; public DNS services may use distributed entry points.

Per-app testing: confirm actual traffic one app at a time

Once the exit IP and DNS look right, return to the apps you actually need to use. Apps handle system proxies differently: browsers can usually read system proxy settings; some desktop programs use only their own settings; command-line tools may need separate environment configuration; and games, voice apps, and apps using specific transport methods depend more heavily on whether tunnel mode fully takes over their traffic.

For each app, exit it completely, connect the route, and launch it again. Check the client’s connection log, matched rules, or traffic activity to confirm that a new request appears when the app accesses the target domain. If the client can show connections by process, verify the process directly. If it cannot, keep other apps closed and use request timing and target domains as supporting evidence.

Browser testing should not stop at the home page. Modern services often place login, static assets, media, APIs, and downloads on different domains. Matching a proxy rule on the main page does not mean the media domain matches the same rule. Common symptoms include a page that opens while login loops, images stay blank, video will not play, or downloads fail immediately. Check the client log for direct and proxied matches, then adjust the relevant domain rules.

Per-app proxying can also leave an app excluded. Bypass lists, direct LAN access, process-based routing, and system power-saving policies can all keep a program off the route. During troubleshooting, simplify the rules temporarily and use a clearer takeover mode. Once the app works, restore fine-grained routing step by step.

Protocols and routes are not the same thing

When troubleshooting, people often compare Shadowsocks, VMess, Trojan, VLESS, Hysteria2, TUIC, and “direct, relay, and IEPL dedicated routes” as if they were the same category. They describe different layers. The first group mainly defines how data is packaged and transported between the client and server. The second focuses on the network path traffic takes from local access to the exit.

A successful protocol handshake shows only that the client can communicate with the server using that protocol. Whether system traffic enters that protocol connection still depends on client mode and routing rules. Conversely, an IEPL dedicated route or relay route describes the access and transport path; it does not automatically fix incorrect DNS, missing domains in split-tunneling rules, or apps that the proxy does not control.

A direct route usually connects the device straight to a remote entry point, with a relatively simple path, but performance is affected by public routing between the local network and the remote endpoint. A relay route first reaches a nearby access point, then the service network forwards traffic to the exit, which can help adjust some cross-region paths. An IEPL dedicated route emphasizes a specialized transport path after access; the client may still connect to the entry point using a common protocol.

In practice, change the protocol to address handshake failures, transport compatibility, or connection issues in a specific network environment. Change the route to address path quality, exit region, or reachability. Change proxy mode when an app is not entering the route. Test these separately instead of reducing everything to a vague judgment about whether a node is good.

A subscription link is also only a configuration entry point. The client uses it to obtain node names, server parameters, and rule information. A successful import does not mean a node is connected, much less that app traffic is working through it. Treat the subscription link like a credential and do not post it on public pages or share it in screenshots or logs. When seeking help, provide redacted error details instead.

Platform-specific clients: troubleshooting differences

Windows and macOS

Desktop systems commonly use either system proxy mode or a virtual tunnel. System proxy mode depends on apps actively reading the proxy settings, so programs that do not may connect directly. A virtual tunnel takes over more traffic through a system network interface but requires the relevant permissions. If the client reports a successful connection while no app shows a changed exit, check whether the virtual interface exists, whether another network tool has replaced the default route, and whether the system proxy was actually written after connection.

Enterprise network tools, security software, and other proxy clients may also modify routing or proxy settings at the same time. You do not need to uninstall everything at once, but temporarily exit other tools that can control networking, keep only the current client active, and reconnect.

Android

Android clients usually use the system-provided VPN interface to take over traffic, but they may be configured to bypass certain apps or proxy only selected apps. If the browser works while one app always connects directly, check per-app rules first. Data-saving settings, battery restrictions, and background policies can also terminate the connection service, leaving the interface showing a status even though the tunnel is no longer usable.

iOS and iPadOS

Clients on these devices also depend on system network extensions. After switching networks, an old tunnel may need to be rebuilt. The browser’s separate privacy or DNS features can also change what you observe. If the issue occurs only on one network, record that network’s baseline, exit, and DNS separately instead of applying conclusions from another network.

Linux

Linux desktop environments, network managers, and command-line sessions may use different proxy sources. Enabling a system proxy in the graphical interface does not necessarily affect terminal programs. Tunnel mode also involves the routing table, DNS management services, and permissions. If the browser works but a command-line tool does not, check whether the tool supports the current proxy type, or compare it with a mode that can take over system routing.

Common causes of a false connection

When a VPN “looks connected,” the displayed status often differs from the real data path. The situations below are easy to mistake for a remote failure, but most can be located through the layered checks above.

• ✅ The client completed its handshake, but the current mode only configured a system proxy that the target app does not read.
• ✅ Routing rules classify the IP check page or target resource domain as direct, so some requests bypass the node.
• ✅ The browser retained an old connection or session, so it still shows content from the previous region after the route changes.
• ✅ DNS is managed separately by the browser, system, and client, so its resolution path differs from the web traffic path.
• ✅ The subscription updates successfully, but the specific node fails its handshake or an old configuration has not refreshed.
• ✅ After the device switches networks, the client interface does not immediately reflect that the tunnel was interrupted.
• ✅ Another proxy tool modifies the system proxy or routes at the same time, and its later configuration overwrites the current client.
• ✅ The target service uses multiple domains: the main site matches the proxy, while API, media, or login domains match direct routing.
• ❌ Success was judged only from the status icon, without retesting the exit IP, DNS, and app requests.

If connection protection is enabled, also test what happens after disconnecting the node. When protection is active, the client may block network requests according to its configuration instead of falling back to a direct connection. Without understanding this behavior, it is easy to mistake “protection is blocking traffic” for a broken system network. Conversely, if you want to prevent direct traffic after a disconnect, confirm that the protection scope covers the target app and test it under controlled conditions.

Final verification and record-keeping

After making changes, repeat the process from the baseline instead of checking only the item you just fixed. Disconnect the client and confirm the original exit, connect to the fixed node and check the exit IP, then check the DNS path. Finally, restart the target app and see whether its actual requests match the expected rules. This closed loop prevents cases where the browser works but other apps still connect directly.

Your troubleshooting notes should identify the platform, client mode, node name, target app, exit change, DNS change, and exact error. Redact subscription links, authentication details, and complete server addresses before sharing. Clear notes such as “the connection times out” or “downloads are slow” help support staff determine whether the issue is local configuration, the route, or the target service.

• ✅ The original exit can be identified while disconnected, and the exit changes as expected after connecting.
• ✅ DNS queries follow the expected path configured by the client and are not accidentally overridden by an independent setting.
• ✅ The browser, target desktop app, and background requests have each been tested separately.
• ✅ The rules show target and resource domains matching the expected proxy or direct-routing policy.
• ✅ After switching networks or waking the device, the tunnel status and exit are checked again.
• ✅ Subscription links, authentication details, and complete connection parameters are redacted before troubleshooting information is shared.
• ❌ Do not treat one successful page load as proof of long-term stability or that every app is working through the route.

This method also applies when one website opens but another does not, the browser works while a client app fails, or the region does not change after switching routes. The goal is not to find one universal test button, but to break the connection into observable stages: baseline, exit, resolution, rules, and app. Checking each layer makes most false-connection symptoms easy to explain.