Port VPN annoncé ouvert, qBittorrent toujours « fermé » : le diagnostic Gluetun en trois verrous

La ligne dans les logs avait exactement l’air d’une bonne nouvelle:

[port forwarding] port forwarded is 62884

Juste après, Gluetun confirmait que le port était autorisé sur l’interface VPN.

J’ai donc ouvert qBittorrent, vérifié l’état de la connexion, puis lancé un contrôle depuis l’extérieur.

Port fermé.

J’ai relancé le test. Fermé.

Redémarré qBittorrent. Fermé.

À ce moment-là, le réflexe le plus naturel était de penser que Gluetun mentait, que Docker bloquait quelque chose ou que mon routeur refusait encore une connexion entrante. Un utilisateur de r/gluetun décrivait encore exactement ce scénario en mai 2026: Gluetun obtenait bien un port ProtonVPN et l’autorisait sur tun0, qBittorrent semblait synchronisé, mais les contrôles externes continuaient à répondre « closed ». Mon erreur était ailleurs: j’avais interprété « le port VPN existe » comme « mon application est joignable sur ce port ».

Ce sont deux choses différentes.

Le nombre dans les logs n’est que le premier verrou

J’avais commencé à bricoler la section ports: de mon fichier Compose.

Puis j’ai ouvert le port sur le routeur.

Puis j’ai commencé à comparer TCP et UDP.

C’était beaucoup d’activité pour un diagnostic qui n’avait pas encore commencé.

La documentation Gluetun est très explicite sur un point: le VPN server port forwarding n’est pas le port mapping Docker. Le fournisseur VPN attribue une porte d’entrée sur son propre serveur. Gluetun récupère ce numéro et autorise le trafic correspondant dans le tunnel. Docker, lui, gère une autre frontière: celle entre ses conteneurs et la machine hôte. J’ai fini par imaginer le trajet comme trois portes successives:

Internet → port du fournisseur VPN → Gluetun → application qui écoute.

Voir 62884 dans les logs prouvait que la première porte avait été créée.

Cela ne prouvait pas encore que quelqu’un se trouvait derrière la troisième pour répondre.

Cette distinction change presque tout le dépannage.

Premier test: est-ce toujours le même port?

J’ai commencé par vérifier ce que Gluetun considérait réellement comme le port actif.

Avec les intégrations natives, le port transmis est disponible via le serveur de contrôle ou le fichier /tmp/gluetun/forwarded_port. Gluetun peut également lancer une commande dès qu’un nouveau port est obtenu. Dans mon cas:

cat /tmp/gluetun/forwarded_port retournait: 62884 Puis j’ai regardé qBittorrent. Il écoutait encore sur 54127.

Voilà une panne beaucoup plus intéressante que « Docker bloque mon port ».

Avec ProtonVPN, le numéro attribué peut changer après une reconnexion. Proton demande d’ailleurs explicitement de reporter le port actif dans le client BitTorrent et précise qu’une reconnexion VPN peut imposer de le mettre à jour. Le VPN avait donc fait sa partie du travail.

Gluetun aussi.

C’était qBittorrent qui était resté une connexion en retard.

J’ai remplacé 54127 par 62884, enregistré puis relancé le test.

Cette fois, avant même de regarder le résultat externe, j’ai voulu vérifier le deuxième verrou.

Avec network_mode: service:gluetun, les deux conteneurs partagent la même porte

Mon Compose utilisait:

network_mode: "service:gluetun"

Ce détail est plus important que toutes les lignes ports: que j’avais ajoutées au hasard.

Docker définit ce mode comme l’utilisation, par un service, du réseau du service référencé. En pratique, qBittorrent ne possède plus son propre chemin réseau indépendant: il utilise celui de Gluetun. C’est précisément ce qu’on veut dans ce montage.

Si qBittorrent sort, il sort par le tunnel.

Si le tunnel tombe, le pare-feu Gluetun sert de garde-barrière.

Et si une connexion arrive par le port VPN, l’application doit être réellement en écoute dans cet espace réseau partagé.

Cela explique aussi pourquoi publier frénétiquement 62884:62884 vers l’hôte ne réparait pas mon problème. Cette règle peut être utile lorsqu’on veut atteindre localement une interface Web ou un autre service depuis le LAN. Elle ne transforme pas magiquement un port obtenu sur le serveur VPN en processus à l’écoute derrière Gluetun.

J’avais jusque-là essayé de rajouter des portes.

Il fallait simplement vérifier si quelqu’un répondait derrière celle qui existait déjà.

Le test qui sépare Gluetun de qBittorrent

C’est là que la documentation officielle fournit le test le plus utile de tout le diagnostic.

Gluetun propose de lancer son petit port-checker directement dans le conteneur, en écoute sur le port attribué, puis de tenter une connexion vers l’IP publique du VPN et ce port. L’intérêt n’est pas l’outil lui-même.

L’intérêt est ce qu’il retire de l’équation.

