Gluetun connecté mais domaines cassés : le journal m’a évité de changer de serveur pour rien

Le téléchargement n’avait pas ralenti. Il n’avait même pas commencé. Dans Docker, Gluetun affichait pourtant une connexion VPN établie, l’adresse IP publique avait changé et le conteneur était debout. Mais Prowlarr répondait avec une erreur beaucoup plus simple : impossible de résoudre le nom de domaine. J’ai regardé ma liste de serveurs et j’ai presque fait ce que je faisais toujours dans ce genre de situation : changer de pays, redémarrer le tunnel et espérer tomber sur une sortie plus propre. Cette fois, j’ai ouvert le journal avant de toucher au serveur.

Le voyant vert m’avait envoyé vers le mauvais diagnostic

La confusion venait d’un détail très convaincant : le VPN avait l’air vivant.

Gluetun s’était lancé.

Le tunnel était établi.

Une nouvelle IP publique apparaissait.

Docker n’était pas en train de redémarrer en boucle.

À première vue, cela ressemblait donc à un mauvais serveur VPN. La sortie fonctionnait assez pour établir le tunnel, mais peut-être pas assez bien pour atteindre les services que je voulais utiliser.

J’avais déjà le curseur sur un autre emplacement quand j’ai relu l’erreur de Prowlarr.

Ce n’était pas :

connection refused

Ni :

timeout connecting

C’était le nom lui-même qui ne se résolvait pas.

Autrement dit, je m’apprêtais à changer la route alors que mon problème se trouvait peut-être dans l’annuaire.

Une connexion VPN peut parfaitement transporter le trafic et laisser malgré tout une application incapable de transformer exemple.com en adresse IP.

Gluetun traite justement le DNS comme une couche distincte. Sa configuration permet de choisir le type de résolveur amont — DNS over TLS, DNS over HTTPS ou DNS classique — ainsi que les résolveurs utilisés, le cache et certaines règles de filtrage.

À ce moment-là, changer de serveur n’était plus mon premier réflexe.

Je voulais d’abord savoir ce que disait le DNS.

Le journal racontait autre chose que l’écran « connecté »

J’avais toujours considéré les logs comme l’endroit où l’on finit après avoir épuisé les solutions simples.

Pour cette panne, ils auraient dû être ma première solution simple.

Les versions récentes de Gluetun ont justement renforcé cette visibilité : le projet distingue clairement la couche DNS du tunnel, prend en charge plusieurs méthodes de résolution et peut journaliser les requêtes DNS bloquées avec leur raison. Son système de healthcheck a lui aussi évolué.

Cela change la manière de lire un voyant vert.

Un healthcheck réussi ne signifie pas que chaque application derrière Gluetun peut résoudre chaque domaine dont elle a besoin. Gluetun vérifie sa propre connectivité selon les mécanismes prévus par son healthcheck.

Le voyant répondait donc essentiellement à cette question :

le tunnel est-il vivant ?

Prowlarr m’en posait une autre :

où se trouve ce domaine ?

J’avais traité les deux comme si elles étaient identiques.

Elles ne l’étaient pas.

J’ai arrêté de faire tourner la roulette des serveurs

J’ai laissé le serveur VPN exactement où il était.

Pas de nouveau pays.

Pas de nouvelle clé WireGuard.

Pas de redémarrage complet de la stack.

J’ai regardé les erreurs DNS et la configuration du résolveur.

Ce changement d’ordre paraît évident après coup, mais c’est précisément le genre de panne qui pousse à modifier trop de choses à la fois.

En février 2026, un utilisateur de Gluetun décrivait des conteneurs qui fonctionnaient puis cessaient de résoudre leurs noms de domaine après vingt à trente minutes. Il avait régénéré sa clé ProtonVPN, recréé le réseau et essayé plusieurs réglages avant d’isoler une différence entre DNS over TLS et DNS over HTTPS. Dans son environnement, le passage au DoH avait stabilisé la résolution.

