How to check whether your VPN is working: check your IP and DNS with this beginner’s guide

To check whether your VPN is really working, don’t rely only on the green icon in the client. A more reliable approach is to record your public IP and DNS results before connecting, repeat the checks after connecting, and then test your browser, desktop software, and other networked apps separately. The current setup is working as expected only when the exit path, DNS resolution, and target app traffic all match your expectations.

You don’t need to understand complex network commands for this process. Beginners can find most issues by completing the basic comparison first; if the results conflict, move on to split tunneling, system proxy, TUN mode, and DNS settings. Change only one condition at a time—don’t switch routes, protocols, and rules together, or you won’t know which setting made the difference.

Establish a baseline: check the disconnected state first

To determine whether a route has changed your network path, you need a starting point for comparison. Fully disconnect the client, disable any browser proxy extensions that may be enabled separately, and open a new private window. Search for “what is my IP” and record the public address, network provider, and approximate location shown. Detection sites may update their databases at different times, so the location name does not need to match word for word; focus on whether the public address and network ownership changed.

Next, check the current DNS resolution results. DNS converts website domain names into addresses that can be reached, but it is separate from the exit path ultimately used by the webpage. While disconnected, DNS requests may be handled by the local network, the resolver specified by the operating system, or the browser’s built-in secure DNS. Record the resolver’s network ownership shown by the test page, then compare it with the result after connecting.

When establishing a baseline, also note the network environment in use, such as fixed broadband, public Wi-Fi, or a shared hotspot. Switching networks can change both your public IP and DNS; if the disconnected and connected checks use different networks, the comparison is meaningless. After recording everything, connect the VPN and wait for the client status to stabilize. Then reopen the test pages instead of only refreshing an old tab, since it may retain cached data or existing connections.

• ✅ After disconnecting the client, record the original public IP, network ownership, and approximate location.
• ✅ Record the DNS resolver’s network ownership while disconnected.
• ✅ Use the same local network environment for the post-connection test.
• ✅ Use a new private window to reduce interference from caches, extensions, and old connections.
• ✅ Change only one route, protocol, or mode at a time, then check again.

Check the public IP: confirm where web traffic exits

The public IP is the request source external websites see. After connecting to a route, if the test page still shows exactly the same address as the baseline, the node is not necessarily broken. A common cause is that the current browser is not using the proxy path provided by the client. First check the client’s operating mode: system proxy mode generally handles programs that follow the system proxy settings, while TUN or virtual-adapter mode handles matching traffic at a lower level.

If the public address has changed but the location does not match the selected route, don’t jump to conclusions. IP geolocation databases can lag behind, and the same address may appear as a nearby region or an old data-center location on different test sites. Network ownership, the common direction across multiple results, and the location reported by the actual target service are more useful indicators. If one page looks wrong, clear site data, reopen the browser, and cross-check with another source.

A browser may also establish real-time connections through WebRTC. Seeing an additional local network address on a test page does not necessarily mean that your public exit has leaked; local addresses usually cannot be routed directly over the internet. What matters is whether the page exposes the same public exit as your baseline. If it does, check whether the browser is bypassing the system proxy or whether the client rules mark real-time traffic as direct.

The difference between system proxy and TUN mode

A system proxy is essentially a forwarding configuration that applications can read. Browsers usually follow it, but some games, command-line tools, update programs, and software with its own network stack may ignore it completely. TUN mode handles traffic through a virtual network interface, typically covering more traffic and making it better for testing apps that do not read system proxy settings. However, TUN mode still follows routing and split-tunneling rules; it does not mean every connection will automatically use the remote route.

On desktop platforms, administrator permissions, firewall policies, and other network tools can affect virtual-interface creation. Mobile clients usually take over traffic through the VPN interface provided by the operating system, but battery-saving policies, per-app settings, and always-on options can still change actual behavior. Judge the coverage by testing the target app, not by inferring it from the client interface.

Check DNS resolution: identify deviations in the resolution path

