Is a VPN Safe? Privacy, Encryption, and Leak Checks

A VPN can improve privacy on an untrusted network, but it does not make every activity private or secure by itself. Its protection depends on what the VPN encrypts, how your device routes traffic, which settings are enabled, and what the provider records. A connected icon is not proof that DNS requests, browser traffic, or every app is using the route you intended.

This guide explains how to evaluate a VPN’s privacy claims, what encryption does and does not protect, and how to check for DNS or WebRTC leaks. It also covers Kill Switch behavior and practical precautions for public Wi-Fi. The goal is not to promise anonymity, but to help you identify what is protected and what still needs attention.

What a VPN protects—and what it does not

A VPN creates an encrypted connection between your device and a VPN server. On a network where other people could observe local traffic, such as shared public Wi-Fi, this can make it harder for someone on that same network to read the contents of traffic traveling through the tunnel. The network operator can generally still see that your device is communicating with a VPN endpoint, along with some connection metadata such as timing and volume.

After traffic leaves the VPN server, it continues to its destination using the protections available there. A VPN does not replace HTTPS: HTTPS helps protect the connection between your browser and a website, including when traffic exits the VPN server. If a site does not use HTTPS, the VPN’s encrypted tunnel ends at the VPN server, so the connection beyond that point may not have equivalent content protection. For sensitive accounts, check for HTTPS and use the site’s own security features.

A VPN also does not prevent phishing, malicious downloads, weak passwords, compromised devices, or tracking through cookies and account sign-ins. If you log in to a service, that service can still associate activity with your account. Browser fingerprinting and information you voluntarily submit are separate from the network route. Treat a VPN as one layer in a broader privacy and security setup, not as a tool that makes every action anonymous.

A VPN changes which network can observe parts of your connection; it does not remove every observer. Consider the local network, VPN provider, destination service, and your own device as separate parts of the privacy picture.

For example, a VPN may reduce the visibility of your browsing traffic to a public hotspot operator, while the VPN provider handles your connection to the wider internet. The destination website can still see information you provide and may receive an IP address associated with the VPN server. These are different trust relationships, so a useful privacy check asks not only “Is the traffic encrypted?” but also “Who can see which part, and for how long?”

How to evaluate a provider’s privacy claims

“No logs” is not a single technical standard. One provider may use the phrase to mean it does not retain browsing history, while another may retain connection timestamps, bandwidth totals, diagnostic records, or account information. Read the privacy policy and service terms rather than relying on a badge or slogan. Look for specific descriptions of data categories, retention periods, purposes, sharing practices, and the process for handling legal requests.

It is useful to distinguish data needed to operate an account from information about network activity. An account system may need credentials and subscription status, while a VPN service may also process operational information to maintain a connection or troubleshoot a fault. The important questions are what is collected, whether it can be linked to a particular user, how long it is kept, and whether it is used for purposes beyond providing the service.

Independent assessments can add context, but check their scope and date. An audit might examine a particular application version, infrastructure component, or policy implementation rather than every service and future update. A clear report should state what was examined and what limitations applied. A provider’s public claims, technical design, and actual operating practices are related, but they are not interchangeable proof.

• ✅ Read the policy for concrete data categories, not just the phrase “no logs.”
• ✅ Check whether diagnostics, crash reports, and optional analytics can be controlled.
• ✅ Review account security options and use a unique password.
• ❌ Do not assume that an audit covers every app, server, or later policy change.
• ❌ Do not treat a VPN connection as a guarantee that the provider cannot observe metadata.

Consider your own threat model before choosing a service. If your main concern is other users on a shared hotspot, a correctly configured VPN and HTTPS may address much of that exposure. If you need to protect highly sensitive work data, follow your organization’s approved security tools and policies; a consumer VPN should not be assumed to replace managed remote access. For people comparing travel connectivity options, VPN for Expats in China is one place to review the service context, but privacy decisions should still be based on the policy and settings that apply to your account.

Encryption, protocols, and the limits of a secure tunnel

Encryption protects data while it travels through the VPN tunnel, provided the client and server negotiate and maintain the connection correctly. Modern VPN protocols use cryptographic mechanisms to authenticate the connection and protect traffic in transit. The protocol name alone, however, does not tell you whether a particular app is configured safely, whether all traffic is routed through it, or whether the device switches back to an unprotected route after a network change.

Use the official client for your operating system when it is available, keep it updated, and review its connection options. Third-party clients such as Clash Verge, sing-box, or Shadowrocket can be useful with compatible configurations, but they are not interchangeable with every VPN protocol. A subscription link may provide proxy profiles rather than a traditional full-device VPN tunnel. Confirm which traffic types the chosen client handles, how DNS is configured, whether IPv6 is covered, and whether the selected mode applies to all apps or only matching rules.

Split tunneling is another setting worth understanding. It intentionally sends some apps or destinations outside the VPN while other traffic uses the tunnel. That can be useful for local services or applications that need a direct connection, but it also means the VPN does not protect every connection. If you enable split tunneling, review the included and excluded apps after updates, and test the apps that matter rather than inferring coverage from the client’s overall connection status.

Finally, a VPN’s encryption does not make a device trustworthy. An outdated operating system, a malicious browser extension, or malware can access information before it is encrypted or after it is decrypted. Keep the operating system and browser current, limit unnecessary permissions, and use reputable endpoint security appropriate to your device.

