La lista completa de campos de datos de IP que debes conocer

Pregunta "¿qué datos se pueden obtener de una dirección IP?" y la mayoría de las respuestas se quedan en "una ubicación aproximada". Esa es la parte más pequeña de lo que abarca la inteligencia de IP. La misma dirección también te dice qué red es su propietaria, si es una línea doméstica o un servidor alquilado, si es una VPN, una salida de Tor o un relé de privacidad, si figura en una lista de bloqueo y si es un rastreador verificado. Para saber cómo se construyen los campos de detección, consulta cómo funciona la detección de VPN y proxy.

Esta referencia ha cambiado mucho desde nuestra versión de julio. La API ganó tres campos, a nuestras tablas se les habían escapado dos, la puntuación de una salida de Tor pasó de 79 a 100, y varios campos devuelven valores que las tablas de julio describían mal. Todos los ejemplos de abajo proceden de GET api.geoiphub.com/v1/lookup/{ip} el 22 de octubre de 2026, y puedes reproducir cualquiera de ellos con la herramienta gratuita de consulta de IP.

Contamos 103 campos en siete respuestas en vivo el 22 de octubre de 2026

Obtuvimos siete respuestas el 22 de octubre de 2026 entre las 04:56 y las 04:57 UTC y contamos 103 campos en 10 grupos. Cinco campos son nuevos en esta lista desde julio, y 11 son marcadores de posición. Las siete direcciones eran infraestructura pública, elegida para activar grupos distintos:

Un pequeño script de Node recorrió cada respuesta y listó cada campo hoja, contando geo.country_names como un solo campo porque es un mapa de traducciones. Las siete respuestas tenían exactamente las mismas 103 claves. Así se reparten:

Cinco campos son nuevos en esta lista. Tres se añadieron a la API en octubre: detection.residential_proxy_status, residential_proxy_evidence y residential_proxy_last_seen. Ya están en la referencia de campos de la API, marcados como reservados. Los otros dos, threat.crawler.unverified y threat.spammer_last_seen, ya estaban en la respuesta en julio, y a nuestras tablas antiguas simplemente se les escaparon. No se ha eliminado ningún campo de la lista de julio.

Once campos son marcadores de posición. Revisamos el generador de respuestas de la API: diez de ellos se escriben como un valor vacío constante ([], "none" o 0) en cada consulta, y crawler.spoofed todavía no tiene ninguna fuente de datos detrás. Otros ocho campos contienen datos pero están reservados, y no mostramos sus valores: blocklist_count, ptr_pattern en ambos grupos y los cinco campos de proxy residencial. Las tablas de abajo marcan ambos tipos.

Cómo encajan los 10 grupos en una consulta de una salida de Tor

Los grupos se entienden mejor siguiéndolos a través de una sola dirección. Esta es la respuesta real de 185.220.101.1, una salida de Tor, recortada a los campos que cuentan su historia:

Los grupos se corroboran entre sí. El ASN dice hosting, detection.is_tor procede de la lista de salidas del Tor Project, threat.dnsbl_sources muestra una entrada en Spamhaus ZEN, y el grupo de puntuación lo resume todo en block con los cuatro métodos que se activaron.

La respuesta también muestra una laguna. ptr_record es "none", así que se activó no_ptr_datacenter, pero un dig -x 185.220.101.1 en vivo esa misma mañana devolvió un nombre de host tor-exit. El DNS inverso almacenado en la API va por detrás del registro en vivo para algunas direcciones. Esa laguna es también la razón por la que rdns_tor, que aparecía en la versión de julio de este artículo, ya no se activa. Ese cruce de comprobaciones entre grupos es la razón para incluir tantos campos. Ahora, cada grupo por orden.

1. La propia IP (ip)

El campo ip devuelve la dirección exacta que resolvió la API, como cadena. Úsalo para confirmar que consultaste lo que pretendías, sobre todo después de analizar una cabecera X-Forwarded-For, donde elegir el salto equivocado es un bug clásico. También es la clave natural para tu propia caché.

