Trafic inhabituel Google sur une sortie VPN partagée : appareil ou IP ?

Devoir prouver que vous êtes humain ressemble à une accusation, et la conclusion évidente est que quelque chose sur la tablette est infecté. Cette conclusion saute une étape. Une sortie VPN partagée place de nombreuses sessions sans lien derrière une seule adresse publique, et l'avertissement réagit à la requête telle qu'elle arrive, ce qui inclut cette adresse. Décider si le schéma appartient à votre appareil ou à la sortie demande trois tests courts, et la bonne réponse change ce que vous faites ensuite.

Ce à quoi l'avertissement réagit vraiment

Les conseils de Google sur le trafic inhabituel citent les réseaux partagés et les services VPN parmi les situations qui provoquent le défi, aux côtés des requêtes automatisées depuis un appareil. L'adresse publique est un signal sur un groupe d'utilisateurs, pas une empreinte d'une seule personne. Les adresses accumulent une réputation à partir de tout ce qui les utilise, y compris le trafic que vous ne voyez jamais.

Cela coupe dans les deux sens, et c'est pourquoi l'avertissement ne prouve aucune des deux histoires. Le défi reste volontairement vague sur le signal déclenché, alors traitez-le comme une invitation à réunir des preuves, pas comme un verdict.

Trois tests qui séparent l'appareil de la sortie

D'abord, emportez le même appareil sur un autre réseau approuvé et refaites une recherche ordinaire. Si le défi suit l'appareil d'une connexion sans lien à l'autre, l'adresse n'est pas la variable et vous devez regarder les extensions, l'automatisation et tout ce que l'appareil exécute. Si l'appareil est propre ailleurs et ne pose problème que sur une connexion, vous avez appris quelque chose sur le chemin. Faites cette comparaison avant de changer le moindre réglage, pour qu'elle reste propre.

Ensuite, utilisez un autre appareil via la même sortie et tentez la même recherche. Deux appareils mis au défi dans la même fenêtre pointent vers l'adresse partagée ; un seul appareil mis au défi renvoie à cet appareil.

Troisièmement, regardez le moment. Un avertissement qui n'apparaît qu'à certaines heures suggère une charge sur la sortie plutôt que quelque chose installé localement. Comparez un soir de semaine avec un matin calme, car une sortie partagée suit l'emploi du temps des autres.

Réagir sans désactiver vos propres contrôles

Accomplissez l'étape de vérification humaine lorsqu'elle est proposée, et essayez un navigateur pris en charge si le défi ne s'affiche pas, car un script bloqué ou une extension peut faire paraître cassée une vérification pourtant résoluble. Ne martelez pas la page et n'ajoutez pas de script autour, car les tentatives répétées depuis la même sortie rendent l'adresse pire pour tous ceux qui sont derrière. Si le schéma persiste, contactez le fournisseur avec l'identifiant de la sortie et les heures approximatives, et demandez ce qu'il peut voir de l'activité de l'adresse partagée.

Il n'y a aucune raison d'envoyer à un fournisseur votre historique de recherche ou vos identifiants VPN, et un agent de support qui demande l'un ou l'autre mérite d'être questionné.

Changer de sortie pour contourner la vérification n'est pas un diagnostic, et selon votre fournisseur cela peut vous placer sur une adresse encore moins riche en historique.

Ce que change une adresse dédiée

Une adresse dédiée retire les autres utilisateurs de l'équation et laisse en place l'historique antérieur, vos schémas de requêtes et les signaux au niveau du compte. Elle peut aider, et ce n'est pas une guérison garantie, car une adresse neuve déjà utilisée pour du trafic massif porte ce passé avec elle. La formulation honnête est que vous achetez un isolement vis-à-vis des autres clients, pas une réputation propre.

Le résultat utile de tout cela est une phrase que vous pouvez défendre : l'avertissement suit cet appareil, ou il suit ce chemin partagé, ou il apparaît sous charge indépendamment des deux. Le reste est une supposition sur le trafic de quelqu'un d'autre.

Si une équipe partage une sortie, la même logique s'applique à plus grande échelle : un client bruyant affecte tous ceux qui sont derrière l'adresse, et la correction vit généralement à l'intérieur de l'équipe plutôt que dans un nouveau serveur.