VPN connected but not working? Check your exit IP, check DNS with a complete verification guide

A VPN being connected does not mean you can rely only on the client’s “Connected” status. That status usually means the client completed a handshake with the remote node or started a local proxy port. It does not prove that traffic from your browser, command-line tools, and other apps is using the intended route. Reliable verification requires checking the exit IP, DNS resolution, IPv6 path, and per-app rules in sequence.

Avoid frequently switching nodes, protocols, and system settings while troubleshooting. Change one variable at a time, then repeat the same test. This helps distinguish a node issue from a routing problem or an app bypassing the proxy. The methods below apply to common system VPNs, system proxies, TUN mode, and clients configured with Shadowsocks, VMess, Trojan, VLESS, Hysteria2, or TUIC.

Why “Connected” may still not mean it is working

After the client establishes a connection, it still needs to send traffic through the appropriate tunnel or local proxy port. This involves the system proxy, routing table, virtual network adapter, DNS settings, and the app’s own networking implementation. If any one of these fails to take over, the client may look normal while access results remain unchanged.

Different connection modes cover different types of traffic. A system proxy mainly affects apps that honor system proxy settings. Browsers usually do, but some command-line programs, games, download tools, and software with its own networking stack may ignore them. TUN mode handles a broader range of IP traffic through a virtual network adapter, but it can still be affected by excluded routes, LAN bypasses, split-routing rules, and system permissions.

The protocol name itself does not prove how much traffic is covered. Shadowsocks, VMess, Trojan, VLESS, Hysteria2, and TUIC describe how data is transported between the client and node. Whether app traffic enters that connection is still determined by the local listening port, system proxy, TUN, and routing rules. A successful protocol handshake and full traffic takeover are two different things.

Record a network baseline before connecting

To identify a change, you first need to know the disconnected state. Close the client connection, confirm that the system proxy and TUN have been restored, then record the current exit IP, network provider details, IP type, and approximate region. You can use this site’s IP lookup page to complete the baseline.

Run the baseline test in the same app you plan to verify later. If you are checking a browser, record the result there. If the issue affects a command-line tool, test it separately from the command line. A browser result cannot stand in for other apps because they may use different proxy settings.

• ✅ Disconnect the current connection and confirm that the client no longer controls the system proxy or virtual network adapter.
• ✅ Open the IP lookup page in the target app and record the exit IP, IP type, and region.
• ✅ Close other proxy extensions or parallel clients that could alter the network path.
• ✅ Keep the same network connection throughout testing; do not switch between wired, wireless, or other networks.
• ✅ Reconnect to the target node, then retest with the same app and the same test page.

If the node’s exit still appears after disconnecting, the system proxy, browser extension, virtual network adapter, or a background process may not have been restored. Continuing with connection tests is pointless because the baseline is contaminated by the old configuration. Exit the relevant clients, check the system network settings, and establish the baseline again.

Check the exit IP: confirm where web traffic goes

After recording the baseline, connect to the target node and open the IP lookup page again. To reduce cache interference, reload the page or use a new browser tab. If the exit IP changes from the local network address to the node’s exit and the network ownership matches the selected route, you can confirm that web requests from this browser tab are using the proxy path.

A changed exit IP is the most direct evidence, but it proves only the path used by the current test request. A browser extension may proxy only browser traffic; a system proxy may be read by only some programs; and split-routing rules may send the test site through the node while other domains connect directly. Continue by checking the app where the problem occurs and the target domain.

How to troubleshoot when the exit IP does not change

1. Check whether the client started only a local proxy port without automatically applying the system proxy settings.
2. Confirm that the browser has no separate proxy configured. A separate setting may override the system configuration or point to an old, inactive port.
3. Check the client’s current mode. Rule mode may classify the test domain as direct; for diagnosis, temporarily use a mode with a clearer coverage scope.
4. If you use TUN, check that the virtual network adapter was created successfully and that the client has the system permissions required to modify routes.
5. Review the runtime logs to confirm whether requests matched proxy, direct, or reject rules.

After importing a configuration from a subscription link, the client usually receives node parameters and group rules, but a successful import does not mean the system proxy is enabled. Some clients separate “Update subscription,” “Select node,” “Start local service,” and “Set as system proxy” into independent actions. Confirm each state while troubleshooting instead of repeatedly reimporting the subscription.

