VPN engegat i localhost deixa de funcionar: nom, proxy o bind?

El teu servidor de desenvolupament va respondre fa un minut, i ara que el túnel està aixecat la petició expira amb un nom d'amfitrió que mai no has escrit. Dos mecanismes expliquen gairebé tots els casos, i des de fora semblen idèntics. Un sufix de cerca converteix un nom curt en un de corporatiu, mentre que un proxy envia el trànsit de loopback a un amfitrió que no el pot assolir. Separar els dos costa una consulta i estalvia la regla de tallafocs que estaves a punt d'escriure.

Quan localhost resol a la zona corporativa

Comprova a què resol el nom mentre el túnel està aixecat, després executa la mateixa consulta amb el túnel baixat i compara les dues respostes. La pista és una adreça dins del rang corporatiu on esperaves 127.0.0.1. Un registre com localhost.mycompany.corp guanya l'entrada de loopback quan el client afegeix aquest sufix a la llista de cerca, i la petició viatja a un amfitrió privat on no hi ha res escoltant en aquest port. Llegeix la llista de cerca en lloc d'endevinar-la, perquè un client pot afegir més d'un domini i l'ordre decideix quin candidat es prova primer:

getent hosts localhost
resolvectl domain
ss -ltnp | grep 8080

Substitueix el nom d'amfitrió per l'adreça literal a l'aplicació, al client de base de dades o a l'URL del quadern, i després repeteix la petició. Si la fallada desapareix, tenies un problema de noms i el túnel només era el desencadenant. Si persisteix, l'oient o la ruta és el següent sospitós i el nom era un esquer fals.

Configuració de proxy que captura loopback

Un proxy de sistema aplicat quan el túnel puja acceptarà una petició a 127.0.0.1 i la reenviarà a un proxy remot que no té ni idea de què volies dir. Una llista d'exempcions buida converteix una petició local en remota, i el missatge d'error poques vegades ho diu. Afegeix les adreces de loopback a la llista d'exempcions per a tota la sessió i no per a una sola ordre, i després confirma que l'eina ho respecta abans de concloure res sobre la xarxa.

Els marcs d'aplicació llegeixen les seves pròpies variables d'entorn i de vegades el seu propi fitxer de configuració, així que una exempció que funciona per a una eina no demostra res per a la següent. Els navegadors afegeixen un detall: els navegadors basats en Chromium ometen el proxy per a loopback de manera implícita, i un testimoni d'exempció pot eliminar aquest comportament. Comprova la decisió efectiva del proxy en lloc de suposar que la configuració del sistema operatiu és tota la història. Dues ordres ho resolen per a qualsevol cosa llançada des d'un shell:

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

L'adreça de bind decideix qui es pot connectar

Un servidor iniciat a 127.0.0.1 accepta connexions només d'aquella màquina, que normalment és el valor per defecte correcte per al desenvolupament. Un servidor a 0.0.0.0 respon a totes les interfícies, adaptador VPN inclòs, cosa que és més exposició de la que la majoria de gent pretén. Quan l'adreça literal de loopback falla, comprova el bind abans que res.

Mira el socket d'escolta i fixa't en l'adreça a què està lligat, no només en el port. Si un altre dispositiu o un contenidor ha d'assolir el servei a través del túnel, lliga'l a la interfície específica que farà servir i permet aquell port deliberadament. Si només cal per a la teva màquina, mantén el bind estret i corregeix el client en lloc d'ampliar el servidor. Un port forward o una capa de túnels pot fer de pont entre els dos, però cadascun afegeix un component que després necessitarà la seva pròpia depuració.

On una eina de depuració espera la LAN

Les eines de depuració porten supòsits que un túnel trenca en silenci. Un pont de depuració de telèfon perd el dispositiu quan la VPN captura la subxarxa del dispositiu, així que reconnectar per l'adreça LAN o un cable evita el conflicte. Un centre d'automatització de navegador expira quan el centre només és accessible a través del proxy, o quan un tallafocs local descarta el seu port de control. Un depurador remot pot exigir elevació i una adreça de loopback on el client va reescriure la ruta.

Identifica el port de control i el port de dades per separat, ja que sovint un sobreviu mentre l'altre no. Després decideix si la correcció pertany a la configuració de l'eina, a una ruta per a aquesta subxarxa o a una regla de túnel dividit. Editar un fitxer hosts a cada màquina de desenvolupador escala pitjor i s'oblida primer. Prefereix la configuració que viu amb el perfil i que pot revisar qui sigui el propietari del túnel.

Atura't a la primera etapa que falla

Baixa per tres etapes: resol el nom, obre un socket a l'adreça literal, i després deixa que l'eina faci la seva pròpia connexió. Cada etapa elimina una capa, així que la primera fallada nomena la capa a corregir i tot el que ve després queda sense provar. Anota el resultat abans de canviar res, perquè una correcció aplicada abans del mesurament no es pot distingir de la sort. Si el primer intent falla i un reintent funciona, el túnel probablement no estava a punt quan l'eina va arrencar.

Substitueix l'espera fixa per una comprovació de disponibilitat limitada que esperi la ruta, i mantén l'etapa que falla al registre perquè la propera persona vegi on es va aturar. Una eina que es recupera sola no està arreglada, té sort, i la sort s'acaba a la màquina d'algú altre. Canvia el túnel al final, i només per a l'etapa que realment va fallar. Aquest ordre també és el camí més curt de tornada a una compilació funcional, perquè t'impedeix reconstruir un component que mai no hi era.