CONNECT-timeouts i proxyn efter en lyckad TCP-anslutning
Hitta den timeout som är aktiv under CONNECT i stället för att anta att en slutförd TCP-anslutning också har slutfört tunneluppsättningen.
En TCP-anslutningstimeout har gjort sitt när klienten ansluter till proxyn. Nästa väntan—att ta emot ett fullständigt CONNECT-svar—kan styras av en annan timer.
Proxyn kanske fortfarande ansluter uppströms, utbyter autentiseringsmeddelanden eller väntar på en annan tjänst. Webbplatsens vanliga svar har inte börjat ännu.
| Senast slutförda steg | Vad väntas det fortfarande på? |
|---|---|
| TCP ansluten till proxyn | Proxyns handskakning, inklusive godkännande av CONNECT |
| CONNECT godkänd | TLS till målet, när målet använder det |
| Begäran till målet skickad | Målets svar |
Hitta timern som är aktiv medan anslutningen läser och skriver den handskakningen. En egenskap som kallas ”response timeout” kanske bara träder i kraft efter att vägen upprättats. Med HttpClient 5 ska du skilja mellan ConnectionConfig och dess socket-timeout, TLS-handskakningskonfigurationen och svarstimeouten på begärandenivå. Tillämpa den relevanta anslutningskonfigurationen via den manager som den faktiska klienten använder. Äldre generationer av Apache HttpClient använder andra API:er, så ett äldre utdrag är inte en tillförlitlig karta över dessa ansvarsområden.
Behåll ett slutgiltigt CONNECT-avslag som ett svar från proxyn. Ett lyckat svar följt av ett TLS-stopp är ett annat felstadium. ”TCP ansluten; inget fullständigt CONNECT-svar före uppsättningsdeadline” beskriver problemet mer exakt än en generisk proxy-timeout.
En övergripande deadline kan begränsa anroparens väntan vid sidan av dessa fasgränser. När den löper ut ska du avbryta eller stänga operationen via den livscykel som klienten stöder innan ett nytt försök förbrukar anslutningskapacitet.