A VPN can improve privacy on an untrusted network, but the word “protected” covers several different things. A VPN usually encrypts traffic between your device and the VPN server and routes selected traffic through that server. It does not make every app private, hide your activity from every service, or prevent malware and phishing. To judge whether a setup is working as intended, check what the provider can observe, confirm that DNS and browser traffic follow the expected route, and understand what encryption does—and does not—cover.
Use the checks below as a repeatable review rather than a one-time badge of approval. Results can differ by device, browser, network, and client mode. A browser test cannot verify every app, and a successful connection icon does not prove that all traffic is using the tunnel. If you need platform-specific setup steps, start with the quick start guide; for account or service questions, consult the help center.
Define what privacy you need
Before evaluating a provider or changing settings, identify the threat you are trying to reduce. On public Wi-Fi, you may want to make it harder for someone on the same local network to inspect unencrypted traffic. When using a VPN on a home connection, you may want your internet provider to see less about the destinations you contact directly. When browsing, you may want to reduce exposure of your network’s public IP address to websites. These are related goals, but they are not the same guarantee.
A VPN moves part of the trust relationship. Instead of sending traffic directly from your device through your internet provider to a destination, selected traffic travels through an encrypted connection to a VPN server. The VPN provider operates that server and can potentially observe information associated with the traffic it handles. Websites and apps still receive the information you choose to provide, and they may identify you through an account, cookies, browser characteristics, or app telemetry. A VPN does not erase those identifiers.
- ✅ Decide whether your priority is safer traffic on shared Wi-Fi, a different network exit, or limiting exposure of DNS requests to your local network.
- ✅ Check which apps and destinations are included in the VPN tunnel, especially when split tunneling or per-app rules are enabled.
- ✅ Keep HTTPS enabled. A VPN tunnel and HTTPS protect different parts of a connection and can work together.
- ❌ Don’t assume that a changed public IP address makes you anonymous or prevents websites from recognizing your account.
- ❌ Don’t treat a VPN as protection against unsafe downloads, phishing pages, weak passwords, or malicious browser extensions.
This distinction matters when interpreting tests. An IP lookup can tell you which public exit address a browser appears to use; it cannot tell you whether an account provider stores activity. A DNS test can show which resolver answered particular lookups; it cannot prove that the provider keeps no records. Treat each result as evidence about one part of the setup, not as a complete privacy certification.
Review no-logs claims with care
“No logs” is a broad phrase, and providers may use it to describe different categories of information. Read the privacy policy and any technical explanations to see what is meant by connection logs, activity logs, diagnostic data, account records, payment records, and support conversations. A policy may say that browsing activity is not recorded while still describing limited operational data used to maintain an account or troubleshoot a service. The important question is not whether a page contains the words “no logs,” but what data is collected, why it is collected, how long it is retained, and who can access it.
Look for a clear explanation of collection and retention rather than relying only on a short marketing statement. Check whether the policy distinguishes information needed to provide the service from information about destinations or browsing activity. See whether it explains data sharing with processors, how legal requests are handled, and how users can contact the provider about privacy questions. If a policy is unclear, ask for clarification before relying on assumptions. Also check the policy’s publication or revision information: a statement you read earlier may no longer describe current practices.
Independent audits or assessments can add useful evidence, but they have a scope. Read what systems, processes, and dates an assessment covers, and whether its conclusions are publicly available. An audit of a particular infrastructure or policy process does not automatically verify every app, server, operating practice, or future change. Likewise, a provider’s location or a short slogan alone does not establish how it handles data. Look for specific, current explanations and be cautious about claims that promise absolute anonymity.
Consider account and payment data separately from network activity. A service may need account information to manage access, and payment providers may process transaction details. If minimizing identifying information is important to you, check what registration details are required and which payment methods are offered. Do not provide false information or assume that a payment choice makes all other activity untraceable; the goal is to understand the data flow and make an informed choice.
Test IP, DNS, and WebRTC behavior
Run leak checks after connecting to the VPN, using the browser and network you actually plan to use. First note the public IP address and approximate region shown before connecting. Connect to the VPN, reload the same kind of IP lookup page, and check whether the browser now shows the expected VPN exit. If it still shows your usual network address, confirm that the client is connected, that the browser is included in the route, and that no proxy rule or split-tunneling exception is bypassing the VPN.
Next, use a DNS leak test that lists the resolvers handling its test lookups. Run it while connected and compare the results with what you expect from the VPN configuration. A resolver name or location may not correspond neatly to the VPN exit location, so do not judge by country labels alone. Focus on whether the results appear to come from the expected DNS path or from an unexpected local internet provider. If you are unsure, check the client’s DNS settings and the provider’s documentation before changing operating-system settings at random.
WebRTC is a set of browser technologies used for real-time communication, such as voice or video. Depending on browser behavior and network configuration, a WebRTC test may display network addresses that differ from the address shown by a basic IP lookup. A test result needs interpretation: a private local address is not the same as exposing your public home address, and browser protections vary. Review the browser’s current privacy controls and retest after changes. Do not install an unfamiliar extension simply because a test page recommends one.
Check IPv4 and IPv6 behavior if your device and network support both. Some configurations route one address family through the VPN but handle the other differently. A test that only checks IPv4 can miss an IPv6 routing issue, while a test page that does not support IPv6 cannot confirm how IPv6 traffic behaves. If results differ, use the VPN client’s documented IPv6 options, disable or restrict a route only if the client or operating system supports doing so safely, and test again.
| Check | What it can help show | What it cannot prove | What to do if the result is unexpected |
|---|---|---|---|
| Public IP lookup | Whether the tested browser appears to use the VPN exit address. | Whether every app uses the tunnel or whether a provider keeps logs. | Check connection status, app routing, proxy settings, and split-tunnel rules. |
| DNS leak test | Which resolvers answered the test’s DNS requests. | Every DNS request from every app, or the provider’s retention practices. | Review DNS mode, operating-system settings, and the VPN client’s guidance. |
| WebRTC test | What address information the browser exposes to that test. | That all browser traffic is private or that every displayed address is public. | Check browser privacy controls and distinguish local from public addresses. |
Repeat checks after a meaningful change: switching networks, changing the VPN protocol, enabling split tunneling, or updating browser privacy settings. Also test after reconnecting if the client reports a dropped connection. A single successful result is useful, but it is only a snapshot of that browser and configuration at that time. For troubleshooting, change one setting at a time and record what changed; otherwise, it becomes difficult to identify which adjustment fixed or caused the behavior.
Understand encryption and protocols
Encryption is a way to make data unreadable to parties that do not have the required keys. In a typical VPN setup, the client and VPN server establish an encrypted tunnel. This helps protect traffic between your device and that server from observation on the local network. The VPN server then forwards traffic toward its destination. For websites using HTTPS, the browser also encrypts the connection to the website, so the VPN tunnel and HTTPS form separate layers with different endpoints.
That separation explains both the benefit and the limit. On shared Wi-Fi, the tunnel can make it harder for another person on the same network to inspect the contents of traffic traveling inside it. HTTPS continues to protect the contents between your browser and the website beyond the VPN server. However, the VPN provider is the operator of the tunnel endpoint, and it may handle connection metadata needed to route traffic. HTTPS does not conceal all metadata, and a VPN does not make the destination website unable to see information you submit or associate with your account.
VPN protocols define how clients establish and maintain tunnels, including aspects of authentication, encryption, and transport. Names such as WireGuard, OpenVPN, IKEv2, Shadowsocks, VMess, Trojan, and Hysteria2 refer to different technologies or protocol families and are not interchangeable labels for identical protections. A protocol name alone does not tell you how a particular service has configured it, which options its client uses, or whether all traffic is routed through it. Check the service’s documentation and client settings rather than assuming that a protocol name guarantees a particular security result.
When reviewing a client, confirm that it uses a supported, documented configuration and that it is updated through a trusted distribution channel. Avoid manually copying settings from an unknown source. If the client offers an automatic protocol choice, it can be reasonable to begin with that documented default, then change it only to address a specific compatibility or connectivity issue. A protocol change may affect how the tunnel connects, but it does not replace checking DNS routing, application rules, or the privacy policy.
Remember that encryption cannot correct a compromised device. A malicious app can read information before it enters the tunnel or after it leaves the tunnel. A browser extension with excessive permissions may observe activity inside the browser. Keep your operating system and apps updated, use screen locks and strong account authentication, and install software only from sources you trust. These measures address risks a network tunnel cannot solve.
Use practical settings for everyday browsing
For public Wi-Fi, connect the VPN before opening sensitive services, and confirm the client reports an active connection. If the client provides a kill switch or network-lock option, read what it blocks and when it activates. Such a feature is intended to reduce the chance that traffic leaves outside the tunnel during a disconnect, but its behavior depends on the client, operating system, and configuration. Do not assume that the feature is enabled by default; test the documented behavior in a non-sensitive situation and learn how to reconnect if it blocks access.
Keep routing rules understandable. If all traffic should use the VPN, choose a mode that routes all supported traffic and verify the result for the apps you care about. If split tunneling is necessary, list which apps are excluded and why. An excluded browser, messaging app, or background service may use the ordinary network path even while the VPN client shows as connected. On phones, per-app VPN behavior and operating-system privacy features can also affect results, so test the actual apps rather than relying only on a browser check.
Use secure websites and apps, and pay attention to certificate or account warnings instead of dismissing them because a VPN is active. Avoid entering sensitive information on pages you did not intend to visit. Use unique passwords and multifactor authentication where available. When you leave a shared network, disconnect if you no longer need the VPN, or keep it on if that matches your privacy needs and the client’s documented behavior. The right choice depends on your threat model and device setup, not on a universal rule.
- ✅ Install the official client for your platform and keep it updated.
- ✅ Confirm the active route, DNS behavior, and browser settings after changing networks or routing rules.
- ✅ Use HTTPS and account security controls even when the VPN is connected.
- ✅ Review permissions for VPN apps, browser extensions, and apps that handle sensitive information.
- ❌ Don’t run multiple VPN or proxy clients at once unless you understand how their routes interact.
- ❌ Don’t rely on a VPN to stop tracking by logged-in accounts, remove cookies, or protect a device already compromised by malware.
If a test indicates a possible leak, avoid using that result as proof of a breach. Confirm that the test is reporting a public address or an unexpected resolver, check whether the browser or app is intentionally excluded from the tunnel, and repeat the test after changing one relevant setting. If the behavior persists, save the client version, operating system, network type, and test result, then contact support through the provider’s official channel. Avoid sharing account credentials or sensitive browsing details when requesting help.
A useful privacy review combines policy reading, configuration checks, and repeatable tests. Read what the provider says it collects, verify the route on the device and apps you use, and understand where encryption begins and ends. Recheck after updates or configuration changes, and treat unexpected results as a troubleshooting signal rather than a reason to assume either perfect protection or complete failure.