VPN activé et localhost ne répond plus : nom, proxy ou bind ?

Votre serveur de développement répondait il y a une minute, et maintenant que le tunnel est monté, la requête expire avec un nom d'hôte que vous n'avez jamais saisi. Deux mécanismes expliquent presque tous les cas, et de l'extérieur ils se ressemblent. Un suffixe de recherche transforme un nom court en nom d'entreprise, tandis qu'un proxy envoie le trafic loopback vers un hôte qui ne peut pas l'atteindre. Séparer les deux coûte une requête et épargne la règle de pare-feu que vous étiez sur le point d'écrire.

Quand localhost résout dans la zone d'entreprise

Vérifiez vers quoi le nom résout pendant que le tunnel est monté, puis exécutez la même requête une fois le tunnel coupé et comparez les deux réponses. L'indice est une adresse dans la plage d'entreprise là où vous attendiez 127.0.0.1. Un enregistrement comme localhost.mycompany.corp l'emporte sur l'entrée loopback dès que le client ajoute ce suffixe à la liste de recherche, et la requête voyage vers un hôte privé où rien n'écoute sur ce port. Lisez la liste de recherche au lieu de la deviner, car un client peut ajouter plus d'un domaine et l'ordre décide quel candidat est essayé en premier :

getent hosts localhost
resolvectl domain
ss -ltnp | grep 8080

Remplacez le nom d'hôte par l'adresse littérale dans l'application, le client de base de données ou l'URL du carnet, puis répétez la requête. Si l'échec disparaît, vous aviez un problème de nommage et le tunnel n'était que le déclencheur. S'il persiste, l'écouteur ou la route est le prochain suspect et le nom n'était qu'une fausse piste.

Réglages de proxy qui capturent loopback

Un proxy système appliqué à la montée du tunnel acceptera une requête vers 127.0.0.1 et la transmettra à un proxy distant qui n'a aucune idée de ce que vous vouliez dire. Une liste d'exceptions vide transforme une requête locale en requête distante, et le message d'erreur le dit rarement. Ajoutez les adresses loopback à la liste d'exceptions pour toute la session plutôt que pour une seule commande, puis confirmez que l'outil la respecte avant de conclure quoi que ce soit sur le réseau.

Les frameworks applicatifs lisent leurs propres variables d'environnement et parfois leur propre fichier de configuration, donc une exception qui fonctionne pour un outil ne prouve rien pour le suivant. Les navigateurs ajoutent une nuance : les navigateurs basés sur Chromium contournent implicitement le proxy pour loopback, et un jeton d'exception peut retirer ce comportement. Vérifiez la décision effective du proxy au lieu de supposer que le réglage du système d'exploitation est toute l'histoire. Deux commandes règlent la question pour tout ce qui est lancé depuis un shell :

curl --noproxy '*' http://127.0.0.1:8080/health
NO_PROXY=localhost,127.0.0.1,::1 your-tool

L'adresse de bind décide qui peut se connecter

Un serveur démarré sur 127.0.0.1 n'accepte les connexions que depuis cette machine, ce qui est généralement le bon défaut pour le développement. Un serveur sur 0.0.0.0 répond sur toutes les interfaces, adaptateur VPN compris, ce qui expose davantage que ce que la plupart des gens visent. Quand l'adresse loopback littérale échoue, vérifiez le bind avant tout le reste.

Regardez le socket à l'écoute et notez l'adresse à laquelle il est lié, pas seulement le port. Si un autre appareil ou un conteneur doit atteindre le service via le tunnel, liez-le à l'interface précise qu'il utilisera et autorisez ce port délibérément. Si seule votre machine en a besoin, gardez le bind étroit et corrigez le client au lieu d'élargir le serveur. Une redirection de port ou une couche de tunnels peut relier les deux, mais chacune ajoute un composant qui aura besoin de son propre débogage plus tard.

Où un outil de débogage attend le LAN

Les outils de débogage portent des hypothèses qu'un tunnel casse en silence. Un pont de débogage de téléphone perd son appareil quand le VPN capture le sous-réseau de l'appareil, donc se reconnecter via l'adresse LAN ou un câble évite le conflit. Un hub d'automatisation de navigateur expire quand le hub n'est joignable que via le proxy, ou quand un pare-feu local abandonne son port de contrôle. Un débogueur distant peut exiger une élévation et une adresse loopback là où le client a réécrit la route.

Identifiez le port de contrôle et le port de données séparément, car souvent l'un survit quand l'autre non. Décidez ensuite si la correction relève de la configuration de l'outil, d'une route pour ce sous-réseau ou à une règle de tunneling divisé. Modifier un fichier hosts sur chaque machine de développeur passe le plus mal à l'échelle et s'oublie en premier. Préférez le réglage qui vit avec le profil et que peut relire celui qui possède le tunnel.

Arrêtez-vous à la première étape qui échoue

Descendez trois étapes : résolvez le nom, ouvrez un socket vers l'adresse littérale, puis laissez l'outil faire sa propre connexion. Chaque étape élimine une couche, donc le premier échec nomme la couche à corriger et tout ce qui suit reste non testé. Notez le résultat avant de changer quoi que ce soit, car une correction appliquée avant la mesure ne se distingue pas de la chance. Si la première tentative échoue et qu'une nouvelle fonctionne, le tunnel n'était probablement pas prêt au démarrage de l'outil.

Remplacez l'attente fixe par une vérification de disponibilité bornée qui attend la route, et gardez l'étape qui échoue dans le journal pour que la personne suivante voie où cela s'est arrêté. Un outil qui se rétablit tout seul n'est pas corrigé, il a de la chance, et la chance s'épuise sur la machine de quelqu'un d'autre. Changez le tunnel en dernier, et uniquement pour l'étape qui a réellement échoué. Cet ordre est aussi le chemin le plus court vers une compilation qui fonctionne, car il vous empêche de reconstruire un composant qui n'était jamais impliqué.