Cómo comprobar si un proxy funciona (y si filtra tu IP)

Un proxy puede responder y aun así filtrar tu IP real. Comprueba la salida, DNS, WebRTC, el protocolo y las blocklists antes de poner el endpoint en producción.

Cómo comprobar si un proxy funciona (y si filtra tu IP)

Que un proxy “funcione” significa dos cosas distintas. El gateway tiene que aceptar tu cliente y cargar una página. El resto de tu dispositivo también tiene que dejar de exponer la IP real. Muchos endpoints pasan el primer test y fallan el segundo.

Haz esta comprobación antes de escalar un plan. Hazla otra vez después de rotar. Los pools cambian. El firmware del navegador del teléfono cambia. Un test que pasó ayer no es un contrato.

01Confirma primero la IP de salida#

Apunta un cliente simple al proxy. Usa el mismo protocolo y la misma autenticación que vas a usar en producción. Luego pide una página que devuelva la IP del cliente.

El comprobador de proxy es el atajo para ese primer hop. Te dice si el endpoint responde, qué protocolo habló y qué IP vio el destino. Si este paso falla, para. Las fugas de DNS no importan en un gateway muerto.

Abre Mi IP a través del mismo proxy. Lee el país, el ASN y la etiqueta hosting versus residencial si la página muestra una. Compáralo con lo que compraste. Un producto “residencial de EE. UU.” que sale en un ASN de nube es el producto equivocado, no un problema de ajustes.

Repite la consulta después de rotar. Un pool mixto puede darte otro país en el siguiente session id. Si pagaste por proxies de EE. UU., la segunda muestra debería seguir en Estados Unidos.

02Busca fugas alrededor del proxy#

Un proxy solo cubre el tráfico que tu cliente envía por él. Todo lo demás puede seguir usando tu red real.

DNS es la fuga habitual. El navegador pregunta el nombre a tu ISP antes de que el proxy vea la URL. Fuerza el DNS a través del proxy o de un resolver que hayas elegido. Luego carga una página de test de fuga DNS con el proxy activo. Los resolvers que ves no deben ser tu ISP de casa.

WebRTC es la fuga específica del navegador. Algunos navegadores abren una conexión peer que revela una dirección local o pública aunque el HTTP vaya por el proxy. Desactiva WebRTC en ese perfil, o usa una herramienta que muestre las direcciones candidate. Si un candidate es tu IP pública real, el perfil no es seguro para trabajo con cuentas.

IPv6 es la fuga silenciosa. Enviaste IPv4 por el proxy y el sistema operativo todavía tiene una dirección IPv6 global. Los sitios que prefieren v6 se saltan el proxy. Desactiva IPv6 en ese perfil o usa un proxy dual-stack que hayas probado de verdad en una página de eco v6.

Las aplicaciones pueden saltarse el proxy del sistema. Una app nativa puede ignorar el ajuste del SO e ir directo. Prueba la app, no solo el navegador. SOCKS5 en la capa de la app suele ser la única vía fiable. Mira SOCKS5 vs HTTP si el cliente ofrece los dos.

03Comprueba la reputación, no solo el alcance#

Una IP puede cargar una página y seguir siendo inútil para tu trabajo. Flags de hosting, blocklists y abuso previo viven en la dirección.

Si la tarea es correo, registro o cualquier cosa que otra gente ya haya quemado, pasa la salida por la lista negra de IP. Un listing es una advertencia. No es un juicio moral. Los pools residenciales compartidos acumulan listings. Las IPs dedicadas de datacenter también.

Si la tarea es scraping, pide la URL de destino real, no solo un servicio de eco. Algunos hosts dejan pasar https://httpbin.org y aun así bloquean tu página de catálogo. Guarda el código de estado, la longitud del body y si apareció un challenge. Esa es la única puntuación que importa.

Si la tarea es QA geo, compara la página que querías con la que obtuviste. La moneda, el idioma y el catálogo deben coincidir con el país que compraste. Un ASN correcto con el storefront equivocado significa que el sitio usa otra señal.

04Haz que la comprobación sea repetible#

Anota los pasos. El mismo cliente, la misma autenticación, la misma URL de eco, la misma URL de destino, las mismas páginas de fuga. Ejecútalos cuando compres. Ejecútalos cuando rotes. Ejecútalos cuando un job empiece a fallar.

Registra la IP de salida, el ASN, el protocolo y si DNS o WebRTC mostró tu dirección real. Cuando un proveedor cambie un puerto, sabrás qué cambió.

No te saltes errores de autenticación. Usuario y contraseña en el campo equivocado parecen un proxy muerto. La autenticación por IP-allowlist parece un proxy muerto desde una red de oficina nueva. Corrige la autenticación antes de abrir un ticket.

Un proxy que responde, sale en el país correcto, oculta tu IP real y devuelve la página de destino está funcionando. Cualquier cosa por debajo es un aprobado parcial. Déjalo fuera de producción hasta que cierre la parte que falta.