Cómo detectar VPN y proxy sin API key

En pocas palabras: Con curl iplogs.com/{ip} detectás VPN, proxy, Tor y datacenters sin API key: la herramienta gratuita de Jamil Haider devuelve verdict, score de 0 a 1 y banderas is_vpn, is_proxy, is_tor e is_relay, con 2.000 checks diarios gratis.

Ejemplo hipotético (a modo ilustrativo): imaginate que a tu SaaS le llega un signup nuevo, el email parece legítimo, pero la IP viene de un datacenter en Albania y en el mismo minuto activa el trial premium. Con una sola llamada HTTP sin API key podés chequear esa IP antes de habilitar nada costoso: IPLogs devuelve un verdict, un score de 0 a 1 y banderas separadas para VPN, proxy, Tor y datacenter.

IPLogs es un servicio gratuito que identifica si una dirección IPv4 o IPv6 pertenece a una VPN, un proxy, un nodo de Tor, una red de datacenter o un relay de privacidad como iCloud Private Relay. Lo construyó Jamil Haider y lo documentó en su artículo en dev.to, publicado el 5 de noviembre de 2026; no pide registro ni clave de API.

¿Una VPN es prueba de fraude en un registro?

No. Una VPN sola no prueba nada. Mucha gente real la usa para laburar, para evitar geobloqueos o porque le preocupa su privacidad, y eso no la convierte en sospechosa automáticamente.

El punto, según la fuente de dev.to, es otro: las cuentas falsas, el abuso de free-trial y el spam de registros suelen salir de VPN, proxies o servidores cloud. Eso no te da certeza sobre una persona puntual, pero sí te da una señal barata para mirar antes de dejar que una cuenta recién creada haga algo que te cuesta plata, como activar un trial premium o procesar un pago. La clave está en no tratar el dato de forma aislada: una IP de datacenter en un signup que solo pide leer un artículo gratuito pesa distinto que la misma IP en un signup que dispara 30 días de plan pago sin tarjeta.

¿Cómo detectar VPN y proxy con una sola llamada HTTP?

Se hace con un curl a la IP que querés chequear, sin headers, sin token, sin cuenta previa. curl iplogs.com/45.142.26.2 te devuelve JSON al instante con el verdict de esa dirección.

La respuesta trae, entre otros campos, "verdict": "vpn_detected", "score": 1, "is_vpn": true, "vpn_provider": "Mullvad" y el ASN con la organización detrás (en ese ejemplo, “Keminet SHPK” en Albania). Para producción, el mismo lookup se hace vía POST https://iplogs.com/v1/check mandando el JSON {"ip":"..."}. ¿Necesitás chequear otra dirección en vez de la tuya? Agregás la IP después de la barra, como en curl iplogs.com/8.8.8.8, y listo.

¿Qué significan el verdict, el score y las señales de la respuesta JSON?

El verdict es una etiqueta que resume el score: clean por debajo de 0,30, suspicious por debajo de 0,60, vpn_likely por debajo de 0,85 y vpn_detected por encima de eso. El score no es una probabilidad, es la suma de los pesos de cada señal que coincidió, hasta tope 1.

Según la documentación de IPLogs, siete capas alimentan ese número: inteligencia de IP, fingerprint TCP/IP, fingerprint TLS, timing de ida y vuelta, probing activo, señales del navegador y sanidad de puertos y red. Las señales fuertes (un servidor VPN confirmado, un exit de Tor, un proxy abierto) pesan más que las débiles (estar en un datacenter, tener routing raro). El campo signals lista cada chequeo que matcheó, con su tipo y su peso, así que podés ver la evidencia en vez de confiar en un número opaco. Esto es lo que permite armar una tabla base de acciones según el rango de score:

Score	Nivel	Acción sugerida
0 a 29	Clean	Dejar pasar el registro.
30 a 59	Suspicious	Dejar pasar; agregar fricción solo en acciones sensibles.
60 a 84	Likely VPN	Desafiar: verificar email o teléfono, o exigir login. Con relays de privacidad, preferir un desafío liviano.
85 a 100	VPN detected	Desafiar o bloquear, según tu política sobre VPN y Tor.

Un criterio propio para calibrar la fricción: score más costo de la acción

La tabla de arriba toma un solo eje: el score. En la práctica conviene cruzarla con un segundo eje que la fuente no desarrolla en detalle: cuánto le cuesta a tu negocio que esa cuenta se equivoque de lado, es decir, qué tan cara es la acción que el usuario está a punto de hacer. No es lo mismo un score de 65 en alguien que va a comentar un artículo que el mismo score en alguien que va a activar 14 días de plan enterprise sin tarjeta.

