De belangrijkste les uit dit deel van de ProtonVPN/Gluetun-discussie is eenvoudig: qBittorrent toevoegen aan een Docker-netwerk met de naam gluetun is niet hetzelfde als al het qBittorrent-verkeer via de Gluetun-VPN-container routeren. De gebruiker kon met succes testtorrents downloaden, terwijl controles van het openbare IP-adres binnen qBittorrent nog steeds het IP-adres van de internetprovider teruggaven.
De community bracht het probleem uiteindelijk terug tot de netwerksemantiek van Docker. Om de netwerkstack van Gluetun te delen, heeft qBittorrent een Compose-relatie nodig, zoals network_mode: "service:gluetun", en de gebruikersinterface van ZimaOS kan die instelling overschrijven of verwijderen als de stack later op incompatibele manieren wordt bewerkt.
Gluetun was zelf al verbonden
De bron van de probleemoplossing had al een punt bereikt waarop de logboeken van Gluetun een openbaar VPN-IP-adres en een succesvolle tunnelstart toonden. Dat betekent dat de VPN-container zelf niet langer het probleem was.
De volgende vraag was of qBittorrent daadwerkelijk dezelfde netwerknaamruimte gebruikte.
qBittorrent beheerde geen eigen VPN
De netwerkvervolgkeuzelijst van ZimaOS selecteerde een Docker-netwerk
gluetun maakte qBittorrent deelgenoot van een netwerksegment, maar niet van de netwerknaamruimte van Gluetun.De bronreactie maakte correct onderscheid tussen twee Docker-concepten:
- deelnemen aan hetzelfde door de gebruiker gedefinieerde Docker-netwerk;
- de netwerknaamruimte van een andere service delen via
network_mode: service:gluetun.
Alleen het tweede model dwingt al het qBittorrent-netwerkverkeer door de stack van Gluetun.
De test van het openbare IP-adres bewees dat qBittorrent de VPN omzeilde
De community adviseerde het openbare IP-adres vanuit de qBittorrent-container te controleren en dit te vergelijken met het VPN-IP-adres dat in de Gluetun-logboeken werd weergegeven.
De gebruiker voerde de tests uit en beide gaven het normale IP-adres van de internetprovider terug. Dat was het sterkste bewijs in de discussie op pagina 2, omdat hiermee het daadwerkelijke verkeerspad werd gemeten in plaats van dit af te leiden uit interfacenamen.
network_mode moet de import van ZimaOS Compose overleven
Een latere deelnemer ontdekte dat het exporteren van de app nadat er wijzigingen in de ZimaOS-interface waren aangebracht, kon laten zien dat de network_mode ontbrekende regel. Ze meldden succes nadat ze een Compose-definitie hadden geïmporteerd waarin de relatie tussen de netwerkmodi behouden bleef en incompatibele ports/networks instellingen op de qBittorrent-service.
Dit is door de community geverifieerd ZimaOS-gedrag uit 2026, geen officiële garantie van IceWhale voor elke huidige YAML-editor van de App Store.
Houd Gluetun en qBittorrent in één Compose-project
In de brondiscussie legde de community uit dat service:gluetun Werkt wanneer beide services deel uitmaken van hetzelfde Compose-project. qBittorrent deelt dan de netwerknaamruimte van Gluetun, waardoor de WebUI en inkomende poorten van qBittorrent in plaats daarvan op de Gluetun-service worden gepubliceerd.
De upstream Gluetun-community gebruikt dezelfde Docker Compose-architectuur. Bekijk het huidige Gluetun-project en de providerconfiguratie voordat je oude omgevingsvariabelen overneemt.
Gebruik WireGuard-inloggegevens van ProtonVPN, niet het normale wachtwoord van je Proton-account
Uit de bredere discussie bleek nog een veelgemaakte fout: de WireGuard-configuratie van Gluetun heeft de juiste WireGuard-sleutel-/configuratiewaarden van Proton VPN nodig, niet het gewone wachtwoord voor het account.
Plaats nooit een privésleutel van WireGuard op een openbaar forum. De oorspronkelijke gebruiker maakte er per ongeluk een openbaar en heeft deze daarna terecht ingetrokken.
Controleer het kill-pad, niet alleen het ideale pad
Controleer het volgende nadat de gecombineerde stack actief is:
- De Gluetun-logboeken tonen het verwachte openbare VPN-IP-adres;
- Het uitgaande openbare IP-adres van qBittorrent komt ermee overeen;
- qBittorrent verliest internettoegang als de Gluetun-tunnel wordt gestopt of niet gezond is;
- De WebUI blijft bereikbaar via de op Gluetun gepubliceerde poort.
Dit bevestigt dat de applicatie niet stilletjes terugvalt op de verbinding van de internetprovider.
ARR-apps hoeven niet allemaal achter de VPN te staan
In de lange brondiscussie werd ook besproken om de volledige ARR-stack achter de VPN te plaatsen om communicatie te vereenvoudigen. Dat kan werken, maar is niet altijd nodig. Veel gebruikers routeren alleen de downloadclient via Gluetun, terwijl Sonarr/Radarr het normale Docker-netwerk blijven gebruiken en via expliciete host-/containerpaden en poorten communiceren.
Kies bewust voor de architectuur in plaats van elke service achter de tunnel te plaatsen alleen omdat dat één communicatieprobleem oplost.
Publiceer qBittorrent-poorten op Gluetun, niet op qBittorrent
Wanneer qBittorrent network_mode: "service:gluetun"; het heeft dan geen eigen netwerknaamruimte meer. Dat betekent dat de WebUI en alle inkomende BitTorrent-poorten van qBittorrent op de Gluetun-service moeten worden gepubliceerd in plaats van op de qBittorrent-service.
Als de qBittorrent-WebUI verdwijnt nadat je bent overgeschakeld naar de gedeelde netwerkmodus, controleer dan de poortenlijst van Gluetun voordat je concludeert dat de toepassing niet is gestart.
Wees voorzichtig met het bewerken van de geïmporteerde stack in de ZimaOS-gebruikersinterface
Het latere communityrapport is bijzonder belangrijk voor ZimaOS-gebruikers: het geïmporteerde Compose-bestand bevatte oorspronkelijk network_mode, maar na wijzigingen in de gebruikersinterface deed de geëxporteerde definitie dat niet langer. Dezelfde deelnemer zei dat het verwijderen van conflicterende ports en networks vermeldingen en het opnieuw importeren van de stack behielden de werkende relatie.
Dit bewijst niet dat elke huidige wijziging van ZimaOS-YAML zich zo gedraagt, maar het betekent wel dat de gegenereerde Compose-configuratie opnieuw moet worden gecontroleerd nadat de netwerkinstellingen via de grafische editor zijn gewijzigd.
De Docker-topologie is herbruikbaar voor verschillende VPN-providers, maar inloggegevens zijn dat niet
Pagina 2 bevat een voorbeeld voor het oplossen van problemen met Surfshark, terwijl de oorspronkelijke thread met ProtonVPN begon. De Docker-netwerkles is hetzelfde: Gluetun levert de tunnel en qBittorrent moet het verkeer via zijn naamruimte routeren. Providerspecifieke sleutels, serverselectoren, opties voor port forwarding en authenticatiewaarden zijn niet onderling uitwisselbaar.
Stel de Gluetun-omgeving altijd samen op basis van de huidige providerconfiguratie in plaats van de Surfshark- of Proton-waarden van een andere gebruiker te kopiëren.
Plak nooit privésleutels van WireGuard in openbare screenshots of forumberichten
De oorspronkelijke poster had per ongeluk een privésleutel van WireGuard openbaar gemaakt en heeft deze ingetrokken nadat een andere deelnemer hen daarvoor had gewaarschuwd. Beschouw elke gepubliceerde VPN-sleutel als gecompromitteerd en roteer deze onmiddellijk.
Wanneer je om hulp vraagt, verwijder dan privé-sleutels, tokens, wachtwoorden, cookies en identificatiegegevens van provideraccounts, maar laat niet-geheime logs en foutmeldingen zichtbaar.
Veelgestelde vragen over Gluetun-routing
Leidt deelname aan een Docker-netwerk met de naam gluetun het verkeer via de VPN?
Nee. De bron bewees dat qBittorrent via de ISP-verbinding kon blijven werken terwijl het aan dat netwerk was gekoppeld.
Welke instelling deelt de netwerknaamruimte van Gluetun?
De bron en het upstream Compose-patroon gebruiken network_mode: "service:gluetun".
Hoe verifieer je de route?
Vergelijk het openbare IP-adres dat vanuit qBittorrent wordt gezien met het VPN-IP-adres dat door Gluetun wordt gerapporteerd.
