Proxy "Alemania", pero el sitio ve Países Bajos: cómo funciona realmente la geolocalización IP

Un escenario que se repite para todos los que trabajan con proxies en serio. Tienes una IP residencial con geo "Alemania". Abres un verificador — y honestamente dice Alemania, Frankfurt. Entras al sitio objetivo — y este muestra la moneda holandesa, la salida holandesa y un banner de cookies holandés. El segundo verificador dice que la IP está en Bélgica. ¿Quién miente?

Nadie. El problema es que la dirección IP no tiene coordenadas. La geo-localización no es una propiedad de la dirección, sino una opinión de una base de datos específica, que ha recopilado información de manera indirecta. Hay varias bases, son independientes y sus datos difieren — de manera sistemática y predecible. A continuación, analizaremos de dónde provienen estos datos, cuán grande es el margen de error real según mediciones recientes y qué hacer al respecto en la práctica.

No hay geografía en la IP — solo estimaciones

En el paquete no hay un campo "país". Todo lo que Internet sabe sobre la dirección es a quién se le ha asignado según los documentos del registrador y a dónde llevan las rutas BGP. A partir de esto, las bases comerciales (MaxMind, IPinfo, IP2Location, DB-IP y otras) recopilan conjeturas, combinando cinco fuentes:

• Registros RIR y whois. El país en el registro es la jurisdicción de la organización a la que se le ha asignado el bloque, y no el lugar donde están físicamente las máquinas. Un proveedor alemán puede desplegar direcciones en Ámsterdam sin problema.
• Geofeeds. El formato de los datos geo-autopublicados está definido por el RFC 8805 (2020), que en 2024 fue reemplazado por el RFC 9632 — con validación y detección a través de RDAP. El operador declara dónde se encuentra su subred. Esta es la única fuente autorizada, pero la cobertura es mínima: a finales de 2023, los geofeeds habían publicado alrededor de 2,800 sistemas autónomos — aproximadamente 34 millones de direcciones IPv4, o el 0.8% de las asignaciones mundiales.
• Enrutamiento y prefijos BGP. Si se sabe dónde se encuentra una dirección, la base extrapola a todo el prefijo. De ahí proviene la mayoría de los errores.
• Mediciones de latencia. La triangulación por RTT desde puntos conocidos — funciona bien en ciudades de Europa densa, pero falla donde hay pocos puntos de medición.
• Datos de socios. Señales de aplicaciones y servicios que correlacionan IP con coordenadas GPS de dispositivos.

Cada proveedor mezcla esto en su propia proporción y según sus propias reglas. Los resultados no tienen que coincidir.

¿Cuán grande es el error: mediciones de 2026?

El 21 de mayo de 2026, investigadores de Virginia Tech (Syed Tauhidun Nabi, Jocelyn Bliton, Tijay Chung, Shaddi Hasan) publicaron un trabajo titulado "Lost in the Prefix: Revisiting IP Geolocation Accuracy Across Networks and Geographies". Compararon cuatro bases — MaxMind GeoLite2, IPinfo, IP2Location DB11 y DB-IP Lite — con un estándar de 16,010 sondas RIPE Atlas en 175 países y 21,292 pares "IP — escuela" del proyecto UNICEF Giga. En total, 37,302 observaciones, de las cuales 74.7% eran IPv4 y 25.3% IPv6.

Números clave:

• Redes fijas: error mediano de 3–16 km dependiendo del proveedor. Para Internet de banda ancha en un país desarrollado, la geo-localización funciona bien.
• Redes móviles: error mediano de 179–207 km. Esta es una brecha más de diez veces mayor que en redes fijas, y es consistente en las cuatro bases.
• Porcentaje de errores graves (más de 100 km) por regiones: Europa 9–20%, Américas 8–22%, Asia 53–61%, África 66–72%.
• Causa: alrededor del 70% de los prefijos móviles están físicamente extendidos más de 100 km. Cuanto más grande es el prefijo, mayor es el error — independientemente del proveedor, tipo de red y región.

Un detalle importante: las cuatro bases cometen errores aproximadamente de la misma manera y en los mismos lugares. No se trata de "un mal proveedor contra uno bueno" — es una limitación común del método. En los países del Sur Global, hay de 2 a 3 veces más prefijos "gruesos", por lo que allí los errores son mayores.

MaxMind señala sus límites de manera honesta: 99.8% de precisión a nivel de país, alrededor del 80% a nivel de estado/región en EE.UU. y 66% a nivel de ciudad — donde "ciudad" significa estar dentro de un radio de 50 km. Se aclara que las direcciones en redes móviles son utilizadas por teléfonos a grandes distancias, y en el caso de VPN o proxies, la base geo-localiza el servidor, no al usuario final.

Por qué el verificador y el sitio ven cosas diferentes

Aquí es donde se encuentra la clave del escenario inicial. El verificador que abriste muestra datos de su base. El sitio objetivo consulta su propia base. Estas son respuestas diferentes a la misma pregunta, y ambas son "correctas" en su propio sistema de coordenadas.

Tres mecanismos específicos de discrepancia:

