Cererile aplicației eșuează în spatele unui VPN corporate, dar browserul funcționează

Deschizi portalul intern într-un browser și se încarcă. Rulezi aplicația care apelează același host și eșuează, cu un mesaj care nu numește niciun nivel. Tunelul transportă browserul, așa că tunelul nu este primul suspect. Între cererea ta și serviciu stau patru lucruri, iar fiecare lasă o urmă diferită. Aceasta este ordinea pe care o urmez, pornind de la cererea pe care aplicația o trimite efectiv, nu de la pagina de setări a clientului VPN.

Uită-te la cererea pe care aplicația o trimite efectiv

Înainte să atingi configurația, lasă aplicația să spună ce face. O captură a unei singure cereri cu proxy-ul dezactivat explicit și un test simplu de port îți dau două linii de bază cu care se compară pașii următori. Dacă cererea reușește cu proxy-ul oprit, ai terminat deja trei din cele patru niveluri.

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

Rulează ultimele două către aceeași destinație și urmărește unde se despart. Un browser care funcționează plus un curl care funcționează plus o aplicație care nu funcționează restrâng problema la ceva ce aplicația adaugă: un proxy, un transport sau o dimensiune de mesaj.

Aplicația a moștenit un proxy pe care nimeni nu l-a configurat

Majoritatea stivelor HTTP citesc configurația proxy din sistemul de operare implicit. Un client VPN corporate instalează adesea unul ca parte a profilului său de acces, așa că cererile ies printr-un proxy pe care dezvoltatorul nu l-a menționat niciodată în cod. În .NET handler-ul implicit preia setările din IE/WinHTTP; Java citește -Dhttp.proxyHost; Node nu are suport proxy încorporat până când o bibliotecă îl adaugă. Eșecul este rareori un refuz curat, de aceea oamenii încep să se uite la server.

Testul costă o cerere: dezactivează proxy-ul explicit pe un singur handler și compară.

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

Dacă asta funcționează, corectarea aparține configurației aplicației, nu tunelului. Repetă auditul pentru fiecare runtime din proiect, pentru că fiecare citește o altă sursă și poate doar unul este stricat.

Portul ales nu este portul pe care politica îl permite

Un host rutat nu este un serviciu permis. Politica corporate permite de obicei porturile web de ieșire și le aruncă pe restul, așa că un serviciu pe 8080 sau 1883 este inaccesibil în timp ce 443 funcționează bine. Browserul nu demonstrează nimic aici: folosește 443 prin definiție.

Publică același serviciu în spatele portului 443 și ajunge la el după nume înainte de a cere o excepție. Dacă excepția este cu adevărat necesară, limiteaz-o la un interval de sursă și o destinație și trateaz-o ca parte a definiției serviciului, nu ca o soluție personală a cuiva.

TCP brut pe care calea îl resetează

Conexiunile TCP brute de lungă durată sunt nivelul care eșuează în cel mai derutant mod. O cale care permite trafic web poate totuși reseta sau rescrie TCP de ieșire neobișnuit, iar clientul raportează o eroare de socket care se citește ca o pană. Serviciile de mesagerie și de evenimente livrează de obicei un transport WebSocket exact pentru astfel de rețele, iar comutarea este o opțiune a clientului, nu o modificare a tunelului.

Schimbă transportul, retestează și nu modifica nimic altceva în aceeași rulare. Acel test cu o singură variabilă îți spune dacă resetarea a venit de pe cale sau din serviciu.

Conexiuni care se închid doar la încărcături mari

O cerere care reușește și apoi moare cam o secundă mai târziu, dar numai când corpul este mare, indică o limită de dimensiune undeva la mijloc. Un intermediar care numără octeții mesajelor poate scăpa conexiunea la mijlocul transferului, iar clientul raportează o închidere anormală în loc de un timeout.

Împarte încărcătura în bucăți la nivelul aplicației. Ține asta separat de munca la MTU: scăderea dimensiunii pachetului tunelului ajută când sesiunile TCP obișnuite se blochează la un număr constant de octeți și nu face nimic pentru un mesaj pe care un intermediar îl consideră prea mare.

Cum să distingi cele patru într-o singură trecere

Trei observații rezolvă majoritatea cazurilor. Eșecul apare imediat sau doar cu un corp mare? Aceeași cerere reușește cu proxy-ul dezactivat? Rezultatul se schimbă când schimbi portul sau transportul? Scrie răspunsurile înainte de următoarea modificare, pentru că un VPN corporate plus un proxy moștenit plus o valoare implicită a aplicației îți dau trei cauze plauzibile deodată.

Păstrează o variabilă pe test și notează hostul de destinație pe care l-ai folosit. Fără acea linie de bază, următoarea persoană repetă toți cei patru pași de la început.