Pedidos da aplicação falham atrás de uma VPN corporativa, mas o navegador funciona

Abre o portal interno num navegador e ele carrega. Executas a aplicação que chama o mesmo host e ela falha, com uma mensagem que não nomeia camada nenhuma. O túnel transporta o navegador, portanto o túnel não é o primeiro suspeito. Há quatro coisas entre o teu pedido e o serviço, e cada uma deixa uma assinatura diferente. Esta é a ordem que sigo, começando pelo pedido que a aplicação realmente envia, e não pela página de definições do cliente VPN.

Olha para o pedido que a aplicação realmente envia

Antes de mexer na configuração, deixa a aplicação dizer-te o que faz. Uma captura de um único pedido com o proxy explicitamente desativado e um teste de porta simples dão-te duas linhas de base com que os passos seguintes são comparados. Se o pedido funcionar com o proxy desligado, já resolveste três das quatro camadas.

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 os dois últimos contra o mesmo destino e repara onde divergem. Um navegador que funciona mais um curl que funciona mais uma aplicação que não funciona reduzem o problema a algo que a aplicação acrescenta: um proxy, um transporte ou um tamanho de mensagem.

A aplicação herdou um proxy que ninguém configurou

A maioria das pilhas HTTP lê a configuração do proxy do sistema operativo por predefinição. Um cliente VPN corporativo instala frequentemente um como parte do seu perfil de acesso, por isso os pedidos saem por um proxy que o programador nunca mencionou no código. Em .NET o manipulador predefinido lê as definições do IE/WinHTTP; Java lê -Dhttp.proxyHost; o Node não tem suporte de proxy incorporado até uma biblioteca o acrescentar. A falha raramente é uma recusa limpa, e é por isso que as pessoas começam a olhar para o servidor.

O teste custa um pedido: desativa o proxy explicitamente num único manipulador e compara.

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

Se isso funcionar, a correção pertence à configuração da aplicação, não ao túnel. Repete a auditoria para cada runtime do projeto, porque cada um lê uma fonte diferente e talvez só um esteja avariado.

A porta que escolheste não é a porta que a política permite

Um host encaminhado não é um serviço permitido. A política corporativa costuma permitir as portas web de saída e descartar o resto, por isso um serviço na 8080 ou na 1883 é inalcançável enquanto a 443 funciona bem. O navegador não prova nada aqui: usa a 443 por definição.

Publica o mesmo serviço atrás da 443 e chega-lhe pelo nome antes de pedir uma exceção. Se a exceção for realmente necessária, limita-a a um intervalo de origem e a um destino e trata-a como parte da definição do serviço, não como o desenrascanço pessoal de alguém.

TCP bruto que o caminho reinicia

As ligações TCP brutas de longa duração são a camada que falha de forma mais confusa. Um caminho que permite tráfego web pode ainda reiniciar ou reescrever TCP de saída pouco habitual, e o cliente reporta um erro de socket que se lê como uma queda. Os serviços de mensagens e de eventos fornecem normalmente um transporte WebSocket precisamente para este tipo de rede, e a troca é uma opção do cliente, não uma alteração do túnel.

Troca o transporte, volta a testar e não alteres mais nada na mesma execução. Esse teste de uma única variável diz-te se o reinício veio do caminho ou do serviço.

Ligações que só fecham com payloads grandes

Um pedido que funciona e depois morre cerca de um segundo mais tarde, mas só quando o corpo é grande, aponta para um limite de tamanho em algum ponto do meio. Um intermediário que conta os bytes das mensagens pode deixar cair a ligação a meio da transferência, e o cliente reporta um fecho anómalo em vez de um tempo limite.

Divide o payload na camada de aplicação. Mantém isso separado do trabalho de MTU: baixar o tamanho do pacote do túnel ajuda quando as sessões TCP normais param num número de bytes constante, e não faz nada por uma mensagem que um intermediário considera demasiado grande.

Como distinguir as quatro numa só passagem

Três observações resolvem a maioria dos casos. A falha acontece de imediato ou só com um corpo grande? O mesmo pedido funciona com o proxy desativado? O resultado muda quando trocas de porta ou de transporte? Escreve as respostas antes da alteração seguinte, porque uma VPN corporativa mais um proxy herdado mais um valor predefinido da aplicação dão-te três causas plausíveis ao mesmo tempo.

Mantém uma variável por teste e anota o host de destino que usaste. Sem essa linha de base, a pessoa seguinte repete os quatro passos desde o início.