As peticións da aplicación fallan tras unha VPN corporativa, pero o navegador funciona

Abre o portal interno nun navegador e carga. Executas a aplicación que chama o mesmo host e falla, cunha mensaxe que non nomea ningunha capa. O túnel transporta o navegador, así que o túnel non é o primeiro sospeitoso. Hai catro cousas entre a túa petición e o servizo, e cada unha deixa unha sinatura distinta. Esta é a orde que sigo, comezando pola petición que a aplicación envía de verdade e non pola páxina de axustes do cliente VPN.

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

Antes de tocar a configuración, fai que a aplicación che diga que fai. Unha captura dunha soa petición co proxy desactivado explicitamente e unha proba de porto simple danche dúas liñas base coas que comparar os pasos seguintes. Se a petición funciona co proxy desactivado, xa remataches tres das catro 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

Executa as dúas últimas contra o mesmo destino e observa onde diverxen. Un navegador que funciona máis un curl que funciona máis unha aplicación que non funciona reducen o problema a algo que engade a aplicación: un proxy, un transporte ou un tamaño de mensaxe.

A aplicación herdou un proxy que ninguén configurou

A maioría das pilas HTTP len a configuración do proxy do sistema operativo por defecto. Un cliente VPN corporativo adoita instalar un como parte do seu perfil de acceso, así que as peticións saen por un proxy que o desenvolvedor nunca mencionou no código. En .NET o controlador predeterminado toma os axustes de IE/WinHTTP; Java le -Dhttp.proxyHost; Node non ten soporte de proxy integrado ata que unha biblioteca o engade. O fallo raramente é un rexeitamento limpo, e por iso a xente comeza a mirar o servidor.

A proba custa unha petición: desactiva o proxy explicitamente nun só controlador e compara.

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

Se iso funciona, a corrección pertence á configuración da aplicación, non ao túnel. Repite a auditoría para cada contorno de execución do proxecto, porque cada un le unha fonte distinta e pode que só un estea roto.

O porto que escolleu non é o porto que permite a política

Un host encamiñado non é un servizo permitido. A política corporativa adoita permitir os portos web de saída e descartar o resto, así que un servizo no 8080 ou no 1883 é inalcanzable mentres que o 443 funciona ben. O navegador non demostra nada aquí: usa o 443 por definición.

Publica o mesmo servizo detrás do 443 e chégao por nome antes de pedir unha excepción. Se a excepción é realmente necesaria, limítaa a un rango de orixe e un destino e trátaa como parte da definición do servizo, non como o apaño persoal de alguén.

TCP cru que a ruta reinicia

As conexións TCP cru de longa duración son a capa que falla de forma máis confusa. Unha ruta que permite tráfico web pode igualmente reiniciar ou reescribir TCP saínte pouco habitual, e o cliente informa dun erro de socket que se le como unha caída. Os servizos de mensaxería e de eventos adoitan incluír un transporte WebSocket xusto para este tipo de rede, e cambiar é unha opción do cliente, non un cambio do túnel.

Cambia o transporte, volve probar e non cambies nada máis na mesma execución. Esa proba dunha soa variable diche se o reinicio veu da ruta ou do servizo.

Conexións que só se pechan con cargas grandes

Unha petición que funciona e logo morre aproximadamente un segundo despois, pero só cando o corpo é grande, apunta a un límite de tamaño nalgún punto intermedio. Un intermediario que conta os bytes das mensaxes pode soltar a conexión a metade da transferencia, e o cliente informa dun peche anómalo en lugar dun tempo de espera.

Trocea a carga na capa de aplicación. Mantén isto separado do traballo de MTU: baixar o tamaño de paquete do túnel axuda cando as sesións TCP normais se atascan nun reconto de bytes constante, e non fai nada por unha mensaxe que un intermediario considera demasiado grande.

Como distinguir as catro nunha soa pasada

Tres observacións resolven a maioría dos casos. O fallo ocorre de inmediato ou só cun corpo grande? A mesma petición funciona co proxy desactivado? O resultado cambia cando cambias de porto ou de transporte? Escribe as respostas antes do seguinte cambio, porque unha VPN corporativa máis un proxy herdado máis un valor por defecto da aplicación danche tres causas plausibles á vez.

Mantén unha variable por proba e anota o host de destino que usaches. Sen esa liña base, a seguinte persoa repite os catro pasos desde o principio.