A DNS leak usually means that web traffic is already leaving through a remote exit while domain-resolution requests are still handled by a resolver visible to the local network. This may not stop pages from loading, but it makes the resolution path differ from expectations and can create conflicting location signals. Connect to the route, open a DNS test page, and check whether the resolver’s network ownership is still the same as in the disconnected baseline.

If the result has not changed, first check whether the browser has enabled its own secure DNS. Modern browsers can send DNS requests directly to a chosen service; this path may bypass the client’s usual DNS settings while still passing through the VPN exit. Therefore, an unchanged resolver name alone does not prove a leak. Consider the public IP, browser settings, and client connection logs together.

Another common setup uses remote DNS while split-tunneling rules require domains to be resolved locally before deciding whether to connect directly or use the proxy. This design is not necessarily wrong, but it may expose queries to the local resolver. If you want DNS resolution to follow the remote route, check whether the client supports proxy DNS, remote resolution, or encrypted DNS, and confirm that rule matching occurs at the appropriate resolution stage.

Why browser secure DNS can complicate testing

Browser secure DNS wraps domain lookups in an encrypted connection. If the browser follows the system proxy, that encrypted connection may still use the remote route; if the browser sends the request directly, it creates a separate path. During troubleshooting, you can temporarily make the browser follow the system DNS, complete the baseline comparison, and then restore the original setting. This only reduces variables during testing; secure DNS and a VPN can still be used together.

The operating system may also cache earlier resolution results. Right after switching routes, opening a familiar website may not trigger a new DNS request, while a test page may already show a different resolver. To test a specific domain, close the relevant app, wait for old connections to end, and use a new private window. If the client provides connection logs, check which rule matched the domain request and which resolution path it used.

Test apps individually: avoid a working browser with apps connecting directly

Passing a browser test only shows that the browser’s web requests behave as expected. Desktop chat apps, sync tools, downloaders, games, and command-line tools may use different networking methods. The safest approach is to close the target app, connect to the route, restart it, and confirm the exit through the app’s own diagnostics, the client connection logs, or session information from the target service.

If the client supports connection logs, clear the old entries first, then open the target app and perform one clear network action. Logs usually show the target domain or address, the matched rule, whether the connection was direct or proxied, and the selected node. This is more direct than simply watching a webpage: if the target connection never appears, the app may be bypassing the current interception method; if the log explicitly shows DIRECT, check the rules instead of repeatedly changing nodes.

1. Fully quit the app you are preparing to test so it cannot reuse a connection opened before the test.
2. Connect to the target route and confirm that the client is not repeatedly reconnecting or reporting authentication errors.
3. Clear the client log or mark its current position.
4. Reopen the app and perform one easily identifiable network action.
5. Check the domain, matched rule, and outbound method in the log.
6. If it shows a direct connection, check the split-tunneling rules; if there is no entry, switch to TUN mode and test again.

Why different clients can produce different results

Proxy clients on Windows and macOS commonly offer both system proxy and TUN modes, but virtual-interface permissions and DNS interception methods vary. Linux clients more often depend on explicit routes, environment variables, or transparent-proxy settings, and you must separately confirm whether terminal programs read proxy environment variables. Mobile platforms usually show VPN status centrally, but per-app exclusions, background restrictions, and network switching can still affect the connection.

A browser extension handles only traffic inside the browser and does not automatically take over other apps. Conversely, some browsers may have their own proxy or secure DNS settings, creating differences from the system configuration. During troubleshooting, first identify whether you are using a browser extension, system proxy, or TUN interception, then choose the corresponding test method.

Check the subscription and protocol: a successful connection may still provide no usable forwarding

Importing a subscription link into a client usually generates configurations such as nodes, protocol parameters, and names. Successful import only means that the client understood the subscription; it does not guarantee that the current node can establish complete data forwarding. An expired subscription, updated node configuration, an incompatible client core version, or a significantly incorrect system clock can all make nodes visible while connections fail. In these cases, update the subscription first and review the specific client error instead of repeatedly clicking Connect.