Una forma simple de ordenar esa decisión, pensando el score de IPLogs junto con el costo de la acción, es esta matriz:

Acción del usuario	Score 0–59 (clean/suspicious)	Score 60–100 (likely/detected)
Leer contenido, navegar, comentar	Dejar pasar sin fricción.	Dejar pasar; como mucho, loguear para revisión posterior en bulk.
Crear cuenta gratis, newsletter	Dejar pasar.	Challenge liviano: confirmar email antes de activar la cuenta.
Activar trial pago, promo con costo real	Dejar pasar; registrar el score por si hay abuso en cadena.	Challenge fuerte (teléfono, tarjeta sin cobro, revisión manual) antes de habilitar el beneficio.
Mover plata, cambiar datos de cobro	Fricción estándar de seguridad, igual que cualquier otro acceso.	Bloquear la acción puntual y pedir verificación adicional, no solo un CAPTCHA.

La lógica detrás de esta matriz es la misma que explica por qué la fuente insiste en “fail open” y en is_relay aparte: el costo de frenar a un usuario real (falso positivo) no es simétrico con el costo de dejar pasar a un abusador (falso negativo), y esa asimetría cambia según qué botón está apretando la persona. Cuanto más cara la acción, más vale la pena tolerar fricción extra aunque eso moleste a algún usuario legítimo de VPN; cuanto más barata, más vale la pena priorizar que nadie real se quede afuera.

¿Cómo integrar la verificación de IP en el flujo de signup?

Se integra como un chequeo asincrónico antes de habilitar la cuenta, no como un bloqueo duro. La fuente propone una función checkSignupIp(ip) que llama a https://iplogs.com/v1/check/{ip} y, si la respuesta falla, devuelve { review: false }: fail open.

Hay dos decisiones de diseño que vale la pena tomar a propósito. Fail open significa que si el lookup está lento o caído, dejás entrar el signup y lo revisás después, porque un check roto no tiene que trabar a un usuario real. Flag, don’t ban significa que un registro riesgoso (is_vpn, is_proxy, is_tor o is_hosting en true) no se rechaza directo, se manda a email verification, a un CAPTCHA o a revisión manual. Lo interesante es que is_relay viene separado de esas banderas, así que podés dejar pasar a los usuarios de iCloud Private Relay mientras seguís marcando VPN y datacenters.

¿Conviene bloquear o solo marcar los registros sospechosos?

Conviene marcar, no bloquear directo. Rechazar un registro solo porque usa VPN te va a sacar usuarios reales del medio: periodistas, gente que labura remoto desde otro país, usuarios corporativos atrás de un gateway como Zscaler.

¿Y si ignorás la VPN directamente? Ahí te comés el fraude de free-trial que la fuente menciona como caso típico. La solución intermedia es la que propone el artículo: usar el score para decidir el nivel de fricción, no el acceso. Aplicando la matriz de más arriba, un score de 85 con is_hosting: true en un signup de trial pago amerita CAPTCHA o verificación de teléfono porque la acción tiene costo real; ese mismo score en un usuario que solo quiere leer contenido público probablemente no justifica ningún freno, porque ahí el costo de equivocarse con un usuario legítimo pesa más que el riesgo de dejar pasar a alguien que, en el peor caso, solo va a mirar una página.

¿Cómo revisar en bloque las IPs de cuentas que ya existen?

Se hace pegando un log o un export de usuarios en la página bulk de IPLogs. La herramienta extrae las direcciones IPv4 e IPv6 del texto solita, revisa hasta 1.000 por corrida y te deja copiar el resultado como CSV o JSON.

Las direcciones privadas (10.x, 192.168.x, loopback) se saltean automáticamente, y solo se envían las IPs, no el resto del archivo. Vía API, el endpoint /v1/bulk-check toma 100 direcciones por llamada, con hasta tres llamadas en ráfaga y después una cada 5 segundos, así que una base grande se procesa en lotes. Vale la pena pensar este chequeo masivo como un ejercicio periódico y no como algo que se corre una sola vez: una IP que hoy puntúa limpia puede pasar a ser un servidor VPN la semana que viene, y al revés, por eso la caché de 30 minutos que documenta IPLogs solo cubre el corto plazo, no sustituye una revisión recurrente de la base.

¿Qué no puede detectar esta verificación de IP?

No puede decirte quién está atrás de la dirección ni qué intención tiene. Detecta si la IP se parece a una VPN, un proxy, un exit de Tor o un datacenter, nada más.

