Contenido del artículo

Introducción: qué obtendrás de esta guía

Si trabajas con proxies móviles, tarde o temprano verás en los logs de tu parser, en la consola de un navegador antidetect o directamente en la ventana de tu panel publicitario una línea como «407 Proxy Authentication Required», «502 Bad Gateway», «504 Gateway Timeout» o el corto y temido «tunnel failed». En ese momento, un error de servidor proxy parece una caja negra: no sabes si la culpa es del propio proxy, de tu software, del sitio de destino o simplemente de una contraseña desactualizada. Esta guía convierte esa caja negra en un esquema de acciones claro.

Deliberadamente limitamos el tema: analizamos solo los códigos y mensajes que devuelve la capa de proxy. Los timeouts de red a nivel de conexión (cuando no hay respuesta alguna y el cliente corta la espera por sí mismo) se analizan por separado en el blog, y aquí no los duplicamos. Si en tu log aparece un código o la frase sobre el túnel, estás en el lugar correcto.

Qué obtendrás al final

  • Entenderás qué significa cada uno de los cuatro errores y en qué punto exacto de la cadena «tu software — proxy — sitio de destino» nace cada uno.
  • Aprenderás a identificar el origen del problema en dos o tres minutos con la utilidad curl, integrada en cualquier sistema.
  • Tendrás secuencias de acciones listas para 407, 502, 504 y tunnel failed, que puedes ejecutar como una lista de verificación.
  • Configurarás tu software para que reaccione correctamente a cada código: algunos errores hay que reintentar, otros no tienen sentido reintentar.
  • Armarás un registro personal de incidentes que te ahorrará horas en el próximo fallo.

Para quién es esta guía

La guía está escrita para marketers, especialistas en arbitraje, dueños de equipos pequeños y desarrolladores que usan proxies móviles pero no están obligados a ser ingenieros de redes. La parte principal está pensada para principiantes: cada comando está explicado, cada acción está detallada. Para quienes escriben sus propios scripts y quieren profundizar, al final hay un bloque avanzado aparte.

Qué necesitas saber de antemano

Basta con saber abrir una terminal o línea de comandos, copiar texto en ella y leer el resultado. Entender qué es una dirección IP y un puerto ayuda, pero lo recordaremos brevemente. No se requiere experiencia en programación.

Cuánto tiempo te llevará

La lectura completa y el primer diagnóstico tomarán entre 60 y 120 minutos. Si ahora mismo tienes un error específico en curso, ve directamente al paso correspondiente: cada error individual tiene asignados de 15 a 25 minutos junto con las verificaciones.

Preparación previa: herramientas y accesos

El diagnóstico de errores de la capa de proxy no requiere instalar programas pesados. Casi todo ya está en tu sistema operativo. Aun así, conviene prepararse con antelación para no buscar contraseñas ni recordar dónde está el archivo de configuración en el momento del fallo.

Herramientas necesarias

  1. Terminal o línea de comandos. En Windows 10 y 11 abre el menú «Inicio», escribe «cmd» o «PowerShell» y presiona Enter. En macOS abre «Programas», luego «Utilidades», luego «Terminal». En Linux, la terminal generalmente se abre con Ctrl+Alt+T.
  2. La utilidad curl. Está integrada en Windows desde la versión 10 (compilación 1803), en macOS y en la mayoría de las distribuciones de Linux. Verifica: escribe en la terminal curl --version y presiona Enter. Debe aparecer una línea con el número de versión, por ejemplo «curl 8.x.x». Si en su lugar dice que el comando no se encuentra, instala curl mediante el gestor de paquetes de tu sistema.
  3. Un navegador común con herramientas de desarrollador. Sirve cualquier navegador moderno donde con la tecla F12 se abre un panel con la pestaña «Network» (Red).
  4. Un editor de texto para llevar el registro de incidentes. Con el Bloc de notas alcanza, pero es más cómodo algo con resaltado para ver la estructura de los logs.
  5. Tu software de trabajo: navegador antidetect, parser, gestor de paneles publicitarios o tu propio script. Necesitaremos acceso a su configuración de proxy y a sus logs.

Accesos necesarios

  • Acceso al panel de tu proveedor de proxies. Para usuarios de mobileproxy.space es la página de gestión de tus canales, donde se ven el host, el puerto, el login, la contraseña, el tipo de autenticación y el enlace para cambiar la IP.
  • Credenciales vigentes de al menos un proxy: dirección (host), puerto, login y contraseña o la IP confirmada para autenticación por dirección.
  • Entender qué protocolo usas: proxy HTTP(S) o SOCKS5. Esta información también la muestra el panel.

Requisitos del sistema

Cualquier sistema operativo lanzado en los últimos ocho años. Conexión a internet con acceso al host del proxy. Nada más se necesita.

Copias de seguridad

Antes de cambiar la configuración de proxy en tu software de trabajo, guarda el estado actual. Esto toma cinco minutos y te salva de la situación en la que «curaste» el error y a la vez perdiste la configuración de diez cuentas.

  1. En el navegador antidetect exporta la lista de perfiles junto con la configuración de proxy. Por lo general la función de exportar está en el menú de perfiles y crea un archivo CSV o JSON.
  2. En el parser o script copia el archivo de configuración a una carpeta aparte con la fecha en el nombre, por ejemplo «config_backup_2026-03-14».
  3. Desde el panel copia a un archivo de texto las credenciales de todos los canales. Guarda ese archivo donde nadie más tenga acceso.
  4. Anota qué IP tiene tu computadora o servidor ahora. La necesitarás si usas autenticación por dirección IP.

Consejo: crea un archivo de texto «Registro de proxies» y anota ahí cada error en el formato «fecha, hora, código, host del proxy, sitio de destino, qué hice, qué ayudó». En un mes tendrás una base de conocimiento personal más útil que cualquier artículo.

Verificación: la terminal abre, el comando curl muestra la versión, accediste al panel y ves las credenciales de al menos un proxy, las copias de seguridad de las configuraciones están en una carpeta aparte. Puedes seguir adelante.

Conceptos básicos: cómo está estructurada la capa de proxy y de dónde vienen los códigos

Para corregir un error de servidor proxy con criterio y no por prueba y error, hay que imaginar el recorrido de la petición. Consta de tres tramos, y cada uno de nuestros cuatro errores vive en su propio tramo.