Se aceptan tanto IPv4 como IPv6. Si no sabes cuál es tu propia dirección pública, la herramienta ¿cuál es mi IP? la muestra junto con todo lo que un sitio web puede deducir de ella.

2. Datos de red y ASN (asn)

El grupo asn te dice qué red anuncia la dirección, y está entre los datos de IP más fiables que puedes obtener. Toda IP enrutable pertenece a un sistema autónomo, y ese dato procede de la tabla de enrutamiento global, no de una estimación.

Los valores cambian con la dirección. 1.1.1.1 volvió con asn_type: "cdn" y user_type: "content_delivery_network", y Googlebot volvió con user_type: "search_engine_spider". La salida de Private Relay devolvió asn_type: "unknown", connection_type: "unknown" y user_type: "consumer_privacy_network". Una cosa cambió desde julio: 8.8.8.8 ahora devuelve rpki: "valid", mientras que el ejemplo de nuestra documentación todavía muestra "invalid".

El campo que hay que vigilar es connection_type. Una dirección de centro de datos en un inicio de sesión de consumidor merece una segunda mirada. Aun así, el hosting por sí solo no es fraude: 45.33.32.156 es hosting normal y obtuvo 10, allow. Puedes comprobar cualquier dirección con la comprobación gratuita de IP de centro de datos, y la página de la API de geolocalización IP explica el modelo de ASN.

3. Datos de geolocalización (geo)

El grupo geo sitúa la dirección en un mapa, y es el grupo en el que más a menudo se confía en exceso. Los 15 campos contenían datos en todas las consultas que hicimos.

El país es sólido, y la ciudad es aproximada. Un estudio revisado por pares sobre geolocalización mediante DNS inverso, con datos de 2018, midió errores medianos de 11,1 km y 16,7 km para dos bases de datos comerciales. Recogemos más pruebas en qué tan precisa es la geolocalización IP. Trata la ciudad como un radio, nunca como un punto exacto, y nunca uses una IP para localizar a una persona.

Lee geo_confidence junto a detection.is_anycast. 1.1.1.1 devolvió 0,8 para Sídney, pero también es is_anycast: true, porque la misma dirección se anuncia desde muchos lugares a la vez. Para una dirección anycast, la ciudad es una ubicación plausible entre varias.

Aparecieron otras dos lagunas. timezone volvió como "none" en las tres direcciones de EE. UU. que consultamos (8.8.8.8, la 66.249.66.1 de Googlebot y 45.33.32.156) aunque la ciudad estaba rellenada, así que calcula tú la zona cuando la necesites. Y la salida de Private Relay 104.28.46.99 se situó en Luanda, Angola, mientras que la lista de salidas de la propia Apple sitúa ese rango en Lusaka, Zambia. Para los relés, toma la ubicación de la fila de Apple, como explicamos en cómo comparar IP de relés con la lista de salidas de Apple.

4. Datos de WHOIS y registro (whois)

El grupo whois dice quién registró el bloque y cuándo, obtenido por RDAP de los cinco registros regionales de internet (RIR). Añade una capa de titularidad que la geolocalización no ve.

La cobertura varía según el registro. 8.8.8.8 y 45.33.32.156 devolvieron "none" en org, netname, status y last_changed, con solo country y registered rellenados. El registro del servidor de Mullvad era muy completo: netname: "NET-31173-185-213-155-0-24", registrado el 19 de julio de 2017 y modificado por última vez el 11 de noviembre de 2025.

Los indicadores de palabras clave son pruebas de apoyo, nunca el único motivo para marcar una dirección. Ambos fueron false en las siete direcciones, incluido el servidor de Mullvad, cuyo org en el registro dice "31173 Services AB infrastructure in Frankfurt, DE." sin mencionar ninguna VPN. Por eso importan más las listas de proveedores de las secciones siguientes.

5. Pruebas de red (network)

El grupo network contiene el DNS inverso y el contacto de abuso del registro. Tres de sus siete campos son hoy marcadores de posición.

