Cómo funciona de verdad la detección de VPN y proxies, señal por señal
Cómo funciona la detección de VPN en la práctica: las señales detrás de la detección moderna de VPN y proxies, desde listas de proveedores y análisis de ASN hasta el sondeo de protocolos.

Todos los equipos de fraude, abuso y cumplimiento acaban haciéndose la misma pregunta: ¿esta dirección IP está ocultando algo? (Si antes quieres lo básico, empieza por qué es una VPN y cómo detectar tráfico VPN. Este artículo profundiza en la maquinaria). La respuesta honesta es que ninguna comprobación aislada puede decírtelo. Una VPN comercial, un proxy SOCKS de datacenter, un proxy residencial alquilado a una botnet y un nodo de salida de Tor se ven distintos en la red (el desglose de tipos de proxy cubre cada familia), y cada uno burla un método de detección ingenuo distinto.
Esta guía recorre las señales en las que se apoyan los sistemas de detección de nivel de producción, incluidas dos (las comprobaciones de latencia y el modelado de comportamiento) que GeoIPHub no utiliza. GeoIPHub construye sus propios veredictos a partir de siete familias de métodos de verificación que cubren el mismo terreno. Para cada capa verás qué puede ver y qué no, y cómo se combinan los resultados en los campos de respuesta que realmente usas: is_vpn, is_proxy, is_residential_proxy e is_tor.

