A VPN can improve privacy on an untrusted network, but it is not a universal security shield or a guarantee of anonymity. It encrypts traffic between your device and a VPN server, which changes who can observe parts of your connection. What the VPN provider can see, what a website can identify, and whether your browser leaks information all depend on the service, client settings, and the apps you use. This guide explains those boundaries and gives you a repeatable way to check for DNS and WebRTC leaks.
What a VPN protects—and what it does not
When a VPN connection is active, selected traffic travels through an encrypted tunnel from your device to a remote VPN server. On public Wi-Fi, this can make it harder for someone sharing the local network to read or alter traffic inside that tunnel. The network operator can generally see that your device is communicating with a VPN endpoint, along with some connection metadata, but should not be able to read the contents of properly encrypted tunnel traffic.
The tunnel ends at the VPN server. From there, traffic continues to its destination across the internet. If a website uses HTTPS, the connection between the browser and that website has its own encryption. A VPN does not replace HTTPS, and it does not make an unencrypted website safe. Without HTTPS or another end-to-end protection mechanism, information may be exposed after it leaves the VPN server.
A VPN also changes which party handles your network traffic. Your internet provider or local network may have less visibility into the destinations you visit, while the VPN provider becomes an important intermediary. Depending on the protocol, routing configuration, DNS settings, and destination encryption, the provider may be able to observe your original connection IP, connection times, data volume, DNS requests, or destination information. HTTPS normally protects page contents, passwords, and form submissions from network observers, but it does not hide every piece of metadata.
- ✅ Use a VPN to add an encrypted connection between your device and a VPN server, especially on networks you do not control.
- ✅ Keep HTTPS enabled and pay attention to browser security warnings; a VPN does not repair an unsafe destination.
- ❌ Do not assume a VPN hides your identity from accounts you sign in to, cookies, browser fingerprinting, or tracking scripts.
- ❌ Do not treat a changed public IP address as proof that every app on your device is using the VPN.
Think in terms of a threat model rather than a blanket claim of being “protected.” Ask what you want to protect, from whom, and under what conditions. Protecting traffic from other people on airport Wi-Fi is a different goal from preventing a website from linking activity to an account, or preventing malware on your device from stealing credentials. A VPN can help with the first goal, has limited effect on the second, and cannot by itself solve the third.
How to evaluate a no-logs policy
“No logs” is a broad marketing phrase, not a complete technical description. A provider may use it to mean that it does not retain browsing history, while still collecting account details, payment records, support messages, diagnostics, or short-lived operational data needed to maintain a service. Those categories are not necessarily equivalent, and a privacy policy should explain what is collected, why it is collected, how long it is kept, and whether it is linked to an account.
Read the full privacy policy and any separate logging or data-retention statement. Look for specific language about traffic contents, destination records, DNS queries, connection timestamps, source IP addresses, bandwidth totals, device identifiers, crash reports, and abuse-prevention systems. Check whether data collection is optional, whether diagnostics can be disabled, and whether the policy distinguishes information held by the service from information held by payment processors or app platforms.
An independent audit can provide useful evidence, but it is not a permanent guarantee. Check who performed it, when it was completed, what systems or claims were in scope, and whether the public report describes limitations. An audit of a server configuration does not necessarily cover every app, support system, payment provider, or future change. Similarly, a statement that a system is designed not to store a category of data is different from proof that no relevant data can ever exist anywhere in the service’s operations.
Consider the provider’s operating model as well. A privacy policy should identify the responsible legal entity and explain how users can contact it about data requests. Jurisdiction may affect legal obligations, but a country name alone does not tell you what data is collected or how a request would be handled. Prefer clear, consistent documentation over dramatic claims such as “completely invisible” or “impossible to trace.”
Finally, separate account privacy from connection privacy. If you sign in to a VPN account, the service must process enough information to authenticate that account. If you use a browser while signed in to a search, email, or social account, those sites can associate activity with your account regardless of the VPN exit address. A no-logs policy cannot make an account-based service forget what you directly provide to it.
How to check for DNS and WebRTC leaks
A leak check is a diagnostic, not a complete privacy audit. Run it after connecting to the VPN, and compare the results with the connection disconnected. If the VPN client offers a DNS test or connection details, use those as an additional reference. Repeat the check after changing networks, switching servers, changing protocol settings, or enabling split tunneling, because each change can alter how traffic is routed.
Check DNS resolution
When you enter a domain name, a DNS resolver helps translate it into an address. A DNS leak occurs when a request that you expected to travel through the VPN is instead sent through another resolver, such as one supplied by your internet provider or local network. A test page may display the resolver’s organization or location. The displayed resolver does not always identify the person who can see a particular request, so interpret the result alongside the VPN client’s DNS settings and the service’s documentation.
- Disconnect the VPN and run a DNS leak test to establish what resolver information is visible on your usual connection.
- Connect the VPN, wait for the client to report an active connection, and run the same test again.
- Check whether the resolver information changes as expected and whether the client is configured to use its intended DNS handling.
- If the result is unexpected, reconnect, test another route, and review system DNS, browser secure-DNS settings, and any custom resolver configuration.
Encrypted DNS in a browser can complicate interpretation. A browser may send DNS requests to a separately configured resolver instead of using the operating system’s resolver. That does not automatically mean a leak, but it means you should understand which resolver is being used and whether the browser’s traffic is routed through the VPN. Avoid changing several DNS settings at once: record the original setting, alter one item, and test again so you can identify the cause.
Check WebRTC address exposure
WebRTC is a set of browser technologies used for real-time communication, including voice and video features. Under some browser and network configurations, a WebRTC test may reveal IP address information that differs from what you expect through the VPN. Modern browsers and WebRTC implementations may limit exposure of local network addresses, so the exact output varies. A result containing an address is not automatically proof that your real public address was exposed; distinguish local, private, and public address information and compare it with the VPN-connected result.
Use a reputable WebRTC test page, run it while connected, and compare the reported public address with the VPN exit address shown by a separate IP check. If your ordinary public address appears while the VPN is active, review browser privacy controls and the VPN client’s routing options. Browser extensions that alter WebRTC behavior can affect calling and conferencing, so test the sites and features you rely on after making a change. Do not install an unknown extension just because it promises to hide an address.
IPv6 deserves a separate check. Some networks and services use IPv6 alongside IPv4. If the VPN client does not route IPv6, handle it safely, or block it while disconnected, IPv6 traffic may take a different path. Check whether the client documents IPv6 support and whether your tests show a public IPv6 address that is not associated with the VPN route. Do not assume that an IPv4-only result proves all traffic is covered.
Practical settings for safer everyday use
Start with the official client or a compatible client that you understand and obtain from a trustworthy source. Keep the operating system, browser, and VPN app updated. A VPN subscription or imported configuration is sensitive: do not post it publicly, send it to an unfamiliar converter, or include access credentials when asking for help. If you use a third-party client, confirm that it supports the subscription format and protocols you intend to use, and review its routing rules rather than assuming every app is covered.
Use a kill switch if your client provides one and if its behavior fits your needs. A kill switch is intended to block selected traffic when the VPN connection drops, but its coverage can vary by operating system, client, and configuration. It may not control traffic from every system service, and it can interrupt local network access or captive-portal sign-in. Test how it behaves before relying on it for a sensitive task. On a laptop, also check whether the VPN reconnects after sleep or a change from Wi-Fi to mobile tethering.
Review split tunneling carefully. It lets you route selected apps or destinations outside the VPN, which can be useful for local services or applications that require a direct connection. The trade-off is that excluded traffic does not receive the tunnel’s network protection and may reveal your ordinary network address to its destination. If privacy is your priority, use the simplest routing mode that meets your needs and verify the path of the apps that matter.
On public Wi-Fi, connect before signing in to sensitive services where practical, but do not treat the VPN as a substitute for basic precautions. Confirm the network name with the venue, avoid unexpected certificate warnings, use HTTPS, and do not approve login prompts you did not initiate. If a captive portal must be completed first, use only the information required to get online, then connect the VPN and verify that it is active. Be cautious about file sharing, remote access, and automatic connection to remembered open networks.
For sensitive logins, use a unique password and multi-factor authentication when available. A VPN does not stop phishing pages, malicious browser extensions, keyloggers, or a person who has access to an unlocked device. If a login page is reached through an unexpected link, navigate to the service directly instead. A password manager can help you avoid entering credentials on a lookalike domain; check the address carefully even when the VPN is connected.
When troubleshooting, change one setting at a time and keep a note of what you changed. If DNS requests appear to use an unexpected resolver, check the client’s DNS mode and any browser-level secure-DNS setting. If an address check shows your ordinary public address, review split tunneling, IPv6 handling, and whether the affected application is included in the VPN route. If the connection fails after enabling a kill switch, disconnect through the client controls or restore the previous setting rather than repeatedly changing unrelated network options.
A simple privacy check routine
Use a repeatable routine whenever you install a client, change a route, or notice that an app behaves differently. First, confirm that the client is connected and that the operating system shows the expected network state. Next, check the public IP, DNS resolver, and WebRTC behavior using more than one independent diagnostic where appropriate. Then open the specific apps you care about: a browser test cannot prove that a separate messaging or media app follows the same route.
After a system update or a network change, repeat the checks that are relevant to your setup. A laptop moving between home Wi-Fi, workplace networks, and tethering may receive different DNS and IPv6 settings. A mobile device may switch between Wi-Fi and cellular service. A VPN can reconnect successfully while a particular application continues to use a separate route or cached connection, so close and reopen that app when troubleshooting.
Keep the checks proportionate to the risk. For routine browsing, a clear privacy policy, current client, active tunnel, HTTPS, and a basic leak check may be a reasonable baseline. For higher-risk activity, consider whether the device itself is trustworthy, whether the account identifies you, whether the destination can correlate your behavior, and whether you need advice from a qualified security professional. No browser test can validate every part of a provider’s logging practices or every component of your device.
Good privacy decisions come from combining several controls rather than relying on one label. A VPN can reduce exposure to the local network and change the public address presented to destinations. HTTPS protects data between the browser and supported websites. Account security, careful link handling, software updates, and a clear understanding of routing settings address risks that a tunnel cannot. Treat “no logs,” “secure,” and “anonymous” as claims to evaluate against evidence and your own needs—not as substitutes for checking how the connection actually works.