Errores de estado del proxy: diagnóstico del salto fallido de la solicitud

Traza la ruta antes de interpretar el error: cliente, proxy de reenvío configurado, cualquier puerta de enlace de destino y aplicación de origen. Es posible que no controles ni puedas observar a todos los intermediarios. Marca los componentes que puedas inspeccionar y la información disponible de cada uno.

Empieza por preguntarte si existe una respuesta HTTP. Un error en la consulta DNS, una conexión TCP rechazada o un fallo en el protocolo de enlace TLS pueden impedir que la solicitud llegue a la fase en la que se devuelve un estado HTTP. Una biblioteca de cliente puede etiquetar la excepción resultante como un error de proxy sin haber recibido en absoluto una respuesta 4xx o 5xx.

Mantén estas categorías de resultados separadas en el colector. Sustituir cada fallo por proxy_failed elimina los detalles necesarios para solucionarlo. Un informe a nivel de origen debería distinguir entre las páginas a las que se intentó acceder y que nunca se conectaron y aquellas que devolvieron un rechazo o un error de análisis.

Por poner un ejemplo concreto, supongamos que todos los destinos fallan antes de que se abra la conexión del proxy. Eso sugiere investigar primero el punto final configurado o la ruta de red local. Si un destino de diagnóstico permitido funciona con la misma configuración, pero una fuente falla más tarde, las pruebas apuntan a un problema más concreto. Ninguna de estas observaciones por sí sola demuestra la causa exacta.

Cambia una variable cada vez. Cambiar simultáneamente el proxy, el cliente, la región, los encabezados y la sesión puede dar resultado, pero sin aclarar el fallo. Una comparación reproducible es más útil que una respuesta afortunada que no se puede explicar.

La especificación semántica de HTTP define los significados estándar de las respuestas. En concreto, una pasarela que devuelve un 502 ha recibido una respuesta no válida de un servidor ascendente, mientras que un 504 indica que no se ha recibido una respuesta ascendente a tiempo. Esas definiciones identifican una categoría, no el fallo subyacente de la red o de la aplicación.

No conviertas la tabla en un mapa automático de culpas. Un 403 no es prueba de bloqueo de IP, y un 429 no es necesariamente un límite aplicado a una dirección IP. Un destino puede aplicar límites por cuenta, credenciales, recursos u otra política. La referencia de MDN sobre el código 429 explica que el mecanismo de recuento no viene definido únicamente por el estado.

En el caso de un 503 o un 504, aumentar el tiempo de espera del cliente puede que no cambie nada. Es posible que el intermediario que responde ya haya aplicado su propio plazo. Registra el tiempo transcurrido junto con la respuesta y, a continuación, compáralo con los límites documentados del componente en cuestión. Una espera más prolongada en la capa equivocada puede limitarse a mantener a los trabajadores ocupados durante más tiempo.

Los códigos específicos de cada proveedor necesitan su propio espacio de nombres. Si un servicio devuelve un estado personalizado o un error JSON, como una etiqueta de enrutamiento interna, consulta la documentación actual de dicho proveedor. No presentes un número propio como si tuviera un significado HTTP universal ni des por sentado que otro proveedor lo utiliza de la misma forma.

Por último, conserva la categoría de respuesta en el informe de ejecución de tu conjunto de datos. Una página rechazada por una política no debe convertirse en un producto ausente cualquiera. Los consumidores deben distinguir entre una observación de la fuente y la imposibilidad de observar dicha fuente.

Un código 407 es una razón de peso para inspeccionar el paso de autenticación del proxy en lugar del inicio de sesión en el sitio web. Una respuesta válida debe incluir un Proxy-Authenticate desafío, y el cliente debe proporcionar las credenciales del proxy a través del mecanismo adecuado. La documentación de MDN sobre el código 407 describe ese intercambio.

Comprueba el nombre de host del proxy, el puerto, el método de autenticación, el estado de la cuenta y cualquier requisito documentado de la lista de permitidos. Confirma que el proceso en ejecución haya recibido la configuración prevista. Un shell de desarrollador puede tener variables de entorno diferentes a las de un trabajador programado o un contenedor, por lo que el éxito en un portátil no valida la configuración de la implementación.

Mantén separadas las credenciales de origen y de proxy. Un encabezado de origen Authorization no sustituye a la autenticación del proxy, y la contraseña del proxy no debe reenviarse a la aplicación de destino. Utiliza la configuración de proxy documentada por tu cliente en lugar de crear tú mismo un encabezado de credenciales genérico.

