Localização do IP errada: como verificar e corrigir

Veja por que o mesmo IP aparece em cidades ou países diferentes, como comparar as fontes e quais dados reunir para pedir a correção da geolocalização.

Luzes noturnas de cidades do Meio-Oeste dos Estados Unidos e uma aurora no horizonte, vistas da Estação Espacial Internacional

Você está em Xangai, mas a consulta de IP mostra outra cidade; dois sites consultam o mesmo endereço e um indica Estados Unidos, o outro, Canadá. Ao ver esses resultados, a intuição diz que “um dos bancos de dados deve estar errado”. Mas antes de comparar bancos de dados, vale confirmar: você está comparando o mesmo endereço, o mesmo tipo de localização, ou vários campos com nomes parecidos e significados diferentes?

A geolocalização por IP é uma estimativa da localização do endereço de rede, não a localização do dispositivo. Plataformas diferentes podem usar fontes de dados, datas de atualização e granularidades de localização distintas; se as localizações não coincidirem, verifique primeiro o endereço e os campos antes de decidir se é necessário corrigir.

Essa ordem é importante. Caso contrário, você pode confundir a localização da saída de rede com a sua própria, ou usar o local da entidade registrante para contestar uma geolocalização no nível da cidade, e acabar enviando uma solicitação de correção para o lugar errado.

“Local de origem” pode incluir quatro tipos diferentes de informação

Muitas páginas de consulta mostram apenas “país”, “região” ou “local de origem”, sem explicar diretamente o significado dos dados. Na prática, as informações abaixo não podem substituir umas às outras.

Informação que você vê

Objeto que ela descreve

O que observar ao comparar

Geolocalização por IP

Estimativa do banco de dados sobre o local de uso do endereço ou da saída de rede

Se há faixa de localização, grau de confiança e data de atualização

Informações de registro de recursos

Registros do endereço IP e da organização relacionada

Informações de registro não equivalem a prova da localização do dispositivo final

Localização pelo navegador ou dispositivo

Localização do dispositivo obtida após a devida autorização

Pode usar GPS e outros recursos do dispositivo, não apenas consulta ao IP

Conteúdo local fornecido pelo site

Conteúdo regional selecionado pelo serviço conforme sua própria lógica

Pode ser influenciado por configurações da conta, idioma ou preferências de histórico

A introdução da ARIN sobre Whois/RDAP explica a finalidade da consulta de informações de registro. Isso é uma camada de dados diferente da estimativa dos bancos de dados geográficos sobre “onde este endereço está em uso agora”.

A documentação da API de geolocalização da MDN, por sua vez, explica que, após obter a autorização do usuário, um site pode obter a localização por meio dos recursos de localização disponíveis no dispositivo. Portanto, o fato de um aplicativo de mapas saber em que rua você está não significa que outro site de consulta de IP deva fornecer a mesma precisão.

Por que o mesmo endereço pode corresponder a resultados de localização diferentes?

A forma como o endereço é usado mudou, mas o banco de dados não é necessariamente atualizado ao mesmo tempo

Recursos de endereço podem ser realocados, sublocados ou usados para novas saídas de rede. Serviços de localização precisam de processos separados para detectar mudanças, verificá-las e publicar atualizações; sites que usam bancos de dados offline também precisam implantar a nova versão em seus próprios sistemas.

Portanto, "o provedor de dados já corrigiu" e "todos os sites que usam esses dados já atualizaram" são duas coisas diferentes. Continuar vendo resultados antigos pode ocorrer no provedor de dados ou no banco de dados local ou cache do usuário.

Não há um prazo fixo de atualização que sirva para todas as plataformas. Não se pode afirmar que o envio foi inválido só porque não mudou após um dia; nem prometer que, corrigido em um lugar, as outras plataformas sincronizarão ao mesmo tempo.

A saída de rede nem sempre fica perto do usuário

Redes móveis, redes corporativas e VPNs separam a localização do dispositivo da localização da saída pública. Bancos de dados geográficos às vezes conseguem determinar bem a posição da saída, mas não conseguem localizar quem usa essa saída.

A explicação de precisão da MaxMind discute especificamente cenários como redes móveis e redes de privacidade, e afirma claramente que dados geográficos de IP não são suficientes para identificar uma residência, pessoa ou endereço específico.

Portanto, se a pessoa está na cidade A e a saída é localizada na cidade B, não significa necessariamente que haja um problema na linha. Primeiro é preciso esclarecer se você quer consultar a localização do dispositivo ou a localização de rede vista por serviços externos.