Los tres tramos del recorrido de la petición

  • Cliente — proxy. Tu navegador, parser o script se conecta al host y al puerto del proxy. En este tramo se verifica la autenticación. Aquí nace el error 407 y parte de los casos de tunnel failed.
  • Proxy — red móvil — sitio de destino. El servidor proxy, al recibir tu petición, abre en su propio nombre una conexión a través del módem con la tarjeta SIM del operador hacia el sitio deseado. Aquí surgen el 502 y el 504.
  • Sitio de destino — camino de vuelta. La respuesta del sitio va de regreso por los mismos nodos. Si el sitio devolvió su propio código, por ejemplo 403 o 429, ya no es un error de la capa de proxy, y es importante aprender a distinguirlos.

Las clases de códigos en lenguaje sencillo

El código de respuesta es un número de tres dígitos que el servidor envía en la primera línea de la respuesta. El primer dígito indica la clase. Los códigos 4xx significan «problema de tu lado, corrige la petición». Los códigos 5xx significan «problema del lado del servidor o detrás de él». Para la capa de proxy funciona así:

  • 407 Proxy Authentication Required — el proxy dice: «No sé quién eres, o tus datos son incorrectos». Clase 4xx: hay que corregir de tu lado.
  • 502 Bad Gateway — el proxy dice: «Intenté llegar más allá, pero recibí una desconexión o basura en lugar de una respuesta». Clase 5xx: el problema está detrás del proxy o en el propio proxy.
  • 504 Gateway Timeout — el proxy dice: «Esperé la respuesta del siguiente nodo el tiempo establecido y no llegó». También es 5xx.

En qué se diferencia el código 504 de un timeout de red

Esta es la distinción clave para todo el artículo. Cuando ves el código 504, significa que el servidor proxy está vivo, aceptó tu petición, esperó él mismo la respuesta del sitio y él mismo te informó del fallo. La conexión entre tú y el proxy funcionaba perfectamente. En cambio, cuando tu cliente escribe «connection timed out» u «operation timed out» sin código, significa que no hubo respuesta alguna y que la desconexión la inició tu software. Lo primero es el tema de esta guía. Lo segundo es otro tema, analizado en materiales relacionados del blog. Un indicio simple: si hay un número de tres dígitos en la respuesta, sigue leyendo aquí.

Qué es un túnel y por qué «se cae»

Cuando abres un sitio por HTTPS a través de un proxy HTTP, el navegador primero envía al proxy un comando especial CONNECT con la dirección y el puerto de destino. El proxy abre una conexión con el sitio y responde «200 Connection established». Después de eso, a través del proxy va un flujo cifrado que el propio proxy ya no lee. Esa conexión se llama túnel. Si al comando CONNECT el proxy respondió con algo distinto de 200, el cliente escribe «tunnel failed» y junto a eso generalmente indica qué código llegó. Es decir, tunnel failed no es un error independiente, sino una envoltura sobre uno de los códigos.

Dos formas de autenticación

  • Login y contraseña. El cliente los transmite en el encabezado Proxy-Authorization. Es el método más común y la fuente más frecuente del 407.
  • Autenticación por IP. Indicas de antemano en el panel la dirección de tu computadora o servidor, y el proxy deja pasar todas las peticiones desde esa dirección sin contraseña. Es cómodo, pero se rompe cuando tu IP cambia.

Encabezados de servicio por los que se ve el autor de la respuesta

El proxy a menudo agrega a sus respuestas encabezados Via, Proxy-Agent o X-Proxy. Los sitios de destino no los ponen. Si en una respuesta con código 502 hay un encabezado Proxy-Agent, sabes con certeza que respondió el proxy. Si no hay esos encabezados y hay un Server con el nombre del servidor web del sitio, es la respuesta del propio sitio. Usaremos activamente este indicio.

Consejo: memoriza la regla mnemotécnica: «cuatro — busca de tu lado, cinco — busca detrás del proxy, túnel — mira qué número está al lado». Resuelve la mitad de los casos sin seguir leyendo.

Paso 1: Determinamos quién exactamente devolvió el error

Objetivo de la etapa: en pocos minutos establecer con precisión si te respondió el servidor proxy, el sitio de destino o tu propio software, y registrar el texto completo de la respuesta para el trabajo posterior.

Instrucciones

  1. Abre el panel y copia las credenciales del proxy problemático: host, puerto, login, contraseña. Para el ejemplo supondremos que el host es proxy.example.net, el puerto 8080, el login user1, la contraseña pass1. Sustituye por tus propios valores.
  2. Abre la terminal.
  3. Escribe el comando, reemplazando las credenciales y la dirección de destino por las tuyas, y presiona Enter: curl -v -x http://user1:pass1@proxy.example.net:8080 https://example.com/. La clave -v activa la salida detallada, la clave -x define el proxy.
  4. Espera a que el comando termine. Por lo general es uno o tres segundos. Si el comando «se cuelga» más de 30 segundos, presiona Ctrl+C: probablemente tengas un timeout de red y no un código, y ese no es nuestro tema.
  5. Encuentra en la salida las líneas que empiezan con el símbolo «mayor que» (eso es lo que envió curl) y con el símbolo «menor que» (eso es lo que llegó en respuesta). La primera línea de la respuesta será del tipo «HTTP/1.1 407 Proxy Authentication Required» o «HTTP/1.1 200 Connection established».
  6. Mira la línea con la inscripción CONNECT. Si inmediatamente después llegó un código distinto de 200, significa que el error lo devolvió el proxy en la etapa del túnel. Si CONNECT recibió 200, y el código de error llegó después, tras las líneas del handshake TLS, significa que ya respondió el sitio de destino.
  7. Encuentra los encabezados de la respuesta. La presencia de Proxy-Agent, Via o encabezados de servicio similares indica inequívocamente el proxy. Un encabezado Server con el nombre del servidor web y un encabezado Set-Cookie indican el sitio de destino.
  8. Repite el mismo comando sin la clave -x, es decir directamente: curl -v https://example.com/. Si el sitio responde 200 y a través del proxy llega 5xx, el problema está localizado en el tramo detrás del proxy.
  9. Repite el comando a través del proxy, pero hacia otro sitio, por ejemplo hacia cualquier recurso grande y estable. Si el segundo sitio abre, el problema está relacionado con una dirección concreta, y no con el proxy en general.
  10. Copia toda la salida al registro de proxies junto con la fecha y la hora. La necesitarás en los pasos siguientes.

