VPN connected but not working? Check your exit IP, DNS, and verify apps individually

A VPN showing “Connected” does not prove that it is working. This status usually means the client has completed a handshake with the remote route, not that your browser, desktop apps, and system DNS are all using the proxy as expected. The most reliable approach is to check your exit IP, DNS, system routes, and individual apps separately, then compare the results before and after connecting.

When troubleshooting, avoid changing protocols or reinstalling the client repeatedly. Changing several conditions at once makes the cause harder to identify. Keep the current route and start with the external IP address, then check DNS, proxy mode, routing rules, and individual apps. This helps distinguish between a route that was never established, a system that was not taken over, and a single app bypassing the proxy.

Use your exit IP first to see whether public traffic has been rerouted

Your exit IP is the public source address external websites see. After connecting to an international route, a browser whose traffic is fully handled will usually show an address in the route’s country or region rather than the public address assigned by your local network provider. Check the IP, provider or data-center ownership, and country or region together; do not rely only on the map marker.

Geolocation databases are not always consistent. The same data-center address may be assigned to a nearby city in one database and still show older regional data in another. A city mismatch alone does not prove that the route has failed. What matters more is whether the address changed from your local provider to the route provider or data center, and whether the result changed after connecting.

• ✅ Use the same test page before and after connecting to avoid differences between databases.
• ✅ Record the complete exit address, network owner, and country or region—not just a map screenshot.
• ✅ Check once in a regular browser window and once in a private window to rule out cached pages or old sessions.
• ❌ Do not assume the VPN is working just because the target website opens; the site may already be reachable on your current network.
• ❌ Do not treat a city-level location mismatch as proof of a route error. First verify the address ownership and the change from before to after connecting.

Even if the browser’s exit address has changed, you cannot immediately conclude that all traffic is working. The system may be using rule-based routing, with only sites matching proxy rules being rerouted; desktop apps may also use independent connections. An exit IP check is only the first piece of evidence. Next, check DNS requests and app connections.

Check whether DNS resolution follows your configuration

When you visit a website, your device usually sends the domain to DNS for resolution before connecting to the resulting address. If web traffic uses a proxy while DNS requests still go to your local network resolver, testing tools may show a local DNS service. This is commonly called a DNS leak. It may not prevent pages from loading, but it can reveal the domains being queried and cause inconsistent region detection, content delivery, or connection results.

Focus on the resolver’s operator and region, not just a “pass” or “warning” label. Some routes resolve through a remote server, producing results near the route’s exit location; some clients use public encrypted DNS, which may appear as a public resolver. If that path is explicitly configured by the client, a resolver name that differs from the exit provider alone does not indicate failure.

Browser secure DNS can make results more complex

Modern browsers may enable DNS over HTTPS. In that case, the browser sends DNS requests independently and may not use the operating system’s DNS settings. If the browser request itself goes through the tunnel, the secure DNS connection may also use the route; if the browser is configured for a direct connection, it may access the specified resolver independently.

Therefore, when system DNS and browser test results differ, check the browser’s secure DNS setting before making changes. During troubleshooting, record the results with the feature enabled and disabled, but do not switch routes, change DNS, and modify proxy modes at the same time. Change one condition per test so you can identify the source of the difference.

Check IPv4 and IPv6 as well

Some networks provide both IPv4 and IPv6. If the client handles only one protocol, a test page may show one exit address from the route while exposing another from the local network. A common symptom is that some websites use the proxy as expected while services that prefer IPv6 still connect through the local network.

Do not disable system features blindly. First confirm whether the client’s virtual network adapter or tunnel mode supports dual-stack handling, then review the routes and DNS settings. If the client clearly does not handle IPv6, you can temporarily disable it for comparison after understanding your network environment. Once confirmed, choose a mode or client that supports the required network stack.

Use per-app testing to find what is bypassing the route

If browser tests look normal while a chat app, download tool, game platform, or command-line program still shows the local network, the issue is usually related to the scope of proxy handling. System proxy mode mainly affects apps that actively read system proxy settings; virtual adapter or tunnel mode handles more traffic at the network layer. An app may behave differently if it has its own proxy, ignores system settings, or uses a transport method not covered by the current client.

For testing, choose an app feature that displays session details or exit ownership, and make sure the test content is legal and repeatable. Fully quit the app before connecting, then reopen it to avoid reusing an old connection. For software that keeps long-lived connections, an existing session may not move to the new exit immediately after the client switches routes.

1. Keep the network and route fixed. Do not switch repeatedly between Wi-Fi, cellular data, and different nodes during troubleshooting.
2. Close the target app. Confirm that the app process has ended so existing long-lived connections do not affect the result.
3. Check the proxy mode. Confirm whether it is global, rule-based, direct, or browser-only. Names vary between clients, but the logic is similar.
4. Restart the app. Perform an observable network action and check the client connection log for the corresponding domain or destination address.
5. Compare with the browser result. If the browser uses the route but the app leaves no record, first check whether the app is bypassing the system proxy.
6. Retest with a different handling mode. If supported by the client, compare virtual adapter or tunnel mode to determine whether the issue comes from the scope of system proxy coverage.

On Windows, start with system proxy settings, the client’s virtual adapter status, and the routing table. On macOS, check both network-service proxy settings and the VPN configuration permissions requested by the client. Android commonly uses the system VPN interface, but an app exclusion list may send selected apps directly. On iOS and iPadOS, confirm that the VPN configuration still appears connected in system settings, and check whether the client uses on-demand connections or routing rules.

