Proton VPN in 2026: I ran it for 60 days on my self-hosted stack — here's what works and what doesn't

• 
  Outbound IP rotation for a handful of scrapers that politely respect rate limits but still get blocked when they all share my home IP.


• 
  A trustworthy exit node for my laptop when I'm on cafe / airport Wi-Fi.


• 
  Port forwarding for one self-hosted service that I want reachable behind a clean static IP without leaking my real residential one.

I subscribed to Proton VPN Plus on March 24, 2026 and have run it daily since. This is the writeup after 60 days.

Disclosure. The Proton link in this post is an affiliate link — if you subscribe I earn a small commission, at no extra cost to you. Same price for you either way. I subscribed on my own card and I run Proton Mail and Drive on separate paid accounts as well. I'm not getting paid to like this. — enim

What I tested

Where it wins

Jurisdiction + corporate structure is real, not marketing. Proton AG is a Swiss stock corporation whose primary shareholder is the non-profit Proton Foundation (Geneva). The point of that structure is to lock the privacy mission into the cap table — it's harder to acquire and pivot a company whose controlling shareholder is a foundation with a stated charter than one whose owners are PE funds answering to LPs. This isn't unique among VPNs (Mullvad does the right things too) but it's the structure that survives an acquisition attempt.

Independent audits, public. Proton publishes its annual no-logs audits by Securitum in full at covers the from-scratch path.) This matters because I can verify what's happening at the protocol level and I'm not depending on Proton's closed-source client for the cryptography.

Kill switch is real on Linux. Most Linux VPN clients ship with a "kill switch" that's a iptables rule the GUI adds and removes. The Proton CLI installs an nftables-based set of rules and systemd-resolved overrides that actually survive a process crash. I tested by SIGKILLing the client mid-connection — outbound traffic stopped. With WireGuard direct, you have to roll your own with PostUp / PostDown hooks.

Port forwarding works (P2P-marked servers only). Proton supports incoming connections on any server marked "P2P" in the client — they're flagged with a double-arrow icon in the country list. You enable port forwarding once in client settings, get a forwarded port assigned per-session, and you can run a self-hosted service behind it. It's not as flexible as a dedicated IP from a cloud provider, but it's the right answer for "I want this reachable without exposing my home IP."

Speed is fine for everything that's not raw single-stream throughput. Helsinki → Amsterdam exit on a 1 Gbit Hetzner link: ~620 Mbit/s sustained, 18ms added latency. Same path with Mullvad: 740 Mbit/s, 16ms. Difference matters for iperf3 benchmarks; doesn't matter for any actual workload I run.

Where it falls down

The WireGuard config download flow is awful in 2026. You log into the account portal, click through three menus to get to "WireGuard configurations", create a new key per device (one at a time, no bulk), and download each .conf file individually. If you want 5 different exit countries, that's 5 separate clicks-through-menus + 5 downloads. Mullvad has a single-page bulk download. This is the one place where the UX feels like 2019.

Streaming is genuinely a coin flip. Netflix US worked from 3 of the 5 US servers I tried on day one. By week three, only 1 of the 5 worked. By week six, none did. BBC iPlayer worked from UK servers but not consistently — about 60% of sessions get the "not available in your region" error. If streaming is your reason to subscribe, you'll be disappointed. Get one of the streaming-focused VPNs instead.

No SOCKS5 proxy. I wanted to point a handful of headless containers at a SOCKS5 proxy that exits via Proton, without running the WireGuard tunnel system-wide. Proton doesn't offer SOCKS5 — it's WireGuard or OpenVPN only. (Mullvad does, and this is the one place I still use Mullvad as well.)

Multi-hop costs you 40% throughput, every time. A Switzerland → Iceland multi-hop chain dropped me from 620 Mbit/s to ~370 Mbit/s. Expected and unavoidable — but if you read marketing that says "no performance impact," that's not what I measured.

The Linux CLI is fine, the Linux GUI is bad. I'm not going to dwell on this — most ByteGuard readers will use the CLI. But: the GUI on Ubuntu 24.04 is laggy, the system-tray indicator is unreadable on dark themes, and on Fedora 40 it didn't launch at all. Use the CLI.

