El proxy no funciona: cómo diagnosticar el error paso a paso

¿Por qué el proxy no funciona? Un orden de pruebas para encontrar el fallo: tu red sin proxy, host y puerto, protocolo, contraseña o whitelist y, al final, el sitio de destino.

Si el proxy no funciona, lo peor que puedes hacer es cambiar cinco ajustes a la vez. Esta guía es para quien ya tiene datos de un proveedor (host, puerto, usuario o IP autorizada) y necesita saber en qué punto se rompe la cadena. No regalamos claves ni vendemos IP: Top Proxy es un catálogo que compara servicios.

01Por qué un proxy deja de funcionar: la cadena completa#

Una conexión a través de proxy tiene cuatro tramos, y cualquiera puede fallar por separado:

1. Tu dispositivo tiene que salir a Internet.
2. Tu dispositivo tiene que alcanzar el servidor proxy en un host y un puerto concretos.
3. El proxy tiene que aceptarte: protocolo correcto y credenciales válidas, o tu IP en su lista blanca.
4. El proxy tiene que llegar al sitio de destino, y ese sitio tiene que responder a la IP de salida del proxy.

El mensaje de error casi nunca dice en qué tramo está el fallo: «No se puede conectar al servidor proxy» puede ser un puerto mal escrito, un firewall o un servidor caído. Por eso el diagnóstico va en orden, del tramo 1 al 4. Cada prueba reduce las sospechas, pero ninguna descarta por sí sola que fallen dos tramos a la vez.

02Paso 1: comprueba la red sin proxy#

Antes de tocar el proxy, desactívalo y abre cualquier sitio conocido. Si sin proxy tampoco hay conexión, empieza por tu red: mientras no funcione, las pruebas del proxy no darán resultados fiables. Eso no garantiza que el proveedor esté bien; solo indica por dónde empezar.

Revisa también lo que puede interferir sin que lo recuerdes:

• Una VPN activa. Si la VPN enruta todo el tráfico, la conexión al proxy sale desde el servidor VPN, y eso afecta a la whitelist por IP (lo verás en el paso 3).
• Otro proxy configurado. Una extensión del navegador, un proxy del sistema y el proxy de una aplicación pueden estar activos a la vez. Deja solo uno mientras pruebas.
• Una red gestionada. En redes de empresa o universidad, el administrador puede imponer su propio proxy o bloquear puertos de salida. No borres esa configuración por tu cuenta; si dudas, consulta con quien gestiona la red.

Anota tu IP pública actual en Mi IP. Ese dato te servirá dos veces: para la whitelist y para comparar después con la IP de salida del proxy.

03Paso 2: verifica que el host y el puerto responden#

Lo más común es un error de copia: un carácter de más en el host, un puerto equivocado o un espacio al final de la contraseña. Copia los datos de nuevo desde el panel del proveedor y confirma allí que el plan sigue activo y con tráfico.

Para aislar el proxy de tu navegador, prueba con curl, incluido en las versiones recientes de Windows, macOS y muchas distribuciones Linux. En PowerShell de Windows, curl puede ser un alias de otro comando; escribe curl.exe para usar el programa real. Sustituye los marcadores por tus datos:

curl -v --connect-timeout 10 --max-time 30 -x http://HOST:PUERTO https://example.com/

La opción -v muestra cada fase de la conexión. Según la documentación de curl, --connect-timeout limita solo la fase de conexión, que termina cuando se completan la resolución DNS y los handshakes TCP o TLS; --max-time pone un tope a toda la prueba. No añadas -k ni desactives la verificación TLS para «hacer que funcione»: ocultaría el problema en lugar de resolverlo.

Cómo leer el resultado:

• Conexión rechazada inmediatamente. Algo respondió con un rechazo: puede que en ese puerto no escuche nada (puerto equivocado, proxy detenido) o que un firewall rechace la conexión de forma explícita.
• Tiempo de espera agotado. Los paquetes no llegan o no vuelven a tiempo. Puede ser un host incorrecto, un firewall (el tuyo, el del router, el de la red o el del proveedor) o un servidor caído.
• No se puede resolver el nombre del proxy. El host está mal escrito o tu DNS no lo encuentra. Prueba con la IP del servidor si el proveedor la publica.
• La conexión se establece y llega a la fase de autenticación. El tramo 2 parece correcto. Pasa al paso 3.

