Por qué tu IP muestra ubicaciones distintas en cada servicio

En pocas palabras: si tres herramientas de geolocalización IP te dan tres respuestas distintas para la misma dirección, no es que una esté rota. Son tres datasets diferentes (registro, ruteo y observación de usuarios) que comparten el mismo formato de salida. Según dev.to (22/10/2026), el truco no es encontrar “la base buena”, sino saber qué capa te está respondiendo en cada caso.

Che, si alguna vez chequeaste la misma IP en dos o tres servicios gratis de geolocalización y te dieron resultados distintos —ciudad en uno, capital de provincia en otro, solo país en el tercero, y de paso uno te la marca como datacenter mientras el whois dice línea residencial— no estás viendo un bug aislado. Según una publicación de dev.to del 22 de octubre de 2026, “Geo-IP” es en realidad el nombre que le damos a tres fuentes de datos distintas que casualmente escupen el mismo tipo de respuesta. El problema no es técnico, es de interpretación: comparás peras con manzanas y te extraña que no cierren.

¿Qué son en realidad las “tres capas” que miden algo distinto sobre tu IP?

La idea central es simple aunque suene técnica: cuando consultás una IP, no estás consultando una base, estás consultando tres bases distintas que alguien empaquetó con la misma apariencia. Cada una mide algo diferente y, por eso mismo, falla de forma diferente.

Los datos de registro (whois, RDAP) vienen de los RIR y dicen quién tiene asignado el bloque. Son autoritativos sobre la titularidad, pero no sobre el uso real: un bloque alocado a una filial alemana puede estar ruteado en Singapur al día siguiente, y el registro seguiría diciendo “Alemania”. Los datos de ruteo (BGP/ASN) dicen por dónde pasa físicamente el tráfico hoy, y se actualizan en horas si cambia algo en la red. Los datos observados vienen de paneles que registran dónde aparecieron usuarios reales con esa dirección: son los más finos para geografía de consumidor final, pero también los más lentos en reflejar un cambio.

Capa	¿Quién la controla?	Dónde se pudre
Registro (whois/RDAP)	El RIR	Bloque alocado en un país, operado en otro
Ruteo (BGP/ASN)	El operador de red	Anycast: un prefijo, docenas de ubicaciones posibles
Observación (paneles)	El vendor de geolocalización	Muestras chicas, historial viejo, centroides inventados

Lo que un vendor te muestra como resultado “final” es, en la práctica, una mezcla ponderada de estas tres capas según lo que sus propios clientes observaron. Esa ponderación es propietaria y no la ves. Por eso dos vendors pueden decirte cosas opuestas sobre la misma IP y ambos jurar que tienen 99% de precisión: no están mintiendo, están ponderando distinto.

Ejemplo hipotético: cómo se lee una discrepancia real paso a paso

Este ejemplo es hipotético, armado solo para ilustrar el método de lectura —no es un caso real ni una medición propia.

Imaginate que administrás un VPS contratado en un datacenter de Buenos Aires y lo consultás en tres servicios. El primero te devuelve “Argentina, Buenos Aires, Buenos Aires” con bandera datacenter en verdadero. El segundo te devuelve “Argentina, Buenos Aires” pero sin ciudad, con coordenadas que coinciden exactamente con el centro geográfico del país. El tercero te marca “Argentina, Córdoba” y la IP como residencial. Aplicando el criterio de capas: el primer resultado probablemente viene de ruteo (ASN) actualizado, y es el más confiable porque refleja dónde está físicamente el servidor hoy. El segundo es un caso típico de observación con poca muestra que cayó en el centroide del país —la coordenada “parece” precisa pero es un placeholder, hay que descartarla y quedarte solo con el país/región. El tercero probablemente arrastra un registro viejo: el bloque se reasignó al datacenter después de que ese dataset se actualizó por última vez. Ninguno de los tres “está mal” en abstracto; cada uno te está mostrando una capa distinta y con distinto nivel de atraso.

¿Por qué divergen las bases geo-IP, más allá de “están desactualizadas”?

