How to Check Whether a VPN Is Working: A Complete Beginner’s Guide

You cannot tell whether a VPN is working simply by looking for a “Connected” label in the client. This status usually confirms that the client has established a session with the remote node, but it does not prove that browser traffic, desktop apps, and system DNS are using the route as intended. Reliable verification should check the exit IP, DNS resolution path, and the connection results of the specific apps you use.

During troubleshooting, record the results while disconnected first, then connect to the route and repeat the same tests. Only comparable before-and-after results can distinguish traffic not being captured, rules intentionally sending traffic direct, apps ignoring the system proxy, or a test page showing cached data. The workflow below starts with the easiest check—the exit address—and then moves into routing modes, protocols, and platform differences.

First, understand what “Connected” really means

When a client shows Connected, it usually means the local software has established an encrypted session with the server and completed authentication and the protocol handshake. With common proxy protocols such as Shadowsocks, VMess, Trojan, and VLESS, this status means the local proxy entry can send data to the node. For Hysteria2 and TUIC, which use UDP and QUIC characteristics, it likewise mainly reflects whether the transport session has been established. It does not automatically mean that all system traffic has entered the session.

Whether traffic actually uses the route also depends on how the client captures it. System proxy mode changes the operating system’s proxy settings and usually affects only programs that follow those settings. TUN mode uses a virtual network interface to capture a broader range of IP traffic. Browser extensions generally handle only requests made inside the browser. Some apps have their own network stack, built-in proxy, or DNS mechanism and may not follow the system proxy.

Use the exit IP for the first verification pass

The exit IP is the most straightforward item to check. First disconnect the client, open a page that shows your public address and approximate exit region, and record the result. Then connect to the target route and refresh the test page. If the address and exit region change as expected for the selected route, you can confirm that this web request went through the remote exit.

Use the same browser, test page, and roughly the same network conditions whenever possible. Browser cache, a page script that did not run again, or switching between Wi-Fi and another connection can make the comparison unreliable. If a normal refresh still shows old data, close the test tab and reopen it, or run the check again in a private browser window.

1. Disconnect the route and record the current public exit address and region.
2. Turn off any automatic node selection and manually connect to the route you want to verify.
3. Reopen the test page instead of relying only on the old result in the previous tab.
4. Compare the address and region before and after connecting, and confirm that the result matches the selected node.
5. Test the apps you actually need to use as well; do not verify only the browser.

If the exit address has not changed, check the client mode first. In System Proxy mode, the browser used for testing must follow the system proxy; if it has its own proxy settings, it may bypass the client. In Rule mode, the test site may also be classified as direct traffic. You can temporarily switch to Global mode for diagnosis. Global mode is useful for locating the problem, but may not be suitable as a long-term configuration.

Also watch for differences between IPv4 and IPv6. Some networks provide both types of address while the client captures only one. If the test page prefers the address that is not being captured, it may expose the local exit or show different regions on different pages. Check both connection types separately and confirm that the client, operating system, and current node handle them consistently.

Check whether DNS follows the expected path

Before accessing a domain, a device usually resolves the domain name to an IP address. A DNS leak occurs when queries that should be handled through the specified route or resolver are instead sent to a resolver provided by the local network. The webpage itself may go through a remote exit while domain lookups remain on the local path. This may not prevent the connection, but it shows that the actual traffic path does not match the configured expectation.

For a DNS check, connect to the route first, then open a DNS testing page and start fresh queries. The key question is not whether the resolver is located in the same city as the exit server, but whether the result comes from the expected resolution setup. For example, the client may use server-side resolution or explicitly use a public resolver. If the result matches the configuration, a geographic difference alone is not evidence of a leak.

A browser’s Secure DNS feature can also affect the result. When enabled, the browser may bypass the operating system’s usual resolution process and send encrypted queries directly to the resolver configured in the browser. This can produce results that differ from other apps. During troubleshooting, test the behavior with the feature enabled and disabled separately, but do not make permanent changes without understanding the original setting.

