Que un proxy responda no basta. Antes de confiarle un robot de extracción, un seguimiento de posiciones o cuentas de clientes, tienes que saber qué IP muestra, desde qué país, a qué velocidad y si deja escapar tu dirección real por otro camino. Estas comprobaciones llevan unos minutos y te ahorran días de resultados falseados.

Este es el método, paso a paso, con las dos herramientas gratuitas de Airproxy (sin necesidad de cuenta) y unos cuantos comandos sencillos.

Comprobar la IP de salida y el país

Lo primero es ver la dirección que reciben realmente las webs. Configura el proxy en tu navegador o en el perfil correspondiente y abre Cuál es mi IP. La herramienta muestra la IP pública, el país, la ciudad, el operador, el ASN y la zona horaria. Fíjate en tres puntos:

  • La IP que aparece no es la tuya. Si ves la dirección de tu router o de tu servidor, el tráfico no pasa por el proxy: revisa la configuración con nuestra guía para configurar un proxy.
  • El país es el correcto. Debe coincidir con la ubicación que compraste y con tu objetivo.
  • El operador es coherente. En un proxy ISP, lo normal es ver un proveedor de acceso doméstico y no una empresa de alojamiento.

Las bases de geolocalización varían de un servicio a otro, sobre todo en la ciudad: consulta nuestra guía para elegir el país de un proxy.

Probar la disponibilidad, la latencia y la velocidad

El comprobador de proxies prueba un proxy HTTP, HTTPS o SOCKS5 sin tocar tu configuración. Pega el acceso con el formato ip:puerto:usuario:contraseña, elige el protocolo y lanza la prueba. Obtendrás:

  • la disponibilidad: ¿responde el proxy y acepta tus credenciales?
  • el ping: el tiempo que tarda en establecerse la conexión con el proxy;
  • la latencia: lo que tarda una petición HTTPS real en atravesar el proxy;
  • la IP de salida, la ubicación, el operador y el nivel de anonimato.

Estas mediciones se hacen desde el servidor de la herramienta. Te dicen si el proxy está en buen estado, pero la latencia que notarás depende también de la distancia entre tu máquina y el proxy, y luego entre el proxy y tu objetivo. Así que repite la prueba desde tu propia infraestructura, a distintas horas del día: una latencia estable vale más que una buena medición aislada.

Medir la velocidad de descarga

Descarga a través del proxy un archivo de tamaño conocido y deja que curl haga las cuentas:

curl -x "http://USUARIO:CONTRASEÑA@HOST:PUERTO" -s -o /dev/null \
  -w "connect: %{time_connect}s\nttfb: %{time_starttransfer}s\nspeed: %{speed_download} B/s\n" \
  https://example.com/archivo-prueba.bin

Aquí, connect mide la conexión con el proxy, ttfb la llegada del primer byte enviado por la web y speed la velocidad media en bytes por segundo. Elige un archivo alojado cerca de tu objetivo real y repite la medición, porque la velocidad varía con la carga de la red. Para integrar estas comprobaciones en tus scripts, consulta nuestra guía para usar un proxy en Python, Node.js y curl.

Entender los niveles de anonimato

Un proxy HTTP puede añadir cabeceras a tus peticiones. Dos de ellas delatan su presencia: Via, que indica que un intermediario ha reenviado la petición, y X-Forwarded-For, que puede transmitir la dirección original del cliente. Según lo que añada el proxy, se distinguen tres niveles.

NivelLo que ve la webPara un uso profesional
TransparenteTu IP real, transmitida en X-Forwarded-ForDescartado
AnónimoLa IP del proxy, pero una cabecera como Via delata a un intermediarioAceptable para tareas sencillas
ÉliteLa IP del proxy, sin ninguna cabecera reveladoraRecomendado

El comprobador de proxies deduce este nivel automáticamente: llama a una página que devuelve las cabeceras recibidas y mira lo que ha añadido el proxy. En SOCKS5, el proxy reenvía la conexión sin reescribir tus cabeceras HTTP, así que lo que recibe la web depende de tu programa. Eso sí, un proxy élite no oculta el resto de tu huella: las cookies, el idioma, la zona horaria y WebRTC hay que controlarlos aparte.

Detectar fugas de DNS y WebRTC

Una fuga es información que sale por un camino distinto del proxy. Las dos más habituales tienen que ver con el DNS y con WebRTC.

Las fugas de DNS

Antes de conectarse a una web, tu programa tiene que traducir su nombre a una dirección IP. Si esa resolución se hace en tu máquina, tu servidor DNS habitual, a menudo el de tu operador o el de tu proveedor de alojamiento, ve pasar la lista de dominios que visitas. La web no ve tu IP, pero esa información sale sin pasar por el proxy, y la ubicación del servidor DNS puede contradecir la de la IP.

Con un proxy HTTP(S), el nombre de la web suele enviarse al proxy, que lo resuelve él mismo. En SOCKS5, todo depende del cliente: hay que pedir la resolución remota. Con curl y muchas bibliotecas, de eso se encarga el esquema socks5h:// (la «h» viene de hostname); con socks5://, el nombre se resuelve en local.

