VPN Connected but Not Working?Check Your Public IP and DNS: A Complete Guide

When a VPN connects, don’t rely only on the client’s “Connected” status. It usually confirms communication with the remote node, not that every app’s traffic is using the VPN. Verify the public IP, DNS path, system routes, and app routing in that order.

The most reliable approach is to record baseline results before connecting, then compare them afterward. A changed public IP shows that at least some traffic was rerouted; expected DNS results and consistent behavior across apps help confirm the scope of traffic handling.

Define “working” first: a connection is not the same as traffic handling

After establishing a connection, the client may still need to write proxy settings, a virtual network interface, or routing rules to the system. Establishing communication and taking over traffic are separate stages: the first lets the client reach the node, while the second determines which packets enter the route. If system rules are missing, overwritten by another network tool, or limited to certain apps, the client may show a successful connection while browsing results remain unchanged.

Clients also handle traffic in different ways. System proxy mode mainly affects apps that follow system proxy settings; virtual network adapter mode usually covers more apps, but can still be affected by routing rules, LAN bypasses, and an app’s own networking stack. Browsers may also use a separate proxy or secure DNS, so their behavior can differ from other system applications.

It is best to define “working” in three parts: the exit shown by a test page has changed; DNS queries are not exposed through an unexpected path; and the apps that need coverage actually match proxy or tunnel routes. If only one condition is met, the VPN may be partly working, but troubleshooting is not finished.

Check the public IP: record a baseline, then test again after connecting

The public IP is the address websites see as the source of a request. Before connecting, it is usually provided by the current network; after traffic is routed through the VPN, the test page should show the node’s exit or its upstream exit. Compare results on the same browser and test page to avoid differences between site databases.

1. Disconnect the client, disable any separate browser proxy extensions, open a trusted IP lookup page, and record the address, country or region, and network operator.
2. Connect to the target node and wait for the client status to stabilize. Then hard-refresh the original page instead of relying on a tab that was already open.
3. Check whether the address changed and whether the approximate location matches the selected route’s exit region. Databases can update slowly, so location is only supporting evidence; an address change is more direct.
4. Repeat the request in another browser or with a built-in system network tool. If the results differ, check the browser proxy, cache, extensions, and routing rules first.

• ✅ Use the same network and test page before and after connecting to reduce variables.
• ✅ Refresh the page and read the result again; do not rely on an old tab or screenshot.
• ✅ Record both the address and operator information, not just the flag or location text.
• ❌ Do not use “a website opens” as a substitute for checking the public IP.
• ❌ Do not compare mixed results after switching through several nodes in succession.

If the address does not change at all, first check whether the current mode uses rule-based routing. Some rules may send IP-check sites directly while routing target sites through the VPN; this does not necessarily indicate a connection failure. Temporarily switch to global traffic handling for diagnosis, then restore the original routing settings. Global mode is useful for isolating issues but may not be suitable as a permanent configuration.

If the browser’s exit changes but command-line tools or other apps do not, you are probably using system proxy mode and those apps are not reading the system proxy. Conversely, if system tools are rerouted while the browser keeps its original exit, check the browser’s internal proxy, extensions, and secure DNS settings.

Check DNS: identify resolution paths and browser differences

Before connecting to a domain, the device must resolve it to an address. DNS usually handles this step. If web traffic uses the VPN while DNS queries still go to the original network’s resolver, a DNS leak may occur. Here, “leak” describes the path: the lookup follows an unexpected network route, not that account details or page content are automatically exposed.

To check DNS, use a trusted DNS testing page and compare the resolver provider when disconnected and connected. Do not focus only on the city shown for a server; resolvers may use proximity-based routing, and geolocation databases can lag. The provider, network ownership, and before-and-after differences are more useful.

Local commands can also help inspect the current system configuration. They show the resolver settings known to the device, which may not match the path ultimately used by the browser. Use them alongside web-based tests rather than as substitutes.

Windows
ipconfig /all
nslookup example.com

macOS
scutil --dns
nslookup example.com

Linux
resolvectl status
nslookup example.com

Why browser and system results may differ

Modern browsers may enable secure DNS and send queries directly to a resolver chosen in the browser. System commands then show the operating system configuration, while the browser’s test page reflects a different path. To check whether the client is handling system DNS, temporarily disable the browser’s separate secure DNS and test again. If the results match afterward, the difference comes from the browser setting rather than the node.

Caching is another common cause. The operating system, browser, and apps may retain previously resolved domain results. After switching routes, an app may keep using a cached address instead of making a new DNS query. A safer approach is to clear the browser’s network cache or query a domain you have not visited before, then check the results again.

Test apps individually: find out which app is not using the VPN route

Once the browser works normally, check the apps you actually need. Apps may use different networking stacks: some follow the system proxy, some read only an in-app proxy, some connect directly, and others use datagram transport that traditional proxy modes cannot easily handle. It is therefore common to see a website work while another client does not on the same device.

During testing, check the client connection log to see whether app requests match a rule. If the client provides a connection list, see whether the domain or process is marked as proxied, direct, or rejected. Without connection logs, use a comparison: keep the node fixed and test the same app in system proxy mode and virtual network adapter mode. If only the latter works, the app probably does not follow the system proxy.