• Only the browser shows an abnormal result: Check the browser’s Secure DNS, extensions, and independent proxy settings.
• All apps resolve locally: Check the client’s DNS capture, TUN configuration, and system network priority.
• Old DNS results remain after switching nodes: Clear the system and browser DNS caches, then make a new domain request.
• The result comes from an explicitly selected public resolver: Compare it with the client settings instead of guessing based only on location.

In a rule-based routing environment, DNS also participates in domain classification. Some clients resolve a domain first and then match IP rules; others use domain rules first to decide whether traffic goes direct or through the proxy. If the rule set is outdated or a domain is classified incorrectly, the main page may use the route while images or login endpoints go direct. Check the domains, matched rules, and final outbound connections in the connection log instead of repeatedly changing nodes.

Verify browsers and desktop apps separately

After confirming the exit through a webpage, test the software you actually use. Browsers, download tools, games, command-line programs, and store apps do not support system proxies in the same way. Some read the system proxy automatically, some support only their own proxy settings, and others are better handled through a TUN virtual interface. Testing only one webpage can miss app-specific differences.

Start with a web service that can show a network region or connection status. Open it in different browsers separately, then test the target desktop app. If the exit changes in one browser but not another, the issue is usually in the browser’s proxy settings, extensions, or Secure DNS. If the browser works but the desktop app still uses the local network, first check whether the app ignores the system proxy and whether the client offers TUN or app-level routing.

Split-routing rules are not inherently a problem. Rule mode typically sends local services direct while routing specified domains or regions through the route. Seeing different websites use different exits may therefore be expected behavior. Before testing, clarify the goal: should all traffic use the route, or should only specific apps and domains use it? Different goals produce different correct results.

If the client supports connection logs, watch for new connection records while opening the target app. Logs typically show the target domain or address, the matched rule, and the final direct or proxy outbound connection. Logs are more useful for diagnosis than simply watching the Connected status, but they may contain visited domains. Check and redact anything you do not want to disclose before sharing a screenshot.

Understand verification differences between direct, relay, and IEPL routes

A route name describes the path used between the device and the exit; it does not change the basic verification principles. Direct routing usually means the device connects straight to the remote node, with a simpler path whose quality depends more on the public route from the current network to the node. A relay route connects to an entry or relay node first, which then forwards traffic to the exit to adjust cross-network routing or improve performance in some network environments.

IEPL generally refers to international Ethernet private-line capacity provided by a carrier. In a proxy service’s route design, it is often used as a dedicated transport segment between the entry point and the provider’s handoff point. When accessing a website, the traffic may still reach the public internet through the exit. Providers may use route names differently, so read them alongside the route description rather than inferring every detail of the full path from the name alone.

Whether you use a direct, relay, or IEPL route, an exit IP check usually shows the final exit, not the relay node. A standard webpage test cannot reliably confirm whether a relay is present. For most users, the priorities are confirming the correct exit region, verifying that the target app actually uses the route, checking that the DNS path matches the settings, and ensuring that old connections are rebuilt after switching routes.

After switching routes, some apps continue reusing established long-lived connections. As a result, the exit test page may update while the app’s session still follows the old path. Close the active pages inside the app and, if necessary, fully quit and restart it. If the client offers an option to block traffic when disconnected, also test separately whether the app stops networking or falls back to the local network after an unexpected disconnect.

What to do when a subscription imports successfully but traffic does not use the node

A subscription link provides the client with nodes and related configuration. A successful import only means that the client can read the subscription content; it does not mean that a node is reachable or that system traffic has been captured. After updating a subscription, confirm the node actually selected, the proxy mode, the system proxy or TUN status, and whether the rule set finished loading.

Shadowsocks, VMess, Trojan, VLESS, Hysteria2, and TUIC have different client and transport-parameter requirements. An older client may display node names from a subscription without fully recognizing some protocol fields. If a node repeatedly times out, the handshake fails, or no traffic flows after connection, first re-import it with a client version supported by the service provider instead of guessing the encryption method, transport layer, or certificate parameters manually.