curl -x "socks5h://USUARIO:CONTRASEÑA@HOST:PUERTO" https://example.com

En Firefox, la opción que deja el DNS en manos del proxy SOCKS v5 está en la configuración de conexión (preferencia network.proxy.socks_remote_dns). Para comprobarlo, abre a través del proxy una página de prueba de fugas de DNS: muestra los servidores DNS que la han consultado. Si aparece el de tu operador, la resolución sigue haciéndose en local. Nuestra guía proxy HTTP o SOCKS5 explica en detalle las diferencias entre los dos protocolos.

Las fugas de WebRTC

WebRTC permite a los navegadores establecer llamadas de audio y vídeo directas. Para encontrar el mejor camino, consulta servidores externos por UDP, un tráfico que la mayoría de los proxies no reenvía. Así, una página puede descubrir tu IP pública real aunque toda la navegación pase por el proxy. Los navegadores recientes ocultan las direcciones de la red local, pero no necesariamente la IP pública.

Abre a través del proxy una página de prueba de WebRTC: si aparece tu IP real, hay una fuga. Para limitarla:

  • en Firefox, desactiva WebRTC con la preferencia media.peerconnection.enabled de about:config;
  • en los navegadores basados en Chromium, la política WebRtcIPHandling configurada como disable_non_proxied_udp impide que WebRTC use UDP fuera del proxy;
  • en un navegador con varios perfiles, revisa el ajuste de WebRTC de cada perfil y repite la prueba después de cada actualización.

Comprobar la reputación de la IP

Una IP puede funcionar perfectamente y tener mala fama. Si una dirección se ha usado para enviar spam o cometer abusos, puede figurar en listas de bloqueo, y algunas webs le imponen CAPTCHA o la rechazan.

  • Consulta las listas de bloqueo públicas. Hay servicios de consulta gratuitos que indican si una dirección figura en listas DNSBL. Estas listas se centran sobre todo en el correo electrónico: una IP listada no está necesariamente bloqueada por tu objetivo, y una IP que no aparece en ellas no tiene por qué ser bien recibida.
  • Comprueba el ASN. La herramienta Cuál es mi IP muestra el operador y el ASN: un rango de proveedor de alojamiento se filtra más a menudo que uno de operador doméstico.
  • Haz una prueba real. Unas cuantas peticiones manuales a tu objetivo dicen más que cualquier lista: ¿página normal, CAPTCHA sistemático, error 403 o 429?

Con una IP dedicada, la reputación solo depende de tu uso: no heredas el comportamiento de otros usuarios. Es uno de los argumentos de nuestra comparativa proxy dedicado o compartido.

Lista de comprobación antes de pasar a producción

  1. La IP de salida no es la tuya y está en el país esperado.
  2. El operador que aparece corresponde al tipo de proxy que compraste.
  3. El proxy responde en el protocolo que vas a usar (HTTP, HTTPS o SOCKS5), con tus credenciales.
  4. El nivel de anonimato es «élite».
  5. La latencia se mantiene estable en varias mediciones hechas desde tu infraestructura, y la velocidad basta para el volumen previsto.
  6. Ninguna fuga de DNS (resolución remota en SOCKS5 con socks5h://) ni de WebRTC en los perfiles de navegador.
  7. La zona horaria y el idioma de los perfiles corresponden al país de la IP.
  8. La IP no provoca bloqueos sistemáticos en tu objetivo.
  9. Tu uso respeta las condiciones de las webs visitadas, su robots.txt y el RGPD.
En resumen: comprueba la IP y el país, mide la latencia y la velocidad desde tu infraestructura, exige un nivel élite, cierra las fugas de DNS y WebRTC y, por último, controla la reputación en tu objetivo real. Un proxy que supera estos pasos está listo para producción.

Los proxies ISP dedicados de Airproxy se entregan con el formato host:puerto:usuario:contraseña, con el mismo acceso en HTTP(S) y en SOCKS5, así que puedes recorrer esta lista en cuanto los recibas. Las ubicaciones disponibles están en la página de ofertas.

Preguntas frecuentes

¿Qué diferencia hay entre el ping y la latencia del comprobador?

El ping solo mide el establecimiento de la conexión con el proxy. La latencia mide una petición completa que atraviesa el proxy hasta una web: es más alta y se parece más a lo que van a encontrarse tus herramientas.

¿Un proxy SOCKS5 es más anónimo que un proxy HTTP?

No por sí mismo. SOCKS5 reenvía la conexión sin modificar tus cabeceras, pero hay que activar la resolución DNS remota, y ninguno de los dos te protege frente a WebRTC o las cookies.

¿Por qué aparece mi IP real a pesar del proxy?

Las causas más frecuentes son un programa que no pasa por el proxy, una fuga de WebRTC o una extensión que se salta tus ajustes. Comprueba la IP desde el programa en cuestión y después haz la prueba de WebRTC.

¿Cada cuánto hay que probar los proxies?

Al recibirlos, antes de cada paso a producción y después con regularidad. Lo más sencillo es automatizar en tus scripts una comprobación de la IP de salida y de la latencia.