Evita incluir credenciales directamente en un comando de diagnóstico copiado. El historial del shell, los listados de procesos, la salida de CI y los sistemas de tickets pueden conservarlas. Utiliza el mecanismo de secretos aprobado para tu entorno y oculta los valores en cualquier rastro de solicitud que compartas con otra persona.

En el caso de las sesiones de sitios web, comprueba por separado la página autenticada esperada. Un proxy puede autenticarse correctamente mientras que el destino devuelve un formulario de inicio de sesión. Nuestra guía sobre cookies HTTP explica por qué la retención de cookies y la validez de la sesión del lado del servidor son aspectos distintos.

Tras corregir la configuración, prueba una pequeña solicitud autorizada antes de liberar toda la cola. Un bucle de reintentos ilimitado con credenciales incorrectas puede ocultar el error original y generar una carga innecesaria. Un estado de fallo útil detiene el trabajo dependiente e identifica al responsable de la configuración que puede resolverlo.

Cuando se utiliza un proxy HTTP para tunelizar una conexión HTTPS, el cliente suele enviar una solicitud CONNECT en la que se especifica el host y el puerto de destino. La respuesta del proxy corresponde al establecimiento del túnel. El éxito del túnel no garantiza que el posterior protocolo de enlace TLS o la solicitud al destino vayan a tener éxito.

Esto crea al menos tres puntos de control útiles: conectarse al proxy, establecer el túnel y completar el intercambio con el destino. Dependiendo de la implementación, también puede haber TLS entre el cliente y el proxy. Registra qué conexión segura está fallando, en lugar de considerar cada error de certificado como un problema del destino.

El manual de curl documenta valores de salida distintos para la respuesta CONNECT (http_connect), la respuesta final (response_code) y los errores de transferencia. Estas distinciones resultan útiles a la hora de comparar una reproducción desde la línea de comandos con un rastreo de la aplicación. Asegúrate de que la versión de curl instalada coincida con las opciones que utilizas.

Un informe de diagnóstico que indique «HTTP 200» puede ser engañoso si ese número procede únicamente de CONNECT. Confirma que la solicitud al destino se haya completado y que su respuesta contenga la representación esperada. Del mismo modo, un valor de respuesta similar a cero o ausente en las herramientas no es un código de estado HTTP real procedente de la fuente.

Mantén habilitada la verificación de certificados. Si la verificación falla, comprueba el nombre de host configurado, el almacén de confianza, la hora del sistema y la configuración de interceptación autorizada, según corresponda. Deshabilitar la verificación puede convertir un fallo de confianza evidente en una conexión aparentemente correcta con un punto final no fiable.

Utiliza el cliente más sencillo que reproduzca el problema. Nuestra comparación de clientes HTTP en Python ayuda a identificar diferencias en la gestión de sesiones y conexiones. Registra el esquema de proxy y el comportamiento de resolución DNS como datos de configuración; no des por sentado que dos bibliotecas interpretan de forma idéntica la misma cadena abreviada.

El Proxy-Status campo de respuesta añade información de diagnóstico sobre el manejo del intermediario. El RFC 9209 define parámetros como error, received-status, y details, junto con tipos de error que incluyen fallos de DNS, de conexión y de TLS. Se aplica a los proxies de reenvío y a las puertas de enlace, no solo al proxy que hayas configurado localmente.

Una respuesta ilustrativa podría tener este aspecto:

HTTP/1.1 504 Gateway Timeout
Proxy-Status: edge.example; error=connection_timeout

En este caso, el intermediario mencionado informa de un tiempo de espera de conexión agotado. Esto es más específico que el simple código 504. Varias entradas pueden describir una cadena, pero las implementaciones deciden cuándo añadir el campo, por lo que su ausencia no implica que no haya participado ningún intermediario.

Considera el campo como una pista, no como una prueba irrefutable. La información de diagnóstico puede omitirse o transformarse a lo largo de la ruta, y el texto arbitrario de una respuesta remota no debe convertirse en una instrucción de control fiable. Valida la sintaxis utilizando un analizador de campos estructurados adecuado si tu aplicación la utiliza mediante programación.

Mantén el diagnóstico completo disponible solo cuando su contenido sea apropiado. Un details valor o un identificador de siguiente salto pueden revelar información de la infraestructura que no debe figurar en una página de error pública. Tu mensaje externo puede resumir la categoría del fallo, mientras que un registro de incidente restringido conserva los detalles técnicos autorizados.