Si tienes acceso a otra red (por ejemplo, los datos móviles del teléfono), repite la prueba desde allí. Que responda desde otra red apunta a tu red local o a tu operador, pero no es la única explicación: si el proveedor autoriza IP de origen concretas, la diferencia puede estar en qué IP aceptó.

04Paso 3: protocolo, contraseña y whitelist#

Protocolo. Un puerto HTTP no habla SOCKS5 y viceversa. Si el proveedor te dio un puerto SOCKS5 y la aplicación está configurada como proxy HTTP, la conexión se abrirá y se cerrará sin explicación clara. Prueba el esquema que indica el proveedor:

curl -v --connect-timeout 10 --max-time 30 -x socks5h://HOST:PUERTO https://example.com/

La guía oficial Everything curl explica la diferencia entre socks5 y socks5h: con socks5 el nombre del sitio lo resuelve tu equipo, y con socks5h el nombre se envía al proxy, que hace la resolución.

Usuario y contraseña. Con autenticación por credenciales, añádelas en la prueba:

curl -v --connect-timeout 10 --max-time 30 -x http://HOST:PUERTO -U "USUARIO:CONTRASEÑA" https://example.com/

Las reglas de comillas y caracteres especiales cambian entre bash, zsh, PowerShell y la consola clásica de Windows; si la contraseña contiene símbolos, revisa cómo los trata tu terminal. Un proxy HTTP que exige autenticación responde con el código 407 Proxy Authentication Required. Según MDN, esa respuesta va acompañada de la cabecera Proxy-Authenticate, que indica cómo autenticarse, y el cliente debe repetir la petición con Proxy-Authorization. Un 407 confirma que el proxy responde y pide autenticación: la causa puede ser una credencial errónea, pero también que el cliente no la envíe o use un método que el proxy no acepta. El error 407 merece su propia guía.

Whitelist por IP. Muchos proveedores permiten autorizar una IP en lugar de usar contraseña. Si tu IP pública cambió (router reiniciado, red móvil, VPN encendida), el proxy deja de aceptarte aunque nada más haya cambiado. Compara la IP que anotaste en el paso 1 con la que figura en el panel del proveedor.

Qué devuelve curl en cada caso: pruebas controladas

Para comprobar cómo se ven estos fallos, ejecutamos curl 8.7.1 contra un proxy de prueba local con credenciales ficticias y la verificación TLS activada. No es una prueba de ningún proveedor comercial, y no reprodujimos cortes de conexión, tiempos agotados ni rechazos por whitelist.

La lección práctica: sin --fail, curl termina con código 0 aunque reciba un 407 o un 502, así que mira el estado HTTP en la salida de -v, no solo si el comando «terminó bien». Y un 502 puede venir del propio sitio de destino, no del proxy.

05Paso 4: comprueba el sitio de destino y el resultado#

Si curl llega a https://example.com/ a través del proxy pero tu sitio concreto sigue sin cargar, el proxy acepta tráfico y conviene mirar el último tramo.

Haz dos comparaciones. Primero, abre ese mismo sitio sin proxy: si tampoco carga, el sitio puede estar caído o rechazarte por otros motivos. Segundo, abre otro sitio con el proxy. Si el resto carga, una posibilidad es que el destino limite la IP de salida, pero no la única: la resolución DNS de ese dominio, restricciones del proveedor sobre ciertos destinos, la negociación TLS o los ajustes de sesión y rotación también pueden diferir.

Los códigos que devuelve un intermediario ayudan a acotar el fallo, sin aislarlo del todo. Según MDN, un 502 Bad Gateway significa que un proxy o pasarela recibió una respuesta no válida del servidor siguiente, y un 504 Gateway Timeout que no recibió respuesta a tiempo. Ese intermediario puede ser el proxy del proveedor, otro intermediario o la infraestructura del propio sitio, así que el código no señala por sí solo qué red falla.