abuse_contact es el campo al que recurres cuando necesitas denunciar una actividad, y se rellenó en cinco de nuestras siete direcciones. fcrdns_valid no es un booleano simple: devolvió la cadena "none" para la salida de Tor, el servidor de Mullvad y el relé, que no tienen PTR almacenado. El código que compruebe === false no detectará ese caso.

No te fíes de un PTR almacenado sin comprobarlo. Para Googlebot 66.249.66.1, el ptr_record almacenado pertenece a una dirección vecina, mientras que un dig -x en vivo devuelve crawl-66-249-66-1.googlebot.com. Confirmamos el valor de 8.8.8.8 (dns.google) y el de 1.1.1.1 (one.one.one.one) con dig -x esa misma mañana.

open_ports está vacío incluso cuando una sonda obtuvo respuesta. Se escribe como [] en cada consulta. Ten en cuenta que el wireguard_open del servidor de Mullvad no es un resultado de sondeo: significa que la lista de servidores de Mullvad etiqueta ese servidor como WireGuard. Lee los resultados de sondeo, como openvpn_open, en scoring.detection_methods hasta que el campo esté conectado.

6. Detección de VPN, proxy, Tor y relés (detection)

El grupo detection responde a si la dirección anonimiza a su usuario, y cómo. Con 23 campos es el grupo más grande, y tres de ellos son nuevos desde julio.

vpn_provider es el campo que hay que destacar. La mayoría de las API pueden decir que una IP es "una VPN"; nombrar al operador requiere una lista de proveedores. Identificamos una VPN a partir de las listas de servidores de nueve proveedores, una lista pública de terceros o una tabla breve de redes de VPN conocidas, y vpn_confidence muestra qué vía se activó: 95 aquí significa la lista propia de Mullvad. Cuando una dirección no figura en ninguna lista, vpn_provider devuelve "none" aunque un handshake demuestre que es una VPN. Explicamos esas vías en cómo se identifica una VPN a partir de su propia lista de servidores, y puedes probar cualquier dirección con el test de detección de VPN.

is_relay y relay_provider funcionan en pareja. 104.28.46.99 devolvió is_relay: true, relay_provider: "iCloud Private Relay", una puntuación de 9 y allow. La API también devuelve "Cloudflare WARP" para los rangos de conexión de WARP que publica Cloudflare, las direcciones a las que se conecta la aplicación WARP, y un "Cloudflare" no documentado para otras salidas de privacidad de Cloudflare que la lista de Apple no cubre.

is_anonymous no cubre los relés. /docs lo describe como true para cualquier anonimizador, incluidos los relés, pero la salida del relé devolvió is_anonymous: false con anonymity_level: "medium". El indicador solo tiene en cuenta VPN, proxy y Tor, así que lee is_relay por separado.

Los tres nuevos campos de proxy residencial están reservados. Llegaron con un cambio del backend en octubre y todavía no están documentados. La detección de proxies residenciales no es una funcionalidad que ofrezcamos hoy, así que trata los cinco campos de proxy residencial como reservados y no construyas reglas sobre ellos. Si ese tráfico te preocupa, aquí explicamos lo que una consulta de IP puede y no puede ver.

7. Inteligencia de amenazas y bots (threat)

El grupo threat pregunta si se sabe que la dirección es abusiva o si se sabe que es un bot amigable. Tiene 25 campos, y siete de ellos son marcadores de posición.

La salida de Tor rellena la otra mitad de esta tabla: is_spammer: true, threat_types: ["spammer", "tor"] y dnsbl_sources: ["zen.spamhaus.org"]. El servidor de Mullvad devolvió threat_types: ["vpn"], así que el array también refleja los indicadores de anonimizadores.

El objeto crawler es donde se toman las decisiones sobre bots. Para 66.249.66.1, la API devolvió verified: true, name: "Googlebot", operator: "Google" y verification_method: "ip_range_list", comparando con 19 fuentes oficiales de rangos de rastreadores de 10 operadores. Las categorías que hemos visto en las consultas de octubre son search_engine, ai y fetcher. Los nombres pierden los guiones, así que el fetcher de Google activado por usuarios vuelve como GoogleUserTriggeredFetcher.