How to check for DNS, WebRTC, and routing leaks

DNS translates domain names into network addresses. If a device sends DNS requests outside the VPN tunnel, the resolver handling those requests may learn which domains are being looked up, even when the subsequent website connection uses the VPN. A DNS leak check can help identify the resolver visible from a browser session, but it is a snapshot of the current setup, not a permanent guarantee. Results can differ between browsers, apps, networks, and client modes.

Run checks with a deliberate process:

1. Record a baseline. Note the network you are using and whether the VPN is disconnected. Do not enter private account information on an unfamiliar test page.
2. Connect the VPN and confirm its status. Wait for the client to report a completed connection. If you use a proxy client, confirm that the active mode and rules are the ones you intended.
3. Check the visible address and DNS resolvers. Compare the results with the disconnected baseline. A resolver name or location may not match the VPN server’s location exactly, so interpret the result carefully rather than treating every difference as a leak.
4. Test WebRTC separately. In some browsers, WebRTC features can reveal network addresses to a webpage as part of peer-to-peer communication. Check the browser’s current behavior and privacy controls; a result that shows a local or private address is not automatically the same as exposing your public address.
5. Repeat after a change. Recheck after switching Wi-Fi networks, changing VPN protocols or modes, enabling split tunneling, or updating the client or browser.

Also consider IPv6. If the VPN or proxy configuration handles IPv4 but leaves IPv6 traffic outside the intended route, a test may show an address or connection path that differs from expectations. Do not disable IPv6 reflexively across the whole device without understanding the consequences. First check whether the client supports IPv6 routing or blocking, then use its documented setting and verify the result.

For a meaningful test, close unrelated apps that may maintain their own network connections, and avoid drawing conclusions from a single browser tab. Some browsers use secure DNS settings that differ from the operating system’s resolver; some apps use their own DNS behavior. If a suspected leak persists, disconnect, review the client’s DNS and routing settings, and test again. When using a third-party configuration, verify its source and contents before importing it.

Set up and test the Kill Switch

A Kill Switch is intended to block selected traffic if the VPN connection drops, helping prevent the device from silently using its ordinary network route. Its exact behavior varies by operating system and client. Some options apply only while the app is open; others use operating-system network controls and can remain active until the VPN reconnects or the setting is changed. Read the client’s description so you know which traffic is blocked and under what conditions.

Enable the Kill Switch if uninterrupted routing matters, then test it cautiously. Use a non-sensitive browsing session, connect the VPN, and follow the client’s documented test procedure or temporarily interrupt the connection in a controlled way. Confirm whether traffic is blocked, whether local network access remains available, and how the client behaves when connectivity returns. Do not perform this test during a critical call, file transfer, or task that could be disrupted.

Check for conflicts with other network tools. A firewall, another VPN, a proxy application, endpoint security software, or a custom DNS tool may modify routing rules. Running multiple tunneling clients at once can produce confusing results, including traffic being blocked unexpectedly or one app taking precedence over another. If the connection fails after enabling a Kill Switch, disconnect other network tools, restart the VPN client, and change one setting at a time.

On mobile devices, background restrictions and battery-saving features may affect whether a client stays connected. Review the operating system’s VPN permission, background activity controls, and any always-on or block-without-VPN options that are available. Their names and behavior differ by platform and version, so rely on current system documentation rather than assuming the same toggle exists everywhere.

Use public Wi-Fi with practical safeguards

A VPN can be useful on café, hotel, airport, or other shared Wi-Fi, but first make sure you have joined the intended network. Fraudulent hotspots can imitate legitimate network names. When possible, confirm the network name with staff, and avoid automatically joining unknown open networks. A VPN does not prove that a hotspot is genuine.

Many public networks require a captive portal where you accept terms or complete sign-in before internet access is granted. Complete that step before troubleshooting the VPN. If the portal does not load while the VPN is active, disconnect temporarily, open the portal, and reconnect once access is authorized. Do not enter sensitive credentials into a page that looks suspicious or whose address does not match the organization you expect.

• ✅ Keep your operating system, browser, and VPN client updated.
• ✅ Use HTTPS websites and multifactor authentication for important accounts.
• ✅ Disable automatic connection to unfamiliar Wi-Fi networks.
• ✅ Turn off file sharing and device discovery on networks you do not trust.
• ❌ Do not ignore certificate warnings or install a profile supplied by an unknown hotspot.
• ❌ Do not assume that a VPN protects traffic when its client is disconnected or bypassed.

If the VPN repeatedly disconnects, do not keep entering credentials or sending sensitive data while assuming protection remains active. Check the client status, reconnect, and confirm that the Kill Switch behaves as expected. If the network is unstable, switching to a trusted mobile connection may be safer than repeatedly retrying on a questionable hotspot. Avoid making sensitive account changes on a device you do not control.

Privacy is strongest when the pieces agree: a provider policy you understand, an appropriate client and protocol, routing that matches your needs, leak checks performed after meaningful changes, and safe habits on the device itself. No single setting can substitute for that combination. Treat the VPN as one part of your security plan, verify its behavior instead of relying only on its status icon, and revisit the configuration when your apps, networks, or privacy requirements change.