VPN activada y localhost deja de funcionar: ¿nombre, proxy o bind?

Tu servidor de desarrollo respondió hace un minuto, y ahora que el túnel está activo la petición expira con un nombre de host que nunca escribiste. Dos mecanismos explican casi todos los casos, y desde fuera parecen idénticos. Un sufijo de búsqueda convierte un nombre corto en uno corporativo, mientras que un proxy envía el tráfico de loopback a un host que no puede alcanzarlo. Separar los dos cuesta una consulta y ahorra la regla de cortafuegos que estabas a punto de escribir.

Cuando localhost resuelve en la zona corporativa

Comprueba a qué resuelve el nombre mientras el túnel está activo, luego ejecuta la misma consulta con el túnel desactivado y compara las dos respuestas. La pista es una dirección del rango corporativo donde esperabas 127.0.0.1. Un registro como localhost.mycompany.corp gana a la entrada de loopback en cuanto el cliente añade ese sufijo a la lista de búsqueda, y la petición viaja a un host privado donde nada escucha en ese puerto. Lee la lista de búsqueda en lugar de adivinarla, porque un cliente puede añadir más de un dominio y el orden decide qué candidato se prueba primero:

getent hosts localhost
resolvectl domain
ss -ltnp | grep 8080

Sustituye el nombre de host por la dirección literal en la aplicación, el cliente de base de datos o la URL del cuaderno, y luego repite la petición. Si el fallo desaparece, tenías un problema de nombres y el túnel solo era el desencadenante. Si persiste, el oyente o la ruta es el siguiente sospechoso y el nombre era una pista falsa.

Ajustes de proxy que capturan loopback

Un proxy del sistema aplicado cuando sube el túnel aceptará una petición a 127.0.0.1 y la reenviará a un proxy remoto que no tiene idea de qué querías decir. Una lista de excepciones vacía convierte una petición local en remota, y el mensaje de error rara vez lo dice. Añade las direcciones de loopback a la lista de excepciones para toda la sesión y no para un solo comando, y luego confirma que la herramienta lo respeta antes de concluir nada sobre la red.

Los frameworks de aplicaciones leen sus propias variables de entorno y a veces su propio archivo de configuración, así que una excepción que funciona para una herramienta no demuestra nada para la siguiente. Los navegadores añaden un matiz: los navegadores basados en Chromium omiten el proxy para loopback de forma implícita, y un token de excepción puede eliminar ese comportamiento. Comprueba la decisión efectiva del proxy en lugar de suponer que el ajuste del sistema operativo es toda la historia. Dos comandos lo resuelven para cualquier cosa lanzada desde un shell:

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

La dirección de bind decide quién puede conectarse

Un servidor iniciado en 127.0.0.1 acepta conexiones solo de esa máquina, que suele ser el valor predeterminado correcto para el desarrollo. Un servidor en 0.0.0.0 responde en todas las interfaces, incluido el adaptador VPN, lo que es más exposición de la que la mayoría pretende. Cuando falla la dirección literal de loopback, comprueba el bind antes que nada.

Fíjate en el socket de escucha y anota la dirección a la que está vinculado, no solo el puerto. Si otro dispositivo o un contenedor debe alcanzar el servicio a través del túnel, vincula a la interfaz específica que usará y permite ese puerto a propósito. Si solo lo necesita tu propia máquina, mantén el bind estrecho y corrige el cliente en lugar de ampliar el servidor. Una redirección de puertos o una capa de túneles puede unir ambos, pero cada una añade un componente que luego necesitará su propia depuración.

Donde una herramienta de depuración espera la LAN

Las herramientas de depuración llevan supuestos que un túnel rompe en silencio. Un puente de depuración de teléfono pierde su dispositivo cuando la VPN captura la subred del dispositivo, así que reconectar por la dirección LAN o un cable evita el conflicto. Un centro de automatización de navegador expira cuando el centro solo es accesible a través del proxy, o cuando un cortafuegos local descarta su puerto de control. Un depurador remoto puede exigir elevación y una dirección de loopback donde el cliente reescribió la ruta.

Identifica el puerto de control y el puerto de datos por separado, ya que a menudo uno sobrevive mientras el otro no. Luego decide si la corrección pertenece a la configuración de la herramienta, a una ruta para esa subred o a una regla de túnel dividido. Editar un archivo hosts en cada máquina de desarrollo escala peor y se olvida primero. Prefiere el ajuste que vive con el perfil y que puede revisar quien sea el propietario del túnel.

Detente en la primera etapa que falla

Baja por tres etapas: resuelve el nombre, abre un socket a la dirección literal y luego deja que la herramienta haga su propia conexión. Cada etapa elimina una capa, así que el primer fallo nombra la capa que hay que corregir y todo lo posterior queda sin probar. Anota el resultado antes de cambiar nada, porque una corrección aplicada antes de la medición no se distingue de la suerte. Si el primer intento falla y un reintento funciona, el túnel probablemente no estaba listo cuando arrancó la herramienta.

Sustituye la espera fija por una comprobación de disponibilidad acotada que espere la ruta, y mantén la etapa que falla en el registro para que la siguiente persona vea dónde se detuvo. Una herramienta que se recupera sola no está arreglada, tiene suerte, y la suerte se acaba en la máquina de otro. Cambia el túnel al final, y solo para la etapa que realmente falló. Ese orden es también el camino más corto de vuelta a una compilación funcional, porque te impide reconstruir un componente que nunca estuvo implicado.