Pourquoi un site connaît encore votre ville malgré un VPN

Deux mécanismes peuvent afficher une ville à l’écran et un seul se soucie de l’endroit d’où sort votre VPN. L’API Geolocation du navigateur renvoie une position d’appareil quand la page a l’autorisation, et une recherche IP estime une région à partir de l’adresse d’où la requête est arrivée. Un site qui affiche votre vraie ville alors que le tunnel tourne dans un autre pays utilise généralement le premier mécanisme, ou lit une ville qu’il a enregistrée il y a des mois. Cinq étapes séparent ces cas.

Première étape : décider quel mécanisme peut répondre

Commencez par demander ce que la page peut savoir. Une position d’appareil exige un appel à l’API et une décision d’autorisation, et elle produit une coordonnée précise. Une estimation par IP n’exige rien de l’utilisateur et produit au mieux une ville, souvent fausse. Une préférence de compte enregistrée n’exige ni l’un ni l’autre et survit à chaque changement de réseau.

Ces trois sources expliquent presque tous les signalements. Un site de cartes qui se centre sur votre rue utilise l’API. Une boutique qui vous accueille dans la mauvaise langue utilise une estimation par IP. Un site d’actualités qui continue d’afficher votre ville natale après un déménagement utilise ce que votre compte a enregistré.

Deuxième étape : lire l’autorisation pour cette origine exacte

Les navigateurs retiennent la décision d’autorisation par origine, donc un site que vous avez autorisé l’an dernier s’ouvre sans nouvelle demande. Examinez l’entrée de localisation pour ce site précis dans les paramètres de sites du navigateur plutôt que la valeur globale par défaut, car le réglage global décide seulement de ce qui se passe quand rien n’est enregistré.

Vérifiez ensuite le système d’exploitation. Un navigateur sur un ordinateur ou un téléphone moderne a aussi besoin de l’autorisation de localisation de la plateforme, et une autorisation de plateforme refusée fait échouer l’API même quand le site est autorisé. La position disponible peut venir des services de la plateforme, qui n’ont rien à voir avec le tunnel.

Deux conditions techniques expliquent la plupart des échecs qui ressemblent à des problèmes de VPN. L’API exige un contexte sécurisé, donc une simple page HTTP ne peut pas l’utiliser du tout, et les cadres intégrés peuvent être bloqués par la Permissions Policy de la page. Une requête refusée est donc bien plus souvent le résultat du navigateur ou de la politique de la page que du réseau.

Troisième étape : confirmer l’adresse de sortie avec une requête neuve

Demandez à un service indépendant quelle adresse il voit, depuis le même navigateur que vous testez. Un onglet périmé, un service worker ou une page en cache peuvent rapporter la réponse d’hier, et comparer une réponse neuve à ce que le site affiche lève ce doute.

curl -s https://ifconfig.me
curl -s https://ipinfo.io/json

Exécutez-les depuis la machine, pas depuis le routeur, et notez l’adresse et le pays que chacun renvoie. Si les deux indiquent le pays du VPN et que le site affiche toujours votre ville natale, la sortie n’est pas la source, et les candidats restants sont l’autorisation, les données enregistrées et un chemin de fuite.

Les chemins de fuite sont la troisième possibilité : une extension de navigateur avec sa propre pile réseau, une route split-tunnel qui envoie le site hors du tunnel, ou un chemin IPv6 que le tunnel ne transporte pas. Chacun est visible dans la requête elle-même, c’est pourquoi la vérification de sortie précède tout changement de réglage. Une extension avec ses propres réglages de proxy est celle que les gens manquent, car elle peut contourner le tunnel pour un seul onglet.

Quatrième étape : regarder ce que le compte a déjà enregistré

Révoquer l’autorisation affecte l’accès futur selon les règles du navigateur et ne supprime pas une position que le service a déjà enregistrée. Une ville natale enregistrée, une adresse de livraison ou une région de profil restent jusqu’à ce que l’application les mette à jour, et le site peut encore faire une estimation approximative à partir de l’adresse de sortie.

Cherchez le contrôle de localisation propre au site avant de conclure que le navigateur est en cause. Beaucoup d’applications gardent un sélecteur de région manuel qui supplante toute estimation automatique, et un agent de support qui lit le dossier du compte voit cette valeur plutôt que votre connexion actuelle.

Là où la valeur enregistrée compte, changez-la dans le compte et notez la date. Cela vous donne un second point de données quand l’ancienne ville réapparaît. Une capture d’écran de la page du compte avant le changement vaut plus qu’une description après.

Cinquième étape : changer une variable à la fois

Testez dans un ordre fixe : vérification de sortie neuve, autorisation de l’origine, autorisation de la plateforme, réglage du compte, puis un autre profil de navigateur. Changer plusieurs choses à la fois rend la source non identifiable, et c’est ainsi qu’une réponse en cinq minutes devient une semaine de spéculation.

Notez ce que vous avez changé et ce que la page a affiché ensuite. Si l’affichage ne change que dans une fenêtre privée, la cause est un état enregistré ; s’il ne change jamais, la page utilise une estimation par IP ou une valeur de compte que le navigateur ne peut pas influencer. Gardez l’avant et l’après dans la même note, car le schéma est la preuve.

Restez honnête dans la conclusion : un VPN change l’adresse d’où arrive une requête, et l’API Geolocation est un canal séparé soumis à autorisation que le tunnel ne touche pas. Les deux faits peuvent être vrais en même temps, et la plupart des signalements confus viennent du fait de les traiter comme des alternatives.