Help & common questions.

I lost my account token.

The 16-character token is the only credential. We have no email, no phone number, no recovery question. We cannot retrieve it. This is deliberate — if we could, so could a subpoena.

The pragmatic fix: sign up again with a new token, keep a backup (password manager, paper, or both) this time. Your previous account expires naturally and you don't owe us anything.

Can I share my account across devices?

Yes — up to 8 devices per account. The CLI / GUI handles this; for phones, use 0trust export from the desktop client to generate a config QR.

How do I add a new device after my first connection?

sudo 0trust connect on the new device, after pasting the same account token via 0trust login. The server assigns it a unique pubkey and IP. For mobile devices: open the desktop GUI, click Add mobile device, scan the QR with the WireGuard app.

How long does my subscription last?

As long as you paid for. Check expiry with 0trust status — it shows days remaining. We don't auto-renew because we don't keep your payment details. About 7 days before expiry you get a renewal reminder in whichever client you use; renew at 0trustvpn.com/renew, with 0trust topup, or from the desktop app's Extend subscription panel, and the new days stack on top of the old ones.

Is there a free trial? Do I need a card?

Yes, and no. The trial asks for nothing at all — no email address, no card, no form. Your browser spends a few seconds solving a small proof-of-work puzzle, which is there to make signing up for ten thousand of them expensive, and you get an ordinary anonymous account token at the end of it.

It is the same service a paying customer gets, on the same servers, with two limits: it runs for a shorter period, and it allows fewer devices at once. Nothing expires into a paid plan and there is nothing to cancel, because we have no way to charge you. If you decide to pay, the same account continues and whatever the trial had left is added to the months you buy rather than thrown away.

Why crypto only? Why no credit card?

Credit card processors require a real name and a billing address, and the card network itself logs every transaction. That data lives forever and is reachable by subpoena. Our no-logs claim would be meaningless if we collected it at signup. Crypto avoids the trail.

If crypto is genuinely a blocker, the standard workaround is a pre-paid VISA card bought with cash from a corner store. We don't sell those; you'd need to figure that out locally.

I paid but my account is still inactive.

Your account activates once the payment is buried deep enough on-chain. How deep depends on which coin you paid in: the checkout shows the number of confirmations it is waiting for, and counts them off. For Bitcoin that is usually 10–20 minutes; coins that ask for more blocks take proportionally longer. We check the chain once a minute, so activation follows within about that long of the last block. Leave the signup page open and it will update on its own; the account token is on it either way.

If 60+ minutes have passed and the invoice shows Settled but your account is still inactive, that's a real bug — email support with the invoice ID.

Refunds?

Within 30 days, yes, full refund via BTCPay's dispute flow — just ask. After that the bandwidth is used and we can't get it back.

What's the difference between single-hop and multi-hop?

Single-hop: one server terminates your tunnel and forwards traffic to the internet. Fast, simple, slightly cheaper on our end. Adequate for almost everyone.