Relaciona esa evidencia con un identificador de ejecución e intento. Un registro de proxy de un intento diferente puede mostrar un siguiente salto o un resultado distinto. Sin correlación, los ingenieros pueden perder tiempo explicando dos solicitudes no relacionadas como si fueran el mismo evento.

Cuando no se disponga de un diagnóstico estructurado, indica que la atribución está sin resolver. «Respuesta de la puerta de enlace recibida; componente de origen no confirmado» resulta más útil que afirmar que el proxy de reenvío no funciona porque la solicitud pasó casualmente por uno de ellos.

Elige un destino aprobado y una solicitud fallida representativa. Mantén fijos el método, la URL, los encabezados relevantes, la política de tiempo de espera y el contexto de la sesión. Registra las versiones del cliente y de las dependencias. Evita reproducir solicitudes que alteren el estado, a menos que la operación cuente con un mecanismo de reintento seguro documentado.

Compara la ruta configurada con otra ruta de diagnóstico permitida solo cuando tu entorno lo permita. No eludas un proxy corporativo obligatorio para comprobar si una solicitud funciona directamente. Si el acceso directo está prohibido, utiliza puntos finales de estado aprobados o solicita al propietario de la red una prueba controlada.

La referencia de errores de libcurl distingue entre fallos como la resolución del proxy, la resolución del host, la conexión y la verificación del certificado. Utiliza las categorías de excepciones equivalentes en tu propio cliente. Mantén estos errores de transporte separados de los códigos de estado de respuesta HTTP en los registros y las métricas.

Recopila un registro conciso y censurado. El siguiente ejemplo sintético es un esquema de diagnóstico propio de la aplicación, no un formato de respuesta exigido por un proveedor de proxy:

{
  "run_id": "catalog-check-17",
  "attempt": 1,
  "destination_host": "catalog.example",
  "stage": "target_response",
  "connect_status": 200,
  "http_status": 504,
  "elapsed_ms": 12040,
  "diagnostic_category": "upstream_timeout",
  "response_body_saved": false,
  "credentials_redacted": true
}

La duración numérica es ilustrativa, no una recomendación de tiempo de espera ni un valor de referencia. En producción, rellena los campos a partir de los eventos observados y deja los valores desconocidos como están. Nunca inventes un estado CONNECT simplemente porque el cliente estuviera configurado para utilizar un proxy.

Una vez que consigas una reproducción controlada, cambia una variable sospechosa. Si el cambio resuelve el fallo, repite una comprobación delimitada y documenta la diferencia. Un único éxito tras una larga serie de fallos puede ser una intermitencia habitual, más que una prueba de que se ha solucionado el problema.

Los reintentos son útiles cuando otro intento tiene una probabilidad razonable de éxito y repetir la operación es aceptable. No son una solución general para credenciales rechazadas, una solicitud mal formada o una restricción de acceso documentada.

Cuando esté presente y sea aplicable, respeta Retry-After. Su valor puede ser un retraso en segundos o una fecha HTTP, tal y como se documenta en la referencia de Retry-After. Combina esa instrucción con un número finito de intentos, un plazo global para el trabajo y una política para reprogramar las tareas que no puedan completarse dentro de la ejecución actual.

Evita los reintentos acumulados. Si la biblioteca HTTP, el servicio proxy y el ejecutor de tareas realizan reintentos de forma independiente, una sola solicitud lógica puede generar más intentos de los que la aplicación espera. Identifica qué capa es responsable de las decisiones de reintento y expón el recuento real de intentos siempre que sea posible.

Utiliza reintentos retardados con fluctuación (jitter) para fallos transitorios cuando no se aplique ninguna instrucción más específica. Limita la concurrencia por fuente y supervisa la carga agregada de todos los trabajadores. Un retraso local en un proceso no controla la tasa generada por toda la flota.

Pausa o reduce el tráfico cuando los fallos persistan. Mantén una condición de recuperación para que el trabajo no permanezca suspendido indefinidamente, pero haz que la comprobación sea limitada y adecuada a la fuente. Los fallos de autenticación y de políticas suelen requerir una revisión de la configuración o del acceso, en lugar de una rotación automática de los puntos finales.

Separa la recopilación de reintentos de la entrega de reintentos. Si los registros ya se aceptaron localmente y solo falló la exportación, volver a recuperar las páginas crea una nueva observación y puede alterar los valores. La guía de scraping web automatizado explica esa distinción en el ciclo de vida más amplio de la tarea.

