Por que un sitio web segue coñecendo a túa cidade a través dunha VPN
Un sitio pode usar o permiso de localización do navegador e a túa IP pública de forma independente: comproba o permiso da orixe, o axuste do sistema e a cidade gardada.
Dous mecanismos poden poñer unha cidade na pantalla e só un deles se preocupa por onde sae a túa VPN. A API Geolocation do navegador devolve unha posición do dispositivo cando a páxina ten permiso, e unha consulta de IP estima unha rexión a partir do enderezo desde o que chegou a solicitude. Un sitio que mostra a túa cidade real mentres o túnel funciona noutro país adoita usar o primeiro mecanismo, ou le unha cidade que gardou hai meses. Cinco pasos separan eses casos.
Primeiro paso: decide que mecanismo pode responder
Comeza preguntando que pode saber a páxina. Unha posición do dispositivo require unha chamada á API e unha decisión de permiso, e produce unha coordenada precisa. Unha estimación por IP non require nada do usuario e produce unha cidade no mellor dos casos, a miúdo equivocada. Unha preferencia de conta gardada non require ningunha das dúas cousas e sobrevive a cada cambio de rede.
Esas tres fontes explican case todos os informes. Un sitio de mapas que se centra na túa rúa usa a API. Unha tenda que te saúda no idioma equivocado usa unha estimación por IP. Un sitio de noticias que segue mostrando a túa cidade natal tras unha mudanza usa o que gardou a túa conta.
| 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 paso: le o permiso para esa orixe exacta
Os navegadores lembran a decisión de permiso por orixe, así que un sitio que permitiches o ano pasado ábrese sen unha petición nova. Revisa a entrada de localización para ese sitio concreto nos axustes de sitios do navegador en lugar do valor global predeterminado, porque o axuste global só decide que ocorre cando non hai nada gardado.
Despois revisa o sistema operativo. Un navegador nun ordenador ou teléfono moderno tamén necesita o permiso de localización da plataforma, e un permiso de plataforma denegado fai fallar a API mesmo cando o sitio está permitido. A posición dispoñible pode vir dos servizos da plataforma, que non teñen nada que ver co túnel.
Dúas condicións técnicas explican a maioría dos fallos que parecen problemas de VPN. A API esixe un contexto seguro, así que unha páxina HTTP simple non pode usala en absoluto, e os marcos incrustados poden bloquearse pola Permissions Policy da páxina. Unha solicitude denegada é, por tanto, moito máis a miúdo un resultado do navegador ou da política da páxina que da rede.
Terceiro paso: confirma o enderezo de saída cunha solicitude nova
Pregunta a un servizo independente que enderezo ve, desde o mesmo navegador que estás probando. Unha pestana obsoleta, un service worker ou unha páxina na caché poden informar da resposta de onte, e comparar unha resposta nova co que mostra o sitio elimina esa dúbida.
curl -s https://ifconfig.me
curl -s https://ipinfo.io/jsonExecútaos desde a máquina, non desde o router, e anota o enderezo e o país que devolve cada un. Se ambos informan do país da VPN e o sitio segue mostrando a túa cidade natal, a saída non é a fonte e os candidatos restantes son o permiso, os datos gardados e un camiño de fuga.
Os camiños de fuga son a terceira posibilidade: unha extensión do navegador coa súa propia pila de rede, unha ruta split-tunnel que envía o sitio fóra do túnel, ou un camiño IPv6 que o túnel non transporta. Cada un é visible na propia solicitude, por iso a comprobación de saída vai antes de calquera cambio de axustes. Unha extensión con axustes de proxy propios é a que a xente pasa por alto, porque pode saltarse o túnel para unha soa pestana.
Cuarto paso: mira o que xa gardou a conta
Revogar o permiso afecta o acceso futuro segundo as regras do navegador e non borra unha posición que o servizo xa gardou. Unha cidade natal gardada, un enderezo de entrega ou unha rexión de perfil quedan ata que a aplicación as actualice, e o sitio aínda pode facer unha estimación aproximada a partir do enderezo de saída.
Busca o control de localización propio do sitio antes de concluír que o navegador ten a culpa. Moitas aplicacións manteñen un selector de rexión manual que anula toda estimación automática, e un axente de soporte que le o rexistro da conta ve ese valor en lugar da túa conexión actual.
Cando o valor gardado importa, cámbiao na conta e anota a data. Iso dache un segundo punto de datos cando a cidade antiga volva aparecer. Unha captura de pantalla da páxina da conta antes do cambio vale máis que unha descrición despois.
Quinto paso: cambia unha variable á vez
Proba nunha orde fixa: comprobación de saída nova, permiso da orixe, permiso da plataforma, axuste da conta e logo outro perfil de navegador. Cambiar varias cousas á vez fai que a fonte non se poida identificar, e así é como unha resposta de cinco minutos se converte nunha semana de especulación.
Anota que cambiaches e que mostrou a páxina despois. Se a visualización só cambia nunha ventá privada, a causa é un estado gardado; se nunca cambia, a páxina usa unha estimación por IP ou un valor de conta que o navegador non pode influír. Mantén o antes e o despois na mesma nota, porque o patrón é a proba.
Sé honesto na conclusión: unha VPN cambia o enderezo desde o que chega unha solicitude, e a API Geolocation é unha canle aparte con permiso que o túnel non toca. Ambos os feitos poden ser certos á vez, e a maioría dos informes confusos veñen de tratalos como alternativas.