VPN connected but not working: How to Check Your Exit IP and DNS

When a VPN is connected but not working, the most reliable test is not the green icon in the client. Check where traffic actually leaves the device, which resolver handles domain lookups, and whether the target app follows the current route. A connection indicator only shows that the client completed part of a handshake or opened a local proxy port; it does not prove that browsers, download tools, and other apps use the intended route.

Do not change the route, protocol, DNS, and routing rules at the same time. If the issue temporarily disappears, you will not know which setting helped. First record the direct-connection state, then connect the route and check the exit IP, DNS, and target app in order. Each step should answer one question.

First distinguish “connected” from “traffic is being handled”

“Connection successful” does not mean exactly the same thing in every client. With a system-level tunnel, a client usually creates a virtual network interface and adds routes to the operating system. With a system proxy, it may only open a local HTTP, SOCKS, or mixed proxy port and point the system proxy to it. Some clients start only a local core; whether app traffic is handled then depends on browser settings, routing mode, or separate configuration.

The same device can therefore have a browser using the proxy while terminal commands connect directly. Most websites may use the route while the LAN, certain domains, or selected apps connect directly according to the rules. This is not necessarily a fault; it may simply reflect the client's configured routing. The key question is whether the result matches the selected mode.

Protocols such as Shadowsocks, VMess, Trojan, VLESS, Hysteria2, and TUIC carry data between the client and the remote node. But a successful protocol connection and system traffic entering the protocol core are two different things. Whatever the protocol, verify the result through routing, proxy settings, DNS, and app behavior. Repeatedly changing protocols usually will not fix a disabled system proxy or an app that bypasses the proxy.

Step 1: Compare the exit IP before and after connecting

Your exit IP is the public address the destination server sees when you visit it. Disconnect the route, open a trusted IP lookup page, and record the country or region, network operator, and address. Then connect to the target route and refresh the same page. If the address and network ownership change and broadly match the route's region, that web request left through the proxy exit.

Before testing, close and reopen the lookup page or use a private browser window so cached results do not mislead you. If the browser has a separate proxy extension, note whether it is enabled. An extension can override the system proxy, making browser results differ from other apps. Use only one traffic-handling method during the test; do not stack the system client with a browser extension.

1. Disconnect the client, close the existing IP lookup page, then open it again and record the direct-connection result.
2. Connect to the route you want to test and wait until the client clearly shows that it is connected.
3. Open the lookup page again instead of relying on text already cached in an old tab.
4. Compare the address, region, and network ownership; do not rely only on the map marker.
5. Check again in another browser or standalone app to see whether the result is consistent.

Map locations are only supporting evidence. IP databases infer locations from registration data, data-center locations, or historical records, so labels may differ. Address changes and network ownership are usually more useful than a map pin when checking the exit. If the selected node is in Japan and the result shows the Japanese data-center network used by that route, the test is broadly on track. If the address is exactly the same as before disconnection, continue checking how the proxy is taking over traffic.

What to check when the exit IP does not change

• ✅ Confirm that the client is not merely starting a local port, but has enabled system proxy or virtual network interface mode.
• ✅ Confirm that the browser is not set to “direct” and that another proxy extension is not overriding the system settings.
• ✅ Check whether the current routing mode sends the IP lookup site through a direct-connection rule.
• ✅ Exit other network proxy tools to prevent multiple clients from competing over the system proxy and default route.
• ❌ Do not judge the result only by refreshing an old page; cached content may not trigger a complete new request.
• ❌ Do not keep changing protocols and nodes one after another; this can hide the actual traffic-handover problem.

If only one browser shows an unchanged exit, check whether it has its own proxy policy. Some browsers follow the system proxy, while some command-line tools do not read it by default; downloaders and games may also create direct network connections. System proxy mode cannot guarantee that every app joins automatically. For full-device handling, use the client's virtual network interface or system tunnel mode and confirm that routes were written successfully.

Step 2: Check where DNS requests go

