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

VPN verification cannot rely only on the client’s “Connected” status. This usually means the client has completed a handshake with the remote server or started a local proxy port; it does not by itself 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 path, IPv4 and IPv6, and the actual network path used by different apps.

The most useful approach is to record a baseline before connecting, then connect to the route and repeat the same tests. Opening just one IP lookup page is often insufficient because browser caches, split-tunneling rules, system proxy settings, and app-specific network stacks can produce different results. The workflow below is reproducible and helps pinpoint the layer where a problem occurs.

Define “working” first: don’t rely on the connection icon

“Working” includes several independent layers: the tunnel or proxy session is established; the target app sends traffic to the client; routing or proxy rules select the expected route; DNS queries follow the configured path; and the exit address matches the selected region or server. A mismatch at any layer can make the client look normal while websites still use the local network.

Verification should not aim for a single “pass” icon. Instead, collect evidence that supports the same conclusion. The exit IP shows where the request entered the public internet; a DNS test shows who resolved the domain; and app-by-app testing shows which programs actually matched the rules. Together, these results distinguish route failures from missed split-tunneling rules and app configuration errors.

Compare the exit IP: confirm where requests leave

The exit IP is the most straightforward verification point. While disconnected, open a trusted IP lookup tool and record the public address, network owner, and approximate region. Close the page, connect to the target route, and run the lookup again. You can also use the site’s network test page for comparison. An unchanged address does not always prove failure, but it is a strong signal to inspect split-tunneling rules, system proxy settings, and the client mode.

Avoid simply refreshing an old results page. Some sites may be cached, and detection scripts may not send a new network request. A safer approach is to open a private window or use another browser without a separate proxy configuration. If the two browsers show different exits, the issue is usually not the route itself but a browser extension, proxy setting, or app-specific routing rule.

• ✅ Disconnect and record the current exit address and network owner.
• ✅ Connect to the target route, close the old test page, and run the lookup again.
• ✅ Check whether the address changed and whether the region matches the selected node.
• ✅ Cross-check with another browser or a command-line request.
• ❌ Do not infer the exit location from webpage language, time zone, or search results alone.

Website language and location results may come from cookies, account details, browser language, system time zone, or site-side caching; they are not the same as IP geolocation. IP databases can also update slowly, so a slightly inaccurate city and a completely unchanged exit are different issues. Focus on the address range, network owner, and whether the country or region broadly matches expectations.

From the command line, you can request a public IP echo service and compare the result with your browser. Whether a command-line tool follows the system proxy depends on the operating system, environment variables, and the software itself. This makes it useful for determining whether the setup is a full tunnel or only covers apps that support the system proxy.

curl https://example-ip-check.invalid
curl -4 https://example-ip-check.invalid
curl -6 https://example-ip-check.invalid

The domain above is only used to illustrate command structure; replace it with a trusted IP echo service for actual testing. Testing IPv4 and IPv6 separately helps reveal split paths on dual-stack networks, not determine which protocol is faster.

Check the DNS path: identify DNS requests that take a different route

Before connecting to a domain, the system usually resolves its name to an address. If web traffic uses the target route while DNS queries still go to the local network’s default resolver, a test may show that the exit IP changed even though the DNS resolver still belongs to the original network. This is commonly called a DNS leak. It does not necessarily mean the website content bypassed the route, but it does show that DNS and web connections are not following the same expected path.

Use a DNS test tool that sends queries for multiple random subdomains. Random names reduce interference from operating-system, browser, and local caches. Do not focus only on the resolver’s reported city, since public DNS services may use nearby routing. Pay more attention to whether the provider matches your configuration and whether the results change reasonably between disconnected and connected states.

How to troubleshoot unexpected DNS results

1. Clear the browser DNS cache and system resolver cache, then run the random-domain test again.
2. Check whether the client has enabled remote DNS, virtual adapter capture, or DNS hijacking features.
3. Confirm that split-tunneling rules are not proxying web connections while leaving DNS requests on the direct path.
4. Check whether the browser has its own encrypted DNS enabled, and test it separately from the system configuration.
5. Test again on another network to rule out forced DNS rewriting by the current router.

The proxy protocol and DNS handling are separate issues. Shadowsocks, VMess, Trojan, VLESS, Hysteria2, and TUIC can all carry different forms of proxy traffic, but whether resolution occurs locally or remotely depends on the client, operating mode, and rules. The protocol name alone cannot prove that DNS uses a remote resolver.

In rule mode, clients commonly choose direct or proxied connections based on the domain. If the domain is resolved locally before the rule is evaluated, the record may still be exposed to the local DNS service. If the client captures DNS and resolves it remotely, domain matching and the subsequent connection can follow one policy. Terminology varies by client, so check its documentation for DNS, sniffing, virtual adapters, and rule modes instead of copying settings mechanically from another platform.

Test IPv4 and IPv6 separately: rule out dual-stack split paths

Modern networks may provide both IPv4 and IPv6. Some clients capture only IPv4, while the system prefers IPv6 for dual-stack websites. A test page may then alternate between the route’s exit and the local network. This is often mistaken for an unstable node, when the real cause is that the two address protocols use different routes.

Test the IPv4 and IPv6 exits separately. If IPv4 uses the target route but IPv6 still shows the local network, check whether the client supports IPv6 capture, whether the virtual adapter has the required route, and whether the rules cover IPv6. If the service or client does not handle IPv6, adjust system network settings only after understanding the impact. The safer option is a mode that fully captures dual-stack traffic.