Se pueden agrupar en dos familias de causas. La primera es problema de tiempo: anycast y rezago de registro. Un prefijo de CDN se anuncia desde decenas de sitios a la vez, así que a qué ubicación resuelve tu consulta depende de dónde salió la query, no de dónde está la IP. Y los bloques se reasignan más rápido de lo que las bases se actualizan: un /24 vendido a un hosting en marzo puede seguir leyéndose como ISP residencial en junio.

La segunda familia es problema de precisión forzada: cuando no hay confianza a nivel ciudad, el vendor no dice “no sé”, devuelve el centroide del país como si fuera una coordenada real. Según los chequeos de la fuente, hay servicios que devuelven la misma coordenada nacional para cualquier dirección de ese país mientras el nombre de la región sí es correcto —la precisión visual es falsa, la categórica no.

Y después está el caso más dañino de todos: las listas de ASN que alimentan la bandera “datacenter”. Se armaron a mano en algún momento y nadie las revisa con frecuencia. Según la fuente, una lista ampliamente copiada incluía 16 ASN de operadoras chinas de carrier, lo que hace que se clasifiquen como servidor líneas residenciales enteras. Un lookup que dice “datacenter” muchas veces no está describiendo la IP: está describiendo la lista de otro. Complementá esto con cómo resolver problemas comunes de hosting y dominio.

¿Con qué criterio decidir en cuál de las tres confiar, según el síntoma?

No hace falta memorizar las tres capas de nuevo cada vez: alcanza con mirar qué campo exacto difiere entre los lookups, porque eso ya te dice dónde está el problema.

• Si difiere el país: sospechá de anycast o un cambio de ruteo reciente. Confiá en el dato de ruteo (ASN) chequeado el mismo día, no en un lookup de la semana pasada.
• Si la región está bien pero la ciudad es justo la capital: es un centroide de país disfrazado de precisión. Quedate con el nombre de la región y descartá la coordenada completa.
• Si país y región están bien pero la bandera “datacenter” te parece rara: no discutas con el flag, mirá el tipo de titular del ASN vía RDAP. El flag es una búsqueda en lista; el ASN es un hecho verificable.
• Si todo coincide salvo el nombre del proveedor (ISP): es rezago de registro después de una reasignación. De nuevo, el dato de ruteo manda.
• Si el mismo lookup te da respuestas distintas en requests consecutivos: el vendor balancea entre varios backends. Fijá un solo endpoint si necesitás reproducibilidad.

De ahí se desprenden dos reglas prácticas, no negociables si tomás decisiones con esto: nunca mezclés campos de proveedores distintos en una misma conclusión —país de uno y ciudad de otro es, literalmente, la receta para armar una discrepancia donde no había ninguna— y anotá siempre qué vendor te respondió cada dato, porque una comparación sin saber el origen no se puede reproducir ni defender después. Esto conecta con algo que ya tratamos en la nota sobre hosting en la nube vs. hosting local: la ubicación física de un servidor y lo que terceros creen sobre esa ubicación son dos cosas distintas, y conviene no confundirlas al elegir infraestructura.

¿Cómo armar una comparación que sirva, en vez de confirmar lo que ya sospechabas?

La fuente plantea algo sencillo: consultar país, región y ciudad por separado en al menos tres fuentes, usando IPs de control cuya ubicación real ya conocés —no direcciones al azar—. Eso es clave porque sin un control no tenés con qué comparar: si corrés el chequeo contra 1.1.1.1 o 8.8.8.8 (direcciones públicas y conocidas) y una fuente ya falla ahí, sabés que esa fuente tiene un problema de fondo antes de siquiera mirar tu propia IP.

El punto de hacerlo contra un control es detectar si una fuente es el outlier consistente en el mismo campo, para varias direcciones de tu misma región. Si eso pasa, no es que esa fuente sea “menos precisa”: es que su dataset está directamente desactualizado para tu zona geográfica, y conviene dejar de usarla para esa región en particular. Como idea práctica y no como algo que midamos nosotros: si administrás infraestructura propia, correr este mismo chequeo contra dos o tres IPs de control de tu propio proveedor, antes de analizar la IP que te generó dudas, te da una base real contra la cual comparar en lugar de sacar conclusiones con una sola consulta.

¿Cuáles son los errores más comunes al leer estos resultados?