Camino alternativo a través del navegador

Si no te resulta cómodo trabajar en la terminal, abre el navegador con el proxy configurado, presiona F12, ve a la pestaña «Network», marca la casilla «Preserve log» (Conservar registro), recarga la página. En la lista de peticiones encuentra la línea con el código rojo, haz clic en ella y en la pestaña «Headers» estudia el bloque «Response Headers». La lógica es la misma: busca encabezados de servicio del proxy. La desventaja del método es que el navegador a menudo oculta detalles de la etapa CONNECT, por eso para tunnel failed es preferible la terminal.

Atención: el comando con la clave -v muestra el login y la contraseña del proxy en texto plano. No pegues esa salida en chats comunes, tickets de soporte ni capturas de pantalla sin reemplazar la contraseña por asteriscos.

Consejo: agrega al comando la clave -sS junto con -o y la indicación de un dispositivo vacío para no llenar la pantalla con el cuerpo de la respuesta: curl -sS -v -o /dev/null -x http://user1:pass1@proxy.example.net:8080 https://example.com/. En Windows, en lugar de /dev/null usa NUL.

Resultado esperado

En el registro apareció una entrada con la respuesta completa, y puedes decir con seguridad una de tres cosas: «respondió el proxy en la etapa de autenticación», «respondió el proxy en la etapa de contacto con el sitio» o «respondió el propio sitio». Esto te orienta hacia el paso 2, 3-4 o directamente fuera de este artículo.

Posibles problemas

  • El comando dice «Could not resolve proxy». Error de tipeo en el host. Compáralo con el panel carácter por carácter.
  • El comando dice «Failed to connect to proxy». El puerto está cerrado o es incorrecto. Es un problema de transporte, no un código; revisa el puerto e intenta con otro canal.
  • La salida se corta en la línea TLS sin código. Significa que el túnel está establecido, pero el sitio no respondió en el tiempo asignado por tu cliente. No lo confundas con 504: no hay código, así que no es nuestro caso.

Verificación: puedes nombrar al autor de la respuesta y el código exacto o la frase, y la línea de salida de curl está guardada en el registro.

Paso 2: Solucionamos el error 407 Proxy Authentication Required

Objetivo de la etapa: lograr que al comando CONNECT el proxy responda «200 Connection established» y no 407, y entender la causa para que el error no vuelva.

Por qué surge el 407

El proxy no aceptó tus credenciales. Por lo general hay seis causas, y las revisaremos en orden de complejidad creciente: error de tipeo, caracteres especiales en la contraseña, cambio de tu IP en la autenticación por dirección, vencimiento del canal, que el software no transmite los datos en absoluto, caché de datos antiguos en el navegador.

Instrucciones

  1. Abre el panel y encuentra el canal problemático. Asegúrate de que su plazo de vigencia no haya vencido y de que el estado sea activo. Si el plazo terminó, renuévalo y repite la petición en un minuto; en ese caso no hace falta seguir.
  2. Verifica qué tipo de autenticación está habilitado para el canal: login y contraseña o por dirección IP. Muchos paneles permiten habilitar ambos a la vez.
  3. Si está habilitada la autenticación por IP, averigua la dirección externa actual de tu computadora o servidor. Abre en el navegador, sin proxy, cualquier servicio que muestre tu IP y compárala con la dirección registrada en el panel. Los proveedores domésticos y los operadores móviles a menudo cambian la dirección tras reiniciar el router. Si las direcciones no coinciden, actualízala en el panel y espera uno o dos minutos: los cambios no se aplican de inmediato.
  4. Si se usan login y contraseña, cópialos del panel de nuevo, sin volver a escribirlos a mano. Pégalos en el comando curl del paso 1 y ejecútalo. La mitad de los casos de 407 termina aquí.
  5. Mira la contraseña. Si contiene los caracteres @, :, /, #, ?, % o un espacio, al transmitirlos en la línea de dirección hay que codificarlos. El símbolo @ se convierte en %40, los dos puntos en %3A, la almohadilla en %23, el signo de porcentaje en %25. Por ejemplo, la contraseña p@ss:1 en la URL se escribe como p%40ss%3A1. Para no codificar, transmite los datos con una clave aparte: curl -v -x proxy.example.net:8080 --proxy-user user1:p@ss:1 https://example.com/. Aquí curl mismo se encarga de los símbolos.
  6. Si curl pasa pero tu software de trabajo sigue recibiendo 407, el problema está en el propio software. Abre su configuración de proxy. Verifica que el login y la contraseña estén en campos separados y no pegados a la dirección, si el programa no lo espera así. Verifica que no haya un espacio al final de la contraseña: suele aparecer al copiar.
  7. En el navegador antidetect abre la configuración del perfil concreto, no la configuración global. Muchos usuarios cambian la contraseña en la lista general de proxies, pero el perfil sigue guardando una copia antigua. Vuelve a guardar el proxy en el perfil y reinicia el perfil.
  8. Si el navegador memorizó los datos antiguos y no pide los nuevos, borra las contraseñas guardadas para ese host en la configuración del navegador o crea un perfil nuevo para la prueba.
  9. Presta atención al encabezado Proxy-Authenticate en la respuesta 407. Si ahí dice «Basic», el proxy espera un par login-contraseña común. Si indica otro esquema, tu software debe soportarlo; para proxies móviles casi siempre se usa Basic, y una discrepancia significa un error en la configuración del tipo de proxy.
  10. Repite la petición curl y asegúrate de que ahora al CONNECT llega 200.

Atención: no intentes «resolver» el 407 con repeticiones masivas de la petición. Algunos servidores proxy bloquean temporalmente la dirección tras una serie de autenticaciones fallidas, y tendrás un problema adicional encima del original. Una verificación, una corrección, una verificación.

Consejo: si tienes varias decenas de canales, guárdalos en una tabla donde el login y la contraseña estén en columnas separadas, y al lado haya una columna con la contraseña ya codificada para URL. Así nunca confundirás qué variante va dónde.

Resultado esperado