DNS converts domain names into connectable addresses. Web content using a proxy does not mean domain lookups use the same path. If the system still sends queries to the resolver assigned by the local network, the result may not match the proxy exit's region. With region-aware streaming services, download mirrors, and content delivery networks, this mismatch can cause pages to open while content errors, server selection looks wrong, or loading becomes unstable.

A DNS leak usually means that queries intended, under the current privacy or routing goal, to travel through the tunnel or a specified encrypted resolver are instead sent from the local network interface to another resolver. Finding a local resolver does not prove that all web content connects directly, but it does show that DNS handling is not unified as expected. Continue by checking the client's DNS takeover settings.

The method is similar to checking the exit IP: while disconnected, record the resolver's network ownership; then connect to the route and test again. Focus on which network handled the request, whether the region conflicts with the intended exit, and whether local-network resolvers still appear in repeated tests. Do not rely only on the returned website address, since large sites may respond differently based on region, cache, and load.

nslookup example.com

# View the system's current DNS configuration
# Windows
ipconfig /all

# macOS
scutil --dns

# Common Linux environments
resolvectl status

These commands answer different questions. nslookup can show the resolver used for the current lookup and its result; system networking commands show which DNS servers are configured in the operating system. Neither alone proves that the browser uses the same resolver. Modern browsers may enable secure DNS, sending lookups separately over HTTPS and bypassing the operating system settings. When browser and system results differ, check the browser's secure DNS option.

Common causes of unusual DNS results

The client may proxy TCP or UDP application traffic without taking over system DNS. Virtual network interface mode may be active while DNS routes still point to the original interface. The browser may use its own encrypted DNS, and routing rules may send local-domain lookups directly while forwarding other domains to a remote resolver. The last case is common by design; a different resolver alone does not prove a fault. Check the matching rule for the target domain.

If the result does not change after modifying DNS, the system, browser, or local proxy core may still have cached data. Restart the browser first, then disconnect and reconnect the client. If the result still does not update, use the operating system's DNS cache-clearing function. Do not treat cache clearing as a long-term fix; if it is required after every connection, investigate DNS takeover and routing settings in the client.

Step 3: Verify each browser and app

Even after confirming the browser's exit and DNS, you cannot assume that every program is working through the route. App traffic depends on whether it follows the system proxy, is handled by a virtual network interface, uses a particular transport protocol, and matches the routing rules. Browsers, terminals, game platforms, video apps, and download tools may produce different results.

Create a simple verification record with the app name, expected path, actual exit, DNS behavior, and access result. Test the most important apps first; do not use one working webpage as proof for the entire device. If one app fails while others work, the cause is usually its proxy settings, protocol support, or routing rules rather than a complete node failure.

System proxy mode is mainly for apps that honor proxy settings. Virtual network interface mode handles traffic at a broader network layer and is generally better for programs without proxy support, but it remains subject to route priority, exclusions, and the client's implementation. Windows, macOS, Android, iOS, and Linux use different network stacks and permission models, so the available system proxy, virtual interface, per-app routing, and DNS takeover features may differ between clients even with the same subscription.

A subscription link only supplies nodes and related configuration to the client. Successful import means the client obtained the configuration; it does not mean the operating system has authorized a tunnel or that the routing rules fit the current platform. After the first import, select a node, enable the correct mode, and handle any network-configuration permission prompt from the system. If the subscription has updated but the client still uses an old node, refresh the subscription in the client and select a route again.

How global, rule-based, and direct modes affect results

Global mode usually sends more destinations through the proxy, although LAN traffic, the client's own communications, and essential system services may still be excluded. Rule mode chooses proxy or direct access by domain, address, region, or process, so it most often looks “partly active.” Direct mode keeps the node configuration without forwarding ordinary traffic and is useful for temporarily disabling the proxy. If selected by mistake, the client may still be running while the exit remains unchanged.

Rules also have an order of precedence. If a domain first matches a direct rule, later proxy rules will not process it. Apps that resolve a domain and then connect directly to its address may bypass rules written only for domain names. For comparison, temporarily switch to a broader mode: if the app works afterward, the node is probably usable and the original routing rules deserve attention. Restore rule mode after the comparison and correct the matching entries.

