Ante un fallo del proxy, diagnostica en tres capas: comprueba primero si cambió la IP y si la ubicación de salida es correcta, distingue después DNS, tiempos de espera y certificados, y revisa por último autenticación, puerto y protocolo.
El proxy está configurado y el usuario y la contraseña son correctos, pero la comprobación sigue indicando que la conexión ha fallado. Mucha gente contacta de inmediato con el proveedor, cambia de nodo, modifica el puerto o insiste al soporte. Suele ser poco eficiente, porque la causa puede estar en cualquier punto de toda la ruta de conexión y el proxy es solo una parte.
En vez de probar cambios al azar, conviene seguir siempre un orden de fuera hacia dentro: primero confirmar que la salida realmente está activa, después comprobar si la ruta de red funciona y solo entonces revisar la autenticación y el protocolo en la capa de aplicación. Con estas tres capas se puede localizar la mayoría de los problemas.
¿La salida está realmente activa?
Este paso se omite con facilidad porque la configuración parece correcta. Pero que la configuración se guarde bien y que el tráfico pase de verdad por el proxy son cosas distintas.
Comprueba dos puntos. Primero, si cambió la IP: anota la IP pública sin proxy, actívalo y vuelve a comprobarla. Si ambas son iguales, el tráfico no está saliendo por el proxy y seguir investigando no servirá de mucho. Segundo, si la ubicación es correcta: los datos del proxy suelen incluir país, región, estado o provincia, ciudad, coordenadas con seis decimales y código postal. Compáralos con la región adquirida. Una zona horaria del sistema que no encaje claramente con la región de salida también es una señal de riesgo.
Cuando la salida no se aplica, la causa suele estar en ajustes locales residuales y no en el proveedor. Si una herramienta de red usada anteriormente no se cerró limpiamente, pueden quedar variables de entorno como HTTP_PROXY o HTTPS_PROXY en el sistema, o seguir activos los interruptores de proxy web o SOCKS en macOS. En ese caso, el cliente puede creer que usa el proxy del sistema mientras las solicitudes lo evitan. Limpiar esos restos y volver a probar suele ser más útil que configurar de nuevo todo el proxy.
Tres errores comunes en la ruta de red
Confirmada la salida, el siguiente paso es comprobar si la solicitud llega realmente al destino.
La resolución DNS es el primer punto donde puede fallar. Puede aparecer un error de resolución o un resultado claramente incorrecto, por ejemplo cuando un dominio que debería apuntar al servicio de destino termina resolviendo a una dirección extraña. Prueba con un DNS público o limpia la caché DNS local y comprueba si se recupera.
El segundo tipo es el tiempo de espera de conexión. Si un cortafuegos o un programa de seguridad bloquea el puerto, la solicitud puede quedarse cargando hasta agotar el tiempo. Comprueba las reglas de apertura del puerto y si el propio entorno, como una red corporativa o una Wi-Fi pública, impone restricciones. Hay una prueba rápida: conecta directamente sin proxy. Si tampoco puedes abrir ningún sitio web, el problema está en la red básica, no en el proxy. Reiniciar el router o cambiar a un punto de acceso móvil permite confirmarlo.
Los errores de certificado merecen atención aparte. Ante mensajes de certificado no confiable o fallo del handshake, es habitual sospechar que el tráfico se está descifrando o que el certificado ha sido sustituido. Puede ocurrir, pero existe otra causa menos visible: una hora local incorrecta. Muchos mecanismos de autenticación y sesión dependen de marcas de tiempo. Si la hora local difiere de la del servidor en más de 5 minutos, la validación de firma puede fallar y la conexión ser rechazada; sobre HTTPS se manifiesta como un fallo de validación del certificado. Al ver un error de certificado, revisa también la sincronización horaria del sistema. Si es anómala, activa la sincronización automática, corrige la hora de inmediato, reinicia el cliente y vuelve a probar.
No confundas autenticación y protocolo
Si se puede llegar al servidor proxy pero el tráfico sigue sin funcionar, el problema suele estar en la capa de aplicación.
Lo más común son los datos de autenticación. El usuario, la contraseña y el método de autenticación deben coincidir con los proporcionados por el proveedor; también es frecuente cambiar la contraseña y no actualizarla en la configuración. En modo manual, confirma además que el puerto introducido coincide con el puerto en el que escucha la propia herramienta proxy. Los números pueden parecerse, pero un puerto incorrecto impide por completo la conexión.
La segunda categoría es un protocolo incorrecto. HTTP, HTTPS y SOCKS5 no son intercambiables: si el proveedor te da SOCKS5 y configuras HTTP, la comprobación fallará. Confirma también que el proxy permite acceder al sitio y al puerto de destino, ya que algunos proxies restringen destinos o protocolos.
La forma más rápida de diferenciar un problema del nodo de uno de configuración es probar otro nodo. Si el nuevo funciona, el problema está en el nodo original. Si también falla, vuelve a revisar la configuración y la ruta de red. No cambies varios parámetros a la vez: modifica una sola variable y anota el resultado, o tus propios cambios pueden ocultar la causa real.
Estar conectado no significa que el entorno sea utilizable
Hay otra trampa habitual. El proxy puede mostrar una conexión normal y, aun así, la cuenta activar controles de riesgo con frecuencia. El problema puede no ser si conecta, sino si esa salida parece corresponder a un usuario normal.
Comprueba de nuevo los puntos básicos: si la ubicación de salida coincide con la región de registro de la cuenta; si el tipo de IP es razonable, porque las plataformas pueden tratar de forma distinta las IP de centro de datos y las residenciales; y si esa IP ya había sido marcada por el sitio de destino. Si una misma IP se usó antes para mucha actividad anómala, los usuarios posteriores pueden verse afectados. Tras superar la prueba de conexión, dedica unos minutos a comprobar también la limpieza de la salida.
Si un dispositivo ejecuta varios entornos, conviene asignar las salidas uno a uno: cada entorno con su propia salida. Así los problemas se aíslan por separado y, si una salida es marcada, solo afecta al entorno correspondiente en vez de interrumpirlos todos. PurpleMark configura y aísla las salidas por entorno en su gestión multi-entorno precisamente con esta lógica.
Estos métodos de diagnóstico se ofrecen únicamente para intercambio técnico. Utiliza las herramientas y servicios relacionados solo de conformidad con las leyes y normas aplicables.