En la salida de curl la línea de respuesta al CONNECT pasó a «HTTP/1.1 200 Connection established», el sitio entregó contenido. En el software de trabajo las peticiones pasan. En el registro queda anotada la causa: error de tipeo, codificación, cambio de IP, vencimiento del plazo o caché.

Posibles problemas

  • El código 407 llega dos veces: primero al CONNECT, luego dentro del túnel. Es señal de que el software envía los datos solo en una de las etapas. Actualiza el programa o activa en él la opción de transmitir la autenticación en el CONNECT.
  • El panel dice que la IP está agregada, pero el 407 sigue. Probablemente trabajas a través de una red corporativa o un servidor con varias direcciones de salida. Verifica la dirección exactamente desde la máquina desde la que salen las peticiones.
  • Funciona contigo, no funciona con un colega con los mismos datos. Con la autenticación por IP esto es esperable: tu colega tiene otra dirección. Cambia a login y contraseña o agrega una segunda IP.

Verificación: tres peticiones seguidas a través de curl y del software de trabajo pasaron sin 407, la causa quedó registrada en el registro.

Paso 3: Analizamos el error 502 Bad Gateway del proxy

Objetivo de la etapa: distinguir un fallo breve en el momento del cambio de IP de un problema persistente con una dirección o un canal, y elegir la reacción correcta para cada caso.

Por qué el proxy devuelve 502

El proxy aceptó tu petición, intentó abrir una conexión más allá y recibió una desconexión, un rechazo o una respuesta ilegible. Para proxies móviles las causas típicas son: el módem en ese momento cambiaba de dirección IP o se reregistraba en la red del operador; el sitio de destino cortó la conexión; del lado del proxy no se pudo resolver el nombre de dominio del sitio; el canal está sobrecargado con demasiados flujos simultáneos; el sitio está inaccesible para todos.

Instrucciones

  1. Registra la hora exacta de aparición del 502 con segundos. Esto es importante para el punto siguiente.
  2. Abre en el panel el historial de cambios de IP de ese canal o recuerda si tienes activada la rotación automática por horario. Si la rotación se activó en los mismos segundos que el error, te encontraste con un comportamiento normal: durante el cambio de dirección las peticiones reciben 502 durante dos a diez segundos. La solución es repetir la petición tras una pausa.
  3. Espera diez segundos y repite el comando curl del paso 1. Si la respuesta pasó a 200, anota en el registro «502 en momento de rotación» y pasa a configurar los reintentos en el paso 6.
  4. Si el 502 se repite de forma persistente, prueba otro sitio a través del mismo proxy. Abrió — el problema está en la dirección. No abrió — el problema está en el canal.
  5. Para el problema en la dirección: abre el sitio de destino directamente sin proxy. Si también directamente está inaccesible o devuelve 5xx, el proxy no tiene nada que ver: el sitio está caído. Si directamente todo funciona, el sitio probablemente corta conexiones desde direcciones de ese operador. Cambia la IP con el enlace del panel y repite. Si no ayudó, prueba un canal de otro operador o región.
  6. Para el problema en el canal: verifica en el panel el estado del equipamiento. Muchos proveedores tienen un indicador del estado del módem. Un estado rojo o amarillo significa que el canal se está recuperando, y solo queda esperar o cambiar a uno de reserva.
  7. Verifica la carga. Mira en tu software cuántos flujos simultáneos van por ese canal. Un canal móvil tiene capacidad limitada, y con decenas de conexiones paralelas el proxy empieza a rechazar parte de las peticiones justamente con 502. Reduce la paralelidad a la mitad y repite la prueba.
  8. Verifica si está relacionado con DNS. Ejecuta la petición al sitio por dirección IP en lugar del dominio, si el sitio lo permite, o cambia al esquema socks5h, en el que los nombres los resuelve el proxy, y compara el resultado. Si por nombre da 502 y por IP todo funciona, es cuestión de la resolución de nombres del lado del proxy; comunica al proveedor el nombre exacto del dominio.
  9. Si nada ayudó en 15 minutos, reúne la salida de curl -v, la hora, el host del canal, el dominio de destino y envíalos al soporte del proveedor. La información bien recolectada reduce la solución de un día a una hora.

Consejo: al trabajar con rotación por horario, sincroniza de antemano las pausas del software con el intervalo de cambio de IP. Si la dirección cambia cada 5 minutos, deja que el parser haga una pausa de 15 segundos al inicio de cada bloque de cinco minutos. El número de 502 bajará casi a cero sin una sola línea de código complejo.

Resultado esperado

Sabes con precisión a cuál de las categorías pertenece tu 502: momento de rotación, dirección concreta, sobrecarga del canal, fallo del equipamiento o inaccesibilidad del sitio. Para las tres primeras tienes una corrección, para las dos últimas, entender qué esperar y a quién escribir.

Posibles problemas

  • El 502 llega solo con archivos grandes. El sitio cierra la conexión por la velocidad lenta de entrega. Reduce el tamaño de los datos solicitados o usa un canal con mejor cobertura.
  • El 502 llega del sitio, no del proxy. Revisa los encabezados: si ahí está el Server del sitio y no hay Proxy-Agent, es un fallo interno del sitio, repite más tarde.
  • El 502 alterna con 200 sin lógica visible. Señal clásica de sobrecarga del canal. Reduce la paralelidad hasta obtener un resultado estable.

Verificación: diez peticiones consecutivas con una pausa de dos segundos a través del canal problemático hacia un sitio estable devuelven 200, o tienes en mano un ticket en soporte con todos los datos.

Paso 4: Trabajamos con el código 504 Gateway Timeout

Objetivo de la etapa: entender en qué tramo detrás del proxy se pierde tiempo y reducir la proporción de 504 a un nivel aceptable, sin confundir el código con un timeout de red del cliente.

Qué significa exactamente el 504 del proxy

El servidor proxy tiene su propio límite interno de espera de respuesta del sitio. Cuando el sitio no alcanza a responder dentro de ese límite, el proxy detiene la espera y te informa honestamente con el código 504. Tu cliente no cortó la conexión, la respuesta llegó. Por eso es importante que el límite de espera de tu software sea mayor que el límite del proxy: de lo contrario verás un timeout de red sin código y no podrás entender qué está pasando.

