Por que um site ainda sabe sua cidade mesmo com uma VPN
Um site pode usar a permissão de localização do navegador e seu IP público de forma independente: verifique a permissão da origem, a configuração do sistema e a cidade guardada.
Dois mecanismos podem colocar uma cidade no ecrã e só um deles se importa com o local de saída da sua VPN. A API Geolocation do navegador devolve uma posição do dispositivo quando a página tem permissão, e uma consulta de IP estima uma região a partir do endereço de onde o pedido chegou. Um site que mostra a sua cidade real enquanto o túnel corre noutro país usa normalmente o primeiro mecanismo, ou lê uma cidade que guardou há meses. Cinco passos separam esses casos.
Primeiro passo: decidir qual mecanismo pode responder
Comece por perguntar o que a página pode saber. Uma posição do dispositivo exige uma chamada à API e uma decisão de permissão, e produz uma coordenada precisa. Uma estimativa por IP não exige nada do utilizador e produz uma cidade no melhor caso, muitas vezes errada. Uma preferência de conta guardada não exige nenhuma das duas e sobrevive a cada mudança de rede.
Essas três fontes explicam quase todos os relatos. Um site de mapas que se centra na sua rua usa a API. Uma loja que o cumprimenta no idioma errado usa uma estimativa por IP. Um site de notícias que continua a mostrar a sua cidade natal depois de uma mudança usa o que a sua conta guardou.
| What the page shows | Likely source |
|---|---|
| Street-level accuracy | Device position from the Geolocation API |
| City or region only | IP geolocation of the exit address |
| Same city for months | Stored account preference |
| Different result in a private window | Stored permission or cached state |
Segundo passo: ler a permissão para essa origem exata
Os navegadores lembram a decisão de permissão por origem, por isso um site que autorizou no ano passado abre sem um novo pedido. Reveja a entrada de localização para esse site específico nas definições de sites do navegador em vez do valor global predefinido, porque a definição global só decide o que acontece quando nada está guardado.
Depois verifique o sistema operativo. Um navegador num computador ou telefone moderno também precisa da permissão de localização da plataforma, e uma permissão de plataforma recusada faz a API falhar mesmo quando o site está autorizado. A posição disponível pode vir dos serviços da plataforma, que não têm nada a ver com o túnel.
Duas condições técnicas explicam a maioria das falhas que parecem problemas de VPN. A API exige um contexto seguro, por isso uma página HTTP simples não a pode usar de todo, e as molduras incorporadas podem ser bloqueadas pela Permissions Policy da página. Um pedido recusado é, portanto, muito mais vezes um resultado do navegador ou da política da página do que da rede.
Terceiro passo: confirmar o endereço de saída com um pedido novo
Pergunte a um serviço independente que endereço vê, a partir do mesmo navegador que está a testar. Um separador antigo, um service worker ou uma página em cache podem relatar a resposta de ontem, e comparar uma resposta nova com o que o site mostra elimina essa dúvida.
curl -s https://ifconfig.me
curl -s https://ipinfo.io/jsonExecute os comandos a partir da máquina, não do router, e anote o endereço e o país que cada um devolve. Se ambos indicarem o país da VPN e o site ainda mostrar a sua cidade natal, a saída não é a fonte, e os candidatos restantes são a permissão, os dados guardados e um caminho de fuga.
Os caminhos de fuga são a terceira possibilidade: uma extensão do navegador com a sua própria pilha de rede, uma rota split-tunnel que envia o site para fora do túnel, ou um caminho IPv6 que o túnel não transporta. Cada um é visível no próprio pedido, por isso a verificação de saída vem antes de qualquer alteração de definições. Uma extensão com definições de proxy próprias é a que as pessoas deixam passar, porque pode contornar o túnel para um único separador.
Quarto passo: ver o que a conta já guardou
Revogar a permissão afeta o acesso futuro segundo as regras do navegador e não apaga uma posição que o serviço já guardou. Uma cidade natal guardada, uma morada de entrega ou uma região de perfil ficam até a aplicação as atualizar, e o site ainda pode fazer uma estimativa aproximada a partir do endereço de saída.
Procure o controlo de localização do próprio site antes de concluir que o navegador é o culpado. Muitas aplicações mantêm um seletor de região manual que anula todas as estimativas automáticas, e um agente de apoio que lê o registo da conta vê esse valor em vez da sua ligação atual.
Onde o valor guardado importa, altere-o na conta e anote a data. Isso dá-lhe um segundo ponto de dados quando a cidade antiga voltar a aparecer. Uma captura de ecrã da página da conta antes da alteração vale mais do que uma descrição depois.
Quinto passo: mudar uma variável de cada vez
Teste numa ordem fixa: verificação de saída nova, permissão da origem, permissão da plataforma, definição da conta e depois outro perfil de navegador. Alterar várias coisas ao mesmo tempo torna a fonte não identificável, e é assim que uma resposta de cinco minutos se torna uma semana de especulação.
Anote o que alterou e o que a página mostrou depois. Se a visualização só muda numa janela privada, a causa é um estado guardado; se nunca muda, a página usa uma estimativa por IP ou um valor de conta que o navegador não pode influenciar. Mantenha o antes e o depois na mesma nota, porque o padrão é a prova.
Seja honesto na conclusão: uma VPN muda o endereço de onde chega um pedido, e a API Geolocation é um canal separado com permissão que o túnel não toca. Os dois factos podem ser verdadeiros ao mesmo tempo, e a maioria dos relatos confusos vem de os tratar como alternativas.