As duas plataformas oferecem precisões diferentes

Uma plataforma informar o país e outra informar a cidade não significa que a segunda seja mais precisa. Um campo mais detalhado pode ser apenas um ponto representativo dentro de um intervalo; a página não mostrar o raio de localização também não significa que esse raio não exista.

Mesmo que o marcador no mapa pareça cair sobre um prédio, não se pode concluir que o servidor ou usuário esteja naquele prédio. Coordenadas com mais casas decimais apenas aumentam a precisão de exibição, não a precisão dos dados.

Se a fonte de dados fornecer um intervalo de localização, leia o ponto e o intervalo juntos. Caso contrário, evite interpretar o nome de uma cidade como uma posição verificada em campo.

Redes com o mesmo nome não significam que todos os endereços têm o mesmo uso e localização

Uma organização pode operar em vários locais. Dentro do mesmo ASN, também pode haver blocos de endereços de regiões e usos diferentes.

O nome da organização e o ASN ajudam a verificar o contexto da rede, mas não permitem localizar todos os endereços da rede em uma única cidade. Uma abreviação de cidade no DNS reverso também é apenas uma pista; o nome do host pode manter uma nomenclatura antiga e não substitui outras evidências.

Antes de investigar, confirme que é realmente "o mesmo IP"

O erro de comparação mais comum geralmente não está no banco de dados, mas no objeto consultado.

Copie o endereço público completo, não apenas o país e a operadora. Confirme especialmente se as duas páginas mostram IPv4 e IPv6: eles não são o mesmo endereço e não devem ser usados diretamente para medir se dois bancos de dados são consistentes.

Registre também o horário da consulta e confirme que as configurações de rede não mudaram no meio do caminho. Seleção automática de linha pelo proxy, reconexão da rede móvel ou regras de proxy diferentes entre navegador e outros aplicativos podem alterar a saída observada.

Você pode registrar o resultado atual pelo Consulta de IP e depois comparar usando o mesmo endereço como objeto explícito de consulta. Se você digitar um domínio, lembre-se de que ele pode resolver para vários endereços; comparar servidores diferentes retornados pelo domínio não é o mesmo que comparar o mesmo IP.

Como transformar a diferença de localização em um problema tratável?

Empilhar capturas de tela e dizer "vocês estão errados" geralmente é menos útil do que o conjunto de informações abaixo.

  1. O IP completo consultado e o tipo IPv4 ou IPv6.

  2. Horário e fuso horário da consulta, para evitar tratar resultados de momentos diferentes como observações simultâneas.

  3. O nome do campo de cada resultado: país de registro, país de localização, cidade ou outra posição.

  4. Fonte dos dados, versão ou data de atualização; se não for possível obter, informe honestamente como não fornecido.

  5. Onde você acha que está errado e o material que apoia esse julgamento.

Por exemplo, "os dois bancos de dados diferem no país de localização do mesmo IPv4" é mais específico do que "os dois sites mostram localidades diferentes"; "o bloco recém-alocado para nós ainda mostra a cidade anterior" se aproxima mais de um problema que pode ser verificado pelo provedor de rede e pelo mantenedor de dados.

Os materiais também têm pesos diferentes. A região de entrega no contrato de serviço, a declaração do operador de rede e as informações verificáveis de uso de recursos geralmente dizem mais do que o fuso horário configurado no sistema operacional do servidor. O fuso horário pode ser alterado e não prova a localização física.

A quem recorrer para correção, em vez de enviar repetidamente a todos os sites

Você é usuário comum de banda larga ou rede móvel

Primeiro pergunte à operadora se há saída concentrada, gateway entre regiões ou ajuste recente na alocação de endereços. Se a saída da rede já estiver em outra região, modificar o banco de dados geográfico não transformará a rota real em uma saída local.

Se apenas o conteúdo de um aplicativo não corresponder à região esperada, enquanto os resultados de vários bancos de dados de IP são consistentes, verifique também as permissões de localização e as configurações de região da conta do aplicativo. Nesse caso, o problema pode não estar no banco de dados de IP.

Você alugou um proxy, VPS ou endereço público fixo

Peça ao provedor que esclareça a forma de entrega real e a região, e verifique se o endereço foi migrado ou realocado recentemente. Não use apenas a opção de região na página de vendas como evidência final de localização.