Disabling IPv6 is not a universal fix. It may temporarily remove a split path, but it can also affect local network environments that rely on IPv6. During troubleshooting, test IPv6 separately to define the issue. For a long-term setup, let the client handle dual-stack traffic correctly or explicitly prevent uncaptured traffic from leaving the device.

Test apps individually: a working browser does not mean the whole system is covered

System proxy mode generally affects software that actively reads the system proxy settings. Browsers often follow them, but some games, command-line programs, download tools, and apps with their own network stacks may connect directly. TUN or virtual-adapter mode is closer to system-level route capture, but exclusions, LAN bypasses, and app-specific rules can still affect coverage.

Test several app categories separately: open an exit lookup page in a browser; request an echo service from the command line; have the target app access its own service; and check connectivity in an app that supports UDP. If only the browser works, first inspect the system proxy’s coverage. If the browser and command line work but one app does not, check that app’s proxy settings, bypass list, and client process rules.

Common differences across platforms

• Windows: The system proxy and virtual adapter are separate paths. Some programs do not read the system proxy and require TUN mode or their own proxy configuration.
• macOS: Different network services have separate settings. After switching between Wi-Fi and Ethernet, confirm that the proxy and virtual interface still apply to the active service.
• iOS: Clients usually capture traffic through a system VPN extension, but on-demand connections, per-app policies, and a paused client can change the actual path.
• Android: System VPN permission, always-on settings, battery restrictions, and the list of allowed or excluded apps all affect coverage.
• Linux: Desktop proxy settings, environment variables, routing tables, and transparent proxies may coexist. Terminal programs do not necessarily read the proxy settings from the desktop environment.

Successfully importing a subscription link does not mean system traffic is already being captured. A subscription only gives the client server addresses, ports, protocols, and some parameters. You still need to select a node, start the connection, and choose rule, global, or TUN mode as needed. If the import only displays a node list without establishing a session, the exit IP will naturally remain unchanged.

Break down common false connections: trace symptoms back to configuration

The client shows connected, but the exit IP is unchanged

First confirm whether the client has only started a local proxy port. If the app uses manual proxy mode and the browser is not reading the system proxy, traffic will still go direct. Then check whether another program has overwritten the system proxy or whether TUN mode lacks permission. Finally, inspect split-tunneling rules: the target domain or address may have been incorrectly matched to a direct rule.

The exit has changed, but the target website still identifies the original region

Websites do not determine region from IP alone; they may also use account region, cookies, location permissions, language, and time zone. Retest first in a private window while signed out, then check the exit IP database results. If only one site behaves oddly while several IP lookup tools consistently point to the target region, site caching or account attributes are more likely than a failed tunnel.

It works right after connecting, then returns to the local exit

This is often caused by the client process being suspended, a failed virtual-adapter rebuild, a switch between Wi-Fi and Ethernet, or automatic fallback after the route drops. Check the client log for reconnects, confirm whether kill-switch or on-demand connection is enabled, and retest routing after a network change. Do not rely only on a connection status that remains visible in the interface.

Some websites work while others do not

This does not necessarily mean the VPN has failed altogether. DNS may return an unreachable address, rules may send related domains down different paths, UDP may not be handled by the current mode, or the target site may reject the exit. Compare DNS results for the failing site first, then check whether its main domain, static asset domains, and API domains match the same policy.

Route and protocol labels cannot replace real verification

Direct, relay, and IEPL describe how a route is organized, not proof that it is working in a browser. Direct usually means the user’s network connects to the remote entry point; a relay passes through an intermediate node before reaching the exit; IEPL generally describes a cross-border transmission design that includes a private-line segment. Whatever the method, verify the actual destination of traffic through the exit IP, DNS, and app paths.

Protocol labels cannot replace testing either. Shadowsocks, VMess, Trojan, and VLESS are common proxy solutions, while Hysteria2 and TUIC emphasize UDP-based transport designs. Client support, matching parameters, TLS settings, subscription parsing, UDP availability, DNS handling, and rule matching all affect the final result. A successful protocol handshake proves only that part of the connection path is working.

If the same subscription works in one client but not another, compare protocol support, transport parameters, TLS settings, subscription parsing, and operating mode. Do not copy similarly named options directly between clients, because terms such as “global,” “rule,” and “bypass LAN” may be implemented differently.

Final verification checklist: keep results reproducible

After troubleshooting, save a short record of the network, client, operating mode, node region, exit owner, DNS results, and affected apps. When the network environment or client version changes, repeat the same process instead of guessing from the connection icon.

• ✅ Saved the exit IP and DNS baseline while disconnected.
• ✅ After connecting, the exit address and network owner match the target route.
• ✅ IPv4 and IPv6 were checked separately, with no unexpected split path.
• ✅ The DNS resolver matches the client configuration, and the browser’s separate DNS was checked.
• ✅ The browser, command line, and target app were tested separately.
• ✅ In rule mode, both direct and proxied targets were tested as expected.
• ✅ After a network switch or route reconnect, the exit was checked again to ensure it had not reverted.
• ❌ Did not use webpage language, time zone, or a single site’s result as a substitute for an exit test.

If no app shows a changed exit, the issue is likely in system capture or proxy configuration. If the exit changes but DNS does not, focus on the resolution path. If only one app fails, check whether it bypasses the system proxy. If the address protocols produce different results, return to dual-stack routing. Following this order usually narrows “connected but not working” to a clear, actionable configuration issue.