A VPN can change the network path used by an application, but it does not automatically hide every piece of information that a website, browser, operating system, or account can reveal. A practical privacy check should therefore look at several layers instead of relying on a single “connected” status. Confirm the visible IP address, inspect DNS requests, test WebRTC behavior, and verify what happens when the VPN connection is interrupted. Then review browser permissions, account sign-ins, and local network settings that may expose information independently of the tunnel.

This guide presents a repeatable method for checking DNS leaks, WebRTC leaks, IP exposure, and Kill Switch protection. The goal is not to promise perfect anonymity. It is to help you understand what a VPN is protecting in a particular setup, identify configuration mistakes, and reduce avoidable privacy risks when using public Wi-Fi, online banking, remote work tools, or other sensitive services.

What a VPN can hide—and what it cannot

When a VPN connection is established, the VPN client normally creates an encrypted path between your device and a remote VPN server. Your internet provider or the operator of a public Wi-Fi network can usually see that your device is communicating with a VPN server, but the contents of correctly routed traffic are protected from ordinary inspection on that local path. Websites may see the VPN server’s public IP address instead of the public IP address assigned by your home or mobile network.

That description has important limits. A VPN does not automatically hide the fact that you are logged in to a service. If you open a shopping, email, social, or work account, that service can associate activity with the account even when the visible IP changes. A VPN also does not remove browser fingerprints, cookies, tracking identifiers, device identifiers, GPS permissions, or information voluntarily submitted in a form. If an application sends data outside the VPN tunnel, the VPN cannot protect traffic it never receives.

Encryption between your device and the VPN server also does not guarantee that every connection beyond the server is encrypted. HTTPS protects the connection between a browser and a website when correctly enabled, while a VPN protects the path between the device and the VPN server. These are different layers. A privacy check should confirm both the VPN route and the security settings of the services you use.

90+

Countries covered

200+

Available routes

14 days

Refund period

Unlimited

Online devices

Check the visible IP address before and after connecting

The visible IP test is the simplest starting point because it establishes a baseline. Disconnect the VPN client, open a reputable IP-checking page, and record the displayed public IP, approximate location, and network or provider name. Do not treat the location shown by a lookup service as a precise physical position. IP geolocation is an estimate and can point to a city, region, or data center that is not where you are located.

Close the test page or note its result, connect the VPN, and repeat the check in a fresh browser tab. A correctly routed connection should normally show an address associated with the selected VPN server or its network provider rather than the address from your home, office, or mobile network. The location may not match the city you expected, especially when a route is registered in a nearby region or when an infrastructure provider owns the address range.

Repeat the test with more than one browser if the result looks inconsistent. Browser extensions, secure DNS settings, enterprise software, and local proxy configuration can affect the request. Also test the applications that matter to you. A browser showing the VPN address does not prove that a command-line program, game launcher, video application, or background updater uses the same route. System proxy mode and TUN mode capture traffic differently, so record which mode is active during every comparison.

Interpret an unexpected IP result

If the original public IP remains visible after connection, first check whether the VPN client reports a completed connection rather than merely starting the connection process. Confirm that the selected profile is enabled, that the operating system has accepted the required permissions, and that another proxy or VPN application is not active at the same time. Multiple network tools can create competing routes and make a test appear random.

If only one application shows the original address, that application may be using its own network stack, an excluded route, or a direct connection that bypasses the system proxy. Review split-tunneling, bypass, and per-app rules before changing the server. A different route cannot correct a program that has deliberately been excluded from the tunnel.

One-line conclusion: Use the visible IP test to confirm the basic route, but test important applications separately because a browser result is not a whole-device guarantee.

Test DNS requests and identify DNS leaks

DNS translates a domain name into an IP address before a browser or application connects. Without suitable VPN handling, a device may send these queries to the DNS resolver supplied by the local Wi-Fi network, mobile carrier, or internet provider even though the main web traffic is routed through the VPN. This situation is commonly called a DNS leak. It can reveal which domains the device is trying to reach to the resolver operator, and it can also cause filtering or inconsistent results from the local network.

To test DNS behavior, first disconnect the VPN and run a standard DNS leak test. Record the resolver names and network providers shown. Connect the VPN, wait for the client to finish establishing the tunnel, and run the test again. The result should be consistent with the VPN configuration rather than clearly identifying the local network’s resolver. The exact presentation differs between test services: some list resolver addresses, while others show provider names or approximate locations. Compare the provider and network context, not only the displayed country.

Common DNS leak causes and fixes

A DNS leak can come from several sources. The operating system may keep using manually configured DNS servers. A browser may enable its own secure DNS policy. A VPN client may support DNS protection but have that option disabled. On some systems, IPv6 requests follow a path that the current VPN profile does not capture. Corporate security tools, virtual machines, and custom firewall rules can also add resolvers that are not covered by the VPN.

Start with the VPN client’s DNS or leak-protection setting and enable it if the feature is available. Avoid stacking several unrelated DNS tools until the basic route works, because each layer makes troubleshooting harder. If you use custom DNS for parental controls, malware filtering, or business policy, decide whether that resolver should be reached through the VPN and confirm that the client supports the intended arrangement.

On Windows, inspect active network adapters and DNS settings after changing the profile. On macOS, review the active network service and any configuration profiles. On Android and iOS, check whether a system-level private DNS or DNS profile is overriding the client. On Linux, systemd-resolved, NetworkManager, local resolvers, and container networking may all affect the result. The menu names vary by version, so focus on the actual resolver path rather than copying a setting from another operating system.

  • ✅ Run the DNS test once before connecting and once after the VPN is active
  • ✅ Check IPv4 and IPv6 behavior if the test service reports both
  • ✅ Review custom DNS, browser secure DNS, and operating system profiles
  • ❌ Do not assume that changing the VPN server will fix a resolver configured outside the client
  • ❌ Do not publish screenshots containing your full public IP or network details