Instrucciones

  1. Verifica el límite de espera en tu software. En la mayoría de los programas se llama timeout, «tiempo de espera de respuesta» o «Read timeout». Si es menor a 30 segundos, ponlo temporalmente en 60. Es un paso de diagnóstico: necesitas esperar precisamente el código del proxy.
  2. Mide el tiempo hasta la respuesta a través del proxy. Ejecuta: curl -sS -o /dev/null -w "%{http_code} %{time_connect} %{time_starttransfer} %{time_total}" -x http://user1:pass1@proxy.example.net:8080 https://example.com/. La clave -w muestra cuatro números: el código, el tiempo hasta la conexión, el tiempo hasta el primer byte y el tiempo total en segundos.
  3. Ejecuta el mismo comando sin la clave -x. Compara el tiempo hasta el primer byte. Si directamente el sitio responde en 0,4 segundos y a través del proxy en 8 segundos, la demora en el tramo «proxy — sitio» es grande, y el 504 aparecerá ante cualquier fluctuación de la red móvil.
  4. Verifica en qué petición aparece el 504. Haz una petición con el método HEAD, que no carga el cuerpo de la página: curl -I -x http://user1:pass1@proxy.example.net:8080 https://example.com/. Si HEAD pasa y el GET de la página da 504, el problema está en el tamaño o en la generación lenta de la página, y no en la conexión como tal.
  5. Cambia la IP del canal con el enlace del panel. La red móvil no es homogénea: una dirección puede salir a una estación base sobrecargada, otra a una libre. Repite la medición. Si el tiempo cayó varias veces, agrega al software una regla: ante 504, primero cambiar la IP, luego repetir la petición.
  6. Revisa el peso de la página de destino. Algunos sitios entregan la respuesta solo tras ejecutar largas operaciones del servidor. Si tu objetivo son datos concretos, intenta dirigirte a una dirección más ligera del mismo sitio: a la API, a la versión móvil, a una página sin parámetros de ordenamiento.
  7. Si el 504 llega solo a un determinado dominio y solo a través de canales de un operador, registra esto en el log y redistribuye el trabajo con ese dominio hacia canales de otro operador.
  8. Devuelve el límite de espera del software a un valor de trabajo, pero ahora de forma consciente: debe ser un poco mayor que el tiempo típico de respuesta a través del proxy y menor que lo que estás dispuesto a esperar en el marco de la tarea. Para la mayoría de los escenarios son 30-45 segundos.

Atención: no pongas el límite de espera del software en varios minutos «por si acaso» y no lo dejes así para siempre. Un flujo colgado bloqueará un lugar en la cola, y una decena de flujos colgados creará la ilusión de que el proxy no funciona, aunque el problema está en un sitio lento.

Consejo: agrega al log de tu software una columna «tiempo hasta el primer byte». Con ella se ve si el canal se degrada gradualmente o cae de golpe. Un crecimiento gradual significa sobrecarga o mala cobertura, una caída brusca suele indicar rotación o un fallo del operador.

Resultado esperado

Conoces el tiempo típico de respuesta a través de cada canal, estableciste un límite en el software mayor que el límite del proxy, y los 504 se volvieron un evento raro ante el cual hay una reacción automática configurada.

Posibles problemas

  • Aumentaste el límite y en lugar de 504 empezaste a recibir un timeout de red. Significa que el proxy espera más de lo que pensabas, o que la conexión con el propio proxy es inestable. Esto ya está fuera de los códigos, mira materiales relacionados sobre timeouts.
  • 504 solo en determinadas horas. Pico de carga vespertino en las redes móviles. Traslada las tareas pesadas a la noche o a la mañana.
  • 504 en la primera petición a un sitio nuevo, luego todo rápido. Resolución primaria del nombre y establecimiento de la conexión del lado del proxy. Agrega una petición de calentamiento antes de la serie principal.

Verificación: una serie de veinte peticiones a un sitio de trabajo muestra el tiempo hasta el primer byte en un rango predecible y no más de uno o dos 504, y el software ante un 504 cambia la IP y repite la petición.

Paso 5: Corregimos el error tunnel failed

Objetivo de la etapa: aprender a leer el número junto a la frase tunnel failed, relacionarlo con la causa real y corregir la configuración del protocolo, el puerto y el tipo de proxy.

Cómo se ve y qué significa

En curl el mensaje se ve así: «CONNECT tunnel failed, response 407». En navegadores y soluciones antidetect pueden ser frases como «Proxy tunnel failed», «Unable to establish tunnel» o «Tunnel connection failed». Lo común es una cosa: el cliente envió el comando CONNECT y el proxy respondió algo distinto de 200. El número al lado es ese mismo código, y trabajar con él se reduce a los pasos anteriores más algunos casos especiales que se manifiestan solo en la etapa del túnel.

Instrucciones

  1. Ejecuta curl con la clave -v hacia una dirección HTTPS y encuentra la línea con tunnel failed. Registra el número tras la palabra response.
  2. Si es 407, vuelve al paso 2. La única diferencia es esta: asegúrate de que el software transmite la autenticación precisamente en la etapa CONNECT. En versiones antiguas de algunos programas, la casilla «Autenticación de proxy» actúa solo sobre peticiones HTTP, y el túnel sale sin contraseña.
  3. Si es 502 o 504, vuelve a los pasos 3 y 4. El proxy no pudo abrir la conexión con el puerto 443 del sitio o no lo esperó.
  4. Si es 403, el proxy se negó a abrir el túnel hacia el puerto o host indicado. Verifica a qué puerto te conectas. Los proxies móviles por lo general permiten túneles en 443 y algunos puertos comunes. Si tu servicio escucha en un puerto no estándar, aclara en el panel o con el proveedor si está permitido.
  5. Si es 400, el proxy no entendió el comando. La causa más común es que indicaste un proxy SOCKS5 como HTTP o al revés. Abre el panel y mira qué protocolo y puerto te dieron. En muchos proveedores, HTTP y SOCKS5 tienen puertos distintos del mismo canal.
  6. Corrige el esquema en el comando. Para SOCKS5 usa: curl -v -x socks5h://user1:pass1@proxy.example.net:1080 https://example.com/. La letra h en socks5h significa que los nombres de dominio los resuelve el proxy y no tu computadora. Para proxies móviles esta es la variante preferida.
  7. Si estás en un navegador antidetect, abre la configuración de proxy del perfil y encuentra la lista desplegable de tipo: HTTP, HTTPS, SOCKS5. Elige el que se indica en el panel y verifica el puerto. Tras guardar, reinicia el perfil por completo, no solo recargues la pestaña.
  8. Si no hay número junto a tunnel failed y solo está la frase, activa en el software el registro detallado o reproduce la situación a través de curl para obtener el código.
  9. Verifica si tu software intenta establecer una conexión TLS con el propio proxy. Algunos programas, al elegir el tipo «HTTPS», cifran no solo el tráfico hacia el sitio, sino también la conexión al proxy. Si el proxy no lo soporta, obtendrás tunnel failed o un error de handshake. Cambia al tipo «HTTP» para la conexión al proxy: el tráfico hacia el sitio de todos modos permanece cifrado dentro del túnel.
  10. Repite la prueba y asegúrate de que el CONNECT recibe 200 y la página carga.