1. Close other proxies, filters, or packet-capture tools that may modify network settings, and leave only the current client running.
2. Confirm in the browser that the public IP has changed, showing that the node and basic connection are working.
3. Open the target app and perform an action that creates a new network request rather than reading an offline cache.
4. Review the client connection log or rule-match result to confirm whether the app is using the proxy or a direct connection.
5. Temporarily switch traffic-handling modes and test again. If the result changes with the mode, adjust the app’s rules instead of repeatedly replacing the subscription.

Why routing rules can make a VPN appear to work only partly

Rule-based routing chooses a path by domain, address range, app process, or rule set. Its usual purpose is to keep local services direct while sending international traffic through an international route, but rules cannot always identify every request. A website may also call separate domains for login, images, APIs, and media. If the main page uses the proxy while an API domain is sent direct, the page may open but login can fail or content may load incompletely.

For this type of issue, start with global traffic handling as a comparison. If global mode works, the node, protocol, and subscription usually have no fundamental fault; the rules are more likely responsible. Restore rule-based mode afterward, find the relevant direct-connected domains in the client log, and add the required ones to the proxy rules. Do not permanently proxy every unknown domain, or routing rules lose their purpose.

Protocols, subscriptions, and route types: what each one affects

Protocols such as Shadowsocks, VMess, Trojan, VLESS, and TUIC define how data is transported between the client and node. A successful protocol handshake only shows that this connection was established; whether traffic enters it is still determined by the system proxy, virtual network adapter, and routing rules. “Protocol connected” and “app traffic using the route” are not equivalent.

A subscription link provides nodes and configuration to the client. After importing it, the client usually stores the remote content locally. A server-side node update does not mean the local list has synced. If a node name remains while its configuration is outdated, connections may fail, handshakes may be unstable, or access may fail after connecting. Update the subscription in the client before troubleshooting, then select the node again instead of repeatedly importing the same old content.

Also distinguish the protocol from the route’s transport method. Direct access means the device connects straight to the node entry point, with the path heavily affected by the local network and international links. Transit routing reaches a relay entry first and then forwards to the next node. IEPL usually describes a specific cross-border transport path. These choices affect routing and stability, but do not replace client-side traffic handling. Even with transit routing or an IEPL route, traffic will not enter it automatically if the app is routed direct.

Common failures: connected successfully, but traffic is not rerouted

System proxy overwritten by another tool

Browser extensions, network filters, debugging proxies, and other clients may rewrite the system proxy. A tool launched later often overrides earlier settings and may not restore them when closed. Exit other related tools, confirm in system network settings that the current client manages the proxy address, then disconnect and reconnect.

Virtual network adapter permissions or route installation failed

The first time virtual network adapter mode is enabled, the system usually asks for approval of a network extension or administrator permission. If authorization is incomplete, the client may still show the node as connected while system routes remain unchanged. Check the client log for interface creation, route installation, or permission errors, and confirm in system network settings that the relevant network extension is allowed.

LAN and local addresses bypassed

Clients commonly keep LAN addresses direct so you can continue accessing printers, routers, and local storage. This is normal and does not mean the route has failed. However, if the target service uses an internal domain, enterprise DNS, or a special address range, bypass rules may send resolution and access along an unexpected path. Adjust them for the actual network.

System clock is inaccurate

Some encrypted protocols require accurate system time for certificate or handshake checks. If the device clock is significantly wrong, the connection may repeatedly establish and drop, or briefly show as connected without transferring data. Enable automatic time synchronization first, then reconnect and test.

Old routes remain after switching networks

After switching from wired to wireless networking, or from one access point to another, the client may retain routes associated with the old interface. The simplest sequence is to disconnect the route, wait for the network switch to finish, confirm that ordinary websites work directly, and then reconnect the client.

Complete troubleshooting order: start with the least disruptive changes

When something goes wrong, work through the checklist below one item at a time. It verifies the basic network first, then the subscription and node, and only afterward changes traffic handling and routing. This helps prevent an existing network problem from being mistaken for a client issue.

• ✅ Disconnect the route and confirm that the current network can resolve domains and open websites normally.
• ✅ While disconnected, record the public IP and DNS test results as a baseline.
• ✅ Update the subscription and select a node that currently connects successfully.
• ✅ After connecting, hard-refresh the test page and check whether the public IP changed.
• ✅ Check the DNS provider and review the browser’s separate secure DNS setting.
• ✅ Test with another browser or app to determine whether the issue is limited to one program.
• ✅ Review connection logs and rule matches to confirm that the target request is not direct.
• ✅ Temporarily use global traffic handling for comparison, then restore and correct the rules.
• ✅ Check system network extensions, virtual network adapter permissions, and leftover proxy settings.
• ❌ Do not change the network, protocol, node, and DNS at the same time, or you will not know which variable caused the result.

If both the public IP and DNS match expectations but a specific website remains unavailable, the issue may be beyond whether the route is working. The site may determine access region through the account region, browser cache, location permissions, or content-delivery policies. Repeatedly changing system DNS is unlikely to help; instead, clear site data, check the account region and app permissions, and confirm that related domains match the same rule set.

If every test still shows the original network, return to the client traffic-handling layer: confirm that the system proxy was written, the virtual network adapter has permission, and routes were not overwritten by another tool. If only the node fails to connect, review protocol logs, the subscription update time, and compatibility with the current network. Treat “the node cannot connect” separately from “the node connects but traffic is not handled”; this is usually more effective than repeatedly changing settings.