Estás en Shanghái, pero la consulta de IP muestra otra ciudad; dos sitios web consultan la misma dirección y uno indica Estados Unidos y el otro Canadá. Al ver estos resultados, la intuición dice que “una de las bases de datos está mal”. Pero antes de comparar bases de datos, conviene confirmar: ¿estás comparando la misma dirección, el mismo tipo de ubicación, o varios campos con nombres parecidos pero significados distintos?
La geolocalización IP es una estimación de la ubicación de una dirección de red, no la ubicación del dispositivo. Diferentes plataformas pueden usar fuentes de datos, fechas de actualización y granularidad de ubicación distintas; ante discrepancias, primero verifica la dirección y los campos, y después decide si necesitas corregir.
Este orden es importante. De lo contrario, podrías confundir la ubicación de la salida de red con tu propia ubicación, o usar la sede de la organización de registro para refutar una localización a nivel de ciudad, y terminar enviando una solicitud de modificación al lugar equivocado.
“Lugar de pertenencia” puede incluir cuatro tipos de información
Muchas páginas de consulta solo escriben “país”, “región” o “lugar de pertenencia”, sin explicar directamente el significado de los datos. En realidad, la siguiente información no puede sustituirse entre sí.
Información que ves | Objeto que describe | Qué debes considerar al comparar |
|---|---|---|
Geolocalización IP | Ubicación de uso estimada por la base de datos o ubicación de la salida de red | Si hay rango de localización, nivel de confianza y fecha de actualización |
Información de registro de recursos | Registros de direcciones IP y organizaciones relacionadas | La información de registro no equivale a una prueba de la ubicación del dispositivo terminal |
Localización del navegador o del dispositivo | Ubicación del dispositivo obtenida tras otorgar los permisos correspondientes | Puede usar capacidades del dispositivo como GPS, no solo la consulta IP |
Contenido local proporcionado por el sitio web | Contenido regional que el servicio elige según su propia lógica | También puede verse afectado por la configuración de la cuenta, el idioma o preferencias históricas |
La introducción de ARIN a Whois/RDAP explica el uso de la consulta de información de registro. Esa es una capa de datos distinta de la estimación geográfica de “dónde se usa actualmente esta dirección”.
La documentación de la API de geolocalización de MDN indica que, tras obtener la autorización del usuario, el sitio web puede obtener la ubicación mediante las capacidades de localización disponibles en el dispositivo. Por eso, que una aplicación de mapas sepa en qué calle estás no significa que otro sitio de consulta IP deba ofrecer la misma precisión.
¿Por qué una misma dirección puede tener resultados de localización diferentes?
El uso de la dirección cambió, pero las bases de datos no se actualizan al mismo tiempo
Los recursos de direcciones pueden ser reasignados, subarrendados o usados para nuevas salidas de red. Los servicios de localización necesitan procesos separados para detectar cambios, verificarlos y publicar actualizaciones; los sitios web que usan bases de datos offline también deben desplegar realmente la nueva versión en sus propios sistemas.
Por lo tanto, «el proveedor de datos ya lo ha corregido» y «todos los sitios web que usan esos datos ya se han actualizado» son dos cosas distintas. Seguir viendo resultados antiguos puede deberse al proveedor de datos o a la base de datos local o a la caché del sitio que los consume.
No hay aquí un tiempo de actualización fijo que sirva para todas las plataformas. No se puede afirmar que el envío no ha funcionado solo porque no ha cambiado tras un día de espera, ni se puede prometer que, al corregir un sitio, los demás se sincronicen al mismo tiempo.
La salida de red no tiene por qué estar cerca del usuario
En entornos como redes móviles, redes corporativas o VPN, la ubicación del dispositivo queda separada de la ubicación de la salida pública. Las bases de datos geográficas a veces pueden determinar bien la posición de la salida, pero no pueden localizar a la persona que usa esa salida a partir de ese dato.
La explicación sobre precisión de localización de MaxMind trata específicamente escenarios como redes móviles y redes de privacidad, y señala explícitamente que los datos geográficos de IP no bastan para identificar una casa, una persona o una dirección postal concretas.
Por eso, si una persona está en la ciudad A y la salida se localiza en la ciudad B, no tiene por qué tratarse de una anomalía en la línea. Primero hay que aclarar si lo que quieres consultar es la ubicación del dispositivo o la ubicación de red que ven los servicios externos.
Las dos plataformas ofrecen distinta precisión
Que una plataforma indique el país y otra la ciudad no significa que la segunda sea necesariamente más precisa. Un campo más detallado puede ser solo un punto representativo dentro de un rango; que la página no muestre el radio de localización tampoco implica que ese radio no exista.
Aunque el marcador del mapa parezca caer sobre un edificio concreto, no se puede deducir que el servidor o el usuario estén en ese edificio. Que la latitud y la longitud tengan más decimales solo aumenta la precisión de visualización, no la exactitud de los datos.
Si la fuente de datos proporciona un rango de localización, conviene leer el punto y el rango juntos. Si no lo proporciona, hay que evitar interpretar el nombre de una ciudad como una ubicación verificada sobre el terreno.
Una red con el mismo nombre no significa que todas las direcciones tengan el mismo uso y la misma ubicación
Una organización operadora puede tener actividad en varios lugares. Dentro de un mismo ASN también puede haber bloques de direcciones de distintas regiones y con distintos usos.
El nombre de la organización y el ASN ayudan a contrastar el contexto de red, pero no permiten localizar en una ciudad todas las direcciones de esa red por sí solos. Que el DNS inverso contenga la abreviatura de una ciudad solo es una pista; el nombre de host puede mantener una nomenclatura antigua y no sustituye a otras pruebas.
Antes de investigar, confirma bien cuál es «la misma IP»
El error de comparación más común no suele estar en la base de datos, sino en el objeto de la consulta.
Primero copia la dirección pública completa, no te quedes solo con el país y el operador. Confirma especialmente si las dos páginas muestran una IPv4 y una IPv6 respectivamente: no son la misma dirección, y no deben usarse directamente para medir si dos bases de datos coinciden.
Anota también la hora de la consulta y confirma que los ajustes de red no hayan cambiado a mitad de camino. La selección automática de ruta por el proxy, la reconexión de la red móvil o que el navegador y otras aplicaciones usen reglas de proxy distintas pueden cambiar la salida observada.
Puedes registrar primero el resultado actual con Consulta de IP y después comparar usando esa misma dirección como objeto explícito de consulta. Si introduces un nombre de dominio, ten en cuenta que puede resolver a varias direcciones; comparar distintos servidores devueltos por el dominio no equivale a comparar la misma IP.
¿Cómo convertir las diferencias de localización en un problema manejable?
Amontonar capturas de pantalla y decir «no sois precisos» suele ser menos útil que la siguiente información.
La IP completa consultada y si es IPv4 o IPv6.
Fecha y hora de la consulta, para no tratar resultados de momentos distintos como observaciones simultáneas.
El nombre del campo de cada resultado: país de registro, país de localización, ciudad u otra posición.
Fuente de datos, versión o fecha de actualización; si no se puede obtener, indícalo tal cual: no proporcionado.
Dónde crees que está el error y los materiales que respaldan esa afirmación.
Por ejemplo, «las dos plataformas dan países de localización distintos para la misma IPv4» es más concreto que «los dos sitios web no coinciden en la atribución»; «el bloque recién asignado a nosotros sigue mostrando la ciudad anterior» se acerca más a un problema que el proveedor de red y el mantenedor de datos pueden verificar.
Los materiales también tienen distinta fuerza. La zona de entrega del contrato de servicio, las indicaciones del operador de red y la información de uso de recursos verificable suelen explicar mejor la situación que la zona horaria configurada en el sistema operativo del servidor. La zona horaria se puede modificar y no sirve para demostrar la ubicación física.
A quién pedir la corrección, en lugar de enviarla repetidamente a todos los sitios web
Eres usuario de una conexión de banda ancha o móvil normal
Primero pregunta al operador si existe una salida concentrada, una puerta de enlace entre regiones o un ajuste reciente en la asignación de direcciones. Si la salida de red ya está en otra región, modificar la base de datos geográfica no puede convertir la ruta real en una salida local.
Si solo el contenido de una aplicación no coincide con la región esperada y los resultados de varias bases de datos de IP son consistentes, también debes revisar los permisos de ubicación y la configuración regional de la cuenta de esa aplicación. En este caso, el problema puede no estar en la base de datos de IP.
Has alquilado un proxy, un VPS o una dirección pública fija
Pide al proveedor que indique el método de entrega real y la región, y verifica si la dirección fue migrada o reasignada recientemente. No uses solo la opción de región de la página de ventas como evidencia final de la ubicación.
Si la corrección involucra un prefijo completo, normalmente es más adecuado que lo gestione de forma unificada el operador de red que controla el recurso. El geofeed puede ayudar al operador a publicar la información geográfica del prefijo, pero RFC 8805 también reserva explícitamente espacio para que los usuarios verifiquen la autoridad y exactitud; publicar un archivo no es una orden de actualización obligatoria para todas las bases de datos.
Ya sabes con certeza de qué fuente de datos proviene el error
Usa el canal oficial de esa fuente de datos. Por ejemplo, MaxMind proporciona en su documentación una entrada de corrección de datos geográficos. Envía hechos verificables según lo solicitado, no pidas que cambie la dirección a la región que deseas mostrar.
Corregir es acercar los datos al uso real, no fabricar una atribución falsa de un país o ciudad. Al enviar, tampoco necesitas publicar la dirección exacta de tu hogar, contraseñas de cuentas ni capturas del panel de administración; solo proporciona la información necesaria a los receptores confiables.
Después de la corrección, ¿cómo confirmar que el problema realmente se resolvió?
Conserva los registros previos al envío y, después de que el mantenedor confirme el procesamiento, consulta nuevamente la misma dirección y el mismo campo, y verifica si el sitio web originalmente afectado también adoptó el nuevo resultado. Ambos pueden no estar sincronizados.
Si los datos de IP ya cambiaron pero un servicio sigue mostrando la región antigua, debes dirigir el problema al usuario del servicio: ¿usa otra fuente de datos, conserva caché o tiene una configuración regional a nivel de cuenta? Seguir modificando datos que ya son correctos a menudo no ayuda.
En cuanto a si el servicio está disponible, debe verificarse por separado mediante Pruebas de acceso a servicios y acceso real normal. Una ubicación correcta no garantiza que el servicio esté abierto; que el servicio sea accesible tampoco prueba a la inversa que la ciudad sea correcta.
La información geográfica de IP es útil para comprender el contexto de red, detectar desviaciones evidentes e iniciar correcciones. Tratarla como un juicio con límites de fuente y precisión, en lugar de una prueba de dirección exacta a nivel de calle, se acerca más a su uso real.
Redes transnacionales con países de ubicación diferentes: país de registro, Anycast y posición de salida
Veamos un escenario hipotético: un proveedor transnacional registra sus recursos de direcciones en Canadá, el servicio real se implementa en Estados Unidos, y por eso la base de datos de localización comercial y la consulta de registro muestran países diferentes. Aquí no hay que asumir Anycast, ni se puede determinar el Anycast solo por la diferencia de países. Primero hay que distinguir si se lee el país de registro, la estimación de ubicación comercial o el nodo de servicio observado en una solicitud concreta; describen hechos distintos y no se puede juzgar quién está equivocado solo por la "inconsistencia de dos países".
El país de registro proviene del registro de recursos en la base de datos RDAP o Whois y describe la atribución administrativa del bloque de direcciones, no la región donde está el dispositivo terminal. Por ejemplo, un rango registrado en Canadá pero usado durante mucho tiempo por un centro de datos en Estados Unidos puede aparecer en la base de datos geográfica con una ciudad estadounidense, mientras que el país de registro sigue siendo Canadá. Son campos distintos y no deben compararse directamente. Al consultar múltiples resultados, primero confirma si la página indica "país", "país de registro" o "ubicación".
Anycast es otra posibilidad que requiere evidencia independiente. Una misma dirección de servicio puede ser ofrecida desde múltiples ubicaciones, y la política de enrutamiento decide a qué instancia llega la solicitud actual, sin garantizar que se elija el nodo físicamente más cercano. Solo con evidencia como la declaración del operador, mediciones desde múltiples ubicaciones o identificación de instancias, es apropiado discutir el impacto del Anycast en la localización. Que dos bases de datos comerciales muestren países diferentes no prueba por sí solo el Anycast, ni descarta datos obsoletos, cambios de asignación o un despliegue transnacional común.
Al verificar, primero revisa la organización, el alcance y los eventos en RDAP, y luego usa las observaciones de BGP como contexto de enrutamiento. Un solo ASN puede cubrir varios países, y que un mismo prefijo aparezca con múltiples ASN de origen tiene varias explicaciones; ninguno determina por sí solo la ciudad del servicio. Si se obtienen declaraciones regionales del operador, geofeed mantenido o mediciones multipunto, se debe anotar el tiempo y alcance de cada uno, y reducir gradualmente el juicio, en lugar de negar la localización comercial directamente con el país de registro.
Al investigar, primero registra la dirección IPv4/IPv6 completa, la hora de consulta y el nombre del campo que da cada plataforma. Si una dirección pertenece a una red Anycast o en la nube transnacional, no te apresures a enviar una corrección; en su lugar, revisa los anuncios de ruta del prefijo y la documentación pública del operador de red. Cualquier juicio de "esto definitivamente está mal" requiere combinar información de registro, observaciones BGP y evidencia de salida real. Para más información sobre la relación entre RDAP, ASN, BGP y evidencia de ubicación, lee RDAP, ASN, BGP y RPKI: cómo interpretar una consulta de IP.
Solicitud de corrección: niveles de evidencia, registro de tiempo y límites de propagación
El material de corrección debe coincidir con el campo específico. Las declaraciones de implementación del operador para ese rango de direcciones, el geofeed mantenido y la región de entrega del servicio pueden dar pistas sobre la ubicación de uso; la latencia, traceroute y DNS inverso son observaciones auxiliares. Los registros del plano de control BGP no dan directamente la ubicación física del servidor y no deben usarse como evidencia definitiva del lugar del centro de datos. Todos los materiales deben verificar autenticidad, fecha de actualización, alcance y si se aplican a la dirección actual, en lugar de establecer un orden de autoridad universal.
Materiales más débiles pero referenciales incluyen: informes de usuarios, configuración de zona horaria del sistema operativo del servidor, idioma del contenido del sitio web, etc. La zona horaria del sistema operativo puede cambiarse libremente y no prueba la ubicación física del dispositivo; el idioma del sitio o la configuración regional de la cuenta reflejan más bien preferencias de contenido, no la atribución de la IP. Al enviar una corrección, no subas la dirección exacta de tu hogar, contraseñas de cuentas ni capturas del panel de administración; debes proporcionar materiales públicos u operativos suficientes para que el mantenedor de datos juzgue la ubicación de uso de la dirección.
Registra la fecha, la hora y la zona horaria de cada consulta. Considera este ejemplo hipotético: una dirección se reasigna a una nueva región en marzo de 2024, pero en mayo la base de datos de geolocalización sigue sin actualizarse. Una captura de enero puede ser una prueba desactualizada para solicitar la corrección. Comparar resultados de la misma dirección en distintas fechas ayuda a distinguir una actualización repentina de una fuente de los cambios que se propagan entre varias. Presenta una cronología de los registros antiguos y nuevos e identifica la fuente de cada resultado. Esto facilita la revisión de las pruebas, pero no garantiza que se acepte la corrección ni que se tramite en un plazo determinado.
Los proveedores de datos y los sitios web que los utilizan son etapas de actualización diferentes. Fuentes como MaxMind o IP2Location pueden actualizar primero sus propias bases de datos, pero los sitios que usan esos datos aún deben descargarlos, implementarlos y posiblemente configurar caché. Por eso, que la fuente muestre un resultado nuevo mientras un sitio web sigue mostrando el antiguo no significa necesariamente que la fuente no haya cambiado. En estos casos, conviene verificar por separado: si la fuente ya corrigió el dato, qué versión utiliza ese sitio y si el sitio tiene su propia caché o lógica de respaldo.
Ningún canal de corrección debe prometer que "tras el cambio, las demás plataformas se sincronizarán en un plazo fijo". Publicar un geofeed o una corrección oficial es solo el inicio de la cadena de actualización de datos. Algunas bases de datos sin conexión pueden publicar actualizaciones solo una vez cada varios meses, y algunos sitios pueden usar datos propios o de terceros en lugar de suscribirse directamente a la fuente. No puedes esperar que una sola solicitud cambie todos los resultados de consulta a la vez. Tras enviar la corrección con éxito, vuelve a consultar la misma dirección y el mismo campo cuando se publique la nueva versión, y confírmalo en al menos dos momentos independientes. Si alguna plataforma tarda mucho en actualizar, pregunta sobre cómo utiliza los datos en esa plataforma, en lugar de volver a enviar repetidamente datos que ya son correctos.
Por último, el objetivo de la corrección es que los datos reflejen mejor el uso real de la red, no cambiar la dirección al país o ciudad que te gustaría ver. Si la evidencia no basta para demostrar que la ubicación es incorrecta, o si la fuente ya indicó que la dirección pertenece a Anycast o a una salida dinámica, seguir enviando solicitudes puede no tener efecto. Puedes consultar Fuentes de datos y metodología para entender mejor cómo se actualizan y validan las bases de datos geográficas.