Exit IP changes, but the target service still will not open

The question has now narrowed from “Is traffic using the proxy?” to “Is this path suitable for the target request?” Possible causes include abnormal DNS results, restrictions imposed by the target service on the exit network, split routing that sends related subdomains along different paths, or an old browser connection. Do not keep switching protocols yet; check DNS, rule matches, and app logs first.

Check DNS: determine which path resolves domains

Before accessing a website, the system usually resolves its domain name to an IP address. Web connections going through a node does not mean DNS queries take the same path. If DNS is still handled by the local network, results may not match the node’s region, some domains may resolve abnormally, or domain queries may be exposed to the local resolver.

DNS troubleshooting cannot rely only on which server appears in the system interface. Many systems use a local stub resolver, while the client may take over queries, return virtual addresses, or encapsulate queries in the tunnel. A local address shown in the interface does not necessarily indicate a leak; the important evidence is how the client logs handle the query and which side ultimately performs recursive resolution.

Browser and system DNS may differ

Modern browsers can enable their own encrypted DNS. When enabled, the browser’s resolution path may differ from the operating system’s. As a result, command-line lookups may work while the browser still has issues, or the browser may work while other apps continue using the local network resolver. Test them separately instead of using one result to represent the entire system.

You can query a target domain that is not cached from a terminal while watching the client logs. On Windows, nslookup is commonly used; on macOS and Linux, use dig or nslookup. The command output shows the resolution result, while the client logs indicate whether the request was intercepted, forwarded, or sent directly according to the rules.

nslookup example.com

dig example.com

nslookup example.com specified resolver

Replace “specified resolver” on the last line with the address of the server you actually plan to test. Do not treat a public resolver itself as a proxy. DNS only resolves domain names; it does not automatically change the exit used for web connections.

Avoid false conclusions caused by DNS caching

The system, browser, and client may all cache resolution results. If you query the same domain immediately after switching nodes, you may still see the old answer. A more reliable approach is to close the relevant tabs, clear the app’s DNS cache, reconnect, and query again. If you are unfamiliar with the system cache-clearing command, restart the target app instead; do not delete unknown network configuration files.

• ✅ Confirm that the exit IP has changed before checking DNS, so the two issues do not interfere with each other.
• ✅ Test the browser and system command line separately to determine whether only one app is affected.
• ✅ Review the client logs to confirm whether DNS requests matched proxy resolution or direct resolution.
• ✅ Check whether the browser has its own encrypted DNS setting enabled.
• ❌ Do not conclude that a DNS leak has occurred solely because the system interface shows a local stub address.
• ❌ Do not equate successful domain resolution with web traffic having entered the tunnel.

Check IPv6 and per-app routing

Some networks provide both IPv4 and IPv6. A client may take over only one, or choose different paths based on system capabilities. If IPv4 goes through the node while IPv6 remains directly connected, websites that support IPv6 may prefer the path that was not taken over. This can make different websites behave differently in the same browser.

On the IP lookup page, check whether the exposed address is IPv4, IPv6, or both. If only part of the protocol stack is covered, enable the relevant support in the client or adjust the IPv6 policy according to the client documentation. Hiding the result in the browser does not change the underlying route.

Common boundaries of per-app proxying

Per-app features usually determine routing by including or excluding apps. It is easy to confuse “only selected apps use the proxy” with “selected apps bypass the proxy.” After a client update, app paths or process names may also change, causing old rules to stop matching.

Browsers may also launch multiple helper processes. Adding the main program to a rule does not necessarily cover requests handled by system components. TUN mode, by contrast, usually matches network traffic against rules and does not depend entirely on whether an app reads proxy settings, making it useful for software that does not support system proxies. TUN still does not guarantee unconditional global takeover: LAN traffic, reserved addresses, direct domains, and manual exclusions may bypass it.

Use client logs to locate connection-layer issues

If both the exit IP and DNS are unexpected, logs are more useful than repeatedly switching nodes. They can usually distinguish subscription parsing failures, node handshake failures, local port conflicts, certificate or clock problems, route-writing failures, and the rule handling each request. Start reading from the time of the connection attempt to avoid being distracted by older errors.