Test WebRTC and browser-specific address exposure

WebRTC is a browser technology used for real-time audio, video, and peer-to-peer communication. To establish a connection, the browser may gather local interface information and network candidates. Depending on the browser, operating system, permissions, and VPN configuration, a WebRTC test may display an address that is not visible in a normal webpage IP check. The result does not always mean that all traffic is bypassing the VPN, but it is a useful signal that the browser is exposing network information through a separate mechanism.

Use a WebRTC leak test after recording the ordinary IP result. Keep the VPN connected, open the test in a private window if appropriate, and note every address category it reports. Test again after disabling browser extensions that modify WebRTC, because an extension can change the outcome. Then compare the result in another supported browser. Different browsers may apply different privacy policies, so a clean result in one browser does not prove that another browser behaves identically.

WebRTC settings require a trade-off. Disabling or restricting WebRTC can reduce address exposure in a browser, but it may affect web-based meetings, voice calls, screen sharing, and other real-time features. A browser extension may provide a convenient control, yet extensions themselves require trust and can introduce new permissions. Prefer a browser setting or a well-understood client feature when available, and test the services you actually use after making a change.

Troubleshoot a WebRTC result carefully

First distinguish a local address from a public address. A private local address may reveal information about the local interface but does not identify the public network in the same way as a public IP. Next check whether the displayed public address belongs to the VPN route. If it matches your original network, review browser permissions, VPN leak protection, IPv6 handling, and split-tunneling rules.

Do not install several privacy extensions at once and assume that more controls always mean better protection. They can conflict with each other, break legitimate WebRTC functions, or make it difficult to identify which change solved the problem. Change one setting at a time, clear the test page, repeat the check, and keep a short record of the browser version and client mode.

Testing tip: WebRTC is a browser behavior, not a universal measurement of every application. A browser-level restriction can reduce exposure in that browser, while other applications still need their own route and permission checks.

Verify Kill Switch protection instead of trusting the label

A Kill Switch is intended to block selected traffic when the VPN tunnel is unavailable or when the client loses contact with its VPN server. Its purpose is to prevent the operating system from silently returning to the ordinary network path during a brief interruption. The exact behavior differs by client. Some options block traffic only while the client is running, some remain active until the VPN is reconnected, and some offer a stricter mode that also blocks traffic before the first connection.

Before testing, save your work and close services that may react badly to a temporary network block. Enable the Kill Switch in the VPN client, connect normally, and confirm the ordinary IP result. Then use the client’s disconnect control if its documentation describes that as a supported test. If appropriate for your device, temporarily disable the network interface or move between Wi-Fi networks. Never unplug equipment or change firewall rules without knowing how to restore them.

During the interruption, try to load a new webpage and start a new network request. A functioning Kill Switch should block the request or leave it unable to complete until the VPN path returns. Reconnect the VPN, confirm that normal traffic resumes, and run the IP and DNS tests again. A browser page that was already loaded is not a useful test because cached content may appear even when the network is blocked.

Remember that Kill Switch coverage is not always identical across devices. A desktop client using a virtual adapter may cover more IP traffic than a mobile application constrained by the operating system’s VPN framework. Some apps use their own fallback connection, and local network services may continue to operate even when internet traffic is blocked. Review the client’s documentation and test the platform where privacy matters most.

One-line conclusion: A Kill Switch is valuable only if its actual interruption behavior matches your risk tolerance, application mix, and operating system permissions.

Build a repeatable privacy check routine

Privacy testing is more useful when performed after meaningful changes rather than repeatedly without a plan. Recheck after installing a major client update, switching between system proxy and TUN mode, enabling split-tunneling, changing DNS settings, adding a browser extension, or moving to a new operating system. A new Wi-Fi network can also expose configuration problems that were not visible on your home connection.

Use the same sequence each time: record the disconnected IP, connect the VPN, check the visible IP, run a DNS test, run a WebRTC test, and verify the Kill Switch. If one result changes, change one configuration item and repeat. Keep the record private and remove full addresses before sharing troubleshooting details with anyone else. The purpose of a record is comparison, not creating a permanent history of your network identity.

  • ✅ Confirm the VPN client is the only active VPN or proxy tool
  • ✅ Select a protocol supported by the client and your network environment
  • ✅ Test both the browser and the applications that handle sensitive traffic
  • ✅ Keep the client, operating system, browser, and security software updated
  • ✅ Use HTTPS and verify the domain before entering banking credentials
  • ❌ Do not use a VPN as permission to ignore phishing warnings or account security
  • ❌ Do not treat a country label as proof of a precise server location

For client selection, official Windows, macOS, Android, iOS, and Linux applications are usually the simplest starting point because they can expose platform-specific permissions and protection features. Compatible clients such as Clash Verge, sing-box, and Shadowrocket can be useful when you understand their profiles, DNS rules, routing modes, and Kill Switch limitations. A subscription import is not the same as a complete privacy configuration: after importing a profile, inspect the active DNS handling, traffic mode, IPv6 behavior, and bypass rules.

Protocol choice also matters for compatibility, but it should not be confused with leak testing. WireGuard and OpenVPN use different implementations and operating-system integrations; VMess, Trojan, and Hysteria2 may be available through compatible clients with different routing and transport behavior. A protocol can connect successfully while a browser or application still bypasses it because of local rules. Test the complete client configuration, not just the protocol name shown in a menu.

Final takeaway: Check the route, DNS, WebRTC, and interruption behavior as separate layers. Once those results are understood, use browser controls, HTTPS, account security, and sensible public Wi-Fi habits to reduce the risks that a VPN cannot solve on its own.