La aplicación arranca en tu máquina virtual.
El servicio está levantado.
El puerto parece correcto.
Y aun así no llegas al endpoint.
Bienvenido a uno de los problemas más habituales del desarrollo corporativo: el código funciona, pero la red tiene otros planes.
Primero separa el problema
Cuando algo no responde, empezar cambiando código suele ser una mala idea.
Antes hay que descubrir en qué punto se rompe la comunicación.
Comprueba en este orden:
- ¿La aplicación está realmente escuchando?
- ¿Responde desde la propia máquina virtual?
- ¿El puerto está abierto en el firewall local?
- ¿La IP y el nombre DNS apuntan al servidor correcto?
- ¿La VPN permite llegar a esa red?
- ¿Existe un proxy intermedio?
- ¿El balanceador o firewall corporativo tiene la regla necesaria?
Cada respuesta elimina una parte del mapa.
Localhost no significa accesible
Que una URL funcione con localhost dentro de la máquina no significa que pueda abrirse desde fuera.
La aplicación puede estar escuchando únicamente en la interfaz local. También puede estar publicada en un puerto que el firewall bloquea.
Prueba primero desde la propia VM utilizando su nombre o su IP. Después prueba desde otra máquina de la misma red.
Ese cambio sencillo permite saber si el problema está en la aplicación o en la conectividad.
VPN, proxy y redes corporativas
Muchas máquinas virtuales solo son accesibles desde una VPN.
Pero conectarse a la VPN no siempre significa tener acceso a todas las subredes.
Puede faltar una ruta, un grupo de seguridad o una regla específica.
El proxy añade otra capa. Algunas peticiones salen directamente y otras deben pasar por él. Una aplicación puede necesitar configurar sus variables de proxy o excluir direcciones internas.
Cuando una petición atraviesa cinco capas, el error que ves rara vez te dice en cuál de ellas se quedó.
DNS, IP y fichero hosts
Si la IP funciona y el nombre no, probablemente tienes un problema de resolución DNS.
Comprueba a qué dirección resuelve el dominio. Puede existir una entrada antigua, una caché local o un DNS diferente según estés dentro o fuera de la VPN.
El fichero hosts puede servir para una prueba temporal, pero no debe convertirse en la infraestructura oficial del proyecto.
Una entrada manual olvidada puede hacer que una persona llegue a un servidor distinto del resto del equipo.
No olvides el certificado
En HTTPS puedes llegar al servidor y aun así recibir un error.
El certificado puede estar caducado, no incluir el nombre utilizado o proceder de una autoridad que tu equipo no confía.
No soluciones esto desactivando la validación de certificados en producción.
Arregla el certificado o la cadena de confianza.
Documenta la ruta
Para cada entorno conviene tener una ficha sencilla: URL, IP o DNS, puerto, VPN necesaria, proxy, certificado, responsable y prueba de conectividad.
No hace falta una enciclopedia.
Hace falta que el siguiente compañero no pierda dos días descubriendo que debía conectarse a otra VPN.
La conectividad no es magia.
Es una cadena de pasos. Si compruebas cada eslabón, el problema deja de ser enorme y se convierte en una lista manejable.
Antes de tocar el código, averigua hasta dónde llega realmente la petición.