Consejo: haz que dos peticiones breves de prueba formen parte de tu rutina diaria: una hacia una dirección por HTTP, la segunda hacia la misma dirección por HTTPS. Si la primera pasa y la segunda falla con tunnel failed, en un segundo entiendes que el asunto está en el túnel y no en la autenticación o el canal.

Resultado esperado

La frase tunnel failed desapareció de los logs, para cada canal están registrados el tipo y el puerto correctos, y en el software no está activado un cifrado innecesario de la conexión al proxy.

Posibles problemas

  • El túnel se establece, pero luego hay un error de certificado. Esto ya no es la capa de proxy: es el sitio o tu conjunto de certificados del sistema. Revisa la fecha y la hora en la computadora.
  • Funciona en curl, no funciona en el software con los mismos datos. El software aplica otro esquema o agrega su propio prefijo. Estudia su documentación sobre el formato de la línea de proxy.
  • tunnel failed solo para un sitio. El sitio usa un puerto no estándar, vuelve al punto sobre el 403.

Verificación: una petición HTTPS a través de curl y del software de trabajo da 200 en el CONNECT, el tipo y el puerto de todos los canales están registrados en la tabla.

Paso 6: Configuramos la reacción correcta del software ante cada código

Objetivo de la etapa: lograr que los errores de servidor proxy se procesen automáticamente: unos reintentarse con pausa, otros activar una alerta de inmediato, y que tú recibas logs claros y no un torrente de líneas rojas.

Principio: no todos los errores son iguales

Repetir la petición ante un 407 no tiene sentido: la contraseña no se volverá correcta por repetirla. Repetir ante un 502 en el momento de la rotación es necesario: en cinco segundos todo funcionará. Repetir ante un 504 es mejor después de cambiar la IP. Estas tres reglas constituyen la base de un procesamiento saludable de errores.

Instrucciones para un software ya hecho

  1. Abre la configuración del parser o del gestor de cuentas y encuentra la sección responsable de los reintentos. Puede llamarse «Retries», «Intentos repetidos», «Procesamiento de errores».
  2. Establece el número de reintentos para 5xx en 3, y la pausa inicial entre ellos en 5 segundos con duplicación: 5, 10, 20 segundos. Ese crecimiento de las pausas se llama retardo exponencial y evita que tu software remate un canal sobrecargado.
  3. Si el software permite definir una lista de códigos para reintentar, indica 502 y 504. No incluyas ahí el 407.
  4. Encuentra la configuración de la acción ante 407. Si no existe, establece el número de reintentos en la sección general al mínimo y activa la notificación de peticiones fallidas. Tu objetivo es ver el 407 en los primeros minutos, y no tras un día de inactividad.
  5. Encuentra el campo para el enlace de cambio de IP, si existe. Pega ahí el enlace del panel para el canal correspondiente y activa la opción «Cambiar IP ante error» o «Rotación ante fallo».
  6. Limita el número de flujos simultáneos por canal móvil. Empieza con 3-5 y aumenta hasta que la proporción de 502 se mantenga por debajo del uno por ciento.
  7. Activa el log detallado con guardado del código de respuesta y los encabezados. Asegúrate de que en el log se vea la diferencia entre el código del proxy y el código del sitio: muchos programas lo muestran en una columna aparte «Proxy status».
  8. Guarda la configuración, reinicia el software y haz una serie de prueba de 50 peticiones.

Instrucciones para un script propio

Si escribes código, la lógica es la misma. En pseudocódigo en Python con la biblioteca requests se ve así:

proxies = {"http": "socks5h://user1:pass1@proxy.example.net:1080", "https": "socks5h://user1:pass1@proxy.example.net:1080"} for attempt in range(3): r = session.get(url, proxies=proxies, timeout=45) if r.status_code == 407: alert("auth failed") break if r.status_code in (502, 504): rotate_ip() sleep(5 * 2 ** attempt) continue break

Presta atención a tres momentos. Primero: ante 407 salimos del bucle de inmediato y enviamos una notificación. Segundo: ante 502 y 504 primero cambiamos la IP, luego esperamos una pausa creciente. Tercero: el valor de timeout se eligió para esperar el código del proxy y no cortar la conexión antes.

Atención: en algunas bibliotecas el error en la etapa CONNECT llega no como una respuesta con código, sino como una excepción con el texto que contiene tunnel failed y el número. Captura esas excepciones por separado y extrae el código del texto, de lo contrario tu lógica de reintentos no funcionará.

Consejo: calcula las proporciones de códigos por cada canal al día y muéstralas en una tabla simple. El canal cuyo 5xx es consistentemente más alto que los demás vale la pena revisarlo primero, aunque formalmente funcione.

Resultado esperado

El software reintenta automáticamente las peticiones ante 502 y 504 con una pausa creciente y cambio de IP, informa de inmediato sobre el 407, limita el número de flujos y lleva un log con separación de códigos de proxy y de sitio.

Posibles problemas

  • El software también reintenta el 407, por lo que el proxy bloquea temporalmente la dirección. Desactiva los reintentos para 4xx por completo o reduce el número total de reintentos a uno.
  • Tras activar la rotación ante error, la IP cambia con demasiada frecuencia. Introduce un intervalo mínimo entre cambios, por ejemplo 60 segundos, para que una serie de 502 no provoque cinco rotaciones seguidas.
  • El log crece hasta gigabytes. Escribe los encabezados solo para respuestas con códigos de error, y para el 200 guarda una sola línea.