Verifica algo más que la desaparición del código de error. Confirma el tipo de página esperado, los campos obligatorios, el contexto de la fuente y el recuento de registros aceptados. Una nueva respuesta 200 que contenga una página de verificación no ha restablecido el flujo de trabajo de recopilación.

Revisa las muestras fallidas y las exitosas tras el cambio. Comprueba si los reintentos han duplicado registros o si los fallos anteriores han dejado un hueco en el conjunto de origen. Una reparación puede evitar futuros errores, aunque siga siendo necesario un relleno posterior independiente o una notificación al consumidor para las ejecuciones afectadas.

Para la escalación, incluye la ventana de observación UTC, la versión del cliente, el identificador del punto final del proxy censurado, el host de destino, la etapa en la que se produjo el fallo, el estado o la categoría de excepción, el ID de la solicitud y el resumen de reproducibilidad. Indica qué cambios de configuración se han probado y qué rutas se han autorizado para la comparación.

No adjuntes archivos «cookie jars» sin procesar, URL que contengan credenciales, encabezados de autorización ni capturas de tráfico sin restricciones. Si un proveedor solicita pruebas adicionales, comparte lo mínimo necesario a través de un canal autorizado. Conserva el registro original con la información ocultada para que una investigación posterior pueda distinguir los hechos de las suposiciones añadidas durante el incidente.

Concluye con una norma operativa: ¿qué detectará este fallo la próxima vez, quién es el responsable y qué parte del proceso debe detenerse? Esto convierte un diagnóstico puntual en una respuesta repetible sin dar por sentado que todos los futuros errores de estado del proxy tendrán la misma causa.

• Distinguir entre fallos de transporte, respuestas del túnel, respuestas del destino y fallos del analizador.
• Interpreta los códigos 407, 429, 502 y 504 como categorías que orientan la investigación, no como causas raíz definitivas.
• Mantén separadas las credenciales del proxy y del origen, y conserva la verificación TLS.
• Utiliza diagnósticos estructurados y la correlación de solicitudes cuando sea posible.
• Limitar los reintentos, verificar los datos devueltos y conservar las pruebas de fuentes perdidas.

Sí. Las condiciones temporales de la red o del servicio pueden resolverse entre un intento y otro. Eso no demuestra que la configuración anterior fuera correcta en todos los aspectos. Conserva las pruebas originales del fallo y comprueba una muestra representativa tras la recuperación. Si el problema se repite, compara los patrones por destino, etapa y hora, en lugar de tratar cada incidente como si fuera independiente.

Mantén los cuerpos de diagnóstico separados de los datos aceptados y consérvalos solo cuando la política lo permita. Una página de error puede contener detalles de la infraestructura, identificadores o información repetida de la solicitud. Almacena un modelo censurado o un registro de fallo clasificado cuando eso proporcione pruebas suficientes, y asegúrate de que los consumidores posteriores no puedan confundirlo con una observación válida de la fuente.

No necesariamente. Un cambio de región puede afectar al idioma, la moneda, los productos disponibles o las condiciones de acceso, incluso cuando se soluciona el problema de conectividad. Registra ese cambio como contexto de recopilación y valida los campos resultantes. No combines silenciosamente observaciones de diferentes regiones en un conjunto de datos que prometa una visión coherente del mercado.

La respuesta útil más rápida ante los errores de estado del proxy es una pregunta precisa: ¿en qué etapa se produjo el fallo y qué pruebas lo identifican? Determina si se trata de una excepción de transporte, una respuesta de túnel o una respuesta HTTP de los consumidores posteriores antes de modificar el sistema. Conserva la observación original, comprueba una hipótesis cada vez y verifica los datos tras la aparente reparación.

Incorpora esas distinciones en el contrato de fallos del recopilador. Un registro de ejecuciones claro, un responsable de reintentos delimitado y un informe de escalación redactado reducen las investigaciones repetidas. Además, preservan la diferencia entre una fuente que no devolvió datos coincidentes y una fuente que tu tarea no pudo observar.

Si el mantenimiento de la capa de recuperación está acaparando la atención del equipo, evalúa la API Scraper de WebScrapingAPI para ese componente, conservando al mismo tiempo tus propias comprobaciones de aceptación y el contexto de los incidentes. Trasladar la recuperación no elimina la necesidad de comprender los fallos. Debería proporcionarte un límite operativo más claro, no otro lugar donde los datos que faltan se vuelvan invisibles.