Finding a privacy VPN you can trust is rarely about the price table. The hard part is two invisible things: how a no-logs claim can actually be verified, and how little personal data you can hand over at signup. Neither is a matter of gut feeling — both come down to clauses you can compare line by line and checks you can run yourself. Below, in order: what providers actually mean by logging, the minimum-data approach to signup and payment, the limits of public Wi-Fi, and a self-check list at the end.
The short version first: no-logs is a policy statement, not a technical guarantee. No provider can erase the traces left by upstream data centers, payment processors, or your own local network. What can be verified is whether it spells out what is not recorded, how long anything is kept, and under which circumstances exceptions apply.
What a No-Logs Promise Actually Covers
On its own, the sentence “we don’t keep logs” carries no information, because logs come in several categories whose sensitivity differs by an order of magnitude:
- Connection logs: account, connection time, duration, exit node used, assigned IP, total traffic. They don’t reveal what you visited, but they are enough to assemble a timeline of behavior.
- Usage logs: domains and IPs visited, DNS queries, session content. This is the most sensitive category, and it is what “we don’t log browsing activity” really refers to.
- Diagnostic logs: client version, OS version, crash stacks. Used for troubleshooting, usually only weakly tied to an account.
So the questions to ask are concrete: which category is not recorded? Is the part that is recorded tied to an account? How long is it kept, and when is it deleted? Do anti-abuse and billing write anything temporarily? Answer those and a slogan becomes a clause you can judge.
| Statement level | Typical wording | What you can verify | What to do |
|---|---|---|---|
| Blanket claim | “We keep no logs at all” | A single sentence, with no definitions and no exceptions | Keep looking for the actual clauses; if there are none, treat it as undisclosed |
| Category breakdown | Separate treatment for connection, usage, and diagnostic logs | You can see which categories are kept and for how long | Prefer the tier that makes “no usage logs” the default |
| Exception clauses | Temporary records for anti-abuse, billing reconciliation, or lawful requests | You can see where the promise ends | Exceptions aren’t automatically a flaw; stated clearly beats hidden |
| Cross-checkable material | Third-party audit reports, transparency reports, terms change history | Outside material exists for cross-verification | Start with the audit’s date, server scope, and the firm that performed it |
A third-party audit covers a specific period, specific data centers, and specific processes — it does not mean every server and every hour was examined. Read the scope and the date first, then the conclusion.
How to Verify: From Clauses to Evidence
Break verification into five steps, and keep them in order. The first four work with any provider; the fifth depends on whether they publish material.
- Read the definitions section, not the homepage slogan. Privacy policies usually have a passage that defines logs and separates connection, usage, and diagnostic data. If that passage is missing, you can usually move on.
- Look for exceptions. Anti-abuse, billing reconciliation, and legal requests are the three most common. Exceptions are normal; what matters is whether the trigger conditions and retention limits are spelled out.
- Check retention periods and deletion. “Kept for 30 days” and “not kept” are two very different positions — at least the first is predictable.
- Check which fields signup and payment require. However clean the policy reads, a long list of required information at signup cancels most of the value.
- Check for outside material you can compare against. Third-party audits, transparency reports, public histories of terms changes — having them doesn’t prove trustworthiness, but at least they can be tested.
Minimal Signup Data: Only the Fields You Need
Signup is the first point of exposure, and there is one test: if a field can be left empty, leave it empty. Fewer fields means fewer anchors to link across platforms.
This site’s approach is no email address required — a username and password are enough. Email deserves its own paragraph because it is the universal primary key: once an email is tied to a service, that single field can string accounts across platforms together. Remove it and the cost of correlation rises noticeably.
Usernames need the same care: don’t reuse an ID from a forum, social network, or another service, and don’t include your real name, birthday, or city. Let a password manager generate a unique password that isn’t shared with any other site. Nor do you need to keep signing in on device after device to share an account — this service allows unlimited simultaneous connections, so there is little reason to spread the account around in the first place.
Payment is the second point of exposure. Alipay, WeChat Pay, and USDT leave very different records: the first two sit on real-name accounts, so the billing side can be linked to a person; USDT moves on-chain, where records are public but can be kept at a distance from your real identity. Each path trades something away — it depends on whom you want to keep out.
Once imported into a client, a subscription link usually carries your user identifier. Don’t paste it into group chats, don’t commit it to public repositories, don’t paste it whole into a support ticket, and mask the tail end in screenshots. Avoid third-party “subscription converter” pages too — the converter sees the whole link. If you suspect a leak, just regenerate it.
Public Wi-Fi: Where the Limits Are
The risk list for public Wi-Fi isn’t long, but every item is real: sniffing on the same subnet, captive portal hijacking, spoofed hotspots with the same name, and swapped DNS. HTTPS blocks most content-level risk; what remains is metadata and the connection setup phase.
A tunnel covers the segment from your device to the exit node: content is encrypted, and when the client takes over DNS, name resolution travels through the tunnel as well. What it does not cover: accounts you are already signed into, an app’s own telemetry and push channels, browser fingerprinting, and root certificates installed on the device — on a managed corporate machine or one where a certificate was installed by hand, interception is still possible.
- After connecting, confirm the exit first: open an IP lookup page and check that the location matches the route you selected.
- Then confirm DNS: the resolver’s location should match the exit region; if it doesn’t, queries are still going out locally.
- Turn on kill switch protection so traffic doesn’t silently fall back to a direct connection when the tunnel drops.
- Turn off “auto-connect to open hotspots” so the device doesn’t join unknown networks without you noticing.
- Keep online banking and corporate admin consoles for networks you trust.
A common misconception is that “once connected, everything goes through the tunnel”. In split-tunnel mode it doesn’t: rules send some domains out directly, and their DNS queries may go to the local resolver too. For privacy-sensitive work, global mode is simpler.
Privacy Details in Protocols and Clients
The protocol determines what your traffic looks like; it does not determine whether the server keeps logs. The two get conflated constantly, and separating them makes things much clearer:
- WireGuard: carried over UDP, a lean handshake, a lightweight implementation, easy on mobile batteries; no traffic obfuscation, so its signature is relatively distinctive.
- OpenVPN: mature and stable, can run over TCP 443, widely compatible — at the cost of heavier handshake and encryption overhead.
- Shadowsocks: essentially a proxy protocol rather than a full VPN; the client has to handle routing and DNS itself.
- VMess / VLESS: VMess depends on time synchronization between client and server; VLESS does no encryption of its own and leaves security to the outer TLS layer.
- Trojan: disguises traffic as an ordinary HTTPS session, relies on a real certificate, and costs a little more to configure.
- Hysteria2 / TUIC: built on QUIC, steadier on weak or lossy networks, and correspondingly sensitive to UDP quality.
Client differences matter just as much. Desktop clients can usually take over system DNS and global routing; mobile platforms impose more limits — on iOS, a system-level network extension handles traffic and DNS is typically resolved inside the tunnel. Don’t guess at these behaviors; verify once on your own device: after connecting, check the exit IP, check which resolver handles DNS, and check whether IPv6 escapes the tunnel — if the tunnel only handles IPv4, IPv6 traffic may go out directly. At the browser level there is also WebRTC, which can expose local addresses; you can restrict or disable it in browser settings.
Split-tunnel rules are another easily overlooked point. The finer the domain-based and GeoIP-based rules, the more traffic bypasses the tunnel, and DNS may fall back to the local resolver. Rules themselves aren’t right or wrong — but know which mode you have enabled.
A Self-Check List You Can Actually Run
The eight items below cover clauses, signup, and connection — work through them one by one:
- ✅ You have read the log definitions in the privacy policy and can say which categories are not recorded and how long anything is kept.
- ✅ You signed up with a unique username and a unique password, reusing no ID from another platform.
- ✅ The subscription link was imported only into the official client, never through a third-party converter page.
- ✅ After connecting, you checked the exit IP and the DNS resolver, and both are in the same region.
- ✅ You confirmed that IPv6 and WebRTC do not bypass the tunnel.
- ✅ Kill switch is on, so a dropped connection doesn’t silently fall back to direct.
- ❌ You did not log into online banking or an admin console over public Wi-Fi.
- ❌ You did not paste the subscription link into a group chat, a public repository, or the body of a ticket.
Conclusion: Turn the Standard into Checkable Items
Privacy has no one-and-done solution, only items you can check. Can you read the clauses? How many fields does signup ask for? Will the subscription link leak out casually? Does the client behave the way you think it does? Running through those four beats reading ten reviews.
When applying that standard to a specific service, start with the facts you can check on the spot:
One last reminder: no-logs is a policy, not a charm. It reduces the risk that comes from data retained on the server side; it doesn’t change the traces you leave in accounts, payments, and devices. Keep those two layers separate and the choice gets much clearer.