Verificación: la serie de prueba de 50 peticiones terminó sin intervención manual, en el log se ven reintentos con pausas de 5, 10, 20 segundos para 5xx, y al sustituir una contraseña incorrecta el software se detuvo y mostró una notificación de 407.

Verificación del resultado: lista de comprobación y pruebas

Recorre la lista y marca cada punto. Si al menos uno no está cumplido, vuelve al paso correspondiente.

Lista de comprobación

  • El comando curl con la clave -v se ejecuta, y sabes encontrar en la salida la línea de respuesta al CONNECT y los encabezados de servicio del proxy.
  • Para cada canal están registrados en la tabla el host, el puerto, el tipo de protocolo, el método de autenticación y la contraseña codificada.
  • Con la autenticación por IP, la dirección actual de tu máquina coincide con la del panel.
  • Una petición HTTPS a través de cada canal recibe 200 en el CONNECT.
  • Está medido el tiempo típico hasta el primer byte a través de cada canal, y el límite de espera del software lo supera con margen.
  • En el software están configurados reintentos solo para 502 y 504, con pausas de 5, 10, 20 segundos y cambio de IP antes del reintento.
  • Ante 407 el software se detiene y notifica.
  • El número de flujos por canal está limitado, y la proporción de 5xx en la serie de prueba es inferior al uno por ciento.
  • El registro de incidentes se lleva y contiene al menos una entrada completamente analizada.

Cómo probar

  1. Introduce a propósito una contraseña incorrecta y ejecuta una petición. Esperado: 407 en curl y notificación en el software sin serie de reintentos.
  2. Devuelve la contraseña correcta y ejecuta 30 peticiones a un sitio estable con una pausa de un segundo. Esperado: todos 200 o no más de un 5xx con reintento exitoso.
  3. Durante la serie presiona el enlace de cambio de IP en el panel. Esperado: uno o dos 502 en el log, luego reintento automático y continuación de la serie.
  4. Indica en la configuración el tipo SOCKS5 para un canal que fue entregado como HTTP y haz una petición. Esperado: tunnel failed o un error de protocolo que reconocerás en un segundo. Devuelve el tipo correcto.

Indicadores de una ejecución exitosa

La proporción de errores de la capa de proxy en las series de trabajo no supera el uno o dos por ciento, cada error está clasificado por código, y ninguno requiere intervención manual salvo el 407. El tiempo de reacción ante el 407 es de minutos, no de horas.

Errores típicos y soluciones

Problema: 407 después de cada reinicio del router

Causa: autenticación por IP, y el proveedor entrega una dirección dinámica.

Solución: cambia a autenticación por login y contraseña o activa ambos métodos a la vez. Si necesitas precisamente la IP, contrata una dirección estática con tu proveedor.

Problema: la contraseña es correcta, pero hay 407 en el navegador, aunque curl pasa

Causa: el navegador o el perfil del navegador antidetect guardó en caché los datos antiguos.

Solución: vuelve a guardar el proxy en la configuración del perfil concreto y reinicia el perfil; si es necesario, borra las contraseñas guardadas para el host del proxy.

Problema: 502 exactamente cada N minutos

Causa: coincide con el intervalo de rotación automática de IP.

Solución: sincroniza las pausas del software con el horario de rotación o cambia a cambiar la IP por enlace en momentos convenientes entre tareas.

Problema: 502 con un número grande de flujos, con pocos todo va bien

Causa: sobrecarga del canal móvil.

Solución: reduce la paralelidad a 3-5 flujos por canal y distribuye la carga entre varios canales.

Problema: 504 solo en un sitio, los demás son rápidos

Causa: el sitio genera la página lentamente o limita las direcciones de operadores móviles.

Solución: usa direcciones más ligeras del sitio, cambia la IP antes del reintento; ante un problema persistente, traslada el trabajo con ese sitio a un canal de otro operador.

Problema: en lugar del 504 empezó a llegar una desconexión sin código

Causa: el límite de espera del software es menor que el límite interno del proxy.

Solución: aumenta el límite en el software hasta un valor en el que alcances a recibir el código, por lo general 30-60 segundos.

Problema: tunnel failed, response 400

Causa: el puerto SOCKS5 está indicado como proxy HTTP o al revés.

Solución: compara el tipo y el puerto con el panel; para SOCKS5 usa el esquema socks5h, para HTTP usa http.

Problema: tunnel failed, response 403 hacia un puerto no estándar

Causa: el proxy no permite túneles hacia ese puerto.

Solución: aclara con el proveedor la lista de puertos permitidos y, de ser posible, reconfigura el servicio de destino al puerto 443.

Problema: el código 502 o 504 llega con un encabezado Server del sitio

Causa: es la respuesta del propio sitio y no de la capa de proxy: el sitio tiene problemas con sus propios servicios internos.

Solución: espera y repite más tarde; cambiar de proxy no ayudará.

Funciones adicionales para usuarios avanzados

Si ya dominas el diagnóstico básico, las siguientes técnicas harán que el trabajo con errores de la capa de proxy sea casi automático.

Transmisión manual del encabezado de autorización

A veces es útil verificar cómo reacciona el proxy a un encabezado concreto. Codifica el par login:contraseña en Base64 con cualquier herramienta local y transmite el encabezado tú mismo: curl -v -x proxy.example.net:8080 -H "Proxy-Authorization: Basic dXNlcjE6cGFzczE=" http://example.com/. Este método funciona para peticiones HTTP comunes y ayuda a entender si el proxy acepta los datos en general, independientemente de cómo los forme tu software. Para CONNECT usa la clave --proxy-header en lugar de -H.

Resolución de nombres del lado del proxy

El esquema socks5h y el túnel HTTP transmiten el nombre de dominio al servidor proxy, y no lo resuelven localmente. Esto da dos ventajas: el sitio ve la petición completamente originada en la red móvil, y te libras de discrepancias cuando tu DNS local entrega una dirección y la red del operador otra. Si ves 502 solo con la resolución local, el cambio a socks5h a menudo resuelve el problema sin contactar al proveedor.

Automatización a través de la API del proveedor