Se a correção envolver todo o prefixo, geralmente é mais apropriado que a operadora de rede que controla o recurso trate disso de forma unificada. O Geofeed pode ajudar as operadoras de rede a publicar informações geográficas do prefixo, mas a RFC 8805 também reserva explicitamente espaço para que os usuários verifiquem a autoridade e a precisão; publicar um arquivo não é uma instrução de atualização obrigatória para todos os bancos de dados.

Você já sabe com certeza qual é a fonte de dados errada

Use o canal oficial dessa fonte de dados. Por exemplo, a MaxMind oferece em sua documentação um portal de correção de dados geográficos. Envie fatos verificáveis conforme solicitado, em vez de pedir que mudem o endereço para a região que você deseja exibir.

A correção visa aproximar os dados do uso real, não fabricar uma falsa atribuição a um país ou cidade. Ao enviar, também não é necessário publicar o endereço residencial exato, senhas de conta ou capturas de tela do painel administrativo; forneça apenas as informações necessárias a destinatários confiáveis.

Após a correção, como confirmar se o problema realmente foi resolvido?

Guarde os registros anteriores ao envio e, após a confirmação do processamento pela parte responsável, consulte novamente o mesmo endereço e o mesmo campo, e verifique se os sites originalmente afetados também adotaram o novo resultado. Os dois podem não estar sincronizados.

Se os dados de IP já mudaram, mas um serviço ainda exibe a região antiga, o problema deve ser direcionado ao usuário do serviço: ele usa outra fonte de dados, mantém cache ou ainda tem configurações de região no nível da conta? Continuar modificando dados já corretos geralmente não ajuda.

Quanto à disponibilidade do serviço, é necessário verificar separadamente por meio de Testes de acesso a serviços e acesso real normal. A localização correta não garante que o serviço esteja aberto; o serviço acessível também não prova que a localização da cidade está correta.

As informações geográficas de IP são úteis para entender o contexto da rede, identificar desvios óbvios e iniciar correções. Tratá-las como um julgamento com limites de origem e precisão, e não como um comprovante de endereço exato de rua, se aproxima mais de seu verdadeiro propósito.

Redes transnacionais com países de localização diferentes: país de registro, Anycast e posição de saída

Considere um cenário hipotético: um provedor transnacional registra recursos de endereço no Canadá, mas o serviço é implantado nos Estados Unidos, e os bancos de dados de localização comercial e a consulta de registro mostram países diferentes. Aqui não é necessário supor Anycast, nem se pode determinar Anycast apenas pela diferença de país. Deve-se primeiro distinguir se o que se lê é o país de registro, a estimativa de localização comercial ou o nó de serviço realmente observado em uma solicitação específica; eles descrevem fatos diferentes e não se pode julgar qual está errado apenas pela "inconsistência entre dois países".

O país de registro vem dos registros de recursos no banco de dados RDAP ou Whois e descreve a atribuição administrativa do bloco de endereços, não a região onde os dispositivos finais estão. Por exemplo, um bloco registrado no Canadá mas usado por muito tempo por um data center nos EUA pode receber uma cidade americana no banco de dados geográfico; o país de registro ainda mostra Canadá. Os dois pertencem a campos diferentes e não devem ser comparados diretamente. Ao visualizar vários resultados de consulta, confirme primeiro se a página indica "país" (country), "país de registro" (registered country) ou "localização" (location).

Anycast é outra possibilidade que exige evidência independente. O mesmo endereço de serviço pode ser atendido por várias localizações, e a política de roteamento decide a instância alcançada na solicitação atual, mas não garante a seleção do nó fisicamente mais próximo. Somente quando houver suporte de declarações da operadora, medições em vários locais ou identificação de instâncias, é apropriado discutir o impacto do Anycast na localização. Dois bancos comerciais mostrarem países diferentes, por si só, não prova Anycast, nem exclui bancos desatualizados, mudanças de alocação ou implantação transnacional comum.

Ao verificar, consulte primeiro a organização, o escopo e os eventos do RDAP e use as observações BGP como contexto de roteamento. Um único ASN pode cobrir vários países, e múltiplos ASNs de origem para o mesmo prefixo têm várias explicações; nenhum deles determina sozinho a cidade do serviço. Se for possível obter declarações regionais da operadora, Geofeed mantido ou medições em vários pontos, anote os respectivos horários e escopos e reduza gradualmente o julgamento, em vez de negar diretamente a localização comercial com base no país de registro.