La detección de suplantación se hace en tu código. La API solo ve la IP, nunca el User-Agent. Una petición que dice ser Googlebot pero devuelve crawler.verified: false no está verificada, y esa comparación te toca hacerla a ti. Lo mostramos en detección de bots por IP y en cómo verificar rastreadores de IA por IP, rDNS y CIDR.

is_cgnat debería suavizar una decisión, no endurecerla. Una dirección de CGNAT la comparten muchos abonados, así que la puntuación tiene un tope ahí, y un solo actor malicioso no debería bloquear a todo un operador. Consulta la visión general de inteligencia de amenazas para conocer las fuentes que hay detrás de este grupo.

8. DNS inverso (dns)

El grupo dns repite tres campos de DNS inverso de network, para que el código que solo necesita rDNS pueda leer un objeto pequeño. Los valores son idénticos a las copias de network en todas las respuestas que obtuvimos.

fcrdns_valid es el fiable. Un PTR que resuelve de forma directa de vuelta a la misma IP es una prueba mucho más sólida que una simple cadena PTR, que puede establecer cualquiera que controle la zona inversa. Se aplica la misma precaución que en la sección 5: compara un PTR almacenado con un dig -x en vivo antes de citarlo.

9. Puntuación de riesgo (scoring)

El grupo scoring convierte las pruebas en una decisión. Son cuatro campos, y detection_methods es el que hace que la puntuación sea auditable.

El fraud_score combina 36 motivos ponderados, y algunos restan. Googlebot lo muestra: se activaron datacenter_ip y verified_crawler, y la puntuación quedó en 0. Un relé nunca puede llegar a block, porque las puntuaciones de los relés tienen un tope de 60. recommended_action asigna la puntuación a bandas:

Muestra confidence como número, no como cadena: llega con todo el ruido de coma flotante. Explicamos el modelo en la guía de la puntuación de fraude de IP y en cómo cada motivo fija la puntuación y su confianza, y dónde fijar los umbrales en cómo elegir un umbral de puntuación de fraude de IP para inicio de sesión, registro y checkout. Puedes puntuar cualquier dirección con la comprobación de puntuación de fraude de IP.

10. Metadatos (meta)

El grupo meta fecha la respuesta e identifica la petición. Dos de sus cinco campos significan algo distinto de lo que sugieren sus nombres.

last_classified_at es la hora de la respuesta, no la de la clasificación. En las siete consultas cayó a un segundo, más o menos, de cuando enviamos la petición. Usa last_scanned para juzgar la actualidad de los datos. Tenía el mismo valor que detection.last_seen en todas las respuestas, y las siete tenían fecha del 20 de octubre de 2026.

Los datos de IP desactualizados son datos de IP erróneos, porque los rangos cambian de manos. El request_id es lo que citas si crees que una clasificación es incorrecta. La latencia fue de 0 a 3 ms en el servidor en las siete consultas.

Cómo nombran los mismos campos otros proveedores

Otros proveedores de datos de IP cubren un terreno parecido con nombres de campo distintos, y algunos reservan los campos más completos a los planes superiores. Leímos la documentación pública de tres proveedores el 22 de octubre de 2026 y nos quedamos solo con lo que dicen esas páginas.

Fuentes: respuestas de los servicios web GeoIP de MaxMind, datos de detección de privacidad de IPinfo, datos de ASN de IPinfo y parámetros de respuesta de detección de proxy de IPQualityScore.

De ahí se desprenden dos consecuencias prácticas. La escala de una puntuación solo significa algo junto a sus umbrales documentados: el 75 de IPQualityScore es "sospechoso", mientras que nuestro 76 ya es block. Y un campo con el mismo nombre puede significar cosas distintas, así que relaciona los campos por su significado documentado, no por su nombre. Nuestra lista de comprobación para elegir un proveedor de datos de IP lo convierte en una prueba breve que puedes hacer con cualquier API.

Qué campos de datos de IP importan para cada decisión

Rara vez necesitas los 103 campos a la vez. Elige los campos según la decisión y sáltate los marcadores de posición:

