Fingerprinting de dispositivos frente a inteligencia de IP: por qué necesitas ambos
El fingerprinting de dispositivos reconoce un navegador que vuelve; la inteligencia de IP lee su red. En nuestras consultas, una VPN de Mullvad puntuó 100 y una IP de Private Relay, 9.

Los equipos de fraude y de confianza repiten una y otra vez el mismo debate: ¿fingerprinting de dispositivos o inteligencia de IP, cuál compramos? Es la pregunta equivocada. En el tráfico real de un gran sitio web, solo alrededor de un tercio de las huellas eran únicas, cambian en cuestión de días y los navegadores antidetección las falsifican por completo. La IP llega con el primer paquete, en el servidor, en cada petición, incluido el tráfico de API y de bots, y se condensa en una puntuación de fraude de IP de 0 a 100. A continuación: qué ve cada capa, dónde falla cada una y cómo combinarlas.

Qué es realmente una huella de dispositivo
Una huella de dispositivo es un hash de los atributos que el navegador está dispuesto a exponer. Un script lee el user agent, la pantalla, las fuentes instaladas, el idioma, la zona horaria y pistas del hardware, además de las sutiles diferencias con las que una GPU y un driver concretos renderizan un canvas oculto, una escena WebGL o un búfer de audio. Si se combinan todos en un hash, se obtiene un identificador que sobrevive al borrado de cookies y a las ventanas privadas, porque se deriva de la máquina en lugar de almacenarse en ella.
Eso le da al fingerprinting tres puntos fuertes reales:
- Reconocer un navegador que vuelve entre sesiones, inicios de sesión y borrados de cookies.
- Vincular cuentas a un dispositivo compartido, una clave fundamental en la detección de multicuentas.
- Detectar incoherencias internas que delatan la automatización: un user agent que dice ser un iPhone con una cadena de GPU de escritorio, un navegador headless con dimensiones de pantalla imposibles o una huella que cambia en cada petición.
Para esas tareas, es una señal fuerte. El problema empieza cuando los equipos tratan la huella como una identidad en lugar de como una probabilidad.
Tres límites honestos del fingerprinting
El fingerprinting falla de tres maneras: colisiona a escala, cambia con el tiempo y está bajo ataque por parte de las herramientas de fraude, los navegadores y los reguladores.
Es mucho menos único a escala de lo que daban a entender los estudios famosos. Las primeras investigaciones con voluntarios preocupados por la privacidad indicaban que más del 80 % de los navegadores eran identificables de forma única. Cuando los investigadores analizaron 2.067.942 huellas de uno de los 15 principales sitios web franceses, es decir, tráfico corriente y no personas que buscaban una prueba de privacidad, solo el 33,6 % eran únicas, y en móviles la cifra bajaba al 18,5 % (Hiding in the Crowd, WWW 2018). Millones de personas usan el mismo modelo de teléfono con las mismas fuentes por defecto, así que en tráfico real la mayoría de las huellas colisionan.
Cambia con el tiempo. Los navegadores se actualizan solos, se instalan fuentes, se conectan pantallas. El estudio FP-STALKER, basado en 98.598 huellas de 1.905 instancias de navegador, observó que las huellas cambian con frecuencia, "from every few hours to days" (desde cada pocas horas hasta cada pocos días) (FP-STALKER, IEEE S&P 2018). Con su método de vinculación, los autores aún lograron seguir a un navegador durante 54,48 días de media, y al 26 % durante más de 100 días. Es una investigación impresionante y también una advertencia: un sistema ingenuo de hash y comparación ve al mismo cliente como un desconocido en cuestión de días.
Está bajo ataque desde tres frentes. Las redes de fraude lo falsifican deliberadamente: los navegadores antidetección, el kit estándar de las granjas de cuentas, generan una huella nueva y coherente internamente para cada perfil. Los navegadores lo degradan a propósito: Safari limita lo que los scripts de fingerprinting conocidos pueden leer de APIs como canvas y web audio, y Firefox incluye una protección contra el fingerprinting que difumina muchas de esas mismas señales. Y los reguladores lo tratan como seguimiento. El Grupo de Trabajo del Artículo 29 de la UE concluyó en su Dictamen 9/2014 que el requisito de consentimiento de ePrivacy se aplica al fingerprinting de dispositivos. El 19 de diciembre de 2024, la ICO del Reino Unido calificó de "irresponsible" (irresponsable) la decisión de Google de permitir el fingerprinting con fines publicitarios. La seguridad y la prevención del fraude tienen una base jurídica más sólida que la publicidad, pero el riesgo es real.
Nada de esto hace que el fingerprinting sea inútil. Lo convierte en una entrada probabilística que necesita una segunda capa independiente que la confirme o la contradiga.
Lo que ve la inteligencia de IP y una huella no puede ver
La inteligencia de IP describe la red por la que llegó una petición, y lo hace antes de que se ejecute JavaScript alguno. La dirección llega con el primer paquete de cada petición, incluidas las llamadas a la API, los webhooks y los scripts headless que nunca ejecutan tu código de fingerprinting. Enriquecida, responde a preguntas que el navegador nunca puede responder sobre sí mismo (el detalle campo a campo está en qué es la inteligencia de IP):
- ¿Qué tipo de red es?
asn.connection_typesepara el acceso residencial y móvil del de centros de datos o hosting. Un checkout de consumo desde una instancia en la nube es un script mientras no se demuestre lo contrario, y ninguna huella puede decirte eso. - ¿Está anonimizada la conexión?
detection.is_vpn,is_proxy,is_toreis_relay, más unanonymity_level. La mecánica se explica en cómo funciona la detección de VPN y proxies. - ¿Quién opera la red? El ASN y la organización, que es la forma en que "cuarenta cuentas nuevas en un mismo proveedor de hosting" se vuelve visible.
- ¿Dónde está y coincide con todo lo demás? País y ciudad con un
geo_confidence, más unatimezonede IANA cuando se conoce. - ¿Tiene historial esta dirección? Alertas de spam, escaneo y botnet, y entradas en listas de bloqueo DNS en
threat.dnsbl_sources. - ¿Es compartida?
threat.is_cgnatmarca el NAT a nivel de operador, donde una dirección son en realidad miles de personas, y la puntuación de esas direcciones tiene un tope de 50.
Dos propiedades son las más importantes. La inteligencia de IP es del lado del servidor y universal: cubre el tráfico que el fingerprinting no ve. Y es difícil de falsificar desde el cliente: una petición tiene que venir de algún sitio, y un centro de datos o un servidor VPN conocido se muestra como tal. Hay una salvedad que depende de ti: puntúa la IP real del cliente a partir de tu cadena de proxies de confianza, nunca de una cabecera reenviada que se pueda falsificar.
Lo que la inteligencia de IP no puede hacer sola
Una dirección IP no puede distinguir a dos clientes cuando están detrás de la misma dirección CGNAT, la misma puerta de enlace de oficina o la misma red de un campus. No puede reconocer el mismo portátil cuando pasa del Wi-Fi de casa a la zona de cobertura de un teléfono, y las direcciones móviles rotan constantemente.
La carencia más difícil es el proxy residencial. Una red de fraude que alquila salidas en conexiones domésticas reales envía tráfico que parece el de un usuario doméstico normal, y los datos de IP en general no pueden verlo. Nosotros no detectamos proxies residenciales, y ninguna consulta de IP debería ser tu única defensa contra ellos. Aquí es exactamente donde la huella se gana su sitio: el mismo perfil antidetección que reaparece en muchas direcciones "domésticas" es un patrón de la capa del dispositivo, no de la red. Así que la inteligencia de IP sola no puede responder a "¿es este el dispositivo en el que confiábamos la semana pasada?", que es la pregunta para la que existe el fingerprinting.
Pregunta a pregunta: qué capa la responde
Cada capa responde a las preguntas que la otra no puede responder, y la tabla deja ese reparto explícito.
| La pregunta que te haces | Huella | Inteligencia de IP |
|---|---|---|
| ¿He visto este navegador antes? | Sí (probabilístico) | No |
| ¿Estas cuentas están en un mismo dispositivo? | Sí | En parte (misma red) |
| ¿Es una conexión de centro de datos, VPN, Tor o relay? | No | Sí |
| ¿Es una salida de proxy residencial? | Indirectamente (mismo dispositivo, muchos hogares) | En general, no |
| ¿Qué operador de red y qué historial? | No | Sí |
| ¿Dónde está el usuario, aproximadamente? | Débilmente (zona horaria, idioma) | Sí (con geo_confidence) |
| ¿Funciona en tráfico de API y de bots sin JavaScript? | No | Sí |
| ¿Funciona antes de que cargue la página? | No | Sí |
| ¿Es estable durante semanas? | No (cambia en días) | En líneas fijas sí, en móviles no |
| ¿Puede falsificarlo el cliente? | Sí (navegadores antidetección) | Solo alquilando otra salida |
| Exposición regulatoria | Se aplican normas de consentimiento | Tratamiento estándar de IP |
Lee las columnas juntas: en casi todas las filas en las que una capa dice "no", la otra dice "sí".
La misma huella de confianza, dos redes: lo que vimos el 20 de octubre de 2026
La capa de red convierte una misma huella de confianza en un block o en un allow, según desde dónde llegue. Imagina un navegador en el que confías desde hace meses llegando una vez desde cada una de las direcciones siguientes. Consultamos la salida de iCloud Private Relay 104.28.46.99 a las 04:34 UTC y el servidor de Mullvad 185.213.155.73 a las 04:35 UTC del 20 de octubre de 2026, sin clave de API. Los resultados cambian a medida que se mueven los rangos.
El servidor de Mullvad en Fráncfort devolvió esto, recortado y con los valores intactos:
{
"ip": "185.213.155.73",
"asn": {
"asn": 39351,
"org": "ESAB-AS - 31173 Services AB",
"asn_type": "hosting",
"connection_type": "datacenter"
},
"geo": {
"country_code": "DE",
"city": "Frankfurt am Main (Innenstadt I)",
"timezone": "Europe/Berlin",
"geo_confidence": 0.8
},
"detection": {
"is_vpn": true,
"is_hosting": true,
"is_relay": false,
"is_anonymous": true,
"anonymity_level": "medium",
"vpn_provider": "Mullvad",
"vpn_confidence": 95
},
"scoring": {
"fraud_score": 100,
"recommended_action": "block",
"detection_methods": ["known_vpn_server", "wireguard_open", "datacenter_with_vpn_proxy", "no_ptr_datacenter"]
}
}
La salida de relay en la red de Cloudflare devolvió esto:
{
"ip": "104.28.46.99",
"asn": {
"asn": 13335,
"org": "CLOUDFLARENET - Cloudflare, Inc.",
"asn_type": "unknown",
"user_type": "consumer_privacy_network"
},
"geo": {
"country_code": "AO",
"city": "Luanda",
"timezone": "Africa/Luanda",
"geo_confidence": 0.8
},
"detection": {
"is_vpn": false,
"is_proxy": false,
"is_relay": true,
"relay_provider": "iCloud Private Relay",
"anonymity_level": "medium"
},
"scoring": {
"fraud_score": 9,
"recommended_action": "allow",
"detection_methods": ["relay_ip"]
}
}
La dirección de Mullvad puntúa 100, el máximo, y detection_methods explica por qué. Está en la lista de servidores que publica la propia Mullvad, de donde salen vpn_provider: "Mullvad" y vpn_confidence: 95, y esa lista la etiqueta como servidor WireGuard. Una huella de confianza que llega desde ahí es la contradicción "dispositivo conocido en una red anonimizada", así que aplica una verificación reforzada aunque el historial del dispositivo esté limpio. La dirección de Private Relay puntúa 9 con relay_ip como único método. El relay de Apple es una función de privacidad para consumidores, no un proxy, y la puntuación de las direcciones de relay tiene un tope de 60, así que una IP de Private Relay nunca puede llegar a block. Una huella de confianza desde hace tiempo detrás de ella es de lo más seguro que puede ser el tráfico.
Otras dos consultas de la misma ronda completan el panorama:
| Dirección (consultada el 20 oct 2026, UTC) | Qué es | fraud_score | recommended_action | detection_methods |
|---|---|---|---|---|
104.28.46.99 (04:34) | Salida de iCloud Private Relay | 9 | allow | relay_ip |
45.33.32.156 (04:34) | Servidor en la nube de Linode sin más, Fremont | 10 | allow | datacenter_ip |
185.213.155.73 (04:35) | Servidor VPN de Mullvad, Fráncfort | 100 | block | 4 métodos, arriba |
185.220.101.1 (04:34) | Salida de Tor, Hamburgo | 100 | block | tor_exit, datacenter_blocklisted, no_ptr_datacenter, known_spammer |
Que un simple servidor en la nube puntúe 10 es un recordatorio útil: el hosting por sí solo no es fraude. Una huella de confianza que llega desde una máquina en la nube merece una pregunta, no un bloqueo.
Hay dos detalles que importan para la comprobación de la zona horaria. El servidor de Mullvad indica Europe/Berlin, así que un reloj del navegador configurado con la hora de Nueva York en esa dirección es una contradicción clara. El geo.timezone del servidor de Linode volvió como "none", así que en esa dirección la comparación de zona horaria no tiene con qué comparar. Y la salida de relay se geolocaliza en Luanda (Angola), mientras que la propia lista de salidas de Apple situaba ese rango en Lusaka (Zambia) cuando lo comprobamos el 12 de octubre. Que el reloj del navegador no coincida con la ubicación de un relay es lo esperable y no debería contar como indicio de proxy.
Los veredictos de red caducan, así que guarda la hora de la consulta
Un veredicto de IP es una lectura tomada en un momento concreto, y nuestra propia muestra lo demostró. La versión anterior de este artículo usaba 102.129.235.17 como ejemplo de VPN. El 5 de octubre de 2026, y de nuevo el 16 de octubre, devolvió fraud_score 92, block, con known_vpn_server, openvpn_open e ipsec_open. El 20 de octubre a las 04:34 y de nuevo a las 04:35 UTC devolvió fraud_score 0, allow, is_vpn: false y un detection_methods vacío. No hemos determinado si la dirección salió de una red VPN o si nuestro escaneo dejó de verla.
En cualquier caso, guarda la hora de la consulta, la puntuación y los métodos junto al ID de la huella, y vuelve a puntuar la IP en la siguiente acción sensible en lugar de fiarte del veredicto del mes pasado. Una huella cambia en cuestión de días, y el veredicto de esta IP pasó de block a allow en cuatro días.
Mejor juntas: cómo combinarlas
Usar ambas capas compensa allí donde discrepan, y seis reglas convierten eso en decisiones.
Busca contradicciones. Una huella en la que confías desde hace meses que de repente llega a través de una VPN de centro de datos en otro continente es un secuestro de sesión, una cuenta compartida o un proxy delante de un bot. Una huella totalmente nueva en la misma IP residencial que usó ayer un dispositivo de confianza es casi siempre un teléfono nuevo en el hogar. La misma huella más un viaje imposible entre dos IP en una hora es una sesión robada o una salida alquilada.
Compara el reloj del navegador con el de la red. La huella informa de la zona horaria del navegador; la inteligencia de IP informa de la de la red. La hora de Nueva York en una IP con Europe/Berlin es uno de los indicios de proxy más antiguos, y cuesta una sola comparación de cadenas. Sáltate la comprobación cuando timezone sea "none" o la dirección sea un relay.
Usa la red para deshacer colisiones de huellas. Dos huellas idénticas (mismo teléfono, mismo sistema operativo, mismos valores por defecto) son dos personas distintas cuando sus IP están en redes residenciales diferentes de ciudades distintas. Una huella "cambiada" que sigue llegando desde el mismo /64 de IPv6 y el mismo ASN es probablemente la misma persona tras una actualización del navegador.
Deja que cada capa cubra el tráfico que la otra no ve. Aplica el fingerprinting a las sesiones de navegador donde se ejecuta JavaScript, y puntúa la IP en todo.
Agrupa por ambas, de forma independiente. Para multicuentas y abuso de promociones, una huella compartida y una red compartida son dos familias de evidencias independientes. Una clave compartida es un hogar o un bloque CGNAT; dos claves compartidas independientes son una hipótesis de red organizada que merece revisión.
Puntúa y después refuerza la verificación. Introduce la huella como continuidad ("dispositivo conocido" reduce el riesgo, "dispositivo conocido como malo" lo aumenta) y la IP como contexto. Después actúa según las cuatro bandas que ya usa la puntuación, como en los umbrales de puntuación de fraude por acción: allow con 25 o menos, review hasta 50, step_up hasta 75 y block por encima de 75. Cuando una contradicción cae en review y un analista tiene que revisarla a mano, sigue el procedimiento por incidente de cómo investigar una dirección IP.
Una checklist de implementación
Seis pasos de desarrollo convierten esas reglas en una unión que funciona.
- Captura la huella en el inicio de sesión, el registro, el checkout y el pago, y registra su ID junto con la petición.
- Consulta la IP real del cliente en el servidor y conserva las alertas de
detection, el ASN,geo.timezone,is_cgnat,fraud_scoreydetection_methods. - Guarda ambas asociadas a la sesión y a la cuenta con una marca de tiempo, para poder comparar el par de hoy con el del mes pasado.
- Escribe primero las reglas de contradicción: dispositivo conocido en una red VPN, Tor o de centro de datos, discordancia de zona horaria, viaje imposible, dispositivo nuevo en una red de confianza.
- Atenúa en direcciones CGNAT y de operadores móviles. Una huella cambiada en una red conocida no es una señal de alarma por sí sola.
- Documenta por qué usas fingerprinting y confirma la situación del consentimiento en las regiones a las que das servicio.
La mitad de IP con una sola consulta
Todo lo que necesita la mitad de IP llega en una sola petición GET, y la puntuación de fraude explicable de 0 a 100 incluye recommended_action y los métodos que se activaron. También aplica señales exculpatorias: un ISP residencial resta 17 puntos y un rastreador verificado, 28,5. Todos los campos están en el plan gratuito, con 1.500 consultas al día, y puedes consultar cualquier IP sin clave de API antes de escribir la unión con tu tabla de huellas.
Deja de preguntar qué capa comprar
Esta combinación aparece en todo este grupo de artículos, desde las redes de multicuentas hasta el abuso de cupones, y es la forma de seguir detectando tráfico anonimizado sin bloquear a clientes reales, porque una huella de confianza detrás de Private Relay con 9 merece un trato más ligero que una nueva en una VPN con 100. Los motivos detrás de cada puntuación muestran qué señales de red la movieron. Así que no elijas una capa. Pregúntate qué preguntas necesitas responder y verás que necesitas ambas.
Preguntas frecuentes
¿Qué es el fingerprinting de dispositivos?
El fingerprinting de dispositivos (a menudo, fingerprinting del navegador) recopila decenas de atributos que expone un navegador, como el user agent, el tamaño de pantalla, las fuentes instaladas, la zona horaria, el idioma, detalles del hardware y la forma en que el dispositivo renderiza canvas, WebGL y audio, y los convierte mediante hash en un identificador. Como no necesita cookies, puede reconocer un navegador que vuelve entre sesiones y vincular varias cuentas a un mismo dispositivo. Se ejecuta en el cliente, así que solo ve el tráfico en el que se ejecuta su script.
¿Es preciso el fingerprinting de dispositivos?
Menos de lo que sugerían los primeros estudios. Un análisis de 2018 de 2.067.942 huellas de uno de los 15 principales sitios web franceses encontró que solo el 33,6 % eran únicas, y el 18,5 % en móviles, frente a más del 80 % en estudios anteriores con voluntarios preocupados por la privacidad. Las huellas también cambian con el tiempo: el estudio FP-STALKER observó que varían desde cada pocas horas hasta cada pocos días, aunque su método de vinculación siguió a los navegadores durante 54,48 días de media. Trata una huella como una señal probabilística de reconocimiento, no como una identidad estable.
¿Puede la inteligencia de IP sustituir al fingerprinting de dispositivos?
No, y lo contrario tampoco. La inteligencia de IP ve la red: el tipo de conexión, el origen en hosting o residencial, el uso de VPN, proxy, Tor y relay, el ASN, la geolocalización y el historial de abuso. Funciona en el servidor desde la primera petición y en el tráfico de API donde no se ejecuta ningún script. Pero no puede distinguir dos hogares detrás de una misma dirección de NAT a nivel de operador, y el tráfico a través de un proxy residencial parece el de un usuario doméstico normal. El fingerprinting cubre esas carencias, y la inteligencia de IP cubre los puntos ciegos del fingerprinting.
¿Cuál es la mejor forma de combinar las señales de huella del dispositivo y de IP?
Trata la huella como una señal de continuidad (¿hemos visto este navegador?) y la IP como una señal de contexto y riesgo (¿en qué red está y está anonimizada?), y busca contradicciones. Una huella conocida que llega desde una VPN de centro de datos en otro continente es un patrón de secuestro o de proxy; una huella nueva en la misma IP residencial de confianza suele ser un dispositivo nuevo en el hogar. Compara la zona horaria que declara el navegador con la zona horaria de la IP, y usa ambas como claves de agrupación independientes cuando busques multicuentas.
¿Es legal el fingerprinting de dispositivos?
En la UE y el Reino Unido se regula como seguimiento. El Grupo de Trabajo del Artículo 29 concluyó en su Dictamen 9/2014 que la norma de consentimiento de la Directiva ePrivacy para acceder a información del dispositivo del usuario se aplica al fingerprinting, con excepciones limitadas para lo estrictamente necesario para prestar un servicio que el usuario ha solicitado. La prevención del fraude tiene una base más sólida que la publicidad, pero el riesgo de cumplimiento es real: el 19 de diciembre de 2024, la ICO del Reino Unido calificó de 'irresponsable' la decisión de Google de permitir el fingerprinting con fines publicitarios. Usa el fingerprinting de forma deliberada, documenta su finalidad y busca asesoramiento jurídico para tu jurisdicción.
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.


