I Tried to Break Proton VPN for a Day (or three) Here's What Actually Held.
I have done some good and bad work in my day, granted, but what I can always guarantee is that when I go looking for the truth, especilly if I intend to distribute that knowledge, I am ruthless. I do not care if you are friend or foe, I aim and fire at you all the same, impartially. Now with that out of the way (yes, I can be prone to the dramatic!) This is the point, my line in this sand where I turn from "let's test their theory and claim because I like their other products, and they post funny memes on X, to....
I ran the same kill-switch test against Proton VPN that I ran against another provider whose tunnel I already caught leaking. Same bench, same method, same device. This was a VPN-only test. That scope matters, and I will come back to why.
The Method
The kill-switch test is simple and nasty. It exploits the half-second seam where a VPN reconnects after losing signal. That seam is where weak implementations bleed the real IP before the tunnel re-establishes.
Kill switch on. Block connections without VPN on, both confirmed in Android settings. (Side bar-this is another truth I use as a metric in testing only if it aligns with the claims from said company, for example, in prior testing, a company had claimed that they, in-fact, were the manufacturers of the kill-switch and there is a toggle in the UX, that toggle, on it's own, does absolutely nothing to stem the data hemorrhage when the VPN disconnects, so not only would claiming that be a lie, it is a very dangerous premise, and deceptive, also borderline fraudulent, I cannot sell a product, market it as X and sell Y, is that not the very definition of fraud? Proton made exactly 0 of these claims, and their VPN section redirects you, correctly, to your OS kill-switch and Block all connections toggles, correctly saying, make sure both are on, others tell you block all connections must be off to allow split tunneling to work) I split the screen. One side runs a leak checker, refreshing constantly. The other side shows the VPN status. Disconnect the VPN to expose my real South African IP, watch it appear on the leak checker, then hit reconnect and immediately refresh the leak test. I am trying to catch the moment where the real IP flashes through the seam before the kill switch can block it.
That seam is exactly where the other product failed on its Double Hop server transitions. Real IP exposed, documented, submitted to the vendor. They patched it silently with no changelog or acknowledgment.
(Later saying they incorrectly claimed it was patched and it was acceptable loss to them. It was never patched.)
Proton held the line. Across hours of this, the days, disconnect after disconnect, protocol switch after protocol switch, my real IP never once appeared. Not in the seam. Not under load. Not on a slowed handshake. The kill switch did the one job the marketing sells.
The Load
This matters. I did not run this in a clean lab with one app open. I ran it with real usage stacked on top: multiple browser tabs, an online game running, Spotify playing. The device was doing what a device does. The tunnel had work to do. The test was not "does the kill switch work in ideal conditions," it was "does it hold when the device is actually being used."
It held.
The DNS Anomalies
Then the leak tests threw up DNS resolving through hosts I did not recognise. WorldStream. Datacamp. Anexia. That looks alarming until you check it. The pattern suggested the VPN was leaking DNS queries to third-party resolvers.
WHOIS and RDAP on every one of them traced back to Proton's own rented server and DNS infrastructure. Not off-tunnel. Not a leak. A blacklist hit on one Proton IP against a wall of clean results from every reputable list, which is noise, not signal.
What I found:
Proton routes DNS to its own infrastructure, resolves it on its own servers, sends the answer back through the tunnel. That is the correct posture. The anomalies were either Proton's own infrastructure showing up in a way the checker misread, or a third-party list flagging a Proton IP because Proton IPs are shared and sometimes someone on one of those IPs does something the list doesn't like. Neither one is a leak.
The NextDNS Seam
That left one real anomaly. On a slowed Stealth test, the leak checker picked up NextDNS as the resolver. NextDNS is mine. I run it at the browser level in Brave, DoH sitting above the OS tunnel, and I set Android Private DNS to Automatic on purpose so it binds to the VPN.
Here is why this matters:
A VPN tunnel typically handles DNS at the OS level. The tunnel routes all OS-level traffic, including DNS, through the encrypted tunnel and resolves it on the VPN's servers. But I configured Brave to use NextDNS at the application level, above the OS tunnel. During the slowed Stealth handshake, the tunnel took a couple seconds longer to establish, and in that window before the tunnel fully captured DNS, Brave's own resolver surfaced in the leak test. That is my config showing through a seam, not a Proton flaw.
I am saying that plainly because it is true, and because the point of this is what actually happened, not what makes the better headline. The restraint is the credibility. The caveat makes the whole thing stronger.
The Exit IP Question
One more thing, I feel I must say. WHOIS on the exit IP shows Proton AG. Anyone running a lookup knows I am on Proton specifically, not just "a VPN." That is a property of every commercial VPN, not a defect, and Stealth is the feature that mitigates it. While I personally would have preferred to not have seen Proton there at all, (less attack surface) it still isn't a failure, nor is the fact it did show something contradictory to Proton's claim would not happen, because there is nonsuch claim, at least at the time of writing this, that I am aware of. Real, worth knowing, not a failure.
Some VPNs go to great lengths to hide that their exit IPs belong to them, using bulletproof hosters or false registration data. Proton does not. The WHOIS shows Proton AG because Proton owns the IP and Proton does not hide that fact. Whether that is the braver choice or the less clever one, I will let you decide.
The Suite-Wide Slowdown
The dent, in otherwise white shining armour. The honest part, the part that scope was protecting. During this testing window I could not log into Proton Mail or Proton Drive. Biometrics refused. I had to fall back to password, backup codes, and 2FA to get in. Both apps were thrashing against credential recovery, retrying, timing out, starting over.
In the same stretch, the VPN slowed significantly. It did not drop.
The kill switch never faltered.
But throughput fell off a cliff. I was getting single-digit Mbps when the baseline is 60+. While Drive was doing its credential thrashing, the tunnel was dragging.
I cannot tell you Drive caused the slowdown, because I did not isolate the variables. The test was VPN-only. I did not run a clean split where I test the VPN with Drive on, then with Drive off, controlling everything else. What I can tell you is I saw both in the same window, and if you run the whole Proton suite daily, it is a question worth asking:
Does heavy Drive activity drag your tunnel? Does the authentication thrashing starve the VPN of resources? Does the encryption overhead of multiple encrypted apps on one device create contention?
I am not answering that here. I am flagging it. It is adjacent-to-true, not true.
The difference is that one gets published as a finding and the other gets logged for follow-up.
The Audits: What Securitum Actually Did
A word on the audits, because Proton leans on them and you should know what they are. The fifth consecutive Securitum no-logs audit is real. It ran on-site in Zürich from 20 to 27 May 2026, announced mid-June.
Here are the specifics that matter. Two senior consultants, six person-days. That is not the whole firm dropping everything for three weeks. It is two experienced people, spending one working week on-site, reviewing Proton's infrastructure.
The engagement was operator-assisted. Proton staff demonstrated the systems while the auditors directed and verified. The auditors did not have independent remote access to the servers, run their own tests in isolation, or come in as a fully adversarial red team. They came in, Proton showed them the room, the auditors checked the room, and Proton showed them it was configured right.
The scope was selected server samples, not the full fleet. Proton runs servers across multiple countries and data centers. Securitum reviewed samples. , People will say it is disingenuous, it however is a constraint that is honestly stated in the report.
And it is explicitly point-in-time. It reflects how things were configured during those three days in May 2026. It is not a continuous guarantee of future behaviour. A week after the audit, Proton could change a configuration, and the audit would be stale. The auditors are not monitoring ongoing.
So what does the audit actually verify? It verifies that on the infrastructure Securitum examined, during the time Securitum was there, under the conditions Proton demonstrated, the no-logs posture held. There were no persistent logs of browsing activity, DNS queries, connection metadata, or anything that would let Proton associate a user with their activity. The infrastructure does not log. That is a real, unembellished finding.
But, it is also a narrow one.
It is not a full-stack red-team engagement. It is not testing what I tested, which is kill-switch behaviour under real load on a live device, over hours, with the full suite running. Different question. Neither is wrong. They checked the rooms Proton showed them. I tried the locks under weight.
The Verdict
Held to what I can actually stand up. Proton's kill switch passed a test that has caught others. My real IP stayed hidden through every transition I could engineer.Including running a harnass so heavy it was designed to help probe malware on mobile devices. No dice. The DNS anomalies were Proton's own infrastructure or my own browser, not the tunnel bleeding data. The suite has a performance question under load that I have flagged and not concluded.
3 days of testing found no leak and one open question. That is more than the marketing admits and less than the outrage merchants would sell you. Try it yourself. Run the test on your own device with your own setup. Include me in the findings.
There is a saying I love, and used before but this test gives me a different read on the meaning:
"It is better to be a warrior in a garden, that a gardener in a war."
How I interpreted that is the way we all do, know thy enemy, love everyone, but never sell your sword, rather than being the one in a war, with a sword he has no idea how to weild.
I always thought with systems like these I probed and they failed so easily, that I had become the warrior and overcompensating, I would further harden things that never needed that level of protection. When all I needed to do was get a new gardener, and actually enjoy my garden.
About the author:
Clayton Bax Onyxdigitalintelligence85@protonmail.com https://x.com/i/status/2074574337600840159 https://onyxdigital.bearblog.dev/ Baximus855.github.io
Open to work, freelance, journalistic, contract or permanent. Audits, Cyber Security Research.