Shadowsocks is an encrypted proxy protocol, and clients commonly use it as a local proxy or TUN outbound. VMess and VLESS are usually managed by clients that support their respective cores; their configuration fields and transport parameters cannot be mixed. Trojan generally establishes connections over TLS, so the certificate name and system time can affect the handshake. Hysteria2 and TUIC are primarily based on QUIC concepts and are more sensitive to UDP quality and local network policies. Even after a protocol shows “connected,” verify actual forwarding with the public IP and app logs.

Direct, relay, and IEPL describe the route path, not the proxy protocol itself. Direct means connecting from the local network straight to the remote node; a relay enters through an intermediate gateway before reaching the exit; IEPL generally describes an international link with dedicated-carriage characteristics. Whichever route you use, the client still needs a protocol to establish a session, and split-tunneling rules determine where app requests go. The route name cannot replace real testing.

Check log
Disconnected: record the public IP and DNS ownership
Connected: record the selected route and operating mode
Browser: check whether the exit changed and DNS matches expectations
Target app: check whether it appears in the log and whether the rule is proxy or direct
Adjustment: change only one route, protocol, mode, or rule at a time
Retest: close old connections and reopen the app

Handle common false connections: connected on screen, but traffic stays off the route

The most common false connection comes from rule-based modes. The client and node session may be working normally, but the target website is classified as direct, so the status bar continues to show Connected while the test page still sees the original exit. Switching to global proxy mode can be a temporary diagnostic step: if the public IP changes immediately, the node and protocol are probably usable, and the issue is more likely in the rule set, rule order, or DNS-resolution stage. Once confirmed, restore the split-tunneling configuration suited to everyday use.

Another issue is an old connection that never closed. Browsers, chat apps, and sync tools may keep connections open for a long time and continue using the previous path after you switch routes. Fully quit and reopen the app; this is more effective than repeatedly refreshing a page. Sleep mode and network changes can also leave the state inconsistent. Disconnect the client, wait for the network to recover, then reconnect and create a new test session.

Running multiple network tools at once can also create routing conflicts. Browser extensions, system proxy tools, virtual-adapter clients, and security software may all modify the request path. During troubleshooting, keep one primary client and temporarily disable other proxy entry points, then retest starting with the public IP. Do not change the firewall, DNS, protocol, and subscription settings simultaneously before the basic path is confirmed.

• ✅ The client log shows no persistent handshake, authentication, or timeout errors.
• ✅ The post-connection public IP differs from the disconnected baseline.
• ✅ The DNS resolution path matches the current client and browser settings.
• ✅ The target app’s connection appears in the log and matches the expected outbound rule.
• ✅ The same result remains reproducible after closing and reopening the app.
• ✅ Run one complete test after switching back to your everyday split-tunneling mode.

When to switch routes and when to switch protocols

If the client cannot establish a session with the node at all and the log repeatedly shows handshake or transport errors, switch to a similar route first to determine whether the issue affects one node. If multiple nodes all fail on the current network and switching protocols restores the connection, it makes sense to investigate whether the network supports the original transport method. If the session is healthy and the public IP has changed but a specific app connects directly, prioritize the interception mode and rules; changing protocols usually will not fix a rule that did not match.

If webpages load but the experience is unstable, first distinguish slow DNS resolution from slow connection setup and unstable ongoing transfer. Frequently changing protocols resets the test conditions and can hide the real cause. Keep the same test target and network environment, change routes or protocols one at a time, and record each log. This produces more reliable conclusions than switching based on intuition.

Final confirmation standard: the result must be repeatable

A single test page showing a different IP proves only that one request used a different exit. Complete confirmation should also include a DNS path that matches your settings, the target app appearing in the client log, and the same result after reopening the app. For websites that rely on location signals, clear old sessions and site data as well, since account details, caches, and browser location permissions may all affect the result. Do not attribute every location message to the VPN.

After troubleshooting, keep a brief record of the client mode, route, protocol, DNS settings, rule mode, and final result. When the network environment changes, you can start from a verified configuration instead of guessing again. If the issue affects only one app, note whether it supports the system proxy, requires TUN interception, and which rule appears in the log; this usually makes the cause easy to reproduce.