Appens förfrågningar misslyckas bakom ett företags-VPN, men webbläsaren fungerar

En app kraschar medan webbläsaren laddar sidan. Gå igenom den ärvda proxyn, portpolicyn, återställningar av rå TCP och gränserna för nyttolastens storlek i den ordningen.

Du öppnar den interna portalen i en webbläsare och den laddas. Du kör applikationen som anropar samma värd och den misslyckas, med ett meddelande som inte namnger något lager. Tunneln bär webbläsaren, så tunneln är inte den första misstänkta. Fyra saker står mellan din förfrågan och tjänsten, och var och en lämnar ett annat spår. Det här är ordningen jag följer, med utgångspunkt i förfrågan som appen faktiskt skickar, inte i VPN-klientens inställningssida.

Titta på förfrågan som appen faktiskt skickar

Innan du rör konfigurationen, låt appen berätta vad den gör. En inspelning av en enda förfrågan med proxyn uttryckligen avstängd och ett enkelt porttest ger dig två baslinjer som nästa steg jämförs mot. Om förfrågan lyckas med proxyn av har du redan klarat tre av de fyra lagren.

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

Kör de två sista mot samma destination och se var de skiljer sig. En webbläsare som fungerar plus en curl som fungerar plus en app som inte fungerar snävar in problemet till något appen lägger till: en proxy, en transport eller en meddelandestorlek.

Appen ärvde en proxy som ingen har konfigurerat

De flesta HTTP-stackar läser proxykonfigurationen från operativsystemet som standard. En företags-VPN-klient installerar ofta en som en del av sin åtkomstprofil, så förfrågningar går ut genom en proxy som utvecklaren aldrig nämnde i koden. I .NET hämtar standardhanteraren från IE/WinHTTP-inställningar; Java läser -Dhttp.proxyHost; Node har inget inbyggt proxy-stöd förrän ett bibliotek lägger till det. Felet är sällan en ren avvisning, därför börjar folk titta på servern.

Testet kostar en förfrågan: stäng av proxyn uttryckligen på en hanterare och jämför.

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

Om det lyckas hör rättelsen hemma i appens konfiguration, inte i tunneln. Upprepa granskningen för varje körmiljö i projektet, eftersom var och en läser en annan källa och bara en av dem är kanske trasig.

Porten du valde är inte den port som policyn tillåter

En routad värd är inte en tillåten tjänst. Företagspolicy tillåter oftast utgående webbportar och släpper resten, så en tjänst på 8080 eller 1883 är oåtkomlig medan 443 fungerar fint. Webbläsaren bevisar ingenting här: den använder 443 per definition.

Publicera samma tjänst bakom 443 och nå den vid namn innan du begär ett undantag. Om undantaget verkligen behövs, avgränsa det till ett källområde och en destination och behandla det som en del av tjänstedefinitionen, inte som någons personliga omväg.

Rå TCP som vägen återställer

Långvariga rå TCP-anslutningar är det lager som misslyckas mest förvirrande. En väg som tillåter webbtrafik kan ändå återställa eller skriva om ovanlig utgående TCP, och klienten rapporterar ett socket-fel som läses som ett avbrott. Meddelande- och händelsetjänster levererar oftast en WebSocket-transport just för sådana nät, och bytet är ett klientval, inte en tunneländring.

Byt transport, testa igen och ändra inget annat i samma körning. Det testet med en variabel säger om återställningen kom från vägen eller från tjänsten.

Anslutningar som bara stängs vid stora nyttolaster

En förfrågan som lyckas och sedan dör ungefär en sekund senare, men bara när kroppen är stor, pekar på en storleksgräns någonstans i mitten. En mellanled som räknar meddelandebytes kan tappa anslutningen mitt i överföringen, och klienten rapporterar en onormal stängning i stället för en timeout.

Dela upp nyttolasten i bitar på applikationsnivå. Håll det skilt från MTU-arbete: att sänka paketstorleken i tunneln hjälper när vanliga TCP-sessioner stannar vid ett konstant byteantal, och det gör ingenting för ett meddelande som en mellanled anser vara för stort.

Så skiljer du de fyra i en enda omgång

Tre observationer avgör de flesta fall. Sker felet direkt eller bara med stor kropp? Lyckas samma förfrågan med proxyn avstängd? Ändras resultatet när du byter port eller transport? Skriv ned svaren före nästa ändring, eftersom ett företags-VPN plus en ärvd proxy plus en appstandard ger dig tre troliga orsaker på en gång.

Håll en variabel per test och anteckna den destinationsvärd du använde. Utan den baslinjen upprepar nästa person alla fyra stegen från början.

Relaterade artiklar