Common reasons a connection looks active but does not carry proxied traffic

The client only started a local proxy port

Some desktop clients let the core run independently. The node connection is established and a usable local proxy port exists, but the system proxy switch is off, so ordinary browsers and apps still connect directly. The fix is not to change nodes; enable the system proxy, enter the local proxy address in the app, or switch to virtual network interface mode.

Multiple network tools are changing routes

When two clients run at once, the one started later may overwrite the system proxy, while virtual-interface routes may compete by priority. Both may appear connected even though traffic is actually taking the other path. Exit other proxies, filters, and network debugging tools, keep only the current client, and compare the exit again.

The browser cache and persistent connections were not rebuilt

After switching routes, already-open pages may reuse existing connections, and DNS results may remain cached. A newly opened lookup page may show the new exit while an old tab retains the previous state. Close the relevant tab or browser and test again; this is more reliable than pressing refresh repeatedly. Fully quit and reopen desktop apps that keep long-lived connections.

IPv4 and IPv6 use different paths

A network may provide both IPv4 and IPv6 while the client handles only one. If the destination prefers the unmanaged address family, the exit will not match expectations. Check which address types the lookup page reports and whether the client explicitly supports and handles the address families enabled on the system. Do not simply disable one protocol as a permanent solution; correct the client and routing configuration instead.

A rule sends the target domain directly

In rule mode, ad blocking, LAN exclusions, regional routing, and custom rules can all affect the result. The IP lookup site itself may be in a direct-connection set, making the test page show the original exit while other targets use the proxy. Cross-check with another lookup method and review rule-match details in the client's connection log. Use the log to confirm domain matching and outbound selection, not just the line showing a successful handshake.

System time or certificate validation is incorrect

Configurations such as Trojan and VLESS with TLS depend on valid certificate checks; other TLS- or QUIC-based transports can also be affected by system time. If clock drift causes the handshake to fail, the client will usually log certificate, timeout, or handshake errors rather than settle into a stable transferable state. Restore automatic time synchronization first, then check the server name, transport parameters, and subscription configuration.

A repeatable final verification checklist

After troubleshooting each item, run acceptance checks once more in a fixed order. This prevents omissions and makes the process reusable after changing networks, clients, or routes. Recording actual results at every step is more useful for diagnosis than saving a single “connected” screenshot.

• ✅ Disconnect the route and record the baseline exit IP, network ownership, and DNS resolution path.
• ✅ Connect to the target route and confirm whether the client uses system proxy, virtual network interface, or local-port mode.
• ✅ Reopen the lookup page and confirm that the test request's exit changed as expected.
• ✅ Check the DNS resolution path against the browser's secure DNS and system settings.
• ✅ Test the browser, terminal, and target app separately; do not use one webpage to represent all traffic.
• ✅ Review routing-rule matches and confirm that the problem target was not assigned to a direct route by mistake.
• ✅ Check whether IPv4 and IPv6 are handled by the same traffic-taking-over policy.
• ✅ Retest after changing only one variable, and record the differences before and after.
• ❌ Do not treat the client icon, node name, or successful subscription import as final evidence.
• ❌ Do not change the node, protocol, DNS, and client together before the cause is clear.

If the exit IP has changed and the DNS path matches expectations but a specific app still fails, narrow the investigation to that app: check system proxy support, UDP use, separate proxy settings, and routing-rule matches. If no app shows a changed exit, return to the client's traffic-handling mode, system permissions, and route installation. If the exit changes repeatedly or the connection drops often, review timeout, handshake, and network-switching records in the client log.

IEPL dedicated routes, relay routes, and direct public-network connections describe the transport path between nodes or between the user and the exit. They do not change the verification principles above. IEPL generally emphasizes dedicated cross-border transport; a relay route forwards traffic from an intermediate entry point to the exit; a direct public-network route connects to the remote node directly. Whatever the route structure, the destination ultimately sees the exit node's address. Confirm that the device sends traffic into that route through exit, DNS, and app tests.