Los problemas de proxy parecen variados cuando estás en medio de uno, pero en realidad son bastante repetitivos. Casi todo lo que falla se agrupa en ocho patrones, y en la mayoría de los casos la propia respuesta te indica cuál estás viendo. Este es el índice: encuentra 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 |
|---|---|---|
407 Proxy Authentication Required | Credenciales incorrectas, o un flag mal formado en el nombre de usuario | Probar el nombre de usuario simple sin flags |
502 Bad Gateway | Ninguna dirección coincidió con tu filtro en ese momento | Ampliar el filtro |
509 Bandwidth Limit Exceeded | Asignación del plan agotada, exceso desactivado | Comprobar el saldo y el plan |
| Conexión rechazada o bloqueada | Nunca llegaste al gateway | nc -vz p.shifter.io 443 |
| Tiempos de espera agotados | Lentitud del destino, filtro demasiado restrictivo, o tu propia concurrencia | Separar el tiempo de conexión del tiempo de lectura |
403 o una página de desafío | El destino rechazó la identidad, no el proxy | Retirar la sesión, comprobar cabeceras |
200 con contenido incorrecto o vacío | Un bloqueo silencioso, o el locale equivocado | Validar el cuerpo, comprobar señales geográficas |
| Misma IP en cada solicitud | Casi siempre reutilización de conexión en tu cliente | Probar con procesos separados |
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.
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 https://ipinfo.io/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.
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.
La conclusión
Ocho patrones cubren casi todo. El 407 es credenciales o un flag mal formado y nunca merece la pena reintentarlo. El 502 es un filtro vacío en lugar de un fallo. El 509 es ancho de banda. Conexión rechazada significa que nunca llegaste al gateway. Los tiempos de espera agotados necesitan que se separe el tiempo de conexión del tiempo total antes de cualquier otra cosa. Un 403 o un desafío es el destino rechazándote, así que cambia de identidad y después averigua por qué. Un 200 con contenido incorrecto es el 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 volvió 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.