Ce qui m’intéressait n’était pas de copier son réglage.

C’était l’erreur de méthode qui précédait sa découverte.

Si une application dit « nom introuvable », changer immédiatement de serveur VPN ajoute une nouvelle variable sans répondre à l’erreur affichée.

Je voulais désormais toucher uniquement à la couche que le journal mettait en cause.

« DNS ready » ne voulait pas encore dire que Prowlarr utilisait le bon chemin

J’ai alors failli tomber dans un deuxième piège.

Gluetun possède son propre mécanisme DNS.

Donc, pensais-je, les applications derrière lui utilisent forcément ce DNS comme je l’imagine.

Ce n’est pas toujours aussi simple.

Docker, Kubernetes ou la configuration du conteneur peuvent modifier la manière dont une application obtient ses réponses DNS.

Une discussion publiée sur r/gluetun en février 2026 montrait bien cette confusion : Gluetun démarrait, annonçait son IP VPN et indiquait que le DNS était prêt, tandis que Prowlarr continuait à échouer avec un message « Name does not resolve ». Plus troublant encore, un test nslookup manuel pouvait fonctionner.

C’est exactement le genre de contradiction qui donne envie de tout redémarrer.

Pour moi, elle a produit l’effet inverse.

Si un test DNS réussit à un endroit et que l’application échoue à un autre, la question n’est plus seulement :

« Est-ce que le DNS fonctionne ? »

Elle devient :

« Quel DNS utilise réellement ce processus ? »

Cette question valait beaucoup plus qu’un quatrième serveur VPN.

J’ai suivi le nom au lieu de suivre le tunnel

Dans ma configuration, j’ai donc remonté l’erreur dans l’ordre.

D’abord Prowlarr.

Puis la résolution réellement utilisée dans le conteneur.

Ensuite Gluetun.

Et seulement après, le tunnel.

C’était comme suivre un colis à partir de l’adresse incorrecte plutôt que de changer immédiatement de camion.

Le réglage DNS n’était pas aligné avec ce que j’avais supposé.

Je l’ai corrigé, recréé le conteneur concerné et relancé exactement la même requête.

Cette fois, je n’avais pas besoin d’interpréter un voyant.

Le nom s’est résolu.

Prowlarr a joint l’indexeur.

La recherche a renvoyé ses résultats.

Puis le téléchargement est parti.

Même serveur VPN.

Même pays.

Même tunnel.

J’avais passé plusieurs minutes à envisager de remplacer la partie qui fonctionnait.

Le journal m’avait ramené directement à celle qui ne fonctionnait pas.

Le contrôle de Gluetun était utile précisément parce que je voulais l’administrer

C’est là que mon jugement a changé.

J’aime Gluetun parce qu’il me donne du contrôle.

Pour une stack Docker, ce contrôle a du sens. Je peux décider quels conteneurs passent dans le tunnel, choisir le fonctionnement du DNS et disposer de suffisamment d’informations pour comprendre une panne.

Mais le contrôle possède un envers très concret.

Quand quelque chose casse, c’est aussi à moi de comprendre le résolveur, le réseau Docker, le healthcheck et les interactions entre les applications placées derrière le conteneur.

Sur mon serveur domestique, j’accepte volontiers cet échange.

Sur mon portable et mon téléphone, je me suis rendu compte que je voulais presque l’inverse.

Je ne cherchais pas une deuxième installation où je pourrais régler davantage de choses.

Je voulais un VPN qui m’en demande moins.

Sur mon portable, je ne voulais choisir ni DNS ni serveur

J’ai laissé la stack Docker enfin réparée et ouvert mon portable.

Il me restait quelques recherches à terminer et deux fichiers à envoyer. Je n’avais aucune envie de prolonger la matinée avec une deuxième session de diagnostic réseau.

J’ai ouvert OnlydogVPN^↗.

Au lieu de parcourir une liste de pays ou de commencer par choisir un protocole, j’ai utilisé le mode qui sélectionne automatiquement la connexion rapide.

