Cuando falla una conexión proxy, revisa en orden el servicio proxy, la autenticación y el protocolo, la configuración del cliente y el sitio de destino. Cada paso tiene una señal clara para localizar la capa del problema antes de cambiar ajustes.
Después de configurar el proxy, el botón de prueba indica un fallo. En ese momento, lo peor es cambiar opciones al azar: puerto, protocolo o nodo, hasta que algo funcione sin saber qué cambio fue el que realmente ayudó.
Las causas suelen repartirse en cuatro capas: el propio servicio proxy, la autenticación y el protocolo, la configuración del cliente y el sitio de destino. Conviene revisar en ese orden, desde el proxy hacia fuera.
Prueba primero el proxy de forma aislada
No empieces dentro de ninguna herramienta de trabajo. Configura el proxy directamente en un navegador normal que admita proxy manual o en los ajustes de proxy del sistema y comprueba si puede acceder a Internet. Así separas el proxy del entorno de trabajo.
Si tampoco conecta allí, el problema está en el propio proxy: puede haber caducado, estar desactivado, tener un nodo de salida averiado o estar sujeto a restricciones del proveedor. En ese caso no hace falta seguir con los pasos posteriores; consulta directamente con el proveedor el estado y el uso del proxy.
Si allí funciona, el proxy está activo. El problema está en la configuración o en la ruta de conexión, así que continúa.
La regla es sencilla: si las mismas credenciales funcionan en otro lugar, probablemente las credenciales no son el problema.
Alinea la autenticación y el protocolo
Si las credenciales son correctas pero no hay conexión, el siguiente sospechoso es el protocolo. Hay tres desajustes habituales: el proveedor entrega SOCKS5 pero el entorno está configurado como HTTP; se ha creado un túnel SSH y el entorno lo trata como SOCKS5; o el proxy admite varios protocolos con puertos distintos y se ha introducido el puerto de otro protocolo.
Usa el texto del error como referencia. Si indica fallo de autenticación o credenciales incorrectas, revisa usuario y contraseña. Comprueba si al copiar y pegar se añadieron espacios o saltos de línea y si los caracteres especiales del nombre de usuario deben escaparse. Si indica un error de protocolo o de handshake, revisa el tipo de protocolo y el puerto.
En campos como usuario y contraseña, conviene escribirlos manualmente una vez para comparar. Los caracteres invisibles pueden causar fallos imposibles de detectar a simple vista.
Confirma que la configuración del cliente se ha aplicado
Este paso responde a una pregunta menos evidente: la configuración es correcta, pero ¿está realmente activa?
Hay dos casos frecuentes. Primero, la configuración nunca se aplicó: no se guardaron los cambios, se editó otro entorno o sigue ejecutándose la sesión anterior. Segundo, la configuración sí está activa, pero otro ajuste la sobrescribe: puede haber otro interruptor de red en el entorno, una extensión puede haberse apropiado del proxy o la configuración de proxy del sistema puede tener mayor prioridad.
La señal clave es la dirección de salida. Después de conectar, abre una página que muestre la dirección de salida actual. Debe aparecer la dirección del proxy, no la dirección local. Si sigue apareciendo la local, la solicitud no está pasando por el proxy, aunque el botón de prueba indique éxito.
La comparación es simple: en el mismo entorno, activa el proxy una vez y desactívalo otra, y comprueba si cambia la dirección de salida. Si no cambia, el problema está en el cliente. Si ejecutas varios entornos a la vez, verifica por separado la salida de cada uno. Las herramientas que aíslan entornos por cuenta, como PurpleMark, se fijan precisamente en esto al vincular proxies.
Identifica el rechazo del sitio de destino
Si todas las capas responden y el proxy está realmente activo, pero la página de trabajo sigue sin abrirse, observa la respuesta del sitio de destino en lugar de seguir cambiando el proxy.
Estos casos suelen tener patrones claros: la conexión y el handshake se completan, pero la solicitud devuelve 403 o se restablece; la página abre, pero acciones como iniciar sesión o publicar son rechazadas; la misma salida funciona en otros sitios y falla solo en uno; o los fallos son intermitentes, lo que puede indicar limitación de velocidad en la salida o la ruta, o límites de concurrencia.
La clave es separar la capa de conexión de la capa de negocio. Si no puedes conectar, el problema probablemente está en el proxy. Si conectas pero el sitio rechaza la solicitud, suelen influir la calidad de la salida o la frecuencia de acceso. Las IP de centros de datos y las IP compartidas muy reutilizadas tienen más probabilidades de ser bloqueadas en la capa de negocio. Las IP residenciales pueden funcionar mejor, pero no son un pase libre: la frecuencia de solicitudes, la concurrencia y el horario de acceso también afectan al resultado.
Mantén tres hábitos al diagnosticar
Cambia solo una cosa cada vez. Si cambias a la vez el protocolo y el nodo, aunque funcione no sabrás qué solucionó el problema y podrás repetir el mismo error más adelante.
Primero registra, luego ajusta. Guarda una configuración que sepas que funciona, con dirección, puerto, protocolo y método de autenticación. La próxima vez podrás compararla directamente, mucho más rápido que empezar desde cero.
Prefiere las pruebas comparativas a los reintentos continuos. Si la configuración parece correcta y aun así no conecta, pulsar repetidamente el botón de prueba no aporta información nueva. Es mejor probar otra red o un proxy distinto como comparación controlada.
