CONNECT-timeouts i proxyen efter vellykket TCP-forbindelse
Find den timeout, der er aktiv under CONNECT, i stedet for at antage, at en fuldført TCP-forbindelse også har afsluttet tunnelopsætningen.
En TCP-forbindelsestimeout har gjort sit arbejde, når klienten har forbundet til proxyen. Den næste ventetid—at modtage et fuldstændigt CONNECT-svar—kan styres af en anden timer.
Proxyen er måske stadig ved at forbinde opstrøms, udveksle godkendelsesmeddelelser eller vente på en anden tjeneste. Webstedets almindelige svar er ikke begyndt endnu.
| Seneste fuldførte trin | Hvad ventes der stadig på? |
|---|---|
| TCP forbundet til proxyen | Proxyens håndtryk, herunder accept af CONNECT |
| CONNECT accepteret | TLS til destinationen, når målet bruger det |
| Anmodning til destinationen sendt | Destinationens svar |
Find den timer, der er aktiv, mens connectoren læser og skriver dette håndtryk. En egenskab kaldet “response timeout” træder muligvis først i kraft, når ruten er etableret. Med HttpClient 5 skal du skelne mellem ConnectionConfig og dets socket-timeout, TLS-håndtrykskonfiguration og respons-timeouten på anmodningsniveau. Anvend den relevante forbindelseskonfiguration via den manager, som den faktiske klient bruger. Gamle generationer af Apache HttpClient bruger andre API'er, så et ældre uddrag er ikke et pålideligt kort over disse ansvarsområder.
Behold en endelig CONNECT-afvisning som et svar fra proxyen. Et vellykket svar efterfulgt af en TLS-stop er en anden fejlfase. “TCP forbundet; intet fuldstændigt CONNECT-svar før opsætningsfristen” beskriver problemet mere præcist end en generisk proxy-timeout.
En samlet frist kan begrænse den kaldendes ventetid sammen med disse faselofter. Når den udløber, skal du annullere eller lukke operationen via den livscyklus, klienten understøtter, før et nyt forsøg bruger forbindelseskapacitet.