When comparing privacy-focused VPNs in 2026, don’t treat “no logs” as a spec you can compare at face value. The key question is what the provider means: does it avoid storing browsing activity, or does it also discard connection times, source IP addresses and diagnostic records? How the provider uses, retains and deletes this data determines what its claim actually covers. You don’t need to read every legal document, but you should be able to find clear answers in the published policy and use the sign-up process and payment options to work out what information you’ll leave behind.
Privacy isn’t determined by the route alone. The public Wi-Fi operator, VPN provider, websites you visit and apps on your device all play different roles. A VPN can encrypt traffic between your device and the VPN exit, making it harder for the local network to see what passes through that connection. Websites may still identify you through your sign-in, browser storage or information you submit. Consider each layer separately instead of treating “encryption” as a substitute for every other check.
Break down the no-logs claim
When reading a privacy policy, look for specific data categories rather than stopping at a prominent “no logs” headline. Browsing activity, destinations, connection metadata and account details are not the same thing. One policy might clearly state that it doesn’t record browsing activity but may temporarily retain connection errors for troubleshooting. Another might say it collects only account and transaction details. Don’t treat them as equivalent just because both say they take privacy seriously.
| What to check | What to look for | What to do if the answer isn’t clear |
|---|---|---|
| Browsing and connection data | Does the provider retain destinations, source IP addresses, connection times or data usage? If so, what is each item used for? | Don’t assume “we don’t record browsing activity” means “we don’t retain any connection data.” |
| Diagnostic data | Are crash reports or error logs sent automatically? Can you turn them off in the app? Could they include device identifiers? | Check the diagnostic settings in the app and ask the provider which fields are collected. |
| Account and payment details | What information is required to create an account? Who processes orders, and what happens to related data when you delete your account? | Compare connection logs separately from the information needed to maintain an account. |
| Policy scope | Which products does the policy cover? Are exceptions listed? How are users notified of changes? | Read the full, current policy. Ask support about anything that remains unclear. |
A policy you can verify should explain what is collected, why it’s collected, when it’s deleted and who can process it. Without a clear scope, readers can’t tell the difference between temporary troubleshooting records and long-term retention. If a public audit report is available, check what it covered and when it was conducted. A finding about one system doesn’t automatically apply to every app, route or operational process. Don’t fill in the blanks with an assumed audit conclusion when there’s nothing to verify.
Treat “no logs” as a policy claim to verify, not a measure of anonymity. First confirm which data it covers, then decide whether that fits how you plan to use the service.
Sign-up and payments: understand what information is retained
The sign-up page shows what information a provider asks you to provide. Before creating an account, check required fields, verification steps, account recovery options and how to delete the account. If an email address is required, it will become part of your account information. If it isn’t required, make sure it isn’t requested later in the process. Providing less information can reduce the data linked to you, but it doesn’t replace checking connection logs and app behavior.
Payments also need to be considered in context. Different payment methods give payment processors different transaction details, while providers typically still need to know which account an order belongs to, whether a plan is active and how refunds are handled. So “less information shared during payment” doesn’t mean the provider has no order records at all. Review the checkout page and privacy policy to see who processes the transaction, which fields the provider receives and how billing details are retained. Don’t infer a payment method’s privacy level from its icon alone.
If the terms for account deletion, order disputes or refunds are vague, ask a specific question: after an account is deleted, which details are retained for billing or other necessary processes? A clear answer is more useful than a general promise to protect your privacy. VPNZU’s plans and refund terms are listed on the Plans page. Check the current privacy policy separately—refund terms don’t tell you what the service logs.
Choosing and using a VPN on public Wi-Fi
When using shared Wi-Fi at a café, station or hotel, make sure you’re joining the venue’s network before connecting to a VPN. A similar network name isn’t proof that an access point is legitimate, and signal strength can’t verify its source. Once connected, the local network will generally see encrypted traffic between your device and the VPN exit. Traffic from the exit to a website still depends on whether the site uses HTTPS. Don’t ignore a browser certificate warning just because your VPN is connected.
Choose an exit region based on what you need to access and the service’s regional requirements—not simply the geographically farthest location. Distance, current network quality and congestion can all affect performance, so test the connection on your own network. A direct route connects your device straight to the exit; a relay adds a forwarding step; IEPL refers to dedicated transmission capacity. These terms describe a route or resource type. They don’t prove how a provider handles logs or guarantee that a route will be faster on every network. See the global server locations page for available regions, then adjust based on how the connection performs.
- Join a Wi-Fi network whose source you’ve confirmed, and complete any sign-in required by the venue before opening the app. Check for pending security updates to your operating system and VPN app.
- Choose an exit that meets your access needs, then check the app’s connection status. Don’t assume that “connected” means every app is using the same route.
- When visiting a site that requires a sign-in, check its domain and any browser certificate warnings. Enable any additional protections offered by the account provider for important accounts.
- Disconnect from the shared network when you’re done. If your network environment changes, check the app’s connection and split-tunneling settings again.
A VPN can’t identify fake websites for you or remove malware already on your device. If you see a certificate warning, suspicious download or unusual sign-in alert, address it first and don’t enter account details.
DNS and split tunneling: check where your traffic goes
Before your device can load a website, it usually has to look up the domain name. Even if web traffic passes through a VPN, DNS requests may still go to a resolver specified by the local network, potentially exposing the domains you visit. That’s the route to check when investigating DNS leaks. Don’t draw conclusions just because a test page shows a different region: browser Secure DNS, system settings and app configuration can all affect the results.
For a useful check, note your network and DNS settings before connecting. Once the VPN is on, see whether the app offers DNS routing or leak protection, then compare results using the same browser setup. If requests still appear to use the local resolver, check the system proxy and how the app handles DNS, then see whether the browser has its own DNS setting enabled. A test page reflects requests at that moment; it isn’t a guarantee of ongoing privacy.
Split-tunneling rules decide which apps or domains use the VPN and which connect directly. If you need to protect an app on public Wi-Fi, confirm that it actually matches the VPN rule; a “browser only” setup won’t automatically cover other programs. Routing local services through a remote exit by mistake can also cause access or sign-in problems. After changing a rule, reconnect the app you want to use and verify its route rather than relying on the rule name. For help with client setup, see the user guides.
Support for system proxies, virtual network interfaces, background operation and handling dropped connections varies by platform. A desktop app’s traffic coverage isn’t necessarily the same as a mobile app’s, and a browser extension doesn’t mean the whole device is protected. Before relying on a feature such as “block traffic if the VPN disconnects,” test it on your device: disconnect manually and see whether the apps you want to protect can still access the network. If the feature isn’t available, plan around that limitation.
Protocol names don’t replace a privacy policy
Shadowsocks, VMess, Trojan, VLESS, Hysteria2 and TUIC are different proxy protocols or transport options. They involve different handshakes, encryption configurations and transport methods, but a protocol name doesn’t tell you whether the operator retains account details or connection records. Nor does it prove that a client is configured correctly. Evaluate the protocol implementation, client settings and provider’s data-handling policy separately.
Don’t confuse “encrypted in transit” with “leaves no trace.” The first describes how data travels over a connection; the second depends on what the provider retains, what websites receive and what your device stores. Even with a working VPN route, websites you sign in to may still identify you through your account. Switching protocols won’t erase your browser history either. When a recommendation focuses on a protocol name, it’s more useful to ask about log scope, DNS routing and which traffic the app actually covers.
Turn your choice into an actionable checklist
The right privacy-focused VPN isn’t necessarily the one with the highest score on a single metric. It’s one whose data-handling boundaries you can understand, that supports the access you need and whose setup you can verify on your own devices. First rule out options with unclear policies or vague explanations of sign-up and billing data. Then test the routes and app in the environment where you’ll actually use them. Work through this checklist before and after trying a service:
- ✅ Find the current privacy policy and distinguish browsing activity, connection records, diagnostic data and account details. Note anything the policy doesn’t clearly explain.
- ✅ Check required sign-up information, account deletion terms and the payment processor. Decide which details you’re comfortable sharing.
- ✅ Choose an exit region based on your needs and test the websites and apps you use instead of relying on route names.
- ✅ Check DNS, split tunneling and traffic behavior after disconnection on the devices you actually use. Repeat the checks on each platform.
- ❌ Don’t treat “no logs,” a protocol name, a speed test or a single test result as complete proof of privacy.
For specific questions about connections, billing or app settings, see the FAQs. Review your privacy choices as the service’s terms and your usage change; a single decision doesn’t have to be permanent.