Un 407 indica que se requiere autenticación en el proxy. Un 429 indica un límite de peticiones, pero la respuesta por sí sola no te dice qué peticiones comparten ese límite. Un 502 o un 504 indican un problema de respuesta o de tiempo de espera en el upstream. Identifica primero de dónde salió la respuesta y después comprueba la autenticación, los límites o la conectividad según corresponda.
Primero, identifica la capa que responde
Una petición HTTPS a través de un proxy HTTP tiene normalmente dos intercambios: el proxy responde a una petición CONNECT y después el cliente se comunica con el destino a través del túnel. Un proxy HTTPS añade una conexión TLS al proxy antes del CONNECT. En un túnel ordinario sin interceptación TLS, una respuesta recibida después del TLS con el destino proviene de la infraestructura del destino, que puede incluir un CDN o un proxy inverso.
El siguiente ejemplo imprime el estado del CONNECT por separado del estado de la respuesta HTTP. Requiere curl 8.3 o posterior y usa autenticación Basic en el proxy. Asigna a PROXY_URL el gateway HTTP(S) sin credenciales de tu proveedor, y haz que tu gestor de secretos rellene PROXY_USERNAME y PROXY_PASSWORD en el entorno. Usa el método de autenticación que documente tu proveedor.
Guárdalo como proxy-status.sh y ejecuta sh proxy-status.sh sin trazado del shell. Hace una petición GET, descarta el cuerpo y conserva el código de salida de curl. curl importa las credenciales por sí mismo, de modo que el shell no las expande en argumentos del comando.
: "${PROXY_URL:?Set a credential-free HTTP(S) proxy URL}"
case "$PROXY_URL" in
http://*|https://*) ;;
*) printf '%s\n' 'PROXY_URL must use http:// or https://' >&2; exit 2 ;;
esac
case "$PROXY_URL" in
*'@'*|*'?'*|*'#'*)
printf '%s\n' 'Keep credentials, queries and fragments out of PROXY_URL' >&2
exit 2 ;;
esac
curl --disable --silent --fail --http1.1 \
--noproxy '' --proxy "$PROXY_URL" --proxy-basic \
--variable %PROXY_USERNAME --variable %PROXY_PASSWORD \
--expand-proxy-user '{{PROXY_USERNAME}}:{{PROXY_PASSWORD}}' \
--connect-timeout 5 --max-time 15 --retry 0 \
--output /dev/null \
--write-out 'exit=%{exitcode} http=%{http_code} connect=%{http_connect} seconds=%{time_total}\n' \
'https://example.com/'--disable va primero para ignorar los ajustes de curlrc, y --noproxy '' evita que una exclusión heredada se salte el gateway seleccionado. El presupuesto de cinco segundos para la conexión y de quince segundos en total son puntos de partida para este pequeño diagnóstico. El comando no sigue redirecciones ni reintenta, e imprime resultados numéricos sin una traza detallada. Consulta el manual de curl para estas opciones.
La guía de proxy con curl cubre la forma simple con -x, las variables http_proxy y https_proxy y SOCKS5 con socks5h, que deciden adónde va una petición antes de que aparezca cualquiera de estos códigos de estado.
Lee los campos en conjunto. connect=407 significa que el proxy exigió autenticación durante el CONNECT. connect=200 http=429 significa que el túnel fue aceptado y que después llegó un HTTP 429. http=000 significa que no se registró ningún estado de respuesta HTTP para la transferencia; inspecciona el estado del CONNECT y el código de salida de curl. Un CONNECT exitoso no establece que la configuración de TLS o la transferencia del cuerpo se completaran.
Para un destino HTTP plano, normalmente no hay túnel. El proxy reenvía la petición, así que el estado devuelto puede provenir del proxy o del destino. Las cabeceras del proveedor y las páginas de error con su marca pueden dar pistas, pero la apariencia por sí sola no establece quién envió la respuesta. Usa los errores documentados del proveedor o los diagnósticos de petición cuando la atribución siga siendo incierta.
407 Proxy Authentication Required
Un 407 debe incluir un desafío Proxy-Authenticate. El cliente puede reintentar con Proxy-Authorization; la cabecera Authorization del destino no proporciona autenticación en el proxy. Estos requisitos provienen de la RFC 9110, sección 15.5.8.
Empieza con estas comprobaciones:
- Confirma que el gateway, el usuario y la contraseña coinciden con la configuración activa del proveedor.
- Comprueba que las credenciales están en el ajuste de autenticación del proxy, y no en el de autenticación del destino.
- Si el proveedor codifica la selección de país o de sesión en el nombre de usuario, comprueba su formato documentado. Cómo se reporta un objetivo malformado depende del proveedor.
- Si la librería requiere una URL de proxy que contenga credenciales, codifica el usuario y la contraseña por separado para que los caracteres reservados no puedan alterar la estructura de la URL.
La guía para corregir el 407 cubre el diagnóstico de autenticación. La guía de Python Requests muestra la configuración explícita del proxy y la codificación de credenciales. Sigue el formato documentado de la librería antes de añadir reintentos.
429 Too Many Requests
Un 429 informa de un límite de peticiones. La RFC 6585, sección 4 deja deliberadamente la identificación del usuario y el recuento de peticiones al servicio que responde. El límite podría aplicarse a una cuenta, una credencial, una sesión, una dirección, un recurso o un servicio más amplio.
El remitente te dice qué política investigar. Un proxy puede estar aplicando un límite del plan o de concurrencia; el destino puede estar aplicando su propio límite de peticiones. Ninguno de los dos casos establece el alcance solo a partir del estado. Lee los detalles de la respuesta y el límite documentado, y respeta Retry-After cuando se proporcione.
Reduce el tráfico en el alcance afectado. Para un límite de cuenta compartido, eso puede significar coordinar a todos los workers que usan esa cuenta. Para un límite ligado a un recurso, puede significar ralentizar las peticiones a ese recurso. Si el alcance es desconocido, reduce la concurrencia mientras investigas. Cambiar de salida no establece que un límite se haya reiniciado.
El backoff también necesita un tope: si la espera requerida supera el plazo restante del trabajo, detente o programa el trabajo para más tarde. Reintentar repetidamente durante la misma ventana de límite añade carga sin resolver el límite.
502 y 504: un fallo o retraso en el upstream
Un 502 Bad Gateway indica una respuesta inválida del upstream. Un 504 Gateway Timeout indica que un gateway no recibió una respuesta del upstream a tiempo. Sus definiciones HTTP no identifican el componente que falló.
En un pool de proxies, investiga la salida, los gateways intermedios y el destino. Usa los diagnósticos del proveedor y una pequeña petición de control autorizada para acotar el fallo. Mantén constantes la configuración del destino y del cliente al comparar gateways, y cambia una sola variable cada vez.
Importan tres decisiones del cliente:
- Si es seguro repetir. Para una petición aprobada y segura de repetir, permite un número pequeño de intentos con backoff dentro de un plazo global. Una respuesta fallida a una escritura no demuestra que la escritura nunca se aplicara. Comprueba el estado de la operación o el mecanismo de idempotencia documentado antes de reenviarla. Consulta la semántica de reintentos de HTTP.
- Cuánto puede esperar el trabajo. Fija los plazos según el presupuesto de latencia del trabajo. Un plazo de cliente más corto limita la espera pero no repara un fallo del upstream. La guía de tiempos de espera explica los presupuestos de conexión, de transferencia y del trabajo completo.
- Qué fallos están aumentando. Registra los 502 y los 504 por separado, por gateway, destino y región, junto a la tasa de éxito de la aplicación. Un cambio limitado a una ruta es motivo para investigar esa ruta, no prueba de que todo el pool esté en mal estado.
Usa una conexión nueva o una salida distinta solo cuando ese cambio encaje con el diagnóstico y los requisitos de sesión. Una salida nueva también puede cambiar el contexto de sesión del usuario, así que no es una estrategia de reintento universal.
Respuestas 403 y HTTP 200 con contenido inutilizable
Un 403 indica una negativa. Puede reflejar la política de acceso de un proxy de reenvío o una negativa de la infraestructura del destino. Comprueba la capa que responde y su motivo documentado antes de cambiar credenciales, cabeceras o direcciones.
Un caso más difícil de detectar es una respuesta HTTP 200 que contiene una página de desafío, una pantalla de inicio de sesión o un shell de aplicación incompleto. El estado registra un resultado HTTP; tu aplicación también debe validar el contenido que necesita. Por ejemplo, una tarea de datos de producto debería comprobar el identificador de producto esperado y los campos requeridos, no solo una palabra que también podría aparecer en una página de error.
El comando de diagnóstico anterior descarta el cuerpo. La guía de Python muestra igualmente la configuración y la comprobación del estado, por lo que un cliente de producción necesita su propia validación del cuerpo específica del destino. Las observaciones sobre Amazon y Google muestran por qué importa esa comprobación adicional.
Elige la siguiente comprobación
Usa esta tabla después de identificar la capa que responde. Son comprobaciones iniciales, no prueba de una causa raíz.
| Resultado observado | Qué investigar | Primera acción |
|---|---|---|
| CONNECT 407 | Autenticación del proxy | Comprueba el desafío, la configuración de credenciales y la cuenta del proveedor. |
| CONNECT 429 o 429 del destino | El límite del servicio que responde | Respeta Retry-After y reduce el tráfico en el alcance documentado. |
| 502 o 504 | Fallo de respuesta o de tiempo en el upstream | Compara los diagnósticos; reintenta solo trabajo seguro de repetir dentro de su presupuesto. |
| CONNECT 403 o 403 del destino | Política de acceso o autorización | Comprueba qué capa rechazó la petición y por qué. |
| HTTP 200 con un cuerpo incompleto o inesperado | Criterios de éxito de la aplicación | Valida el contenido requerido antes de contar un éxito. |
| Sin estado HTTP | Progreso de la conexión, el túnel o TLS | Lee el código de salida de curl y sigue las comprobaciones por etapas de la guía de tiempos de espera. |
Para mediciones repetidas, el método de benchmark explica los registros de transporte, las distribuciones de tiempos y sus límites. Conserva el resultado del contenido y cualquier diagnóstico del proveedor junto a esos registros para que un recuento de estados no se convierta en una explicación sin respaldo.