A privacy-first VPN does not stand on a no-logs promise alone. Only three things can actually be checked: the exact wording of the privacy policy, which fields signup and payment really collect, and what a tunnel does and does not block on public Wi-Fi. This article breaks those three lines into items you can tick off one by one, and explains what you can compromise on when the budget is tight — and what you cannot.
Start with a premise: no-logs is a promise, not a technical fact anyone can verify remotely. Any provider can put those words on a page, and users have no way to prove from the outside whether they are honoured. So the useful move is not hunting for a service that is absolutely trustworthy, but looking for terms specific enough to be questioned.
No-logs claims come in three tiers — only one can be verified
Group the common wording and it falls roughly into three tiers, with credibility rising as you go.
Tier one: a promise not to sell. The policy says it “values user privacy” and “does not sell data to third parties”. That answers “do you sell?” rather than “do you collect?”. Not selling data is the legal floor in most jurisdictions, so presenting it as a privacy feature says nothing at all.
Tier two: acknowledging necessary processing. The policy states that browsing destinations and content are not logged, while explaining that the account records and total traffic needed for billing are retained, along with retention periods. This is more credible than tier one because it draws its own boundaries — admitting what is kept gives readers something to check.
Tier three: down to the operational level. Where data is generated, where it is stored, who can access it, how it is purged at expiry, and in what form it is disclosed externally. This tier is the rarest, but it is the only one that turns a slogan into something you can question.
| What the policy says | What it actually covers | What to ask next |
|---|---|---|
| Browsing content and destinations are not logged | Content layer | How connection metadata (time, exit node, total traffic) is handled |
| Only the minimum records needed for billing, with retention days stated | Content layer and metadata | Is expiry automated or handled manually? |
| No selling or sharing data with third parties | Business practice | Separate from whether data is collected — one cannot stand in for the other |
| Vague statements about valuing user privacy | Nothing to verify | No specific clauses, so it imposes essentially no constraint |
There is a simple method when reading a policy: look for three fields first — what data is collected, how long it is kept, and who it is shared with. Only when all three are spelled out is there a real commitment; miss one and the rest is marketing copy. Length does not matter; whether the policy answers those three questions does.
Signup and payment are where privacy costs really land
Many people focus entirely on what is logged after connecting and skip the step before it. What the signup form asks for determines whether the account can be tied back to you in person.
Email addresses are the classic example. An address is a long-lived identifier reused across services: the same address appears on forums, shopping sites and cloud services, and a breach at any one of them can let accounts on different platforms be stitched together. A signup flow that asks only for a username and password cuts a large part of that link. VPNCW signup works this way — no email address required.
One thing needs saying: “no email collected” is not the same as “no records at all”. Billing transactions, payment-channel receipts and account creation times exist as soon as a service charges money. What differs is how long they are kept, at what granularity, and whether they are tied to browsing behaviour. That is why the previous section kept returning to retention periods.
Payment methods work the same way. Alipay, WeChat Pay and USDT leave different trails: the first two are tied to real-name accounts, while USDT moves on-chain. Which one you pick depends on how much linkage between payment record and account you are willing to accept. There is no universal answer, and a provider should not be making that call for you.
- ✅ Signup asks only for a username and password — no required email field
- ✅ The policy states which billing records are kept and for how long
- ✅ More than one payment option, so you can pick your comfort level
- ❌ Asks for real name, address, or other fields unrelated to the service
- ❌ The policy is one line about “valuing your privacy” with no specifics
On public Wi-Fi, what an encrypted tunnel blocks — and what it does not
Public Wi-Fi risk is often described in near-mystical terms; broken down, it is quite concrete.
What it stops
Plaintext sniffing on the same subnet. HTTP pages, unencrypted application protocols and some smart-home device traffic are effectively public on an open network. A tunnel pulls that traffic into an encrypted channel, so other people on the same hotspot cannot see the contents.
DNS queries are part of it. By default, domain names are resolved by the DNS server handed out by the local network, so the ISP or hotspot operator can see which domains you visited. With a full tunnel, where resolution happens at the tunnel exit, that link is replaced end to end.
What it does not stop
Phishing pages. If you type your credentials into a fake login page, the encrypted tunnel cannot protect that step, because you handed the data over yourself. Weak passwords, passwords reused across sites, browser fingerprints and already-leaked credentials are likewise outside a VPN's scope.
One more point that is often misunderstood: HTTPS already covers most web pages, and it protects content but does not hide metadata such as which domain you visited. The tunnel fills exactly that gap — the two stack, they do not replace each other.
Practical tip: on captive-portal networks such as hotels and airports, complete the portal sign-in first, then start the client. If the tunnel comes up before authentication, the gateway blocks it — the client just spins and never connects, which is easily mistaken for a client fault.
After connecting, four settings are worth verifying yourself
The policy decides how a provider handles data; client settings decide how data actually travels. The four items below bear directly on privacy, and are worth confirming one by one after you connect.
1. Does DNS go through the tunnel?
After connecting, open any DNS leak test page and check whether resolution requests leave through the same exit as the tunnel. If they do not, queries still go to the local ISP and the tunnel only encrypts web traffic. Some clients offer a “use tunnel DNS” switch that has to be turned on manually.
2. Is IPv6 slipping around the tunnel?
Many tunnel setups handle IPv4 only. When the local network also hands out IPv6 addresses and the client does not block IPv6, some traffic can leave outside the tunnel. Clients usually offer an “IPv4 only” or “block IPv6” option; turning it on is easier than troubleshooting later.
3. Where do the split-tunnel rules come from?
In rule mode, an address list decides what goes through the tunnel and what connects directly, and the list's source and update frequency decide how accurate it is. Global mode is the least fuss, but it also routes local services out through the tunnel, which can affect LAN device access and local payments. Neither mode is better — it depends on whether you care more about consistency or speed.
4. What happens after a drop?
When the tunnel drops unexpectedly, does the client fall back to a direct connection or block all traffic? A fallback means you return to plaintext without knowing, which is the last thing you want on a public network. Treat this as a hard requirement when choosing a client.
The check order for all three lines
Here is everything above as a sequence — just walk through it once.
- Read the policy and find three fields: what data is collected, how long it is kept, who it is shared with. If there are no specifics, set it aside for now.
- Open the signup page and count the required fields. Username and password alone is normal; if real name, address or a mandatory email is demanded, think hard about what those fields have to do with delivering the service.
- See how many payment methods exist and what kind of linkage each one leaves behind.
- Install the client, connect, then run a DNS and exit-IP check to confirm resolution and traffic take the same path.
- Find a real public network (café, airport) and run the full loop: portal sign-in, connect, DNS check, drop and reconnect.
Five steps take very little time and are worth more than reading ten reviews, because each conclusion comes from your own device and network rather than someone else's environment.
Buying verdict: what can be compromised, and what cannot
More can be compromised than you would think: the number of routes, whether the client looks good, how many protocol options there are. Coverage figures like 90+ countries / 170+ routes are fine once they are enough — most people will not use the surplus more than a few times a year. As for protocols, names like Shadowsocks, VMess, VLESS, Trojan, Hysteria2 and TUIC look complicated, but the client picks automatically in practice; ordinary users do not need to understand each one.
Only four things are non-negotiable: whether the policy is specific enough to verify, whether signup forces an email address, whether traffic is blocked on disconnect, and whether DNS goes through the tunnel. Those four decide who holds your data once you are connected — nothing to do with saving a few yuan.
On price: monthly plans are ¥9.9 for 60GB, ¥18 for 250GB and ¥28 for 500GB, with traffic resetting each month on the activation date and mid-cycle upgrades credited pro rata for the remaining days; data packs are ¥158/300GB, ¥358/1000GB and ¥658/3000GB, valid until used with no expiry. Traffic is protected in transit with bank-grade encryption. The full tiers are laid out line by line on the plans and pricing page.
This is where the 60-day no-questions refund matters most: the five checks above need a real network to run, and the refund window gives you enough time to test them. A full refund can be requested within 60 days of the first payment — if it does not fit, return it, with no need to talk yourself into it beforehand.
If you remember only one line: a no-logs promise is worth not how strongly it is stated but how precisely it is written. If it is not precise, treat it as no promise at all.