Los resultados son evidencia, no prueba. Hay que mirarlos junto a otras señales (antigüedad del email, dispositivo, comportamiento), no en lugar de ellas. El plan gratis tiene techo: 60 requests por minuto y 2.000 checks completos por día por IP que llama, sin plan pago ni SLA. ¿Pasaste ese límite? Las respuestas siguen llegando con código 200, pero desde el “fast path”, sin probing en vivo, así que un servidor recién levantado puede puntuar más bajo de lo que debería.

Errores comunes al filtrar signups por VPN

• Bloquear directo con score alto. Un score de 85 no significa fraude confirmado, significa evidencia fuerte de VPN. Bloquear sin challenge previo te saca usuarios legítimos del sistema, sobre todo si la acción que están intentando es barata para tu negocio.
• Tratar iCloud Private Relay como VPN comercial. Apple explica en su soporte oficial que Private Relay enruta el tráfico por dos relays separados para proteger la privacidad en Safari, pero el usuario detrás suele ser un cliente normal de iCloud+, no un atacante. Si no chequeás is_relay antes de actuar, le metés fricción de más a gente que solo activó una opción de privacidad.
• No manejar el error de lookup. Si tu código no tiene un “fail open” explícito, un timeout de la API (el límite es 30 segundos por check completo) te puede trabar signups enteros en producción.
• Confundir ausencia de vpn_provider con resultado limpio. Muchas detecciones vienen de rangos sin operador identificado; hay que decidir según verdict o is_vpn, tratando vpn_provider solo como una etiqueta informativa.
• Aplicar el mismo umbral a toda acción. Usar un único punto de corte de score para decisiones tan distintas como “comentar” y “mover plata” ignora que el costo de un falso positivo no es el mismo en los dos casos.

Preguntas Frecuentes

¿Cómo saber si un registro viene de una VPN o un proxy?

Mandás la IP del registro a curl iplogs.com/{ip} y la respuesta JSON te da is_vpn, is_proxy y un score de 0 a 1, sin necesidad de API key ni cuenta previa.

¿Qué es iCloud Private Relay y cómo se diferencia de una VPN?

Es una función de iCloud+ que enruta el tráfico de Safari por dos relays separados, uno de Apple y otro de un proveedor externo, para que nadie vea a la vez quién sos y qué sitio visitás, según el soporte oficial de Apple. A nivel técnico puntúa parecido a una VPN, pero IPLogs lo marca aparte con is_relay porque la mayoría de esos usuarios son clientes comunes, no atacantes.

¿Cómo bloquear cuentas falsas creadas con VPN sin afectar a usuarios reales?

No bloqueando directo: la recomendación de la fuente es mandar los registros con score alto a un paso extra, como verificación de email, CAPTCHA o revisión manual, en vez de rechazarlos. Combinando eso con el costo de la acción que la cuenta está intentando hacer (ver la matriz más arriba) filtrás el abuso de free-trial sin trabar a la gente que usa VPN por motivos legítimos.

¿Qué significa el score de riesgo en una API de detección de VPN?

Es un número de 0 a 1 que suma el peso de cada señal detectada (VPN confirmada, exit de Tor, proxy abierto, datacenter, routing raro), no una probabilidad estadística. Cuanto más alto, más evidencia hay de que la IP pertenece a una red de VPN, proxy o Tor.

¿Conviene rechazar directamente un registro si viene de una VPN?

No, conviene marcarlo y agregar fricción proporcional al score y al costo de la acción, no rechazarlo de entrada. Una VPN sola no prueba fraude, así que bloquear sin challenge previo corre el riesgo de perder usuarios reales que simplemente valoran su privacidad.

Conclusión

Lo que cambia con esta herramienta no es la idea de chequear IPs, eso existe hace años. Lo que cambia es la barrera de entrada: sin API key, sin registro, con un límite gratuito de 2.000 checks diarios, cualquiera que mantenga un sistema de signups puede sumar esta señal en una tarde. Si administrás un producto con trials o cuentas gratis, el criterio práctico que proponemos en este artículo es combinar dos ejes, no uno solo: el score que devuelve IPLogs y el costo real de la acción que la cuenta está a punto de hacer. Corré los últimos 100 registros por la página bulk, mirá cuántos puntúan arriba de 60, y después de eso preguntate qué estaban a punto de hacer esas cuentas antes de decidir si les metés fricción. Eso es un experimento que podés hacer hoy mismo, no una promesa a futuro.

Fuentes

• Apple Support – About iCloud Private Relay (documentación oficial)
• dev.to – How to flag VPN and proxy signups with one HTTP call (no API key)
• IPLogs – Documentación de la API gratuita de detección de VPN y proxy