Si el sitio carga pero muestra captchas, pide verificaciones o devuelve contenido de otro país, la reputación o la ubicación de la IP son sospechosos habituales, aunque no los únicos: el sitio también valora el comportamiento, las cookies y el navegador. Si el factor es la IP, ayuda cambiar de tipo (centro de datos, residencial o móvil) o de ubicación.

Confirma la IP de salida

Con el proxy activo en el navegador, vuelve a abrir Mi IP. Esa página muestra la IP de la petición actual. Compárala con la IP o el rango de salida que indica el proveedor: si coincide, esa petición siguió la ruta esperada; si ves tu IP directa, esa aplicación no envió la petición por el proxy y conviene revisar su configuración. Ni que la IP cambie ni que el país se mantenga basta por sí solo: una VPN también cambia la IP, y muchos proxies tienen salida en tu mismo país.

Para probar el proxy de forma independiente de tu navegador, usa el comprobador de proxies. Introduce host, puerto, protocolo y credenciales, y el comprobador intentará conectar desde su propio servidor. Ten en cuenta dos límites: si tu proveedor autoriza solo IP concretas y la del comprobador no está entre ellas, la prueba fallará aunque el proxy esté bien; y que el comprobador conecte no descarta un fallo de configuración en tu navegador o aplicación.

06Árbol de diagnóstico: el orden completo#

1. ¿Funciona Internet sin proxy? No: empieza por tu red, VPN o configuración gestionada. Sí: sigue.
2. ¿El puerto del proxy responde con curl? Rechazado: revisa puerto, estado del proxy y firewalls. Tiempo agotado: revisa host, firewall y prueba desde otra red. Responde: sigue.
3. ¿El protocolo coincide con el puerto? Prueba HTTP o SOCKS5 según indique el proveedor.
4. ¿Te acepta el proxy? 407 o cierre inmediato: credenciales, método de autenticación, whitelist, estado del plan.
5. ¿Carga un sitio neutro como example.com a través del proxy? No: vuelve al paso 3 o 4. Sí: sigue.
6. ¿Carga tu sitio sin proxy? No: revisa el propio sitio. Sí: compara DNS (socks5 frente a socks5h), restricciones del proveedor y otra ubicación u otro tipo de IP.
7. ¿Mi IP muestra la salida que indica el proveedor? No: el navegador o la aplicación no usan esa ruta; antes de culpar al navegador, repite en curl el mismo destino, endpoint, protocolo y red de origen.

07Cuándo el problema es el proveedor#

Si las credenciales son correctas y el proxy sigue fallando con sitios neutros, escribe al soporte del proveedor con datos concretos: host, puerto, protocolo, hora de la prueba, mensaje de error y salida de curl -v. Antes de enviarla, borra usuario y contraseña, las cabeceras Proxy-Authorization y cualquier otra de autenticación, y las cookies.

Si el fallo se repite y el proveedor no responde, puede ser momento de comparar alternativas. Incluirlos aquí no significa que hayamos probado su compatibilidad con tu aplicación.

SOAX: proxies residenciales y móviles3.9219

SOAX vende proxies residenciales y móviles rotativos en un pool compartido de créditos, con datacenter e ISP en los mismos planes. Builder empieza en $200/mes + IVA (200 créditos); el tráfico Tier 1 es $3/GB en Builder.

85 países

3,00 US$

por 1 GB

Bright Data: proxies residenciales y de datacenter4.41438

Bright Data es una gran red de proxies para recopilar datos: IP residenciales, móviles, ISP y de datacenter en unos 195 países. El tráfico residencial se puede pagar por uso sin suscripción, y las direcciones de datacenter e ISP se venden en paquetes desde 10 IP. El acceso residencial y móvil exige verificar la identidad.

10 países

5,00 US$

por 1 GB

Oxylabs: proxies residenciales y de datacenter4.0770

Oxylabs vende proxies residenciales, de datacenter y móviles. El residencial de autoservicio empieza en $6/GB para 5 GB/mes. Pagos del comprador: tarjetas, transferencia, AliPay, PayPal.

10 países

0,59 US$

por 1 GB

08Preguntas frecuentes#