Die wichtigste Erkenntnis aus diesem Teil des ProtonVPN-/Gluetun-Threads ist einfach: qBittorrent einem Docker-Netzwerk namens gluetun hinzuzufügen, ist nicht dasselbe, wie den gesamten qBittorrent-Datenverkehr durch den Gluetun-VPN-Container zu leiten. Der Benutzer konnte Test-Torrents erfolgreich herunterladen, während Prüfungen der öffentlichen IP innerhalb von qBittorrent weiterhin die ISP-Adresse zurückgaben.
Die Community grenzte das Problem schließlich auf die Semantik der Docker-Netzwerkfunktionen ein. Damit qBittorrent den Netzwerk-Stack von Gluetun gemeinsam nutzt, benötigt es eine Compose-Beziehung wie network_mode: "service:gluetun", und die ZimaOS-Benutzeroberfläche kann diese Einstellung überschreiben oder entfernen, wenn der Stack später auf inkompatible Weise bearbeitet wird.
Gluetun war selbst bereits verbunden.
Die ursprüngliche Fehlerbehebung war bereits an einem Punkt angelangt, an dem die Gluetun-Protokolle eine öffentliche VPN-IP und einen erfolgreich gestarteten Tunnel zeigten. Das bedeutete, dass der VPN-Container selbst nicht mehr das Problem war.
Die nächste Frage war, ob qBittorrent tatsächlich denselben Netzwerk-Namensraum verwendete.
qBittorrent verwaltete kein eigenes VPN
Das ZimaOS-Netzwerk-Dropdown hatte ein Docker-Netzwerk ausgewählt.
gluetun qBittorrent teilte sich ein Netzwerksegment, aber nicht den Netzwerk-Namensraum von Gluetun.Der Antwortende aus der Community trennte korrekt zwei Docker-Konzepte:
- das Beitreten zum selben benutzerdefinierten Docker-Netzwerk;
- die gemeinsame Nutzung des Netzwerk-Namensraums eines anderen Dienstes durch
network_mode: service:gluetun.
Nur das zweite Modell zwingt den gesamten Netzwerkverkehr von qBittorrent durch den Netzwerk-Stack von Gluetun.
Der Test der öffentlichen IP bewies, dass qBittorrent das VPN umging
Die Community empfahl, die öffentliche IP innerhalb des qBittorrent-Containers zu prüfen und sie mit der in den Gluetun-Protokollen angezeigten VPN-IP zu vergleichen.
Der Benutzer führte die Tests aus, und beide gaben die normale ISP-IP zurück. Das war der stärkste Beleg in der Diskussion auf Seite 2, da damit der tatsächliche Datenverkehrspfad gemessen wurde, anstatt ihn aus den Namen der Netzwerkschnittstellen abzuleiten.
network_mode muss den ZimaOS-Compose-Import überstehen
Ein späterer Teilnehmer stellte fest, dass der Export der App nach Bearbeitungen in der ZimaOS-Benutzeroberfläche Folgendes anzeigen konnte: network_mode Zeile fehlte. Sie berichteten von Erfolg, nachdem sie eine Compose-Definition importiert hatten, die die Beziehung zwischen den Netzwerkmodi beibehielt und inkompatible Ports/Netzwerke Einstellungen am qBittorrent-Dienst.
Dies ist ein von der Community bestätigtes Verhalten von ZimaOS aus dem Jahr 2026 und keine offizielle IceWhale-Garantie für jeden aktuellen YAML-Editor des App Store.
Gluetun und qBittorrent in einem Compose-Projekt behalten
Im Ausgangsthread erklärte die Community, dass service:gluetun funktioniert, wenn beide Dienste Teil desselben Compose-Projekts sind. qBittorrent teilt dann den Netzwerk-Namespace von Gluetun, sodass die WebUI und die eingehenden Ports von qBittorrent stattdessen über den Gluetun-Dienst veröffentlicht werden.
Die Upstream-Community von Gluetun verwendet dieselbe Docker-Compose-Architektur. Lesen Sie das aktuelle Gluetun-Projekt und die Anbieterkonfiguration, bevor Sie alte Umgebungsvariablen übernehmen.
Verwenden Sie ProtonVPN-WireGuard-Zugangsdaten, nicht das normale Passwort des Proton-Kontos
Im weiteren Verlauf des Threads wurde ein weiterer häufiger Fehler festgestellt: Die WireGuard-Konfiguration von Gluetun benötigt die entsprechenden WireGuard-Schlüssel-/Konfigurationswerte von Proton VPN, nicht das normale Passwort des Kontos.
Veröffentlichen Sie niemals einen privaten WireGuard-Schlüssel in einem öffentlichen Forum. Der ursprüngliche Benutzer hat versehentlich einen solchen Schlüssel offengelegt und ihn anschließend richtigerweise widerrufen.
Überprüfen Sie den Kill-Pfad, nicht nur den Erfolgsfall
Nachdem der kombinierte Stack läuft, überprüfen Sie:
- Die Gluetun-Protokolle zeigen die erwartete öffentliche VPN-IP;
- die öffentliche IP von qBittorrent stimmt mit dieser überein;
- qBittorrent verliert den Internetzugang, wenn der Gluetun-Tunnel gestoppt wird oder nicht ordnungsgemäß funktioniert;
- Die WebUI bleibt über den auf Gluetun veröffentlichten Port erreichbar.
Dies bestätigt, dass die Anwendung nicht unbemerkt auf die Verbindung des Internetanbieters zurückfällt.
ARR-Apps müssen nicht alle hinter dem VPN laufen
Im langen Ausgangsthread wurde außerdem diskutiert, den gesamten ARR-Stack hinter das VPN zu stellen, um die Kommunikation zu vereinfachen. Das kann funktionieren, ist aber nicht immer notwendig. Viele Benutzer leiten nur den Download-Client über Gluetun, während Sonarr/Radarr im normalen Docker-Netzwerk verbleiben und über explizite Host-/Container-Pfade und Ports kommunizieren.
Wählen Sie die Architektur bewusst, anstatt jeden Dienst nur deshalb hinter den Tunnel zu verschieben, weil dadurch ein Kommunikationsproblem behoben wird.
qBittorrent-Ports an Gluetun veröffentlichen, nicht an qBittorrent
Wenn qBittorrent network_mode: "service:gluetun", besitzt es keinen eigenen Netzwerk-Namespace mehr. Das bedeutet, dass die Weboberfläche und alle eingehenden BitTorrent-Ports von qBittorrent am Gluetun-Dienst statt am qBittorrent-Dienst veröffentlicht werden müssen.
Wenn die qBittorrent-Weboberfläche nach dem Wechsel in den gemeinsamen Netzwerkmodus verschwindet, überprüfen Sie die Portliste von Gluetun, bevor Sie zu dem Schluss kommen, dass die Anwendung nicht gestartet wurde.
Beim Bearbeiten des importierten Stacks in der ZimaOS-Benutzeroberfläche vorsichtig sein
Der spätere Community-Bericht ist für ZimaOS-Benutzer besonders wichtig: Die importierte Compose-Datei enthielt ursprünglich network_mode, aber nach Änderungen an der Benutzeroberfläche war dies in der exportierten Definition nicht mehr der Fall. Derselbe Teilnehmer sagte, das Entfernen widersprüchlicher Ports und Netzwerke Einträge und der erneute Import des Stacks bewahrten die funktionierende Beziehung.
Dies beweist nicht, dass jede aktuelle Bearbeitung von ZimaOS-YAML-Dateien sich so verhält, bedeutet aber, dass die generierte Compose-Datei nach einer Änderung der Netzwerkeinstellungen über den grafischen Editor erneut überprüft werden sollte.
Die Docker-Topologie ist bei verschiedenen VPN-Anbietern wiederverwendbar, die Zugangsdaten jedoch nicht
Seite 2 enthält ein Beispiel zur Surfshark-Fehlerbehebung, während der ursprüngliche Thread mit ProtonVPN begann. Die Lektion zum Docker-Netzwerk ist dieselbe: Gluetun stellt den Tunnel bereit, und qBittorrent muss über dessen Namespace routen. Anbieterspezifische Schlüssel, Serverauswahl, Optionen für die Portweiterleitung und Authentifizierungswerte sind nicht untereinander austauschbar.
Erstellen Sie die Gluetun-Umgebung immer anhand der aktuellen Anbieterkonfiguration, anstatt die Surfshark- oder Proton-Werte eines anderen Benutzers zu kopieren.
Private WireGuard-Schlüssel niemals in öffentlichen Screenshots oder Forenbeiträgen einfügen
Der ursprüngliche Verfasser veröffentlichte versehentlich einen privaten WireGuard-Schlüssel und widerrief ihn, nachdem ein anderer Teilnehmer ihn darauf hingewiesen hatte. Behandeln Sie jeden veröffentlichten VPN-Schlüssel als kompromittiert und rotieren Sie ihn sofort.
Bei Hilfsanfragen sollten Sie private Schlüssel, Tokens, Passwörter, Cookies und Anbieter-Konto-IDs schwärzen, während nicht geheime Logs und Fehlermeldungen sichtbar bleiben.
Gluetun-Routing-FAQ
Leitet die Verbindung zu einem Docker-Netzwerk namens gluetun den Datenverkehr durch das VPN?
Nein. Die Quelle belegte, dass qBittorrent weiterhin den Pfad des Internetdienstanbieters nutzen konnte, während es mit diesem Netzwerk verbunden war.
Welche Einstellung teilt den Netzwerk-Namespace von Gluetun?
Das Quell- und das übergeordnete Compose-Muster verwenden network_mode: "service:gluetun".
Wie überprüfen Sie die Route?
Vergleichen Sie die öffentliche IP-Adresse, die innerhalb von qBittorrent angezeigt wird, mit der von Gluetun gemeldeten VPN-IP-Adresse.