• Diferentes proveedores. Un sitio detrás de Cloudflare obtiene el país del encabezado CF-IPCountry — estos son datos propios de Cloudflare, y a menudo difieren de lo que MaxMind proporciona en ese mismo momento para la misma dirección. Los servicios de streaming y los sistemas de pago mantienen listas propias, complementadas con el historial de comportamiento.
• Diferente antigüedad de los datos. GeoLite2 City y Country gratuitos se actualizan dos veces por semana — los martes y viernes. Los GeoIP2 comerciales se publican cada día hábil. Un sitio con una base de datos de hace un año verá una imagen del año pasado. Esto también explica por qué nuevas subredes "se establecen" durante semanas.
• Diferente nivel de detalle. Los proveedores tienen políticas diferentes: algunos dan la ciudad, otros redondean deliberadamente al nivel de región o país si la confianza es baja. La falta de ciudad no es un error, sino una decisión de no adivinar.

Cuatro situaciones donde la discrepancia es casi garantizada

1. Proxies móviles. El peor caso por definición: CGNAT, un prefijo para medio país, con un error mediano de casi 200 km. Exigir a una IP móvil una ciudad exacta es inútil — la red no está diseñada así. También es útil verificar que la IP sea realmente móvil y no un centro de datos con un ASN falso: el análisis de la metodología se encuentra en el artículo cómo distinguir un proxy 4G real de un ASN falso.
2. Bloques revendidos y trasladados. Después de transferir una subred IPv4 a un nuevo propietario, el antiguo país permanece en las bases durante meses. El mercado de direcciones secundarias está activo, por lo que esto es un fenómeno masivo, no una rareza.
3. Anycast y nubes. El mismo prefijo se anuncia desde decenas de puntos en el mundo. La base se ve obligada a reducir esto a una sola ubicación — y cualquier elección será incorrecta para la mayoría de las consultas.
4. Registro en la oficina central. El proveedor está registrado en un país, pero mantiene la infraestructura en otro. La base toma los documentos porque no hay otros datos.

Qué hacer en la práctica

1. Verifica donde sea importante, no en el verificador. La única prueba significativa es abrir el sitio objetivo y ver qué país y moneda mostró. Si la tarea es obtener resultados locales de Google o precios regionales, el verificador no es un criterio de aceptación.
2. Compara al menos tres bases. Si MaxMind, IPinfo y DB-IP están de acuerdo — es muy probable que el sitio objetivo también lo vea así. La discrepancia entre ellos es una señal de que la dirección es dudosa y habrá problemas con ella.
3. Separa los requisitos de "país" y "ciudad". El país en un proveedor decente es confiable (99.8% según MaxMind). La ciudad es una variable probabilística con un radio de alrededor de 50 km incluso en el mejor de los casos. Construir la lógica empresarial en la ciudad solo se puede hacer con un margen de error.
4. Mira el prefijo, no la dirección. Verifica whois y el tamaño del bloque anunciado. Si la IP está en /16, extendida por medio país, no habrá una vinculación precisa para nadie.
5. No confundas geo con reputación. Un país correcto no dice nada sobre si la dirección está marcada como proxy. Esta es una verificación separada en bases diferentes — detallada en el artículo sobre mitos sobre IP "limpio" y verificadores de reputación.
6. Pregunta al proveedor sobre el geofeed. Si el operador de la subred ha publicado un geofeed según el RFC 9632, el país y la ciudad provienen de él mismo, no de conjeturas. Este es el argumento más fuerte a favor de un grupo específico. MaxMind importa y verifica correcciones a través del geofeed una vez al día hábil, correcciones puntuales — en 1–2 días hábiles, después de lo cual se incluyen en la próxima versión de la base.

Cómo esto afecta la elección del tipo de proxy

De las mediciones se deduce una regla simple. Si la tarea requiere geografía precisa — resultados locales de un motor de búsqueda, precios regionales, publicidad geo-dirigida — elige proxies residenciales en líneas fijas: allí el error mediano se mide en unidades de kilómetros. Si la tarea requiere que la plataforma confíe en el tipo de red — redes sociales, mensajeros, aplicaciones móviles — elige proxies móviles, pero ten en cuenta que el punto en el mapa fluctuaría dentro de la región. Combinar ambos requisitos en una sola IP no será físicamente posible: esta es una limitación de la arquitectura de las redes móviles, no de la calidad del grupo.

Para regiones con un alto porcentaje de errores graves — Asia, África — planifica a nivel de país, no de ciudad. Allí, según los datos del estudio, cada segunda o tercera dirección se aleja del lugar real más de cien kilómetros en cualquier proveedor.

Conclusión

"El país no se determina" casi nunca significa que te hayan engañado con el proxy. Más a menudo significa que has comparado las respuestas de dos bases diferentes y te has sorprendido de que no coincidan. El orden correcto de acciones: averiguar qué base está leyendo la plataforma objetivo, verificar la geo-localización precisamente en ella, comparar direcciones dudosas en varias fuentes y no exigir a las redes móviles una precisión urbana que no tienen y no tendrán.

Y ten en cuenta la cifra principal de este año: 3–16 km en líneas fijas frente a 179–207 km en móviles. Esto explica gran parte de las quejas sobre la geo-localización en proxies incluso antes de que abras un ticket de soporte.