Los problemas de proxy parecen variados cuando estás en medio de uno, pero en realidad son bastante repetitivos. Casi todo lo que puede ir mal encaja en nueve patrones, y en la mayoría de los casos la propia respuesta te indica cuál de ellos estás viendo. Este es el índice: localiza tu síntoma, obtén la causa probable y la solución inmediata, y sigue el enlace cuando necesites la versión más larga.
La tabla rápida
| Síntoma | Normalmente significa | Primera cosa que hacer | ¿Reintentar? |
|---|---|---|---|
407 Proxy Authentication Required | Credenciales incorrectas, o un flag mal formado en el nombre de usuario | Probar el nombre de usuario simple sin flags | Nunca |
502 Bad Gateway | Ninguna dirección coincidió con tu filtro en ese momento | Ampliar el filtro | Solo después de ampliarlo |
509 Bandwidth Limit Exceeded | Asignación del plan agotada, exceso desactivado | Comprobar el saldo y el plan | No |
| Conexión rechazada o bloqueada | Nunca llegaste al gateway | nc -vz p.shifter.io 443 | No, soluciona antes la conectividad |
| Tiempos de espera agotados | Lentitud del destino, filtro demasiado restrictivo, o tu propia concurrencia | Separar el tiempo de conexión del tiempo de lectura | Sí, con retroceso progresivo |
403 o una página de desafío | El destino rechazó la identidad, no el proxy | Retirar la sesión, comprobar cabeceras | No en la misma sesión |
429 Too Many Requests | El destino está limitando tu tasa de solicitudes | Respetar Retry-After y después reducir el ritmo | Sí, tras esperar |
200 con contenido incorrecto o vacío | Un bloqueo silencioso, o el locale equivocado | Validar el cuerpo, comprobar señales geográficas | No hasta que se solucione la causa |
| Misma IP en cada solicitud | Casi siempre reutilización de conexión en tu cliente | Probar con procesos separados | No aplica |
407: autenticación rechazada
El gateway rechazó tus credenciales, lo que significa que tu tráfico llegó hasta él y la conectividad es correcta.
Tres causas explican casi todos los casos: un error de tecleo en las credenciales, un flag mal formado en el nombre de usuario extendido, o una contraseña que se rotó en el panel mientras una copia antigua sigue desplegada en algún lugar. La segunda es la menos obvia, porque un valor no reconocido como country-uk en lugar de country-gb hace que todo el nombre de usuario sea imposible de interpretar, por lo que se informa como un fallo de autenticación en lugar de un error de segmentación.
El diagnóstico es siempre el mismo: elimina todos los flags y prueba primero el nombre de usuario simple. Si funciona, el fallo está en los flags y los vuelves a añadir uno a uno. Si falla, vuelve a copiar la contraseña desde el panel. Más detalles en solución de errores 407 y de credenciales.
Nunca reintentes tras un 407. Es definitivo, y un bucle de reintentos contra él consume ancho de banda mientras parece, desde fuera, relleno de credenciales.
502: nada coincidió con tu filtro
Tus credenciales fueron aceptadas y después no había ninguna dirección disponible para la combinación que solicitaste. Esto es un problema de segmentación, no un fallo.
Suele aparecer cuando un filtro es muy estrecho, una ciudad pequeña, un ASN específico, o una combinación de ambos, y es más probable en horas en las que el pool local es escaso, ya que la disponibilidad sigue la actividad humana. Amplía el filtro, baja de ciudad a región o país, o elimina la coincidencia estricta para que el gateway recurra a un pool más amplio. Si dependes de la coincidencia estricta de forma deliberada, este error es el sistema funcionando como se espera. Más contexto en disponibilidad por país.
509: sin ancho de banda
La asignación del plan está agotada y el exceso no está activado, por lo que las solicitudes se detienen. No hay nada mal en la conexión ni en la configuración. Añade fondos para activar el exceso, o espera a que el ciclo se reinicie, y si esto ocurre con regularidad el plan es demasiado pequeño, lo cual es una cuestión de previsión tratada en cómo estimar el ancho de banda mensual.
Conexión rechazada, o una solicitud que se queda colgada para siempre
No estás hablando con el gateway en absoluto. Dos causas habituales: estás apuntando a un host antiguo basado en puertos en lugar de a p.shifter.io:443, o tu propia red está bloqueando el tráfico saliente en ese puerto.
Prueba la conectividad en bruto antes de asumir nada sobre el proxy:
nc -vz p.shifter.io 443Si esto falla, es un problema de salida o de firewall en tu lado. Si tiene éxito pero las solicitudes siguen fallando, estás en el terreno de la autenticación descrito antes.
Tiempos de espera agotados
La clase más ambigua, porque varios problemas distintos producen el mismo síntoma. El paso más útil por sí solo es separar el tiempo de conexión del tiempo total, ya que apuntan en direcciones opuestas:
curl -o /dev/null -s -w "connect: %{time_connect}s total: %{time_total}s\n" \
-x customer-USERNAME:PASSWORD@p.shifter.io:443 https://example.comUna conexión lenta apunta a la ruta del proxy o a un filtro demasiado estrecho que ralentiza la selección de direcciones. Una conexión rápida con un total lento apunta a que el destino es lento, algo que no se soluciona cambiando de proxy. Comprueba también si tus tiempos de espera están simplemente calibrados para latencia de datacenter, porque las conexiones residenciales son legítimamente más lentas y un tiempo de espera de dos segundos fallará constantemente por razones que no son errores. El diagnóstico completo está en por qué las solicitudes agotan el tiempo de espera, y las opciones de ajuste en reducir la latencia.
403, captchas y páginas de desafío
Estos provienen del destino, no del proxy, lo que significa que tanto la autenticación como la conectividad funcionaron. El destino examinó la solicitud y la rechazó.
La respuesta inmediata es retirar esa sesión y tomar una nueva en lugar de reintentar con la misma identidad. La respuesta duradera es averiguar por qué, y el orden de probabilidad es primero el ritmo, después la forma de la solicitud, luego el comportamiento, y por último la calidad de la dirección. Reducir la velocidad soluciona más de estos casos que cualquier otra cosa, según limitación de ritmo y regulación de solicitudes, y si el ritmo es defendible el siguiente sospechoso son las cabeceras y el user agent contradiciéndose entre sí. El manual de recuperación está en qué hacer cuando tus IPs son bloqueadas.
429: demasiadas solicitudes
El destino está limitando tu tasa de solicitudes. Al igual que un 403, procede del destino y no del gateway, por lo que tus credenciales y tu conexión están bien. Significa que las solicitudes llegan más rápido de lo que el destino acepta desde un visitante, una sesión o una red.
Reduce el ritmo en lugar de reintentar de inmediato. Si la respuesta incluye una cabecera Retry-After, espera al menos ese tiempo antes de realizar la siguiente solicitud a ese destino. Si no la incluye, aplica un retroceso exponencial, reduce la concurrencia para ese destino y reparte las solicitudes entre más sesiones en lugar de forzar más tráfico a través de una sola. Reintentar un 429 al mismo ritmo convierte un límite temporal en un bloqueo. El método de ajuste de ritmo se explica en la guía de limitación de ritmo enlazada en la sección 403 anterior.
Un 200 que no es lo que querías
El fallo más costoso, porque nada parece estar mal. Una página de desafío, un conjunto de resultados vacío, un listado truncado, o una página genérica regional pueden llegar todos con un estado de éxito, y un proceso que solo cuenta códigos de estado los registrará como datos.
Si el contenido es incorrecto en lugar de faltante, sospecha primero de la geografía: una cabecera Accept-Language que contradice tu país de salida, o una fuga de DNS que resuelve nombres de host desde tu ubicación en lugar de la del proxy, ambas producen contenido plausible para el mercado equivocado. Consulta hacer coincidir geo, zona horaria y locale y prevenir fugas de DNS.
Si el contenido es un desafío o un contenido mínimo, trátalo como un bloqueo, según detectar contenido bloqueado o falso. En cualquier caso la lección es la misma: valida el cuerpo antes de contar una respuesta como éxito, o ninguna de tus métricas significará nada.
La misma dirección en cada solicitud
La rotación parece rota y casi nunca lo está. La causa habitual es que tu cliente HTTP está reutilizando una conexión, y la dirección de salida se elige al establecer la conexión y no por cada solicitud enviada a través de ella.
Prueba primero con procesos separados:
for i in 1 2 3; do
curl -s -x customer-USERNAME:PASSWORD@p.shifter.io:443 http://ip-info.com/json | head -c 60; echo
doneSi esto rota y tu aplicación no, la causa es el agrupamiento de conexiones (connection pooling) en tu cliente. Si ninguno de los dos rota, comprueba si hay un flag sid en el nombre de usuario que solicite una sesión persistente, y confirma que la dirección que ves no es simplemente la tuya propia, lo que significaría que el proxy no se está aplicando en absoluto. Causas completas en la IP no rota.
En un navegador: ERR_PROXY_CONNECTION_FAILED y ERR_TUNNEL_CONNECTION_FAILED
Los navegadores suelen ocultar el código de estado del proxy tras sus propios nombres de error. Dos de ellos cubren la mayoría de los casos.
ERR_PROXY_CONNECTION_FAILEDsignifica que el navegador no pudo llegar al proxy en absoluto. Trátalo como la conexión rechazada mencionada antes: comprueba que el host esp.shifter.ioy el puerto es443, y después comprueba si tu red, firewall o antivirus está bloqueando la conexión.ERR_TUNNEL_CONNECTION_FAILEDsignifica que el navegador llegó al proxy, pero el proxy no abrió el túnel hacia el destino. Normalmente se trata de un 407 (credenciales o un flag mal formado) o un 502 (nada coincidió con tu filtro), así que prueba primero el nombre de usuario simple, como en la sección del 407.
Errores de TLS y certificados
Menos frecuentes, y normalmente ambientales. Una librería TLS desactualizada que rechaza el conjunto de cifrado del gateway, o un middlebox corporativo que rompe la cadena de confianza. Actualiza primero la librería del cliente. Desactivar la verificación de certificados hará que el error desaparezca y debe usarse solo para confirmar el diagnóstico, nunca en nada que llegue a producción.
Un orden general de operaciones
Cuando algo se rompe y no estás seguro por dónde empezar: confirma la conectividad en bruto, después prueba las credenciales simples sin flags, luego añade los flags de nuevo uno a uno, y a continuación comprueba si la respuesta es realmente lo que solicitaste en lugar de confiar en el código de estado. Esa secuencia aísla la capa en un par de minutos, y es la misma secuencia tanto si el síntoma es un código de error como si son datos que parecen sutilmente incorrectos.
Para cualquier cosa continua en lugar de aguda, la instrumentación que detecta estos casos antes de que los notes manualmente está en monitorizar la salud del proxy a escala.
Preguntas frecuentes
¿Qué errores de proxy deberías reintentar?
Reintenta los tiempos de espera agotados con retroceso progresivo, y los 429 tras esperar el tiempo de Retry-After. Nunca reintentes un 407: es un problema de credenciales o de flags, y reintentar consume ancho de banda. Amplía el filtro antes de reintentar un 502, y utiliza una sesión nueva en lugar de reintentar un 403 en la misma.
¿Qué significa 502 Bad Gateway en un proxy residencial?
Tus credenciales se aceptaron, pero ninguna dirección coincidió con la segmentación solicitada en ese momento, normalmente porque una ciudad, un ASN o una combinación es muy restrictiva. Amplía el filtro, de ciudad a región o país, e inténtalo de nuevo.
¿Por qué mi proxy devuelve un 200 pero con el contenido equivocado?
O bien se trata de un bloqueo silencioso, como una página de desafío o un resultado vacío que llega con un estado de éxito, o bien el locale es incorrecto porque una cabecera Accept-Language o una fuga de DNS contradice tu país de salida. Valida el cuerpo antes de considerar una respuesta como correcta.
¿Por qué mi proxy residencial utiliza la misma IP en cada solicitud?
Casi siempre porque tu cliente HTTP reutiliza una conexión, y la dirección de salida se elige al abrir la conexión. Prueba con procesos separados. Si eso rota y tu aplicación no, la causa es el agrupamiento de conexiones (connection pooling); si ninguno de los dos rota, comprueba si hay un flag sid que solicite una sesión persistente.
La conclusión
Nueve patrones cubren casi todo. El 407 es un problema de credenciales o de un flag mal formado, y nunca merece la pena reintentarlo. El 502 es un filtro vacío, no un fallo. El 509 es ancho de banda. La conexión rechazada significa que nunca llegaste al gateway. Los tiempos de espera agotados requieren, antes que nada, separar el tiempo de conexión del tiempo total. Un 403 o un desafío es el destino rechazándote, así que cambia de identidad y después averigua por qué. Un 429 es el destino pidiéndote que reduzcas el ritmo, así que respeta Retry-After y disminuye la velocidad. Un 200 con el contenido equivocado es el caso peligroso, y por eso la validación del cuerpo no es opcional. Y la misma dirección en cada solicitud es casi siempre reutilización de conexión en tu propio cliente. Trabaja desde la conectividad hacia fuera, y comprueba lo que realmente llegó en lugar de lo que afirma el código de estado.
El propio gateway está documentado en cómo conectar, el vocabulario en el glosario, y el producto es proxies residenciales con precios por GB.