• Confirm that the subscription content is up to date and that the selected configuration has not been removed or disabled.
• Confirm that the client supports the protocol and transport parameters used by the node.
• Check that the system proxy or TUN is actually enabled, rather than relying on the node button showing a connected state.
• Temporarily use a more direct routing mode to rule out incorrect rule matches.
• Review the connection log to distinguish a failed node handshake, DNS failure, and direct routing.
• After restoring Rule mode, verify the browser and target apps one by one.

If the client offers both a latency test and a connection test, remember that they are not equivalent. A node responding to a probe only shows that the probe can reach it. Real webpages and apps also involve DNS, TCP or UDP connections, TLS handshakes, routing rules, and the target service’s own status. Even after the node list shows an available node, complete the exit IP and real-app checks.

Key checks on different platforms

Windows

Windows clients commonly offer System Proxy and TUN as two ways to capture traffic. System Proxy works well for software that follows the operating system’s proxy settings, but some command-line tools, store apps, and independent network programs may bypass it. TUN usually covers more traffic, but can be affected by other virtual adapters, security software, and routing priority. During troubleshooting, check whether the system proxy was applied and whether the settings are restored correctly after quitting the client.

macOS

macOS clients may establish a tunnel through the system proxy or Network Extension. The VPN status in System Settings and the client status should agree. If other network tools have also installed network extensions, their rules may conflict. When only some apps work, first disable duplicate proxy configurations, then reconnect and check the exit IP and DNS.

iOS and iPadOS

On mobile systems, clients usually capture traffic through the VPN interface provided by the operating system. A status-bar indicator shows that the configuration is connected, but an existing in-app session may briefly continue using its old connection. After switching routes, fully close and reopen the target app. Browser content filtering, Private Relay-type features, or other VPN configurations can also change the results, so avoid enabling overlapping network configurations at the same time.

Android

Android clients may support per-app routing. If an app is excluded, it will continue using the local network even while other apps use the route. Also check whether the system restricts the client from running in the background; after the client is paused, the VPN indicator and actual connection state may become out of sync. During diagnosis, keep the client in the foreground and review the per-app rules.

Platform differences do not change the core verification order: confirm the client session first, compare the exit IP next, check DNS afterward, and finally test the target apps one by one. Do not change the node, protocol, DNS, and routing rules all at once before identifying the problem layer, or it will be difficult to know which adjustment actually fixed the issue.

Troubleshooting order when connected but unable to access anything

When the client shows Connected but a webpage will not open or the target app still uses the local exit, the most effective approach is to change only one variable at a time. First confirm that the local network works normally with the route disconnected, then check the node connection, capture mode, DNS, and routing rules. This helps narrow the problem to the local network, node session, system routing, or a single app.

1. Disconnect the route and confirm that the local network can resolve domains and access commonly used pages normally.
2. Reconnect to the current node and check the client log for handshake or authentication errors.
3. Test another route of the same type to distinguish a single-node issue from a client configuration issue.
4. Check the system proxy or TUN status and temporarily rule out interference from other network tools.
5. Use an exit IP page to confirm whether the test request reached the remote exit.
6. Check the DNS result, then review rule-log matches and the final outbound connection.
7. Fully quit and reopen the target app so that it does not continue reusing the old path.

If the exit IP is correct but a service still shows the original region, the service may be retaining account-region data, cached information, location permissions, or an old session; this does not necessarily mean the route has failed. Conversely, a page loading does not prove that traffic used the route, since direct access may also succeed. Use the combined evidence from the exit result, DNS path, and app logs for the final assessment.

After verification, restore the temporarily enabled Global routing mode to your everyday configuration and test key apps again. If you need to contact technical support, provide the platform and client version, node protocol, capture mode, affected app type, and error logs with sensitive content removed. Clearly stating “which app did not use the route” is more useful for diagnosis than simply saying “the VPN does not work.”