PeerTube above, but published to YouTube for reach ![]()
If I navigate to a website on Proton server A and switch servers to B, will the website see my IP address even if I don’t reload the page?
Maybe, if it’s making connections in the background with Javascript.
This thread might help: Basic 101 Networking question - #16 by Irrigate0583
@jonah Interesting video with useful information. I experienced similar issues with Proton VPN on Linux (the app itself worked fine, but I encountered network problems, particularly when the Advanced Kill Switch was enabled). Connection speeds sometimes dropped significantly, requiring me to disable the kill switch, switch servers, or restart the application to restore functionality. This issue appeared consistently only with the Advanced Kill Switch setting.
On mobile, however, I didn't encounter these problems. The mobile version offered additional features I missed on Linux, such as the Stealth Protocol and Split Tunneling in many cases.
Currently, I'm using Mullvad with several security features enabled (Lockdown Mode, DAITA, Quantum Resistant Tunnel, and Multi-hop) and the connection speed is notably faster than what I experienced with Proton VPN on Linux.
Do you use Multi-hop also on proton?
Good video, hopefully this brings some productive spotlight to the issue.
One of the reasons I am against simply “delisting” a reputable and established provider like Proton is that regardless of what we say people, will use them, and they will also own Apple products.
When comparing Proton to other VPN products (not the ones we list) they’re still very much ahead, eg audits of network infrastructure, open source and audited apps etc. I think we shouldn’t lose sight of that.
Ideally what I would like to see is clarification in the documentation. I’m not entirely sure that it’s malicious disinformation, rather than an omission that hasn’t been properly described.
I’d also like to see what Proton has to say about Network Extensions, and perhaps what their specific technical discoveries are in regard to that and if they have been in contact with Apple in order to address those, assuming it’s not something easily fixable on their end.
I think primary gripe we all have with Proton is with their misleading/inaccurate documentation and marketing along with the app not working as it should. Proton fixes that. We all shut up and go about enjoying the privacy they provide through all their products.
Hi folks, just some notes from the Proton VPN team that may be helpful, and some updates on what we are working on in this area:
Kill Switch for Linux
The Proton VPN Linux kill switch (https://protonvpn.com/support/advanced-kill-switch, as of v4.2.0 and above) uses a routing-table enforcement model that is standard for Linux networking. All outbound traffic is forced through a non-routable sink interface unless the VPN tunnel is active. This prevents applications from leaking traffic during unexpected disconnections.
A scenario highlighted in this discussion involves an advanced user manually binding an application with the appropriate privileges to a physical network interface. Such bindings intentionally bypass the system routing table and therefore bypass any routing-based firewall or kill-switch mechanism.
For typical users operating in a default environment, the kill switch prevents leaks as designed. For advanced users who intentionally create custom routing or interface-level rules, then naturally having the VPN interfere with this would be undesirable. However, we are actively evaluating additional enforcement layers to provide stronger safeguards against accidental misconfiguration - but without interfering with intended user behaviour.
MacOS Server Reconnection
A valid concern was raised about IP exposure during server switches on macOS. There are some mitigations against this in place - users are warned before switching servers that their VPN connection may be briefly interrupted, and users using any VPN on any platform are advised to bind to the VPN interface when torrenting (https://protonvpn.com/support/bittorrent-vpn). This is not, however, as robust as we would like.
As some posts in this thread have already pointed out, kill-switch limitations on macOS stem more from the OS itself, rather than specific individual VPN implementations. These limitations are documented in our knowledge base, but based on the feedback that we have received, we are presently revising them for clarity and to ensure that no one is inadvertently misled as to how Proton VPN handles these limitations. Proton VPN uses Apple’s Network Extension framework, which provides only limited control over how the operating system handles traffic during transitions such as tunnel renegotiation. Apple’s networking stack restricts low-level firewall and routing manipulation, making certain enforcement mechanisms that exist on other platforms technically impossible or unreliable on macOS.
Despite these platform constraints, we recognise that users expect the kill switch to behave as a leak-prevention mechanism across all operating systems, and ideally without additional measures being required by the user for their protection. To address this expectation, we had already started exploring alternative approaches on macOS to ensure that ProtonVPN meets both our internal standards and the strict criteria valued by this community.
An alternative used by other VPNs involves a tunnel interface set up by a daemon that runs without a sandbox on the user’s machine with elevated privileges. We did consider this solution, but rejected it. The legacy APIs that are used are ones that Apple has heavily signalled that they intend to deprecate, so this was not going to be a long-term, reliable solution.
What we are doing instead is baking the protections into the network stack itself to ensure that the protected tunnel must always be retained even when the connection is interrupted - either accidentally, or during server switches. This new cross-platform network architecture was the main thing that we were working on during our Autumn/Winter roadmap cycle (https://protonvpn.com/blog/product-roadmap-winter-2025-2026#:~:text=a%20random%20country.-,A%20new%20VPN%20architecture,-A%20powerful%20and). We haven’t officially announced our Spring/Summer roadmap for Proton VPN yet, but we can confirm now that we will be rolling this out in the first half of the Spring/Summer roadmap cycle.
We will publish updates as these start to roll into beta and production, and we welcome feedback from privacy-focused users who want to contribute insights.
@Onscreen5341 No, I didn’t. To be fair, I don’t think there was Multi-hop for Linux when I used Proton.
This implies there aren’t other mechanisms on the OS available to you which don’t have such limitations. It is not an OS issue if you’re using the wrong tool for the job.
It is completely false that other mechanisms are technically impossible or even “unreliable”. Your competitors have managed to make it work reliably. Your decision to not use pf, as an example, for whatever reason doesn’t mean it’s not an option and “technically impossible” or “unreliable”. What has been demonstrably proven to be unreliable is the mechanism you’re currently using.
“Intend to deprecate”, even if true, is not the same as actually deprecating. We are a long way off from these APIs being actually deprecated, if ever, and even then much further off from them actually being removed, again if ever. If the new mechanism does not work, I don’t understand why you wouldn’t use the older, more reliable method at the very least until it is actually announced by Apple that it is actually deprecated.
What? The network stack is part of the OS and maintained by Apple. This sentence doesn’t communicate whatever you think it does and is not clear at all at least to me what you are actually planning on doing.
Thanks for also responding to the Linux questions not included in this video.
Where?
Additionally, yes, I would imagine that users would expect a kill switch to protect against interruptions, just not manual disconnections.
Where?
Edit: Well at least this page was edited ![]()
The same way Apple marked OpenGL as deprecated in June 2018 but it still has not been removed.
I would have had the exact same opinion about year ago. With what happened here, it completely changed my perspective and it does seem like malicious disinformation to me (and many others).
Here’s our latest on this, hope it clears things up: How should we handle Proton's misleading marketing? - #50 by Proton_Team