Puis j’ai ouvert les mêmes domaines que j’avais utilisés pendant le dépannage.

Ils se sont chargés.

J’ai fermé puis rouvert le navigateur.

Toujours bon.

J’ai lancé l’envoi de mon premier fichier.

Il est parti.

C’était exactement le contraste que je venais de comprendre.

Dans Gluetun, pouvoir voir et régler la couche DNS m’avait aidé à réparer une infrastructure que je voulais administrer.

Sur mon portable, le petit service m’évitait précisément d’avoir une deuxième infrastructure à administrer.

Pendant les tests réalisés pour cet article, je n’ai eu ni résolveur à sélectionner, ni serveur à faire défiler, ni journal à ouvrir pour accomplir la tâche.

Les noms se résolvaient.

Les pages s’ouvraient.

Les fichiers partaient.

Je continuais.

Puis le Wi-Fi a disparu

Le deuxième avantage n’est pas apparu dans un menu.

Il est arrivé quand j’ai dû partir.

J’ai refermé le portable, pris mon téléphone et descendu les escaliers. Le Wi-Fi a commencé à disparaître avant que la connexion mobile ne prenne complètement le relais.

Après ma matinée, j’avais presque le réflexe d’ouvrir l’application VPN pour vérifier son état.

J’ai ouvert directement la page dont j’avais besoin.

Elle s’est chargée.

La connexion avait repris sur le nouveau réseau sans me renvoyer vers une liste de serveurs.

Le service utilise un transport basé sur HTTP/3 et est conçu pour mieux récupérer lorsque le réseau change. Sur une fiche technique, j’aurais probablement parcouru cette ligne sans m’y arrêter.

Après avoir passé la matinée à chercher pourquoi un domaine ne se résolvait plus, le résultat était beaucoup plus parlant : Wi-Fi perdu, réseau mobile retrouvé, page toujours accessible.

Je n’avais rien eu à réparer.

Moins de choix était devenu un avantage très concret

Le service reste plus récent et propose moins de régions que plusieurs grands fournisseurs.

Si mon objectif était de sélectionner manuellement une sortie parmi une longue liste de pays, cette limite compterait davantage.

Mais ce jour-là, j’avais justement compris que plus de choix ne résolvait pas mon problème.

Dans Gluetun, j’avais une bonne raison de vouloir accéder aux détails : c’était mon infrastructure, et les détails m’avaient permis d’identifier la panne.

Sur mes appareils quotidiens, ces mêmes décisions devenaient du travail supplémentaire.

Je voulais ouvrir le VPN.

Me connecter.

Puis oublier qu’il était là.

C’est ce que le petit service m’a permis de faire dans ce test.

Et après avoir passé suffisamment de temps à regarder des lignes DNS défiler, le fait de n’avoir aucun journal à consulter était probablement la caractéristique que j’appréciais le plus.

Maintenant, je lis la première erreur avant de toucher au serveur

Je n’ai pas arrêté d’utiliser Gluetun.

J’ai simplement arrêté de considérer chaque panne derrière Gluetun comme une panne de serveur VPN.

Si le tunnel est établi mais qu’une application affirme qu’un domaine n’existe plus, je commence désormais par le nom.

Je regarde le journal.

Je vérifie quel résolveur est réellement utilisé.

Et seulement si cette chaîne est cohérente, je remonte vers le serveur.

Cette méthode m’a permis de réparer la partie de mon installation où le contrôle est réellement utile.

Elle m’a aussi montré pourquoi je veux quelque chose de différent sur mes appareils quotidiens.

Dans Docker, je suis prêt à administrer le DNS parce que je veux maîtriser la chaîne.

Sur mon portable et mon téléphone, je veux surtout que cette chaîne disparaisse derrière le résultat.

Ce matin-là, changer de serveur aurait seulement déplacé mon tunnel.

Le journal m’a montré que le tunnel n’avait jamais été la chose à réparer.