Listas de servidores de los proveedores
La evidencia más fiable es la más directa: los proveedores de VPN publican su infraestructura de servidores. Las aplicaciones necesitan listas de endpoints para conectarse, y muchos proveedores exponen API oficiales o paquetes de configuración con el hostname y la IP de cada servidor.
Los sistemas de detección rastrean estas fuentes de forma continua. Cuando una IP aparece en la lista publicada de servidores de NordVPN o de Mullvad, la coincidencia nombra al proveedor, pero solo cuando esa IP exacta está en una lista que tenemos. Un servidor que falta en las listas aún puede ser detectado por las señales de abajo y quedarse sin nombre. Por eso una buena API puede devolver no solo is_vpn: true sino el propio nombre del proveedor, y por eso a veces no devuelve ningún nombre para un servidor que ha marcado.
La limitación es la cobertura. Las listas publicadas solo atrapan a los proveedores que publican, lo que significa que esta capa es más fuerte para las grandes VPN comerciales, que concentran la mayor parte del tráfico VPN de consumo, y más débil para las VPN privadas o autoalojadas.
ASN e infraestructura de hosting
Cada IP pertenece a un Sistema Autónomo (AS), la red que la anuncia en internet. El ASN te dice quién opera la red, y eso es una probabilidad previa muy potente:
- Una IP anunciada por AS396982 (Google Cloud) es casi con certeza un servidor, no una persona en el sofá.
- Una IP anunciada por un ISP residencial (Comcast, Deutsche Telekom, Jio) es probablemente una conexión de usuario final.
- Un ASN de hosting o de colocation veterano con un historial de endpoints VPN eleva la probabilidad previa de cada IP de sus rangos.
La detección de datacenter por sí sola atrapa una parte enorme de las VPN y los proxies, porque la mayor parte de la infraestructura de anonimización alquila servidores en la nube. Pero no puede distinguir un endpoint VPN de un servidor web corriente. Para eso hace falta la siguiente capa.
Sondeo activo de protocolos
Esta es la capa que la mayoría de las bases de datos de consulta se saltan, y es la diferencia entre adivinar y verificar. Un servidor VPN tiene que responder a handshakes de protocolos VPN; ese es su trabajo. Así que un sistema de detección puede llamar a la puerta y ver quién contesta:
- OpenVPN responde a un handshake TLS o UDP característico en su puerto de escucha.
- IKEv2/IPsec responde en UDP 500/4500 con payloads identificables.
- PPTP y L2TP contestan a sus solicitudes del canal de control.
- Los proxies SOCKS5 y HTTP completan sus respectivas secuencias de saludo.
WireGuard es la excepción: un servidor permanece en silencio a menos que el primer mensaje venga de una clave que ya conoce, así que ningún sondeo externo puede confirmarlo. El método wireguard_open de GeoIPHub proviene de que la lista de servidores publicada por el proveedor marca ese servidor como WireGuard, no de un handshake.
Si una IP completa un handshake de OpenVPN, está ejecutando OpenVPN. No hace falta inferencia estadística. GeoIPHub sondea 8 protocolos y registra exactamente qué handshake tuvo éxito, de modo que la evidencia detrás de is_vpn tiene nombre y se puede auditar.
curl -H "x-api-key: YOUR_API_KEY" \
https://api.geoiphub.com/v1/lookup/102.129.235.17
{
"ip": "102.129.235.17",
"asn": {
"asn": 834,
"org": "IPXO - IPXO LLC",
"asn_type": "vpn",
"connection_type": "datacenter"
},
"detection": {
"is_vpn": true,
"is_proxy": false,
"is_tor": false,
"is_anonymous": true,
"vpn_provider": "none",
"vpn_confidence": 100
},
"scoring": {
"fraud_score": 92,
"recommended_action": "block",
"detection_methods": ["known_vpn_server", "openvpn_open", "ipsec_open"]
}
}
Aquí openvpn_open e ipsec_open en detection_methods registran que esta dirección respondió a sondeos de OpenVPN e IPsec, junto con una coincidencia con datos de servidores VPN conocidos. vpn_provider es "none" en este caso, así que no se atribuye ninguna marca; el veredicto está respaldado por evidencia de protocolo con nombre y no por una etiqueta de proveedor.
El sondeo activo tiene un coste: requiere infraestructura y tiempo, y por eso se ejecuta continuamente en segundo plano y no en cada solicitud. Los resultados de los sondeos se almacenan en caché y se refrescan para que la API pueda responder en milisegundos.
Huellas de puertos y servicios
Incluso cuando no es posible un handshake completo, la forma de los servicios abiertos de una IP es informativa. Una conexión residencial normalmente no expone nada. Un endpoint VPN expone un conjunto pequeño y característico de puertos. Una granja de proxies expone paneles de gestión, SSH y puertos de proxy a lo largo de subredes enteras.
La identificación de servicios también atrapa anonimizadores mal configurados o sin marca: un servidor que responde en TCP 1080 con un banner SOCKS es un proxy, lo diga o no alguna lista.
Coherencia de latencia y ubicación
La geografía deja huellas en la física. Si una IP afirma (según sus datos de registro) estar en São Paulo, pero sus tiempos de ida y vuelta desde puntos de observación globales triangulan hacia Ámsterdam, algo está retransmitiendo el tráfico. Las comprobaciones basadas en latencia son especialmente útiles contra:
- Servidores VPN con geolocalización falseada: proveedores que anuncian servidores en "Brasil" que físicamente están en Miami.
- Relays GRE o de túnel que reenvían el tráfico a una ubicación real oculta.
Esta capa rara vez se activa sola, pero es un corroborador fuerte cuando se combina con señales de hosting.
Comportamiento de los proxies residenciales
Los proxies residenciales son la clase más difícil, porque la IP de salida pertenece realmente a un ISP doméstico. Las comprobaciones de listas pasan. Las de ASN pasan. El sondeo no encuentra nada escuchando, porque el "servidor" es un SDK enterrado en la aplicación móvil gratuita de alguien.
Por eso la detección pasa de la infraestructura al comportamiento a lo largo del tiempo:
- La misma IP residencial apareciendo como salida en marketplaces de proxies conocidos.
- Una diversidad de sesiones improbable: una sola IP doméstica presentando decenas de huellas de dispositivo por hora.
- Patrones de rotación que coinciden con la rotación de una red de proxies y no con la renovación de DHCP.
- Discrepancia de tipo de ISP: IP de operadores móviles que producen volúmenes de solicitudes sostenidos al estilo de un datacenter (la guía para detectar proxies móviles explica por qué las IP de operadores son un caso especial).
Por eso las salidas residenciales tienen un campo distinto de is_proxy: la clase de evidencia es diferente, y también lo es la acción adecuada. Ten claro lo que una consulta de IP puede ver aquí. El campo is_residential_proxy de GeoIPHub es una inferencia aproximada basada en el ASN, no una observación directa de pertenencia a una red de proxies, así que trátalo como un indicio y no como una prueba. Si el tráfico de ISP domésticos de repente parece sospechoso en tus logs, por qué siguen apareciendo proxies residenciales en tu tráfico repasa las causas habituales. Un acierto de proxy residencial en un flujo de checkout es una señal de fraude mucho más fuerte que un acierto de VPN de consumo.
Datos del directorio de Tor
Tor es el caso fácil, por diseño. La red Tor publica su consenso de relays y nodos de salida, que se actualiza continuamente. Cruzar los datos con la lista pública de nodos de salida da una precisión casi perfecta en is_tor, con una salvedad: el momento. Los nodos de salida entran y salen, así que el directorio hay que reingerirlo con una frecuencia alta, no semanal.
Los relays de privacidad son el caso opuesto. Apple publica todas las direcciones de salida de iCloud Private Relay, así que un relay también se puede identificar con exactitud, pero por sí solo un relay corresponde a allow, no a una lista de bloqueo. Cubrimos ambos relays, y por qué Cloudflare no publica ninguna lista de salida de WARP, en detección de iCloud Private Relay y Cloudflare WARP.
Confianza cruzando señales
La última capa es la fusión. Cada una de las capas anteriores produce evidencia con un perfil de fiabilidad distinto:
| Capa de señal | Qué atrapa | Confianza cuando se activa | Punto ciego |
|---|---|---|---|
| Listas de proveedores | VPN comerciales | Muy alta (atribuida) | VPN privadas |
| ASN / hosting | Anonimizadores en datacenter | Media (probabilidad previa, no prueba) | Salidas residenciales |
| Sondeo activo | Daemons de VPN/proxy activos | Muy alta (verificada) | Proxies basados en SDK |
| Huellas de puertos | Proxies sin marca | Alta | Endpoints tras firewall |
| Comprobaciones de latencia | Relays con geolocalización falseada | Media | Relays cercanos |
| Modelos de comportamiento | Proxies residenciales | Media-alta | IP completamente nuevas |
| Directorio de Tor | Nodos de salida | Casi total | Bridges |
Un veredicto defendible pondera todo esto en conjunto. Una sola señal de confianza media no debería cambiar un booleano; dos señales independientes de confianza alta sí deberían. Lo que quieres de una API de detección son, por tanto, tres cosas: los booleanos para las decisiones de enrutamiento, los métodos de detección con nombre para la auditabilidad y una puntuación de riesgo que exprese hasta qué punto se corroboran las señales. Los métodos con nombre son también lo que necesita un usuario marcado por error: nuestro repaso de por qué una IP se marca como VPN o proxy los lee sobre direcciones reales.
Cómo aplicar la detección de VPN: decide según combinaciones
Tres conclusiones prácticas:
- No trates
is_vpncomo una lista de bloqueo por sí solo. Muchos clientes de pago usan VPN de consumo (consulta cómo marcar tráfico anonimizado sin rechazar a clientes reales). Decide según combinaciones: VPN + datacenter + historial de abuso es una situación muy distinta de una VPN sola. - Da mucho peso a las señales de proxy residencial, sabiendo que son inferidas. Nadie alquila salidas residenciales por privacidad; la tasa base de uso legítimo es mínima comparada con la de las VPN. Aun así, un indicador residencial a nivel de IP es una inferencia aproximada, así que combínalo con tus propias señales de sesión.
- Prefiere la detección verificada a las listas estáticas. Pregunta a cualquier proveedor cómo sabe que una IP es una VPN. Si la respuesta es "una base de datos que licenciamos", los datos ya se están degradando. El sondeo activo y las listas de proveedores rastreadas de forma continua siguen el ritmo de la rotación de infraestructura.
Puedes ver tú mismo la salida de cada capa: pasa cualquier IP por la herramienta gratuita de consulta de IP o prueba tu propia conexión VPN, sin registro.
Preguntas frecuentes
¿Puede la detección de VPN ser 100 % precisa?
No. La detección es probabilística. Las VPN comerciales con infraestructura publicada se detectan con una confianza muy alta, mientras que las VPN privadas pequeñas en IP de nube recién estrenadas son más difíciles. Por eso las buenas API devuelven evidencia por señal y un nivel de confianza en lugar de un simple booleano.
¿Qué diferencia hay entre un proxy y una VPN a nivel de detección?
Una VPN tuneliza todo el tráfico en la capa de red y normalmente responde a handshakes de protocolos concretos (OpenVPN, WireGuard, IKEv2) en su servidor. Un proxy retransmite tráfico de capa de aplicación (HTTP, SOCKS) y expone puertos y huellas distintos. Los sistemas de detección sondean ambas familias por separado.
¿Por qué es tan difícil detectar los proxies residenciales?
Porque la IP de salida pertenece realmente a un ISP doméstico, así que las comprobaciones basadas en listas y en ASN pasan. En su lugar, la detección se apoya en evidencia de comportamiento: la misma IP apareciendo en redes de proxies, patrones de reutilización anómalos y discrepancias entre el tipo de ISP y el tráfico observado.
¿Tiene sentido bloquear a todos los usuarios de VPN para prevenir el fraude?
Normalmente no. Muchos usuarios legítimos navegan a través de VPN por privacidad. Un patrón mejor es tratar el uso de VPN como una entrada ponderada más de una puntuación de riesgo y escalar solo cuando coincide con otras señales, como alojamiento en datacenter, historial de abuso o viajes imposibles.
¿Qué tan actualizados deben estar los datos de detección de VPN?
Mucho. Los proveedores de VPN rotan servidores a diario y las redes de proxies cambian de IP cada hora. La detección respaldada por un sondeo continuo y por listas de proveedores que se rastrean de nuevo sin parar se mantiene precisa; los conjuntos de datos estáticos se degradan en semanas.
El equipo detrás de la API de GeoIPHub
Escrito por el equipo de GeoIPHub, las personas que crean la API de inteligencia IP de GeoIPHub y su escáner. Los borradores se preparan con ayuda de IA y el equipo los edita; los ejemplos de la API son consultas reales contra la API en producción, salvo que se indique que son ilustrativos.


