I have recently been having a lot of issues maintaining a connection with my proton vpn in gluetun. it keeps dropping and reconnecting due to failing periodic small health check. My internet connection is solid without connection issues, running a symmetrical 1gbit and the router (gl.inet brume 2) doesn't register any dropouts in connection.

i have tried following the suggested troubleshooting in the docs, updating the vpn server list etc., but none of the suggestions seem to fix this issue. it has been going on for several months now. if i use mullvad it works perfectly without connection issues, but this is destroying my seed ratio due to no port forwarding.

docker compose

log from container

[EDIT] it seems to be caused by radar/sonarr trying to reach my trackers. When I removed them from my docker-compose and left just the qbit and gluetun containers, it stopped failing and just kept running without dropping the connection. Configuring flaresolverr to be part of the docker-compose seems to have fixed the issues I was having.

I don't use proton so can't validate but two things stand out to me:

• port forwarding: one of the reasons I don't use proton: port forwarding is limited for them, both for specific servers as well as randomized ports. First test: drop the port forwarding.
• wireguard vs openvpn: download a wireguard config from proton and test that.

Good luck!

I use gluetun with my own ovpn file. I have no knowledge on other vpn-integrations!

I see some issues with the provided info

There are some ping issues in the log
Have you a monitor service like uptime kuma that you can cross-check?
Best case to be configurable to the frequency gluetun checks for

2026-03-15T07:04:49Z INFO [vpn] 👉 See https://github.com/qdm12/gluetun-wiki/blob/main/faq/healthcheck.md

Have you tried that before posting?

2026-03-15T07:04:50Z INFO [openvpn] UDPv4 link remote: [AF_INET]46.29.25.4:1194

2026-03-15T07:05:50Z WARN [openvpn] TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)

🚒🚒🚒🚒🚒🚨🚨🚨🚨🚨🚨🚒🚒🚒🚒🚒 (...)

That seems bad.

Side quests:

• Have you a separate system or VM that you could test your config on a fresh vanilla system? (to rule out issues related to networking tweaks)
• Have you the issue with other connections?
• Do you notice a pattern? Maybe in time (clock), duration of connection (how long did it work before the issue arrised? Does Proton force kill connections periodically?) Maybe a program/service executing in the background that touches the network config?
• When was the last config change? Yesterday? Two days ago? (Example: My traefik cert failed because I fucked with the config. I also touched my 2FA proxy container redirect which resulted in a faulty integration and me being unable to login. The time since I have touched the config was 3 days prior.)

It worked without issues for about 1.5year without me changing anything in the compose file, about 6 months ago I started noticing health issues with the container. My torrent stack has been untouched since I set it up 2 years ago.

There doesn't seem to be a clear pattern in failures, sometimes its 20min, sometimes its 8 hours between failures.

Are you running gluetun on docker desktop for windows by chance?

If so, the networking layer for DD is fucked and every new release fucks it further and differently. Make sure you're not running any other VPNs on the host, restart the docker daemon and pray. And then move off windows before it's too late.

Source: made the mistake of starting an *arr stack on DD for Windows cause I didn't wanna figure out GPU pass-through on VMs, and I suffered with this for a year.

Has your gluetun image been kept up-to-date, btw? Changes to compose file or not, there were IIRC two breaking changes in gluetun connectivity with Proton due to changes in the Proton CLI, the two of them were recent enough, I think in v3.38 and v3.40.

No it's running on my server which is running OMV, so Debian I guess?

It is updated automatically with watchtower, but I have manually pulled the latest a few times, most recently about two months ago.

Edit: weirdly enough, despite me pulling the latest image just now, which was released two days ago, the log still says I'm running 4 commits behind when I start the container 🤔

Don't know if proton does offer it, but try to run the raw openvpn (or what the format of proton uses) config in gluetun.
Maybe theres an issue with the native integration.

If it runs fine, I'd say it's a bug
If it runs just as bad, theres a system issue.

Debian it is.

I ran gluetun + proton for 4-5 years. v3.41 broke the integration completely and I could never get it working. Tried both wireguard and ovpn setups.

My best advice is pin to the 3.40 release or change providers. The maintainer hasn’t address the specific problem with proton in over a year. There was some discussion recently about improvements to the healthcheck endpoint, so he is working on the project. But it’s slow going and proton is the only provider I know about that is having consistent issues

I’ve been using Proton through Gluetun for my torrent stack and haven’t noticed any issues. I followed Dr. Frankenstein’s guide for setting everything up, and I periodically check his docs for changes since they seem to actively keep them up to date.

You can configure gluetun to automatically update qbittorrent with whatever port gets assigned.

Yeah but that doesn't solve OPs problem re/ proton - what I meant was that perhaps there is no Netherlands server that provides their random port forwarding or it gets a hickup with it.

If you refer to me not using proton:

The port forwarding is not the main reason (that's their C level weirding me out) - and for the port forwarding specifically:
It's not (only/mainly) qbittorrent I want port forwarding for :)

Ah, that's fair.

perhaps there is no Netherlands server that provides their random port forwarding or it gets a hickup with it.

They show several NL servers with port forwarding, but i have also tried other locations with the exact same issues.

Wireguard poses the same problem, it also keeps dropping connection.

Disabling port forwarding doesn't seem to make a difference for either openvpn or WG.

3.40 still seems to have this issue, it doesn't change anything in stability unfortunately.