Na investigação, registre primeiro o endereço IPv4/IPv6 completo, o horário da consulta e os nomes dos campos fornecidos por cada plataforma. Se um endereço pertencer a Anycast ou a uma rede de nuvem transnacional, não envie correção apressadamente; verifique os anúncios de rota do prefixo e a documentação pública da operadora de rede. Qualquer julgamento de "isso certamente está errado" precisa ser formado combinando informações de registro, observações BGP e evidências de saída real. Para mais sobre a relação entre RDAP, ASN, BGP e evidências de localização, leia o RDAP, ASN, BGP e RPKI: como interpretar os dados de um IP.

Solicitação de correção: níveis de evidência, registro de tempo e limites de propagação

Os materiais de correção devem corresponder aos campos específicos. Declarações de implantação da operadora para a faixa de endereços, Geofeed mantido e região de entrega do serviço podem fornecer pistas sobre o local de uso; latência, traceroute e DNS reverso fornecem observações auxiliares. Os registros do plano de controle BGP não indicam diretamente a localização física do servidor e não podem ser listados como evidência determinante do local do datacenter. Todos os materiais devem ter autenticidade, data de atualização, escopo de aplicação e relevância para o endereço atual verificados, em vez de estabelecer uma hierarquia de autoridade universal.

Materiais mais fracos, mas consultáveis, incluem: relatos de usuários, configuração de fuso horário do sistema operacional do servidor, idioma do conteúdo do site etc. O fuso horário do sistema operacional pode ser alterado livremente e não prova a localização física do dispositivo; o idioma do site ou as configurações de região da conta refletem mais provavelmente preferências de conteúdo, não a atribuição do IP. Ao enviar correção, não carregue endereço residencial exato, senhas de conta ou capturas de tela do painel administrativo; forneça materiais públicos ou operacionais suficientes para que o mantenedor dos dados julgue o local de uso do endereço.

Registre a data, a hora e o fuso horário de cada consulta. Considere este exemplo hipotético: um endereço é realocado para uma nova região em março de 2024, mas em maio a base de geolocalização ainda não foi atualizada. Uma captura de janeiro pode, portanto, estar desatualizada como evidência para o pedido de correção. Comparar resultados do mesmo endereço em datas diferentes ajuda a distinguir uma atualização repentina em uma fonte de mudanças que se propagam entre várias fontes. Apresente uma linha do tempo dos registros antigos e novos, identificando a origem de cada resultado. Isso ajuda o responsável a conferir as evidências, mas não garante a aprovação da correção nem um prazo de atendimento.

Os provedores de dados e os sites que os utilizam são etapas diferentes de atualização. Fontes como MaxMind e IP2Location podem atualizar seus próprios bancos de dados primeiro, mas os sites que usam esses dados ainda precisam baixá-los, implantá-los e possivelmente configurar cache. Portanto, o fato de a fonte de dados mostrar um resultado novo enquanto um site ainda exibe o antigo não significa necessariamente que a fonte de dados não foi corrigida. Nesse caso, deve-se verificar separadamente: se a fonte de dados já foi corrigida; qual versão o site está usando; e se o site definiu seu próprio cache ou lógica de fallback.

Nenhum canal de correção deve prometer que "após a alteração, outras plataformas sincronizarão dentro de um prazo fixo". A publicação de Geofeed ou a correção oficial é apenas o ponto de partida da cadeia de atualização de dados. Alguns bancos de dados offline podem levar meses para lançar uma atualização, e alguns sites podem usar dados próprios ou de terceiros em vez de assinar diretamente uma fonte de dados. Não se pode esperar que uma única solicitação de alteração mude todos os resultados de consulta ao mesmo tempo. Após o envio bem-sucedido, deve-se consultar novamente o mesmo endereço e o mesmo campo após o lançamento da nova versão e confirmar em pelo menos dois momentos independentes. Se houver plataformas que realmente não atualizam por muito tempo, deve-se questionar como elas usam os dados, em vez de repetir o envio de dados já corretos.

Por fim, o objetivo da correção é tornar os dados mais próximos do uso real da rede, e não alterar o endereço para o país ou cidade que você deseja exibir. Se as evidências não forem suficientes para provar que a localização está errada, ou se a fonte de dados já indicou que o endereço pertence a Anycast ou a uma saída dinâmica, continuar enviando pode não ter efeito. Você pode entender melhor como os bancos de dados geográficos são atualizados e validados por meio de Fontes de dados e metodologia.