Tiempos de espera de CONNECT del proxy tras una conexión TCP correcta
Localice el tiempo de espera activo durante CONNECT en lugar de suponer que una conexión TCP completada también ha terminado la configuración del túnel.
El tiempo de espera de conexión TCP ha cumplido su función en cuanto el cliente se conecta al proxy. La siguiente espera—recibir una respuesta CONNECT completa—puede regirse por un temporizador distinto.
Es posible que el proxy siga conectándose aguas arriba, intercambiando mensajes de autenticación o esperando otro servicio. La respuesta habitual del sitio web aún no ha comenzado.
| Último paso completado | ¿Qué sigue esperando? |
|---|---|
| TCP conectado al proxy | El handshake del proxy, incluida la aceptación de CONNECT |
| CONNECT aceptado | TLS de destino, cuando el objetivo lo utiliza |
| Solicitud de destino enviada | La respuesta del destino |
Busque el temporizador activo mientras el conector lee y escribe ese handshake. Una propiedad llamada “response timeout” puede entrar en vigor solo después de establecerse la ruta. Con HttpClient 5, distinga ConnectionConfig y su tiempo de espera de socket, la configuración del handshake TLS y el tiempo de espera de respuesta a nivel de solicitud. Aplique la configuración de conexión correspondiente mediante el gestor que utiliza el cliente real. Las generaciones antiguas de Apache HttpClient usan API distintas, así que un fragmento antiguo no es un mapa fiable de estas responsabilidades.
Mantenga el rechazo final de CONNECT como respuesta del proxy. Una respuesta correcta seguida de un bloqueo de TLS es otra etapa de fallo. «TCP conectado; ninguna respuesta CONNECT completa antes del plazo de configuración» describe el problema con más precisión que un tiempo de espera genérico del proxy.
Un plazo total puede acotar la espera del llamador junto con estos límites de fase. Cuando expire, cancele o cierre la operación mediante el ciclo de vida que admita el cliente antes de que otro intento consuma capacidad de conexión.