Shadowsocks, VMess, Trojan, VLESS, Hysteria2, and TUIC use different handshake methods, so their error messages are not identical. The troubleshooting order is similar: confirm the configuration is complete, verify that the node is reachable, confirm that the local listener started successfully, then check whether the target request entered the intended outbound. If the handshake succeeds but the logs show no target request, the problem is more likely local traffic takeover or a split-routing rule than the remote protocol.

When importing a subscription link fails, first check that the link is complete, that the client supports the configuration format included in the subscription, and that the current network is not blocking the update. After a successful import, select a valid node and start the connection. Seeing a node list does not mean a node is being used.

Platform-specific checks

On Windows, check for leftover system proxy settings, virtual network adapter status, and whether the app uses WinHTTP or its own proxy settings. On macOS, verify the proxy configuration for the active network service and confirm that system or network extensions have the required permissions. On Linux, desktop proxy settings and terminal environment variables may be independent; a working browser does not mean terminal commands are using the proxy.

On mobile platforms, traffic is usually carried through a unified system VPN interface, but battery-saving policies, per-app VPN settings, always-on connections, and LAN access settings can still change the result. If the connection stops working after background recovery, reopen the client and check the tunnel status and recent logs instead of relying only on the status-bar icon.

Common cases that look connected but are not

Browser works, but the download tool still uses the local exit

This is usually a system proxy coverage issue. The browser reads the system proxy, while the download tool uses a direct networking stack. Check whether the download tool supports proxies, or use TUN mode to cover this type of traffic, then verify the exit in both apps separately.

The website region does not change after switching nodes

First rule out page caching and reuse of old connections, then check whether rule mode sends the test domain directly. If the logs contain no test request, the browser may not be using the current client. If the logs show that the request used the new node but the geolocation has not updated, prioritize the exit IP and network ownership rather than the region text alone.

The network becomes completely inaccessible after connecting

If a kill switch or similar blocking policy is enabled, a failed node handshake may also block local direct access. This does not mean traffic is secretly connecting directly; it means the protection rule stops allowing traffic while the connection is unavailable. Check the handshake error, local time, network permissions, and node reachability.

Only some domains fail

Check domain split-routing, DNS results, and related subdomains first. A service may use multiple domains, with its main site and API requests matching different rules. Adding only the main domain to a proxy list does not ensure that all resources use the same path. Rule-match records in the logs can usually show exactly where the paths diverge.

Direct, standard relay, and IEPL dedicated routes produce different results

Direct access means the device connects to the remote node without an intermediate relay, so the path depends on public-network routing. A standard relay connects to an entry point first and then forwards traffic to the exit. An IEPL dedicated route generally carries traffic between the entry and exit over a private link, but the paths from the user to the entry and from the exit to the target service remain part of the full route. Route type can affect stability, but it does not replace local proxy and DNS checks. Even with a dedicated route, the exit will not change if the local app has not entered the tunnel.

A repeatable verification sequence

A complete investigation does not require changing many settings at once. The sequence below starts with the easiest symptoms to observe and gradually moves into the system and client internals. Record the result after each step; when you find an anomaly, address it at that layer instead of changing later protocol parameters prematurely.

1. Disconnect and record the target app’s exit IP, IP type, and network ownership to establish a baseline.
2. Connect to the target node, retest the exit in the same app, and confirm whether the request changed paths.
3. Check DNS separately in the browser and with system tools, using the client logs to determine how resolution is handled.
4. Check that both IPv4 and IPv6 are taken over as expected to prevent path separation in a dual-stack environment.
5. Repeat the test in the app where the problem actually occurs and confirm the coverage of the system proxy, TUN, or in-app proxy.
6. Review rule matches and outbound logs to distinguish direct, proxy, reject, and resolution errors.
7. Only then switch nodes or protocols, keeping all other conditions unchanged so you can identify the source of any difference.

If the problem persists, organize the connection time, platform, connection mode, protocol type, error logs, and completed checks in the client, then continue troubleshooting through the site’s FAQ or support channel. Clearly stating “which app, which domain, whether the exit changed, and how DNS was handled” makes it easier to identify the failing layer than simply saying “it won’t connect.”