En una investigación, el orden en que lees los grupos importa tanto como los campos. Nuestra guía paso a paso para investigar una dirección IP recorre tres IP reales con doce comprobaciones pasivas que usan estos grupos uno tras otro.

Comprueba los campos tú mismo antes de construir

La lista de campos va cambiando, así que el hábito más seguro es contarla tú mismo. Haz una consulta y lista las claves hoja:

El filtro cuenta cada array como un campo, se salta los elementos de los arrays y vuelve a sumar country_names como un campo. Imprimió 103 para las siete respuestas que guardamos. Si tu cifra es distinta, compara las claves con la referencia de la API y con este artículo. Si haces pruebas sin clave, espacia tus llamadas: la petición sin clave número 30 dentro de un minuto ya devuelve 429 y bloquea tu IP durante dos horas.

Preguntas frecuentes

¿Qué datos se pueden obtener de una dirección IP?

Mucho más que una ubicación. Una consulta en vivo de GeoIPHub el 22 de octubre de 2026 devolvió 103 campos en 10 grupos: la propia IP, la red (ASN, ISP, tipo de conexión, RPKI), la geolocalización aproximada, los datos de registro WHOIS, las pruebas de red y el DNS inverso, la detección de VPN, proxy, Tor y relés con el proveedor identificado cuando figura en una lista, las señales de amenazas y de rastreadores verificados, una puntuación de riesgo explicable de 0 a 100 y los metadatos de la petición. Once de esos campos son marcadores de posición que hoy devuelven un valor vacío fijo.

¿Puede una dirección IP revelar mi dirección exacta de casa?

No. La geolocalización IP estima una zona aproximada (como mucho, una ciudad o una región), nunca una dirección postal ni una persona concreta. Los resultados a nivel de ciudad son imprecisos, y las conexiones móviles, de CGNAT y de VPN los debilitan todavía más. Quien afirme una precisión a nivel de dirección postal a partir solo de una IP está exagerando.

¿Qué es un ASN en los datos de IP?

Un número de sistema autónomo (Autonomous System Number) identifica la red que anuncia una dirección IP a internet. Por ejemplo, 8.8.8.8 devuelve AS15169, GOOGLE - Google LLC. El ASN y su organización proceden de la tabla de enrutamiento global, así que están entre los campos de datos de IP más fiables, a diferencia de una estimación de la ubicación física.

¿Qué es una puntuación de fraude de IP y cómo se calcula?

Una puntuación de fraude de IP es un único número de 0 a 100 que resume lo arriesgada que parece una dirección. GeoIPHub combina 36 motivos ponderados, resta los exculpatorios, como un rastreador verificado, y devuelve los métodos exactos que se activaron junto con una acción recomendada: allow hasta 25, review hasta 50, step_up hasta 75 y block por encima de 75. Una salida de Tor que consultamos el 22 de octubre de 2026 obtuvo 100 con cuatro métodos indicados.

¿Cuál es la diferencia entre una IP residencial y una de centro de datos?

Una IP residencial la asigna un ISP de consumo a una conexión doméstica; una IP de centro de datos (hosting) pertenece a un proveedor de nube o de servidores. La distinción está en los campos asn.connection_type y asn.asn_type. En nuestras siete consultas de octubre, el servidor de Mullvad VPN, la salida de Tor y Googlebot volvieron todos con connection_type datacenter.

¿Todos los proveedores de API de IP devuelven los mismos campos en todos los planes?

No. La documentación de IPinfo dice que su plan Core incluye solo los indicadores de privacidad is_anonymous e is_hosting, con campos de privacidad más completos en Plus, Max y las API personalizadas. GeoIPHub devuelve todos los campos en todos los planes, incluido el plan gratuito de 1.500 consultas al día.

¿Qué significa un radio de precisión en la geolocalización IP?

Un radio de precisión es la distancia, en kilómetros, alrededor de las coordenadas devueltas dentro de la cual es probable que esté la ubicación real. MaxMind lo documenta como location.accuracy_radius. GeoIPHub no devuelve un radio; devuelve geo.geo_confidence, un valor de 0 a 1 que es 0 cuando no hay pruebas suficientes para una ciudad.