VPN activada e localhost deixa de funcionar: nome, proxy ou bind?

O teu servidor de desenvolvemento respondeu hai un minuto, e agora que o túnel está activo a petición caduca cun nome de host que nunca escribiches. Dous mecanismos explican case todos os casos, e desde fóra parecen idénticos. Un sufixo de busca converte un nome curto nun corporativo, mentres que un proxy envía o tráfico de loopback a un host que non pode alcanzalo. Separar os dous custa unha consulta e aforra a regra de cortafogos que estabas a piques de escribir.

Cando localhost resolve na zona corporativa

Comproba a que resolve o nome mentres o túnel está activo, despois executa a mesma consulta co túnel desactivado e compara as dúas respostas. A pista é un enderezo no rango corporativo onde esperabas 127.0.0.1. Un rexistro como localhost.mycompany.corp gaña á entrada de loopback en canto o cliente engade ese sufixo á lista de busca, e a petición viaxa a un host privado onde nada escoita nese porto. Le a lista de busca en lugar de adiviñala, porque un cliente pode engadir máis dun dominio e a orde decide que candidato se proba primeiro:

getent hosts localhost
resolvectl domain
ss -ltnp | grep 8080

Substitúe o nome de host polo enderezo literal na aplicación, no cliente de base de datos ou no URL do caderno, e despois repite a petición. Se o fallo desaparece, tiñas un problema de nomes e o túnel só era o desencadeante. Se persiste, o oínte ou a ruta é o seguinte sospeitoso e o nome era unha pista falsa.

Axustes de proxy que capturan loopback

Un proxy do sistema aplicado cando sobe o túnel aceptará unha petición a 127.0.0.1 e reenviaraa a un proxy remoto que non ten idea do que querías dicir. Unha lista de excepcións baleira converte unha petición local nunha remota, e a mensaxe de erro raramente o di. Engade os enderezos de loopback á lista de excepcións para toda a sesión e non para un só comando, e despois confirma que a ferramenta o respecta antes de concluír nada sobre a rede.

Os frameworks de aplicacións len as súas propias variables de contorno e ás veces o seu propio ficheiro de configuración, así que unha excepción que funciona para unha ferramenta non demostra nada para a seguinte. Os navegadores engaden un matiz: os navegadores baseados en Chromium omiten o proxy para loopback de forma implícita, e un token de excepción pode eliminar ese comportamento. Comproba a decisión efectiva do proxy en lugar de supoñer que o axuste do sistema operativo é toda a historia. Dous comandos resolven isto para calquera cousa lanzada desde un shell:

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

O enderezo de bind decide quen pode conectarse

Un servidor iniciado en 127.0.0.1 acepta conexións só desa máquina, que adoita ser o valor predeterminado correcto para o desenvolvemento. Un servidor en 0.0.0.0 responde en todas as interfaces, adaptador VPN incluído, o que é máis exposición da que a maioría pretende. Cando falla o enderezo literal de loopback, comproba o bind antes que nada.

Fíxate no socket de escoita e anota o enderezo ao que está vinculado, non só o porto. Se outro dispositivo ou un contedor debe alcanzar o servizo a través do túnel, vincula á interface específica que usará e permite ese porto a propósito. Se só o necesita a túa propia máquina, mantén o bind estreito e corrixe o cliente en lugar de ampliar o servidor. Unha redirección de portos ou unha capa de túneles pode unir ambos, pero cada unha engade un compoñente que despois necesitará a súa propia depuración.

Onde unha ferramenta de depuración espera a LAN

As ferramentas de depuración levan supostos que un túnel rompe en silencio. Unha ponte de depuración de teléfono perde o seu dispositivo cando a VPN captura a subrede do dispositivo, así que reconectar pola dirección LAN ou un cable evita o conflito. Un centro de automatización de navegador caduca cando o centro só é accesible a través do proxy, ou cando un cortafogos local descarta o seu porto de control. Un depurador remoto pode esixir elevación e un enderezo de loopback onde o cliente reescribiu a ruta.

Identifica o porto de control e o porto de datos por separado, xa que a miúdo un sobrevive mentres o outro non. Despois decide se a corrección pertence á configuración da ferramenta, a unha ruta para esa subrede ou a unha regra de túnel dividido. Editar un ficheiro hosts en cada máquina de desenvolvedor escala peor e esquécese primeiro. Prefire o axuste que vive co perfil e que pode revisar quen sexa o propietario do túnel.

Deténte na primeira etapa que falla

Baixa por tres etapas: resolve o nome, abre un socket ao enderezo literal e despois deixa que a ferramenta faga a súa propia conexión. Cada etapa elimina unha capa, así que o primeiro fallo nomea a capa a corrixir e todo o posterior queda sen probar. Anota o resultado antes de cambiar nada, porque unha corrección aplicada antes da medición non se distingue da sorte. Se o primeiro intento falla e un reintento funciona, o túnel probablemente non estaba listo cando arrincou a ferramenta.

Substitúe a espera fixa por unha comprobación de dispoñibilidade acoutada que espere a ruta, e mantén a etapa que falla no rexistro para que a seguinte persoa vexa onde se detivo. Unha ferramenta que se recupera soa non está arranxada, ten sorte, e a sorte acábase na máquina doutra persoa. Cambia o túnel ao final, e só para a etapa que realmente fallou. Esa orde é tamén o camiño máis curto de volta a unha compilación funcional, porque che impide reconstruír un compoñente que nunca estivo implicado.