Den viktigaste lärdomen från den här delen av ProtonVPN/Gluetun-tråden är enkel: att placera qBittorrent i ett Docker-nätverk som heter gluetun är inte samma sak som att dirigera all qBittorrents trafik genom Gluetun-VPN-containern. Källanvändaren kunde ladda ned testtorrentfiler utan problem, medan kontroller av den offentliga IP-adressen inifrån qBittorrent fortfarande returnerade IP-adressen från internetleverantören.
Communityn ringade så småningom in problemet till Dockers nätverkssemantik. För att dela Gluetuns nätverksstack behöver qBittorrent en Compose-relation som network_mode: "service:gluetun", och ZimaOS-gränssnittet kan skriva över eller ta bort den inställningen om stacken senare redigeras på inkompatibla sätt.
Gluetun var redan ansluten
Källans felsökning hade redan nått en punkt där Gluetuns loggar visade en offentlig VPN-IP-adress och en lyckad tunnelstart. Det innebar att själva VPN-containern inte längre var problemet.
Nästa fråga var om qBittorrent faktiskt använde samma nätverksnamnområde.
qBittorrent hanterade inte sin egen VPN-anslutning
ZimaOS rullgardinsmeny för nätverk valde ett Docker-nätverk
gluetun gjorde att qBittorrent delade ett nätverkssegment, men inte Gluetuns nätverksnamnområde.Källans svarande skiljde korrekt mellan två Docker-koncept:
- att ansluta till samma användardefinierade Docker-nätverk;
- dela en annan tjänsts nätverksnamnområde genom
network_mode: service:gluetun.
Det är bara den andra modellen som tvingar all qBittorrents nätverkstrafik genom Gluetuns nätverksstack.
Testet av den offentliga IP-adressen visade att qBittorrent kringgick VPN-anslutningen
Communityn rekommenderade att kontrollera den offentliga IP-adressen inifrån qBittorrent-containern och jämföra den med VPN-IP-adressen som visas i Gluetuns loggar.
Källanvändaren körde testerna och båda returnerade den normala IP-adressen från internetleverantören. Det var det starkaste beviset i diskussionen på sida 2, eftersom det mätte den faktiska trafikvägen i stället för att dra slutsatser utifrån gränssnittsnamn.
network_mode måste överleva ZimaOS Compose-importen
En senare deltagare upptäckte att export av appen efter ändringar i ZimaOS-gränssnittet kunde visa den network_mode rad saknas. De rapporterade att det fungerade efter att ha importerat en Compose-definition som behöll relationen för nätverksläget och undvek inkompatibla portar/nätverk inställningar på qBittorrent-tjänsten.
Detta är ett communityverifierat ZimaOS-beteende från 2026, inte en officiell garanti från IceWhale för alla aktuella YAML-redigerare i App Store.
Håll Gluetun och qBittorrent i ett Compose-projekt
I källtråden förklarade communityn att service:gluetun fungerar när båda tjänsterna ingår i samma Compose-projekt. qBittorrent delar då Gluetuns nätverksnamnområde, så qBittorrents webbgränssnitt och inkommande portar publiceras i stället på Gluetun-tjänsten.
Gluetuns uppströmscommunity använder samma Docker Compose-arkitektur. Se det aktuella Gluetun-projektet och leverantörskonfigurationen innan du kopierar gamla miljövariabler.
Använd ProtonVPN-uppgifter för WireGuard, inte det vanliga lösenordet till Proton-kontot
Den övergripande tråden fastställde ytterligare ett vanligt misstag: Gluetuns WireGuard-konfiguration behöver rätt Proton VPN-värden för WireGuard-nyckel/konfiguration, inte det vanliga lösenordet till kontot.
Publicera aldrig en privat WireGuard-nyckel i ett offentligt forum. Den ursprungliga användaren råkade avslöja en och återkallade den korrekt efteråt.
Verifiera avbrottsskyddet, inte bara det lyckade scenariot
När den kombinerade stacken körs kontrollerar du:
- Gluetuns loggar visar den förväntade offentliga VPN-IP-adressen;
- qBittorrents utgående offentliga IP-adress matchar den;
- qBittorrent förlorar internetåtkomst om Gluetun-tunneln stoppas eller blir felaktig;
- Webbgränssnittet är fortfarande åtkomligt via porten som publicerats på Gluetun.
Detta bekräftar att applikationen inte i tysthet faller tillbaka till internetleverantörens anslutning.
Alla ARR-appar behöver inte vara bakom VPN:et
Den långa källtråden tog också upp att lägga hela ARR-stacken bakom VPN:et för att förenkla kommunikationen. Det kan fungera, men är inte alltid nödvändigt. Många användare dirigerar endast nedladdningsklienten genom Gluetun, medan Sonarr/Radarr fortsätter använda normalt Docker-nätverk och kommunicerar via uttryckliga värd-/containersökvägar och portar.
Välj arkitekturen medvetet i stället för att flytta varje tjänst bakom tunneln bara för att lösa ett kommunikationsproblem.
Publicera qBittorrents portar på Gluetun, inte på qBittorrent
När qBittorrent använder network_mode: "service:gluetun", har den inte längre ett eget nätverksnamnområde. Det innebär att dess webbgränssnitt och alla inkommande BitTorrent-portar måste publiceras på Gluetun-tjänsten i stället för på qBittorrent-tjänsten.
Om qBittorrents webbgränssnitt försvinner efter övergång till delat nätverksläge ska du kontrollera Gl 'etuns portlista innan du drar slutsatsen att programmet inte startade.
Var försiktig när du redigerar den importerade stacken i ZimaOS-gränssnittet
Den senare rapporten från communityn är särskilt viktig för ZimaOS-användare: Den importerade Compose-filen innehöll ursprungligen network_mode, men efter ändringar i gränssnittet gjorde den exporterade definitionen inte längre det. Samma deltagare uppgav att borttagning av motstridiga portar och nätverk poster och genom att importera stacken igen bevarades den fungerande kopplingen.
Detta bevisar inte att alla aktuella YAML-redigeringar i ZimaOS fungerar på det sättet, men det innebär att den genererade Compose-konfigurationen bör kontrolleras igen efter att nätverket ändrats via det grafiska redigeringsverktyget.
Docker-topologin kan återanvändas mellan VPN-leverantörer, men autentiseringsuppgifterna kan inte det
På sida 2 finns ett felsökningsexempel för Surfshark, medan den ursprungliga tråden började med ProtonVPN. Lärdomen om Docker-nätverk är densamma: Gluetun tillhandahåller tunneln och qBittorrent måste routa via dess namnområde. Leverantörsspecifika nycklar, serverväljare, alternativ för portvidarebefordran och autentiseringsvärden kan inte bytas ut mot varandra.
Skapa alltid Gluetun-miljön från leverantörens aktuella konfiguration i stället för att kopiera en annan användares Surfshark- eller Proton-värden.
Klistra aldrig in privata WireGuard-nycklar i offentliga skärmbilder eller foruminlägg
Den ursprungliga skribenten råkade exponera en privat WireGuard-nyckel och återkallade den efter att en annan deltagare varnat personen. Behandla alla publicerade VPN-nycklar som komprometterade och byt ut dem omedelbart.
När du ber om hjälp ska du maskera privata nycklar, tokenvärden, lösenord, cookies och identifierare för leverantörskonton, men låta icke-hemliga loggar och felmeddelanden vara synliga.
Gluetuns routnings-FAQ
Dirigeras trafiken via VPN:et om man ansluter till ett Docker-nätverk med namnet gluetun?
Nej. Källan visade att qBittorrent kunde fortsätta använda internetleverantörens anslutning trots att det var anslutet till det nätverket.
Vilken inställning delar Gluetuns nätverksnamnområde?
Källan och det överordnade Compose-mönstret använder network_mode: "service:gluetun".
Hur verifierar du routningen?
Jämför den publika IP-adress som visas inifrån qBittorrent med den VPN-IP-adress som rapporteras av Gluetun.