• Tratar las coordenadas de un centroide de país como un dato real: si la región es correcta y la ciudad es justo la capital de un país grande, esas coordenadas son un placeholder, no una ubicación.
• Confiar más en el booleano “datacenter” que en el ASN: ese flag es una búsqueda en una lista de terceros; el ASN es un hecho que podés verificar vos mismo vía RDAP.
• Comparar vendors en momentos distintos: los datasets se actualizan cada semana, así que un chequeo del mes pasado y uno de hoy son, en los hechos, dos experimentos distintos.
• Juzgar un proxy o un servidor con un solo lookup: hay que validarlo contra la plataforma específica que importa, no contra un servicio genérico cualquiera.
• Asumir que una discrepancia significa que la IP está mal: muchas veces la base está atrasada y la conexión real funciona sin ningún problema.

Ojo con este último punto en particular, porque es el que más dolores de cabeza genera en la práctica: para equipos técnicos en Latinoamérica que operan VPS o servidores dedicados, es habitual que un cliente reporte “mi IP aparece como datacenter” cuando en realidad la lista de ASN del lookup está vieja, no la asignación real del bloque. Si manejás infraestructura propia, chequear el tipo de titular del ASN vía RDAP antes de asumir que el bloque está mal clasificado te ahorra una discusión entera con soporte técnico que, en el fondo, no tiene nada que ver con tu servidor.

Preguntas Frecuentes

¿Qué base de datos de geolocalización IP conviene usar para una salida de proxy?

Ninguna por sí sola. La fuente recomienda usar datos de ruteo (ASN, prefijo) para establecer qué es la salida realmente, y datos observados para entender dónde cree la plataforma de destino que está. Cuando entran en conflicto, en la práctica manda el vendor de la plataforma —aunque esté equivocado, es el que decide tu resultado.

¿Por qué una IP residencial puede aparecer marcada como datacenter?

Casi siempre por una lista de ASN mantenida por un proveedor que incluye bloques de carriers, o por un reseller de hosting que anuncia espacio de direcciones consumer. Conviene revisar primero el tipo de titular del ASN antes de confiar en ese flag. Tema relacionado: self-hosting vs. servicio gestionado.

¿Por qué un servicio reporta una ciudad precisa y otro solo el país?

Porque la precisión que muestra un vendor es una señal de confianza interna, no un dato extra verificado en el terreno. Los servicios con datos de panel limitados caen en el centroide del país y lo etiquetan como si fuera una ciudad: la coordenada se ve exacta pero es, en los hechos, un placeholder nacional.

¿Cómo se actualizan las bases de geolocalización IP?

A ritmos muy distintos según la capa. El ruteo (BGP/ASN) responde en horas ante un cambio de red; los datasets de observación por paneles se actualizan semanalmente y pueden quedar atrasados meses cuando una IP residencial estática cambia de dueño.

¿La geolocalización IP afecta si una cuenta queda marcada como sospechosa en una plataforma?

Sí, de forma indirecta. Las plataformas puntúan consistencia: la región que declara tu sesión tiene que coincidir con la región a la que resuelve tu IP según la base de datos de esa plataforma en particular. Una IP correctamente ubicada pero mal interpretada por el vendor de turno sigue generando un mismatch para ellos, y ese mismatch es el que termina importando.

Conclusión

Lo que cambia con esto no es la tecnología de geolocalización IP, sino la pregunta que le hacés. Tres respuestas distintas para la misma dirección no significan que una base esté rota: significan que estás comparando registro contra ruteo contra observación sin darte cuenta. El dato que conviene recordar es el de las 16 ASN de operadoras chinas filtradas en una lista “datacenter” ampliamente copiada, porque muestra algo más general: un error de clasificación cometido una sola vez, en un solo lugar, se propaga después a decenas de servicios que reutilizan esa misma lista sin revisarla.

Si administrás infraestructura o dependés de que tu IP se identifique bien —hosting, VPS, servidores propios—, el criterio práctico queda bastante claro: nunca saques una conclusión de un solo lookup, separá país, región y ciudad en vez de mirar un resultado “global”, y guardá siempre qué vendor te dijo cada cosa antes de decidir si el problema está en tu dirección o en la base que la consultó.

Fuentes

• dev.to – Why Three Geo-IP Databases Give Three Answers for the Same Address (22/10/2026)