Proxy CONNECT Timeouts After TCP Connection Succeeds
Locate the timeout active during CONNECT instead of assuming that a completed TCP connection has also finished tunnel setup.
A TCP connect timeout has done its job once the client connects to the proxy. The next wait—receiving a complete CONNECT reply—may be governed by a different timer.
The proxy may still be connecting upstream, exchanging authentication messages or waiting on another service. The website's ordinary response has not started.
| Last completed step | What is still waiting? |
|---|---|
| TCP connected to the proxy | The proxy handshake, including CONNECT acceptance |
| CONNECT accepted | Destination TLS, when the target uses it |
| Destination request sent | The destination response |
Find the timer active while the connector reads and writes that handshake. A property called “response timeout” may take effect only after route establishment. With HttpClient 5, distinguish ConnectionConfig and its socket timeout, TLS handshake configuration, and the request-level response timeout. Apply the relevant connection configuration through the manager used by the actual client. Old Apache HttpClient generations use different APIs, so an older snippet is not a reliable map of these responsibilities.
Keep a final CONNECT rejection as a proxy reply. A successful reply followed by a TLS stall is another failure stage. “TCP connected; no complete CONNECT response before the setup deadline” describes the problem more precisely than a generic proxy timeout.
An overall deadline can bound the caller's wait alongside these phase limits. When it expires, cancel or close the operation through the client's supported lifecycle before another attempt consumes connection capacity.