If the client provides connection logs, look for the target app’s domains, destination addresses, or rule matches. Entries such as “Proxy,” “Direct,” or a policy group usually explain more than the connection icon in the app interface. If no request appears in the log, that does not necessarily mean the app is offline; it may be using a protocol the client does not record, or it may have kept a connection open before the tunnel was established.

A successful protocol handshake does not mean routing has taken over

Protocols such as Shadowsocks, VMess, Trojan, VLESS, Hysteria2, and TUIC define how data is transported between the client and remote server. When the client shows the protocol as connected, the handshake or session has been established, but whether system traffic enters that session still depends on the system proxy, virtual adapter, routing rules, and app behavior.

Likewise, successfully importing a subscription link only means that the client received route configuration. You still need to select an available node, enable system proxy or tunnel mode, and allow the client to create the required network configuration. A subscription can update successfully without traffic handling being enabled, causing node tests to work while the web exit remains unchanged.

Understand global mode, rule-based mode, and direct connections

Global mode generally sends all traffic the client can handle through the selected route. It is useful for checking whether routing rules are the cause, but it does not guarantee that every system process is covered. Rule-based mode selects proxy or direct connections by domain, address range, app, or rule set. It is more flexible for daily use, but can make different websites on the same device show different exit locations.

Direct rules are not inherently wrong. Local devices, internal services, and some regional content may need direct access. The issue to investigate is whether a rule incorrectly sends a domain that should use the route directly, or whether the address returned during resolution differs from what the rule expects. Check rule matches in the logs, then temporarily switch to global mode for comparison. If global mode works, the issue is usually in the rules or DNS configuration.

Direct connections, standard relays, and IEPL private lines are different concepts

“Direct” on a route page usually means the device connects straight to the remote server without a provider-deployed relay entry point. A standard relay connects first to a nearby entry point, then the provider’s network forwards traffic to the exit. IEPL private lines emphasize a cross-region transport path distinct from a direct public-internet connection. These terms describe the path between the device and exit, not whether the connection is working.

The verification logic is the same for every route type: did the client establish a session, did the system send requests into the client, did DNS resolve according to the configuration, and which exit did external services see? A private line or relay may improve stability in a particular network environment, but it does not replace proxy-mode and routing-rule configuration.

Common reasons a VPN shows connected but traffic bypasses it

When the exit address has not changed, work through the steps below in order. This sequence starts with settings that are easiest to restore and have the smallest impact, then moves to system routes and software conflicts, reducing unnecessary reinstalls.

• ✅ Confirm that a specific route is selected, rather than merely importing a subscription or updating the node list.
• ✅ Confirm that the system proxy, virtual adapter, or tunnel switch is enabled and that the required network configuration permissions have been granted.
• ✅ Temporarily switch from rule-based mode to global mode and retest to see whether a direct rule matched incorrectly.
• ✅ Fully quit the browser and target app, then reopen them to clear connections that are still being reused.
• ✅ Check browser extensions, custom proxies, and secure DNS to prevent multiple network settings from overriding one another.
• ✅ Review requests, rule matches, and connection errors in the client log instead of looking only at the status icon.
• ✅ Disconnect other active proxy or corporate network clients to rule out routing and virtual adapter conflicts.
• ✅ After updating the subscription, select the route again to avoid using an expired or changed configuration.

The subscription link was imported but never actually enabled

Many clients separate subscription management from the current connection on different screens. Pasting a subscription link, updating the node list, and completing latency tests do not mean that the system has started using a route. You still need to select a node, start the connection, and enable the system proxy or allow a VPN configuration on the platform. If handling does not resume automatically after a restart, the list may remain while the exit returns to the local network.

Old connections and caches are mixing the before-and-after results

Browser connection pools, long-lived desktop-app connections, DNS caches, and website sessions can temporarily retain the old path. Refreshing the same page immediately after switching routes may still show cached content or a reused connection. A more reliable approach is to close and reopen the app, use a new private window, and verify several independent signals instead of repeatedly refreshing one page.

A corporate network or security tool rewrote the routes

Corporate network clients, firewalls, endpoint security software, and other virtual adapters may modify the default route or DNS. If your personal client shows a successful connection but its logs contain no business requests, disconnect other network-handling tools and test again. Do not bypass network policies on managed devices; contact the administrator to confirm which connection methods are allowed.

A repeatable VPN verification process

For similar issues, use the same process each time: record the pre-connection exit and DNS results, then establish the route. After connecting, recheck the exit IP in the same test environment, followed by DNS and dual-stack addresses. Restart the target app and use the client log to confirm whether requests match a proxy or direct rule, then restore your normal rule-based mode.

If every test works in global mode but specific services fail after switching back to rule-based mode, focus on routing rules and DNS. If the exit still does not change in global mode, focus on system handling, permissions, and software conflicts. If only one app fails, check its independent proxy, exclusions, and old connections. This classification usually avoids repeated protocol changes or system reinstalls.

Route types should also be considered at the right stage of troubleshooting. Direct connections, relays, and IEPL private lines mainly affect the path between the device and exit; Shadowsocks, Trojan, VLESS, and other protocols determine how the client and server transport data. None replaces verification of the system proxy, routes, DNS, or per-app rules. First confirm that traffic is entering the route, then decide which route best suits the current network.