Account portal 2FA is TOTP-only. No FIDO2, no Webauthn. For a privacy company in 2026 this is a baffling omission. Proton Mail has full 2FA-key support. The VPN account portal does not.

Speed tests (60-day averages)

These are from a Hetzner CPX22 in Helsinki, 1 Gbit link, multiple times per day over 60 days. Each cell is the median of ~180 iperf3 runs.

For context, my baseline Helsinki→public-internet from the same Hetzner box: 920 Mbit/s down, 870 Mbit/s up, 4 ms to the nearest CDN node.

DNS leak audit

I ran the full battery — dnsleaktest.com extended test, ipleak.net, manual dig @resolver +short whoami.akamai.net, browser WebRTC inspection — on each of the 7 exits above, on both Linux WireGuard direct and the macOS client.

Result: no leaks observed in 168 audited connections. The Linux WireGuard config sets PostUp / PostDown rules that route DNS through Proton's resolver only; the macOS client uses a system-level VPN extension that does the same. WebRTC was unaffected on the macOS client; on Linux I manually disabled WebRTC in Firefox about:config.

Honest verdict

Subscribe to Proton VPN if:

• You want a privacy-respecting paid VPN and don't want to think about it


• You self-host and want a clean WireGuard config you can drop into /etc/wireguard/
  


• You want port forwarding for one or two self-hosted services without a dedicated cloud IP


• You already use Proton Mail / Drive and want one account / one bill

Get instead if:

• You need SOCKS5 (Proton doesn't offer it; Mullvad does)


• You need consistent streaming unblock (neither Proton nor Mullvad is great for this — you want a streaming-specialist provider)


• You need raw maximum throughput on single-stream WireGuard (Mullvad is 15-20% faster in my tests)


• You hate logging into account portals (Mullvad doesn't have accounts — just an anonymous token)

Don't subscribe to any VPN at all if:

• Your threat model is "stop my ISP from selling browsing data" → use a privacy-respecting DNS resolver (NextDNS, Quad9) and call it done. A VPN here is overkill and adds an attack surface.


• Your threat model is "evade nation-state surveillance" → a commercial VPN is not the right tool. Get a Tails USB stick + Tor.

Setup: drop-in WireGuard for a Linux VPS

If you're using this on a server (not your laptop), the cleanest path is direct WireGuard without the Proton client. Here's the exact flow I use on Ubuntu 24.04.

# 1. Get the WireGuard config from the account portal

#    (account.protonvpn.com → Downloads → WireGuard configuration)

#    Download a .conf for the exit country you want.



# 2. Install WireGuard

sudo apt update && sudo apt install -y wireguard-tools



# 3. Drop the config in place (NL-NL-1.conf becomes proton-nl.conf)

sudo mv ~/NL-NL-1.conf /etc/wireguard/proton-nl.conf

sudo chmod 600 /etc/wireguard/proton-nl.conf



# 4. Start it

sudo wg-quick up proton-nl



# 5. Verify exit

curl -s https://api.ipify.org

#   should return a Proton NL IP, not your Hetzner one



# 6. Enable on boot (optional — you might want this manual)

sudo systemctl enable wg-quick@proton-nl

To bring it down: sudo wg-quick down proton-nl.

If you want only certain containers to use the tunnel (which is what I do for the scraper containers), the answer is split-routing via Docker networks or ip rule — that's its own writeup and is queued for a follow-up post.

Where I'd use it in the ByteGuard stack

I run Proton WireGuard on the Hetzner host for two things:

1. A Docker network labeled proton-nl that the scraper containers attach to — those containers' outbound traffic exits through Proton NL, leaving the host's other services on the direct route.


2. Port forwarding for an experimental self-hosted service I don't want pinned to the Hetzner public IP.

The blog itself (this site), the CVE tool, the tools subdomain, and the paste service all use the direct Hetzner route. There's no reason to add VPN latency to a static blog. (The hardening for that host is documented in the — affiliate link; same price for you, small commission to me if you subscribe.

— enim

This review will be updated quarterly. Last data point: 2026-05-22. If anything in this post is stale by the time you read it, ping me on Mastodon.