mobileproxy.space tiene una interfaz programática para el cambio de IP y la consulta del estado de los canales. Integra la llamada de cambio de IP en el manejador del 504, y la verificación del estado del canal en el manejador de 502 persistentes. Así el script decidirá por sí mismo si repetir la petición a través del mismo canal o cambiar a uno de reserva. Un algoritmo simple: tres 502 seguidos en un minuto — consultar el estado; si el canal está bien, cambiar la IP; si no, marcar el canal como no disponible por cinco minutos y pasar al siguiente.

Separación de métricas de proxy y de sitio

Crea en tu sistema de monitoreo dos métricas separadas: los códigos que llegaron con encabezados de proxy y los códigos que llegaron sin ellos. La primera métrica habla de la salud de tu infraestructura de proxy, la segunda, del comportamiento de los sitios de destino. Mientras estén mezcladas, buscarás un error de servidor proxy donde no lo hay, y al revés.

Grupo de canales con pesos

Asigna a cada canal un peso que disminuye con cada 5xx y se restaura lentamente con el tiempo. Distribuye las peticiones proporcionalmente a los pesos. Este enfoque retira automáticamente la carga del operador o la región problemática y la devuelve cuando el canal se recupera, sin un solo cambio manual.

Exportación de HAR desde el navegador

Para casos complejos en el navegador antidetect abre la pestaña Network, reproduce el error y elige «Save all as HAR». El archivo contiene todos los encabezados de peticiones y respuestas, incluidas las etapas que no se ven en el log normal del programa. Antes de enviarlo al soporte, elimina del archivo los valores de Proxy-Authorization y las cookies.

Optimización de los límites de espera

Reúne estadísticas del tiempo hasta el primer byte por cada canal y dirección durante una semana. Establece el límite de espera del software al nivel del percentil 95 más 10 segundos. Ese límite rara vez corta peticiones vivas y a la vez libera rápido los flujos ante bloqueos reales.

FAQ: preguntas frecuentes sobre el diagnóstico

¿Cómo entender que el 502 lo devolvió el proxy y no el sitio?

Mira los encabezados de respuesta. Si hay Proxy-Agent, Via u otros encabezados de servicio del proxy y no hay Set-Cookie ni Server del sitio, la respuesta es del proxy. Además: si el código llegó inmediatamente en respuesta al CONNECT, es con seguridad el proxy.

¿Vale la pena repetir la petición ante un 407?

No. Las credenciales no se volverán correctas por repetir, y una serie de intentos fallidos puede provocar un bloqueo temporal de tu dirección del lado del proxy. Corrige los datos y repite una vez.

¿Por qué en curl todo funciona y en mi software no?

Casi siempre el software forma de otra manera la línea de proxy, no codifica los caracteres especiales de la contraseña, aplica otro tipo de protocolo o no transmite la autenticación en el CONNECT. Compara la línea exacta de la configuración del software con el comando curl que funciona, carácter por carácter.

¿Cómo escribir correctamente una contraseña con caracteres especiales?

En la línea de dirección codifica: @ como %40, : como %3A, # como %23, % como %25, el espacio como %20. En los campos separados de login y contraseña introduce la contraseña tal cual, sin codificar.

¿En qué se diferencia el 504 del timeout del que se habla en otros artículos?

El 504 es un código que el proxy devolvió por sí mismo, tras esperar su propio límite de espera del sitio. Un timeout sin código significa que la conexión la cortó tu cliente al no recibir nada. Se solucionan de manera distinta, por eso están separados en materiales diferentes.

¿Cuántos flujos se pueden lanzar a través de un canal móvil?

No hay un número universal. Empieza con 3-5 y aumenta hasta que la proporción de 502 se mantenga por debajo del uno por ciento. Para páginas pesadas el número será menor, para peticiones API ligeras, mayor.

¿Hay que cambiar la IP ante cada error?

Ante 504 y 502 persistentes — sí, es la primera acción. Ante 407 — no, el cambio de IP no influye en la autenticación. Introduce un intervalo mínimo entre cambios para que una serie de errores no provoque una avalancha de rotaciones.

¿Qué enviar al soporte para resolver el asunto más rápido?

La salida completa de curl -v con la contraseña reemplazada por asteriscos, la hora exacta con segundos y zona horaria, el host y el puerto del canal, el dominio de destino, el tipo de autenticación y el resultado de una petición directa sin proxy. Con ese conjunto el soporte suele responder en el primer mensaje.

¿Se puede usar HTTPS para la conexión al propio proxy?

Solo si el proveedor lo soporta explícitamente. En la mayoría de los casos, para proxies móviles la conexión al proxy va por HTTP común o SOCKS5, y el cifrado del tráfico hacia el sitio lo garantiza el túnel. Activar un cifrado adicional hacia el proxy da tunnel failed o un error de handshake.

Conclusión

Recorriste el camino desde una incomprensible línea roja en el log hasta un sistema completo de diagnóstico. Ahora sabes determinar quién devolvió exactamente la respuesta, lees el 407 como una señal de revisar las credenciales y el método de autenticación, el 502 como un indicio de fallo detrás del proxy o en el momento de la rotación, el 504 como un informe honesto del proxy sobre un sitio lento, y tunnel failed como una envoltura sobre uno de estos códigos con una pista en forma de número. Tu software ya no repite lo que no tiene sentido y no se rinde ante lo temporal.

Qué hacer a continuación

  1. Lleva un registro de incidentes al menos un mes. Ya en dos semanas notarás patrones repetitivos y eliminarás sus causas.
  2. Una vez por semana revisa las proporciones de códigos por canal y redistribuye la carga.
  3. Automatiza el cambio de IP y la verificación del estado a través de la API del proveedor, para que los 5xx rutinarios se resuelvan sin ti.
  4. Estudia los materiales relacionados del blog sobre timeouts de red y sobre el comportamiento de los sitios de destino, para cerrar los dos tramos restantes del recorrido de la petición.

Hacia dónde desarrollarte

El siguiente nivel es construir tu propio grupo de canales con pesos y monitoreo, donde un error de servidor proxy deje de ser motivo de pánico y se convierta en un punto en el gráfico que el sistema procesa por sí mismo. Ya tienes todas las herramientas para eso: la comprensión de los códigos, curl, el panel del proveedor y el hábito de registrar. Buen trabajo y 200 estables.