Multi-hop: your traffic enters via one server in region A and exits via a different server in region B. The entry server can see your IP but never decrypts your traffic (you're end-to-end-encrypted to the exit). The exit decrypts but only ever sees the entry's IP, never yours. Adds latency, eliminates the single-server correlation risk.

Use 0trust connect zur for single-hop, or 0trust connect zur --exit buc for multi-hop.

How often does the multi-hop pair rotate?

Every 24 hours by default; the 0trust-rotate.timer systemd unit fires every 6 hours with jitter. You can rotate manually with sudo 0trust rotate any time — the tunnel hot-swaps without dropping existing connections.

My tunnel works but the internet feels slow.

Check status.0trustvpn.com first — if your region is degraded, capacity might be tight. Otherwise, try a different entry region (0trust connect rey instead of zur). If multi-hop, try removing the exit (--exit) to compare.

Real bottlenecks we’ve seen: ISP throttling of WireGuard on UDP/51820, and MTU problems (some carrier networks fragment WireGuard packets badly). Multi-hop uses a port in the 52000–59999 range rather than 51820, so 0trust connect zur --exit rey is worth trying on a network that appears to single out the default port.

It says “no handshake — the tunnel is NOT carrying traffic”.

The tunnel interface came up, but the node never answered, so nothing is getting through. We tell you rather than printing a tick, because the alternative is believing you are protected while you are not.

We deliberately leave the interface up. It still holds your default route, so traffic is dropped instead of quietly going out in the clear. That is why the internet looks broken rather than merely unprotected. To get back online, fix the cause or run sudo 0trust disconnect.

Usual causes, in order: the network blocks UDP (common on hotel and corporate wifi) — try multi-hop, which uses a different port range; the node is down — check the status page; or the subscription lapsed — 0trust status.

Is there a kill switch?

On Linux and Windows, yes. sudo 0trust connect --kill-switch blocks any traffic that is not going through the tunnel, so if the tunnel drops your connection stops rather than silently falling back to your normal one. The desktop app has a toggle for the same setting. It is sticky — you do not have to repeat the flag — and --no-kill-switch turns it off.

It blocks your local network too: printers, NAS boxes and casting to a TV will stop working while it is on. That is what a strict kill switch means, and we would rather say so than surprise you.

On Windows the official WireGuard service does this itself whenever the tunnel carries all traffic, which ours does, so it is already on. On macOS we do not have one. wg-quick there drives pf rather than iptables, and we would rather ship nothing than ship a setting that looks enabled and is not. The client tells you if you ask for it on a platform where it does nothing.

Can my network tell I’m using a VPN?

By default, yes. We run plain WireGuard, and WireGuard’s handshake is a fixed-shape packet that any deep-packet-inspection box identifies on sight, whatever port it arrives on. We would rather say that than let you assume otherwise — a lot of VPN marketing does not.

DPI protection changes it. Turn it on with sudo 0trust connect --obfuscate, or the switch in the desktop app, and each packet is sealed so what leaves your machine is indistinguishable from random data. It is sticky, like the kill switch, and --no-obfuscate turns it off.

It is off by default on purpose. Every packet takes an extra hop through your machine and the server, and loses a little of its payload, so you will notice the speed. If nothing is filtering your connection you gain nothing by turning it on. That is the trade, and it is yours to make.

Three things it does not do, because the difference matters if you are relying on it. It does not hide that you are talking to one of our servers, or how much — sizes and timing are unchanged. It is not an extra layer of authentication; every customer on a server shares its obfuscation key, and WireGuard is still the only thing protecting your traffic, exactly as when this is off. And it is still UDP, so a network that blocks all outbound UDP blocks this too.

Not every server runs it. If you turn it on and land on one that does not, the client says so and connects you normally rather than pretending. The Android app has the same switch. On iPhone there is nothing to switch: there is no 0trustvpn app for iOS, and the official WireGuard app you use instead speaks WireGuard and only WireGuard. When we do ship one it will not carry this either — the system component that moves the packets there leaves us nowhere to put the relay — and we would rather say that now than ship a switch that does nothing.

What about IPv6 and DNS leaks?

Your tunnel claims both 0.0.0.0/0 and ::/0, so IPv6 cannot route around us on a dual-stack network. That much is true on every connection.

Whether IPv6 is carried depends on the exit node. Where the node has working IPv6, you get a v6 address inside the tunnel and v6 sites load normally; where it does not, you get no v6 address and v6 traffic is dropped rather than let out around us. So the failure mode is IPv6-only sites not loading, never IPv6 leaking. 0trust status tells you which you have on the current connection.

Inside the tunnel your v6 address is a private ULA, and the exit masquerades it the same way it masquerades v4. Sites see the node’s address, not a per-customer prefix — a stable prefix of your own would be a tracking identifier, which is the opposite of the point.

DNS goes to a resolver that only exists inside the tunnel, on the exit node carrying your traffic. It keeps no query log. See the privacy policy, section 4d for what that resolver does and does not know, including the upstream we forward to and cannot audit for you.

Can I use BitTorrent?

We do not block it and the terms do not prohibit it. Be aware of what actually happens, though, because it is not nothing: copyright notices about a torrent swarm arrive at whoever owns the exit IP address, which is us. We cannot pass one on to you — there are no logs that would let us work out which customer it was, which is the whole design — so we reply saying so.

The honest caveat is that if one exit address draws a large and sustained volume of notices, our remedy is coarse: we rotate that address, or in the worst case take the node out of the mesh, and that affects everyone routing through it rather than whoever caused it. There is no port forwarding, so seeding through the tunnel works poorly in any case.

Will Netflix and other streaming services work?

Probably not, and we would rather say so before you pay than after. We do nothing to defeat geographic blocking: there are three exit addresses, they are stable, they belong to hosting providers rather than home ISPs, and the major streaming services identify and block exactly that pattern. Buying more addresses to stay ahead of them is a full-time job we are not doing.

If watching region-locked video is your reason for wanting a VPN, this is the wrong product and you should buy a different one. What this is built for is not being logged.

Where are your servers? Which jurisdictions?

Three nodes in three countries: Switzerland (Zurich), Iceland (Reykjavik), and Romania (Bucharest). All three are outside the Five Eyes, Nine Eyes, and Fourteen Eyes intelligence-sharing alliances. No servers in the US, UK, Canada, Australia, New Zealand, Germany, France, Netherlands, Denmark, Belgium, Italy, Spain, Sweden, or Norway. Not for any reason.

Three nodes means fewer servers to scrutinize and harden, not more. Each box is a RAM-only ephemeral instance — disk is tmpfs, swap is disabled, keys are regenerated on every reboot. A seized machine reveals the OS image and nothing operational. See the audit pack for the verification commands.

Do you actually keep no logs?

The honest answer is "almost". Read the full audit pack for the details, but the short version: we store hashed account tokens, device pubkeys, and 2 days of /24-anonymized nginx access logs (for DDoS forensics). We don't store IPs, user agents, traffic destinations, or connection times.

scripts/audit-verify.sh in the repo runs an automated verification matrix that any independent auditor (or you) can use to confirm what we say matches what the server does.

What happens if you're served a subpoena?

Specifics depend on jurisdiction. The structural defense is that we don't have the data most subpoenas would ask for — there's nothing to hand over. The disclosure signal is the warrant canary, re-signed weekly. If it stops being signed, treat that as the signal.

What if your servers get seized?

Our exit and entry nodes are RAM-only ephemeral instances (see audit pack §5.3). Disk is tmpfs, swap is off, keys regenerate on boot. A seized box contains its base OS and nothing operationally relevant. The control plane has a customer-token table, but tokens are stored as SHA-256 hashes; a seizure reveals which tokens have been issued but not which tokens map to which connections.

Why WireGuard? Why not OpenVPN?

WireGuard is smaller (~4000 lines of audited kernel code vs OpenVPN's ~70k), faster (kernel-space datapath), and has a saner cryptographic design (no negotiation, no roundtrip handshake costs after setup). The tradeoffs — slightly less hairy NAT traversal, no per-connection user authentication — don't matter for our model where we hand out per-device keypairs.

Is the client open source?

Yes — github.com/0trust/cli. Builds are reproducible: same source rev + same Go version produces byte-identical binaries. See the build instructions in build-info.txt in any release.

Can I run my own exit node?

Not currently — we operate the mesh ourselves to keep customer traffic correlation under one trust boundary. A federated model (Bring-Your-Own-Node) is on the long-term roadmap but isn't something we're ready to support.

How do I contact you?

Email 0trustvpn@proton.me. We respond within 48 hours, faster for outages. Please encrypt sensitive details to our PGP key — fingerprint at /.well-known/security.txt.

For security vulnerabilities, use 0trustvpn@proton.me — same key, faster triage. See our security policy.

Tor users: we run a `.onion` mirror of this site. The address is published in the footer below, in our warrant canary, and on our Mastodon profile. Tor Browser auto-promotes you when you visit the clearnet URL (look for the purple onion icon).