La leçon la plus importante de cette partie de la discussion ProtonVPN/Gluetun est simple : placer qBittorrent sur un réseau Docker appelé gluetun n’est pas la même chose que faire passer tout le trafic de qBittorrent par le conteneur VPN Gluetun. L’utilisateur source pouvait télécharger des torrents de test avec succès, alors que les vérifications d’IP publique effectuées depuis qBittorrent renvoyaient toujours l’adresse du FAI.
La communauté a finalement circonscrit le problème à la sémantique des réseaux Docker. Pour partager la pile réseau de Gluetun, qBittorrent a besoin d’une relation Compose telle que network_mode: "service:gluetun", et l’interface utilisateur de ZimaOS peut écraser ou supprimer ce paramètre si la pile est ensuite modifiée de manière incompatible.
Gluetun était déjà connecté
Le dépannage source était déjà arrivé à un point où les journaux de Gluetun indiquaient une IP publique VPN et l’établissement réussi du tunnel. Cela signifie que le conteneur VPN lui-même n’était plus le problème.
La question suivante était de savoir si qBittorrent utilisait réellement le même espace de noms réseau.
qBittorrent ne gérait pas son propre VPN
Le menu déroulant Réseau de ZimaOS avait sélectionné un réseau Docker
gluetun qBittorrent partageait un segment réseau, mais pas l’espace de noms réseau de Gluetun.Le répondant source a correctement distingué deux concepts Docker :
- rejoindre le même réseau Docker défini par l’utilisateur ;
- partager l’espace de noms réseau d’un autre service via
network_mode: service:gluetun.
Seul le second modèle force tout le trafic réseau de qBittorrent à passer par la pile réseau de Gluetun.
Le test d’IP publique a prouvé que qBittorrent contournait le VPN
La communauté a recommandé de vérifier l’IP publique depuis l’intérieur du conteneur qBittorrent et de la comparer à l’IP VPN affichée dans les journaux de Gluetun.
L’utilisateur source a exécuté les tests, et les deux ont renvoyé l’IP normale du FAI. C’était l’indice le plus probant de la discussion de la page 2, car il mesurait le chemin réel du trafic au lieu de le déduire des noms d’interfaces.
network_mode doit survivre à l’import Compose de ZimaOS
Un participant ultérieur a découvert que l’exportation de l’application après des modifications dans l’interface de ZimaOS pouvait afficher la network_mode ligne manquante. Ils ont signalé avoir réussi après avoir importé une définition Compose qui conservait la relation network-mode et évitait les ports/réseaux paramètres du service qBittorrent.
Il s’agit d’un comportement de ZimaOS vérifié par la communauté en 2026, et non d’une garantie officielle d’IceWhale concernant tous les éditeurs YAML actuels de l’App Store.
Gardez Gluetun et qBittorrent dans un seul projet Compose
Dans le fil de discussion d’origine, la communauté a expliqué que service:gluetun fonctionne lorsque les deux services font partie du même projet Compose. qBittorrent partage alors l’espace de noms réseau de Gluetun ; l’interface Web et les ports entrants de qBittorrent sont donc publiés sur le service Gluetun.
La communauté Gluetun en amont utilise la même architecture Docker Compose. Consultez le projet Gluetun actuel et la configuration des fournisseurs avant de recopier d’anciennes variables d’environnement.
Utilisez les identifiants WireGuard de ProtonVPN, pas le mot de passe habituel du compte Proton
Le fil de discussion a également mis en évidence une autre erreur fréquente : la configuration WireGuard de Gluetun nécessite les valeurs appropriées de clé/configuration WireGuard de Proton VPN, et non le mot de passe de connexion habituel du compte.
Ne publiez jamais une clé privée WireGuard sur un forum public. L’utilisateur d’origine en a accidentellement exposé une, puis l’a correctement révoquée.
Vérifiez le chemin d’arrêt, pas uniquement le fonctionnement normal
Une fois la pile combinée démarrée, vérifiez :
- Les journaux de Gluetun affichent l’adresse IP publique VPN attendue ;
- L’adresse IP publique sortante de qBittorrent lui correspond ;
- qBittorrent perd l’accès à Internet si le tunnel Gluetun est arrêté ou défaillant ;
- L’interface Web reste accessible via le port publié sur Gluetun.
Cela confirme que l’application ne bascule pas silencieusement sur la connexion du FAI.
Les applications ARR n’ont pas toutes besoin d’être derrière le VPN
Le long fil de discussion d’origine évoquait également le fait de placer toute la pile ARR derrière le VPN afin de simplifier les communications. Cela peut fonctionner, mais ce n’est pas toujours nécessaire. De nombreux utilisateurs font passer uniquement le client de téléchargement par Gluetun, tandis que Sonarr/Radarr restent sur le réseau Docker normal et communiquent via des chemins et des ports hôte/conteneur explicites.
Choisissez délibérément l’architecture au lieu de faire passer chaque service derrière le tunnel simplement parce que cela résout un problème de communication.
Publiez les ports de qBittorrent sur Gluetun, pas sur qBittorrent
Lorsque qBittorrent utilise network_mode: "service:gluetun", il ne possède plus d’espace de noms réseau indépendant. Cela signifie que son interface Web et tous les ports BitTorrent entrants doivent être publiés sur le service Gluetun plutôt que sur le service qBittorrent.
Si l’interface Web de qBittorrent disparaît après le passage au mode réseau partagé, vérifiez la liste des ports de Gluetun avant de conclure que l’application n’a pas démarré.
Soyez prudent lorsque vous modifiez la pile importée dans l’interface de ZimaOS
Le rapport communautaire ultérieur est particulièrement important pour les utilisateurs de ZimaOS : le fichier Compose importé contenait initialement network_mode, mais après les modifications dans l’interface, la définition exportée ne le faisait plus. Le même participant a déclaré que la suppression des éléments en conflit ports et réseaux entrées et la réimportation de la pile ont préservé la relation fonctionnelle.
Cela ne prouve pas que toutes les modifications YAML actuelles de ZimaOS se comportent ainsi, mais cela signifie qu’il faut revérifier le Compose généré après avoir modifié le réseau via l’éditeur graphique.
La topologie Docker est réutilisable avec différents fournisseurs VPN, mais pas les identifiants
La page 2 contient un exemple de dépannage Surfshark, tandis que la discussion originale avait commencé avec ProtonVPN. La leçon sur la mise en réseau Docker est la même : Gluetun fournit le tunnel et qBittorrent doit acheminer son trafic via son espace de noms. Les clés propres au fournisseur, les sélecteurs de serveur, les options de redirection de ports et les valeurs d’authentification ne sont pas interchangeables.
Construisez toujours l’environnement Gluetun à partir de la configuration actuelle du fournisseur plutôt que de copier les valeurs Surfshark ou Proton d’un autre utilisateur.
Ne collez jamais de clés privées WireGuard dans des captures d’écran publiques ou des messages de forum
L’auteur de la publication originale a accidentellement exposé une clé privée WireGuard et l’a révoquée après qu’un autre participant l’a averti. Considérez toute clé VPN publiée comme compromise et faites-la immédiatement tourner.
Lorsque vous demandez de l’aide, masquez les clés privées, les jetons, les mots de passe, les cookies et les identifiants de compte fournisseur, tout en laissant visibles les journaux et messages d’erreur non secrets.
FAQ sur le routage de Gluetun
Le fait de rejoindre un réseau Docker nommé gluetun a-t-ilchemine-t-il le trafic via le VPN ?
Non. La source a prouvé que qBittorrent pouvait rester sur le réseau du FAI tout en étant connecté à ce réseau.
Quel paramètre partage l’espace de noms réseau de Gluetun ?
Le modèle Compose source et en amont utilisent network_mode: "service:gluetun".
Comment vérifier la route ?
Comparez l’adresse IP publique visible depuis qBittorrent avec l’adresse IP VPN signalée par Gluetun.
