Las peticiones de la aplicación fallan tras una VPN corporativa, pero el navegador funciona

Abres el portal interno en un navegador y carga. Ejecutas la aplicación que llama al mismo host y falla, con un mensaje que no nombra ninguna capa. El túnel transporta el navegador, así que el túnel no es el primer sospechoso. Hay cuatro cosas entre tu petición y el servicio, y cada una deja una firma distinta. Este es el orden que sigo, empezando por la petición que la aplicación envía de verdad y no por la página de ajustes del cliente VPN.

Mira la petición que la aplicación envía realmente

Antes de tocar la configuración, haz que la aplicación te diga qué hace. Una captura de una sola petición con el proxy desactivado explícitamente y una prueba de puerto sencilla te dan dos líneas base con las que comparar los pasos siguientes. Si la petición funciona con el proxy desactivado, ya has terminado con tres de las cuatro capas.

env | grep -i proxy            # Linux/macOS
netsh winhttp show proxy       # Windows, machine-wide
curl -sv --noproxy '*' https://svc.internal/
nc -vz svc.internal 8080

Ejecuta las dos últimas contra el mismo destino y observa dónde divergen. Un navegador que funciona más un curl que funciona más una aplicación que no funciona reducen el problema a algo que añade la aplicación: un proxy, un transporte o un tamaño de mensaje.

La aplicación heredó un proxy que nadie configuró

La mayoría de las pilas HTTP leen la configuración del proxy del sistema operativo por defecto. Un cliente VPN corporativo suele instalar uno como parte de su perfil de acceso, así que las peticiones salen por un proxy que el desarrollador nunca mencionó en el código. En .NET el controlador predeterminado toma los ajustes de IE/WinHTTP; Java lee -Dhttp.proxyHost; Node no tiene soporte de proxy integrado hasta que una biblioteca lo añade. El fallo rara vez es un rechazo limpio, y por eso la gente empieza a mirar el servidor.

La prueba cuesta una petición: desactiva el proxy explícitamente en un solo controlador y compara.

var handler = new HttpClientHandler { UseProxy = false };
using var client = new HttpClient(handler);

Si eso funciona, el arreglo pertenece a la configuración de la aplicación, no al túnel. Repite la auditoría para cada entorno de ejecución del proyecto, porque cada uno lee una fuente distinta y puede que solo uno esté roto.

El puerto que eligió no es el puerto que permite la política

Un host enrutado no es un servicio permitido. La política corporativa suele permitir los puertos web de salida y descartar el resto, así que un servicio en el 8080 o el 1883 es inalcanzable mientras que el 443 funciona bien. El navegador no demuestra nada aquí: usa el 443 por definición.

Publica el mismo servicio detrás del 443 y llégalo por nombre antes de pedir una excepción. Si la excepción es realmente necesaria, limítala a un rango de origen y un destino y trátala como parte de la definición del servicio, no como el apaño personal de alguien.

TCP en crudo que la ruta reinicia

Las conexiones TCP en crudo de larga duración son la capa que falla de forma más confusa. Una ruta que permite tráfico web puede igualmente reiniciar o reescribir TCP saliente poco habitual, y el cliente informa de un error de socket que se lee como una caída. Los servicios de mensajería y de eventos suelen incluir un transporte WebSocket justo para este tipo de red, y cambiar es una opción del cliente, no un cambio del túnel.

Cambia el transporte, vuelve a probar y no cambies nada más en la misma ejecución. Esa prueba de una sola variable te dice si el reinicio vino de la ruta o del servicio.

Conexiones que solo se cierran con cargas grandes

Una petición que funciona y luego muere aproximadamente un segundo después, pero solo cuando el cuerpo es grande, apunta a un límite de tamaño en algún punto intermedio. Un intermediario que cuenta los bytes de los mensajes puede soltar la conexión a mitad de la transferencia, y el cliente informa de un cierre anómalo en lugar de un tiempo de espera.

Trocea la carga en la capa de aplicación. Mantenlo separado del trabajo de MTU: bajar el tamaño de paquete del túnel ayuda cuando las sesiones TCP normales se atascan en un recuento de bytes constante, y no hace nada por un mensaje que un intermediario considera demasiado grande.

Cómo distinguir las cuatro en una sola pasada

Tres observaciones resuelven la mayoría de los casos. ¿El fallo ocurre de inmediato o solo con un cuerpo grande? ¿La misma petición funciona con el proxy desactivado? ¿Cambia el resultado al cambiar de puerto o de transporte? Escribe las respuestas antes del siguiente cambio, porque una VPN corporativa más un proxy heredado más un valor predeterminado de la aplicación te dan tres causas plausibles a la vez.

Mantén una variable por prueba y anota el host de destino que usaste. Sin esa línea base, la siguiente persona repite los cuatro pasos desde el principio.