Si le port-checker reçoit la connexion, alors le fournisseur VPN, le tunnel et le pare-feu Gluetun ont déjà fait le trajet difficile. À ce stade, continuer à modifier WireGuard, Proton ou le routeur revient généralement à chercher la panne du mauvais côté.

Si le port-checker ne reçoit rien, je reste en amont: serveur VPN, port réellement attribué, règles du tunnel ou configuration Gluetun.

C’est beaucoup plus propre qu’un site de test affichant simplement rouge ou vert.

Une discussion publique sur le dépôt Gluetun illustre parfaitement cette séparation: l’utilisateur réussissait le test officiel avec port-checker, utilisait bien l’IP VPN attendue, mais qBittorrent continuait à se considérer derrière un pare-feu. Ce résultat ne condamnait plus toute la chaîne. Il pointait vers le dernier maillon: l’application et son port d’écoute. C’est le moment où mon diagnostic est devenu presque mécanique.

Port Gluetun actuel: 62884. Test Gluetun sur 62884: réussi. qBittorrent: doit écouter sur 62884. Plus besoin de toucher au routeur.

La vraie correction n’était pas de saisir le bon port une fois

Après avoir aligné qBittorrent sur le port actif, le contrôle externe est passé au vert.

Mais je savais déjà ce qui allait arriver.

À la prochaine reconnexion VPN, je risquais de recommencer.

Le problème n’était donc plus « comment ouvrir 62884? ».

C’était: comment faire en sorte que l’application suive automatiquement le port que Gluetun vient d’obtenir?

C’est justement le rôle de VPN_PORT_FORWARDING_UP_COMMAND. Gluetun peut exécuter une commande après l’attribution du port et injecter la valeur {{PORT}} dans cette commande. Dans une configuration qBittorrent, elle peut servir à appeler l’API locale du client et à remplacer son port d’écoute dès que Gluetun reçoit le nouveau numéro. Je préfère cette logique à un port copié manuellement dans trois fichiers.

Le fournisseur attribue le numéro.

Gluetun l’autorise.

L’application l’adopte.

Et surtout, ces trois états restent liés lorsque le tunnel redémarre.

C’est là que mon « port mystérieusement fermé » a cessé d’être mystérieux.

J’avais surtout demandé à la même installation VPN de faire trop de métiers

Une fois qBittorrent réellement joignable, j’ai regardé mon serveur différemment.

Le port forwarding avait une raison précise d’exister: ce conteneur P2P avait besoin de recevoir des connexions entrantes.

Mon navigateur n’en avait pas besoin.

Mon ordinateur portable non plus.

Mon téléphone encore moins.

Pourtant, à force de travailler sur Gluetun, j’avais commencé à traiter chaque besoin VPN comme s’il exigeait un fichier Compose, un namespace réseau, un pare-feu et un port à surveiller.

C’est à ce moment-là que j’ai installé OnlydogVPN^↗ sur la machine que j’utilisais au quotidien.

Je ne lui ai pas demandé de remplacer le port forwarding de Gluetun. Ce serait confondre à nouveau deux problèmes différents.

Je lui ai demandé l’autre travail: garder mon trafic courant derrière un VPN sans transformer chaque connexion en exercice d’administration réseau.

L’interface orientée autour de l’usage m’a surtout permis de revenir à quelque chose que j’avais presque oublié pendant ce dépannage: choisir ce que je voulais faire, connecter, puis passer à autre chose. Je n’avais aucune raison de faire dépendre ma navigation quotidienne de la plomberie réseau dont qBittorrent avait réellement besoin.

Le service plus petit possède évidemment moins de recul public que les acteurs installés depuis de longues années, et moins de régions que certains grands réseaux. Mais après plusieurs heures à distinguer port VPN, pare-feu, namespace Docker et port d’écoute, cette simplicité n’avait plus l’air d’être une absence de fonctionnalités.

Elle ressemblait plutôt à une bonne séparation des responsabilités.

Depuis, je ne demande plus « le port est-il ouvert? »

Je demande où il est ouvert.

Si Gluetun n’obtient aucun port, je regarde le fournisseur VPN.

Si Gluetun obtient le port mais que son test d’écoute échoue, je reste sur le tunnel et son pare-feu.

Si le test Gluetun fonctionne mais que qBittorrent reste fermé, je ne touche plus au VPN: je vérifie le port réellement écouté par l’application et sa synchronisation après reconnexion.

C’est ce troisième cas qui m’avait fait perdre le plus de temps, précisément parce que les logs semblaient annoncer que tout était terminé.

Ils n’avaient pas tort.

Ils annonçaient simplement que Gluetun avait terminé sa partie.

Après correction, le port externe répondait, qBittorrent utilisait le même numéro et une reconnexion ne m’obligeait plus à retourner copier une valeur à la main.

J’ai donc gardé Gluetun là où son port entrant avait une vraie utilité.

Et j’ai cessé d’en faire l’architecture VPN de tout le reste.

Pour ce problème précis, le bon diagnostic n’est pas « ouvert ou fermé ». C’est de savoir lequel des trois verrous — fournisseur, Gluetun ou application — n’a pas encore tourné.