Commencez par identifier qui a émis l'alerte VPN
Lorsqu'une page affiche « proxy ou VPN détecté », il faut d'abord distinguer de quelle couche provient le message. La première catégorie, la plus courante, repose sur les étiquettes de classification des fournisseurs de renseignements IP : le site appelle leur API pour vérifier si l'adresse de connexion actuelle figure dans des listes d'hébergement, de proxy ou de réseaux anonymes, puis affiche directement l'avertissement de risque. La deuxième catégorie correspond aux règles de refus maintenues par le site lui-même, par exemple autoriser uniquement les adresses de certains pays ou de certains ASN, ou mettre en liste noire des plages CIDR entières suite à des abus récents. La troisième catégorie est la détection de l'environnement du navigateur : via JavaScript, elle lit les candidats WebRTC, les résultats de résolution DNS, le fuseau horaire ou la langue, et déclenche un avertissement en cas d'incohérence avec la connexion principale de la page.
Ces trois types de jugement reposent sur des bases et des fiabilités totalement différentes. Les étiquettes des fournisseurs de données proviennent généralement d'observations historiques et de soumissions de tiers, avec des mises à jour irrégulières, et peuvent contenir des entrées périmées. Les règles personnalisées des sites ne visent souvent que leur propre expérience et ne constituent pas une conclusion universelle. La détection du navigateur mêle configuration de l'appareil et environnement réseau, et ne pointe pas nécessairement vers un vrai VPN. Beaucoup de plateformes ne donnent qu'un message vague sans preuve concrète ; si vous prenez cet avertissement comme « confirmation que vous utilisez un VPN », vous sautez l'étape de diagnostic réel.
La plupart des sites fondent leur jugement sur les requêtes visibles, les bases d'adresses et leurs propres règles, sans pouvoir observer directement le tunnel chiffré complet entre l'appareil de l'utilisateur et la passerelle VPN distante. Un avertissement de page ne prouve donc pas que votre protocole VPN a été détecté. Vérifiez d'abord l'étiquette et sa source dans Détection des VPN et proxys, puis examinez la configuration du proxy système, les tunnels d'entreprise et la sortie de l'opérateur pour déterminer s'il s'agit d'un problème de configuration, d'anciens enregistrements ou de la politique du site cible.
Quelle différence entre les étiquettes VPN, proxy, Tor et hébergement ?
Un VPN établit une connexion réseau virtuelle ; les VPN d'accès à distance courants utilisent des tunnels chiffrés, mais tous les réseaux appelés VPN ne se définissent pas par le chiffrement. Un proxy transfère généralement les requêtes pour une catégorie d'applications ou de protocoles, le chiffrement dépendant de l'implémentation. Le nœud de sortie Tor représente la connexion du circuit vers le service internet cible, et un relais ordinaire n'a pas forcément de rôle de sortie. L'étiquette d'hébergement est un indice de classification des fournisseurs de données pour les centres de données ou infrastructures cloud. Ces concepts peuvent se chevaucher, mais ne sont pas interchangeables.
Ne confondez pas hébergement et VPN, ni VPN et malveillance. L'utilisation d'un VPN par une entreprise pour permettre à ses employés d'accéder à distance aux systèmes internes est une pratique de sécurité courante ; l'utilisation d'un VPN commercial par un particulier relève d'un choix légitime de confidentialité. De nombreux sites refusent directement les adresses d'hébergement, car une grande partie du trafic automatisé et des attaques provient de centres de données, et non parce que cette adresse exécute forcément un service VPN. À l'inverse, une adresse haut débit résidentielle peut être temporairement utilisée comme sortie, d'où la nécessité d'une classification tenant compte du temps et des sources d'observation.
Les listes Tor doivent être lues avec la source, la date de mise à jour et le rôle du nœud : une correspondance avec une liste de sortie actuelle signifie seulement que cette source a enregistré cette IP comme sortie au moment concerné ; l'absence de correspondance ne prouve pas l'absence d'utilisation de Tor. Les relais ordinaires, les nœuds pont et les nœuds de sortie ont des fonctions différentes ; on ne peut pas traiter tous les nœuds comme la source d'accès au site cible. Une sortie désactivée peut rester dans certaines bases à cause du retard de mise à jour ; consultez l'entrée spécifique plutôt qu'une simple étiquette.
D'où proviennent les preuves de classification IP ?
Les principaux moyens pour les sites web ou systèmes anti-fraude d'obtenir le contexte d'une IP sont : les enregistrements d'allocation d'adresses publiés par les registres internet régionaux, les bases de classification des fournisseurs commerciaux, les listes de plages d'adresses publiées par les fournisseurs de cloud, et leurs propres observations accumulées à partir du trafic d'attaques ou des comportements de connexion. Un préfixe public officiel indique seulement à qui un CIDR a été alloué, par exemple un fournisseur de cloud ou un FAI, et non la localisation physique de la connexion actuelle ni l'utilisation d'un tunnel. Des sources de données autorisées peuvent fournir des étiquettes proxy ou Tor, mais leur fréquence de mise à jour et leurs règles de détermination sont souvent opaques.
RDAP peut fournir l'organisation d'enregistrement, la plage, les événements et les rôles de contact d'une ressource d'adresse ; l'ASN identifie le système autonome. BGP montre les annonces de routage observées ; la validation d'origine RPKI vérifie si le préfixe et l'ASN d'origine correspondent à une autorisation valide, sans valider le chemin complet ni le comportement de l'utilisateur. Une organisation d'enregistrement appartenant à un fournisseur de cloud est un indice contextuel, mais ne prouve pas à elle seule l'utilisation d'un VPN par l'appareil actuel, et un état RPKI Valid ne constitue pas une preuve de bonne réputation de l'adresse.
Pour savoir comment utiliser les informations RDAP et ASN dans l'évaluation, consultez RDAP, ASN, BGP et RPKI : comprendre les données d’une IP. Ne vous fiez pas à une seule étiquette pour conclure. Les observations de trafic réelles peuvent être biaisées, par exemple une adresse partagée abusée par quelques utilisateurs, entraînant la mise en liste noire de toute l'IP. La classification des fournisseurs de données peut mélanger plages d'hébergement et plages VPN, ou omettre de nouveaux services anonymes. Plus la preuve est spécifique, plus elle est fiable : heure, source, adresse, liste mise à jour ont plus de valeur qu'une simple conclusion de « risque élevé ».
Ordre de diagnostic lorsqu'un haut débit classique est signalé
Lorsqu'une adresse de haut débit résidentiel ou de point d'accès mobile est signalée comme proxy, vérifiez d'abord les paramètres locaux. Le système d'exploitation ou le navigateur peut avoir un proxy manuel configuré, certaines extensions modifient la sortie ; un ordinateur d'entreprise peut avoir un VPN imposé ou un tunnel de sécurité. Vérifiez ensuite l'environnement réseau actuel : une passerelle d'entreprise peut diriger tout le trafic vers un centre de données, un opérateur peut utiliser le CGNAT pour que plusieurs utilisateurs partagent une même adresse IPv4 publique. Le partage signifie que la même adresse peut être utilisée simultanément par d'autres, héritant ainsi de leurs étiquettes de risque.
L'allocation dynamique, le transfert d'adresse ou le changement d'usage peuvent rendre les anciennes étiquettes incohérentes avec l'environnement actuel, mais confirmez d'abord l'enregistrement réel d'allocation, sans supposer que toutes les adresses haut débit dynamiques ont servi à un VPS. Une requête RDAP publique fournit généralement l'enregistrement actuel et certains champs d'événements, sans garantir d'instantanés historiques complets. Vous pouvez vérifier auprès de l'opérateur l'heure d'allocation de l'adresse, puis la comparer à l'entrée de liste et à sa date de mise à jour ; lors de la vérification séparée d'IPv4 et d'IPv6, assurez-vous également que les deux requêtes portent bien sur la même trajectoire de service.
Ce type d'investigation nécessite de combiner les idées de Trouver son IP publique et vérifier la présence de CGNAT : confirmez si l'adresse que vous voyez est une adresse publique ou une adresse interne de l'opérateur. Si c'est du CGNAT, la sortie visible vers l'extérieur diffère de l'adresse locale de votre machine, et les étiquettes de risque peuvent provenir d'autres utilisateurs du même pool. Ne concluez pas immédiatement à une erreur de base de données ; votre environnement peut effectivement comporter un tunnel d'entreprise ou un proxy de point d'accès. Notez l'heure, le type de réseau et l'adresse du moment, puis comparez avec l'heure de jugement indiquée par le site pour identifier la cause de la mauvaise classification.
Cas illustratif : réseau d'entreprise et point d'accès mobile
Supposons qu'un employé utilise un ordinateur professionnel au bureau pour accéder à un service restreint à certaines régions, et que la page affiche « VPN détecté ». Le même employé se connecte au même service via un point d'accès mobile, et le message disparaît. Ce cas est purement illustratif et ne représente aucun test réel. Une cause possible est que la sortie du réseau d'entreprise passe par un VPN d'entreprise ou une passerelle de sécurité, et que l'adresse de sortie se trouve dans une plage de centre de données, étiquetée comme hébergée ou proxy par le fournisseur de données. Le point d'accès mobile utilise une adresse d'opérateur, de type résidentiel ou mobile, et ne déclenche pas la même règle.
Dans ce scénario hypothétique, vous devez noter séparément le type de réseau, l'heure d'accès, l'IP de sortie respective et la présence éventuelle d'un tunnel d'entreprise pour l'ordinateur professionnel et le point d'accès mobile. L'ordinateur professionnel peut être configuré avec un VPN global ou un proxy, et la résolution DNS correspond à la sortie de connexion ; le point d'accès mobile n'a pas ces paramètres. Même si les IP de sortie sont différentes, vous ne pouvez pas attribuer directement le problème à un employé spécifique, car la sortie d'entreprise est généralement partagée et de nombreux employés peuvent utiliser la même adresse au même moment.
Pour approfondir, vérifiez la table de routage ou les paramètres de proxy système de l'ordinateur professionnel afin de confirmer si le trafic est forcé à passer par un tunnel ; consultez les informations RDAP de l'IP de sortie : si elle appartient à un fournisseur de cloud ou à une plage d'hébergement, cela correspond aux règles de risque du site. Les enregistrements du point d'accès mobile servent de groupe témoin, montrant que le même compte, le même appareil (si le téléphone partage la connexion mais que vous utilisez toujours le navigateur de l'ordinateur) donnent des résultats différents selon le réseau. Cet exemple illustre que le message de la page peut provenir de l'environnement réseau et non d'un VPN activé par l'utilisateur, et qu'avec une sortie partagée, l'attribution à un individu est impossible.
Comment comparer lorsque plusieurs sites de détection donnent des résultats contradictoires ?
Il est courant que différents sites attribuent des étiquettes différentes à la même IP. Lors de la comparaison, examinez d'abord la définition de « proxy » ou « VPN » de chaque source : certains considèrent les plages d'hébergement comme des proxys, d'autres n'identifient que les sorties VPN commerciales ; certains incluent les sorties Tor, d'autres les excluent. Ensuite, regardez les horodatages : une liste peut avoir été mise à jour il y a deux jours, une autre vient d'être analysée, d'où des résultats différents. L'adresse interrogée a aussi un impact : vous voyez l'adresse IPv4 de la connexion principale de la page, mais une fuite WebRTC peut en révéler une autre, une adresse IPv6, et le site peut juger sur une adresse différente.
Les différences de couverture sont également importantes. Certains fournisseurs de données ne couvrent que les plages des grands fournisseurs de cloud, sans reconnaître les petits VPS ou les proxys émergents ; d'autres peuvent marquer tout un pays ou une plage d'opérateur comme à haut risque. La gestion des IPv4 et IPv6 est indépendante, et le même service peut donner des résultats différents pour les deux protocoles. Consultez en priorité les enregistrements bruts, comme les informations d'attribution renvoyées par RDAP, les instantanés de routage BGP, ou l'heure et la raison précises des entrées de liste noire, plutôt que de vous fier uniquement au score affiché par le site.
Ne faites pas un simple vote entre plusieurs sites ; qu'une majorité dise « oui » ne prouve pas le fait. Ne prenez pas non plus la confiance maximale d'un site pour une probabilité. La confiance est un score interne du fournisseur de données, influencé par l'historique d'abus ou les sorties partagées, sans calibration publique. La bonne approche consiste à noter la définition de chaque source, l'heure de mise à jour, l'adresse interrogée et les preuves brutes, puis à interpréter selon votre environnement réseau. Inconnu ne signifie pas sûr ; l'absence de correspondance peut être due à une omission de la liste. Une classification ne signifie pas malveillance : une plage d'hébergement marquée n'indique pas un comportement inapproprié de l'utilisateur.
Comment afficher « aucune correspondance » et « inconnu » sans induire en erreur
Les résultats de requête doivent distinguer quatre cas : liste vide, délai d'attente du service, source expirée, requête réussie sans correspondance, et ne doivent pas tous être affichés en vert comme sûrs. Une liste vide peut signifier que la source de données actuelle n'a pas encore intégré d'enregistrement pertinent, ou que l'initialisation du système est incomplète ; un délai d'attente signifie que l'interface amont n'a pas répondu dans le temps prévu, ce qui n'équivaut pas à une absence de risque ; une source expirée indique que l'horodatage du cache local est antérieur à la fenêtre de vérification, et le résultat peut ne plus refléter la situation actuelle ; seule une requête réussie renvoyant explicitement « aucune correspondance » permet de dire qu'aucune entrée ne correspond aux règles actuelles de cette source. L'absence de correspondance n'est pas une garantie de sécurité, car la couverture des sources de données est limitée et aucune liste ne peut répertorier de manière exhaustive tous les proxys, VPN ou sorties abusives.
Les informations de géolocalisation IP, l'ASN, le BGP et le RPKI décrivent une estimation de localisation, un contexte d'enregistrement et un état de routage, pas une preuve de comportement malveillant. Qu'un ASN annonce un préfixe ne signifie pas que chaque adresse de la plage a le même usage ; qu'un enregistrement RDAP indique un fournisseur de cloud ne signifie pas que l'IP actuelle exécute un proxy. La page doit préciser clairement si l'étiquette décrit une infrastructure, un comportement historique ou un événement en temps réel, afin que le lecteur sache à quel objet et à quel moment la conclusion s'applique.
La couche d'affichage doit exprimer les différents états par des niveaux visuels distincts, et indiquer explicitement dans le texte que « aucun enregistrement » ne signifie pas « réussi ». Par exemple, suivant le traitement mentionné dans Réputation IP : comprendre les scores et listes de blocage, il est conseillé de proposer une nouvelle tentative pour les délais d'attente et les données expirées, et d'annoter « non trouvé dans la source actuelle, mais un risque non couvert peut exister » pour les absences de correspondance. Si l'utilisateur voit une icône verte, il doit au moins savoir à quelles conditions précises correspond le vert. L'opérateur peut aussi enregistrer la version et l'horodatage de la source de données de chaque requête pour faciliter une vérification ultérieure. Cela évite les mauvaises interprétations et constitue une chaîne de preuves en cas de contestation.
Le taux de faux positifs n'est pas le taux de précision
Supposons un test avec 1000 adresses indépendantes, dont 25 vrais proxys et 975 non-proxys. Le classifieur marque 30 adresses comme proxys, dont 20 correctement identifiées comme vrais proxys et 10 faux positifs ; il marque 970 adresses comme non-proxys, dont 5 faux négatifs (vrais proxys manqués) et 965 correctement exclus. La précision est alors precision = 20/30 ≈ 0,667, le rappel recall = 20/25 = 0,8, et le taux de faux positifs FPR = 10/975 ≈ 0,0103. Cette matrice de confusion est illustrative, pas une mesure réelle de ce site, car il faut des données supervisées avec des étiquettes de vérité terrain pour la calculer.
L’exactitude globale (accuracy) est la proportion de prédictions correctes sur l’ensemble des prédictions : ici, (20+965)/1000 = 0,985. Ce résultat paraît élevé, mais les adresses qui ne sont pas des proxys constituent la majorité de l’échantillon. Les nombreux vrais négatifs peuvent donc donner une exactitude globale élevée tout en masquant les faux positifs parmi les adresses signalées. Il faut aussi examiner le FPR et la précision (precision). Si l’étiquette « proxy » entraîne directement un blocage, 10 des 30 adresses signalées seront bloquées alors qu’elles ne sont pas des proxys. Le nombre d’adresses ne permet pas de déduire le nombre de personnes concernées. Plus le trafic légitime est important, plus les erreurs peuvent toucher de requêtes. La proportion de proxys, le chevauchement avec les listes de blocage historiques et la répartition de la population évaluée peuvent également modifier ces indicateurs.
On ne peut donc pas assimiler simplement la précision au taux de faux positifs perçu par l'utilisateur. Pour montrer la qualité de la détection, il faut communiquer en même temps la taille de l'échantillon, la définition des cas positifs, la fenêtre temporelle et la répartition des sources. Sinon, un chiffre de précision élevé peut masquer de nombreux faux positifs. Pour l'utilisateur ordinaire, face à une étiquette « proxy », il doit savoir de quelle source de données elle provient, à quelle entrée précise elle correspond et quand elle a été mise à jour pour la dernière fois. Si ce contexte ne peut être fourni, l'étiquette elle-même mérite d'être remise en question. Les équipes d'exploitation ne devraient pas non plus bloquer sur la base d'une seule étiquette.
Les tests de fuite du navigateur sont un autre problème
WebRTC, DNS et la réputation IP répondent à des questions différentes. WebRTC peut collecter des candidats host, srflx ou relay, et l'exposition réelle dépend de la politique de confidentialité du navigateur et de la configuration réseau ; les requêtes HTTP sont transmises selon les règles de proxy et de routage ; les tests DNS voient généralement l'adresse source de la requête du résolveur récursif vers le serveur faisant autorité du test. Des adresses différentes peuvent être tout à fait conformes à la conception : ce n'est qu'en comparant au chemin attendu qu'on peut déterminer s'il y a une exposition d'informations non souhaitée.
Les caractéristiques du navigateur comme le fuseau horaire, la langue ou Canvas ne peuvent pas prouver à elles seules l'utilisation d'un VPN ou une fraude. Un résolveur DNS et une sortie HTTP dans des régions différentes ne sont pas forcément anormaux, car les services de résolution publics et l'Anycast influencent la localisation. Vous pouvez consigner les résultats séparément dans la Vérification de l’environnement du navigateur, puis vérifier la portée du proxy, le choix du résolveur et les types de candidats WebRTC conformément aux Fuites WebRTC, DNS et IPv6 : tester et lire les résultats. Confirmez d'abord quel type d'exposition ne correspond pas à vos attentes, puis ajustez la configuration correspondante.
Ainsi, lorsqu'un site indique « proxy détecté », il ne faut pas d'abord l'attribuer à une fuite du navigateur ou à une erreur WebRTC. Il faut vérifier séparément les résultats de fuite du navigateur et l'étiquette de réputation IP. Si le test de fuite montre une adresse locale, mais que la détection externe marque l'IP de sortie comme hébergement, il peut s'agir simplement du routage de l'opérateur ou d'une sortie partagée. Si les deux sont anormaux, envisagez alors un problème sur l'appareil de l'utilisateur ou la configuration réseau. Les opérateurs peuvent combiner les deux types de signaux, mais doivent savoir qu'ils proviennent de couches différentes et que les mécanismes d'erreur diffèrent.
Comment soumettre une demande de réexamen efficace au responsable de la maintenance
Lors d'une demande de réexamen, fournissez l'adresse publique au moment des faits, l'heure et le fuseau horaire, l'étiquette précise, le service concerné et la source des données. La preuve d'attribution de l'adresse peut provenir des enregistrements de l'opérateur auxquels vous avez légitimement accès ; RDAP est une interrogation du registre des ressources Internet, pas une fonction du routeur lui-même, et ne peut pas remplacer un bail haut débit individuel. En général, il n'est pas nécessaire de soumettre des journaux de navigation complets ni les détails de mappage CGNAT. La portée de la correction par le responsable dépend de ce qu'il gère : base de données de classification, entrée de liste ou règles propres au site.
La documentation de Google sur le trafic inhabituel peut aider à distinguer réseau partagé, requêtes automatiques et problèmes de navigateur. Si vous rencontrez une boucle de défi Cloudflare, consultez sa documentation de dépannage des défis pour vérifier si le navigateur est pris en charge, si des scripts ou extensions interfèrent, et si le réseau est stable ; conservez le Ray ID et l'heure de l'incident si une enquête du site est nécessaire. Ces documents expliquent les pistes de diagnostic de leurs produits respectifs, et ne constituent pas une promesse générale de déblocage d'IP.
Les exigences de réexamen varient selon les fournisseurs de données : certains acceptent les retours des utilisateurs finaux, d'autres exigent que l'administrateur du bloc d'adresses prouve son contrôle ; suivez le canal de correction spécifique. Rédigez la demande comme un problème vérifiable, par exemple « la date de cette entrée est antérieure à l'attribution actuelle de l'adresse, pouvez-vous vérifier l'usage », et joignez les preuves nécessaires. Si le blocage est réellement mis en œuvre par le site cible, interrogez-le également sur les règles et les sources de données qu'il utilise ; modifier une base publique ne garantit pas que tous les sites se mettent à jour immédiatement.
Comment les exploitants de sites réduisent les faux positifs
Les exploitants ne devraient pas transformer la classification IP en un interrupteur binaire. Marquez séparément les signaux hébergement, VPN, sortie Tor, relais, etc., avec des pondérations, et combinez-les avec le comportement de connexion, l'empreinte de l'appareil, l'historique des sessions et la fréquence anormale pour une décision globale. Les actions sensibles comme le changement de mot de passe ou le retrait peuvent avoir un seuil plus élevé, la navigation ordinaire peut être assouplie. Ainsi, même si une IP est inscrite à tort dans un pool de proxys, le compte ne sera pas immédiatement verrouillé. La classification elle-même n'est pas malveillante ; les faux positifs proviennent souvent de sources de données obsolètes ou de sorties partagées, comme le CGNAT qui mappe de nombreux utilisateurs résidentiels vers une seule IPv4.
Les exploitants peuvent consigner dans les journaux la règle, la version de la source de données, l'heure de correspondance et le résultat du réexamen de la réclamation. Après confirmation d'un faux positif, corrigez la règle erronée ou supprimez l'entrée de blocage concernée ; si vous utilisez une règle d'autorisation temporaire, limitez-en la portée et fixez une heure de réexamen, et n'écrivez pas par erreur « retirer de la liste blanche » à la place de « lever le blocage ». La Réputation d’un sous-réseau /24 : couverture et risques aide à comprendre les enregistrements des adresses voisines, mais le nombre d'étiquettes ne permet pas à lui seul de confirmer si un bloc réseau est partagé, appartient au même locataire ou présente un comportement malveillant commun.
Ne cachez pas les conséquences d'un blocage de plage entière derrière une étiquette d'IP unique. Si vous bloquez tout un préfixe parce que quelques adresses d'un /24 ont un historique de proxy, vous devez l'expliquer aux utilisateurs. Une meilleure approche consiste à déclencher un captcha ou une double vérification uniquement pour les actions à haut risque, plutôt que de refuser le service. Les métriques de surveillance devraient inclure le taux de faux positifs par ASN, par source de données et par période, et non la précision moyenne. Ainsi, lorsqu'une source de données marque soudainement en masse les adresses d'un FAI comme hébergement, vous pouvez effectuer un retour en arrière rapide et réduire la pression sur les tickets de support.
Questions fréquentes et limites de validation
Le type d'accès résidentiel ne garantit pas que l'adresse n'a pas été utilisée comme sortie de proxy ; inversement, l'exécution d'un client VPN sur un terminal ne signifie pas que l'adresse résidentielle locale fournit un service de proxy à d'autres. Après la désactivation du VPN, les nouvelles requêtes web peuvent immédiatement passer par une autre sortie, mais l'enregistrement de l'ancienne adresse dans la base de données ne disparaît pas nécessairement ; la mise à jour dépend de la source et de la politique de rétention. Lors du réexamen, précisez si vous comparez le changement d'étiquette de la même IP ou le résultat de la requête d'une autre adresse après changement de sortie.
L'absence d'étiquette ne garantit pas la connexion. De nombreux sites ont leurs propres règles de gestion des risques, par exemple exiger que l'ASN de l'IP appartienne au pays cible, interdire l'accès depuis les centres de données ou désactiver les tunnels IPv6. Même si aucune source de données tierce ne correspond, le site peut toujours refuser en raison de cookies anormaux, d'une empreinte de navigateur incohérente ou d'une fréquence de requêtes excessive. Face à un message de « détection de proxy », séparez d'abord la vérification de l'environnement et les données de réputation IP, et notez quelle page, quelle requête a déclenché le défi. Si RDAP montre que l'IP actuelle appartient à une ligne dédiée d'entreprise ou à un serveur cloud, même si vous n'avez pas activé de VPN, elle peut facilement être marquée comme hébergement.
La conclusion ne peut être limitée qu'aux preuves actuelles et au site spécifique. La même IP peut être marquée comme proxy sur le site A et être tout à fait normale sur le site B, car les sources de données et les seuils diffèrent. Face à un problème insoluble, vous pouvez poursuivre le diagnostic en suivant la procédure de la IP sur liste de blocage et CAPTCHA répétés : que faire ?, en vous concentrant sur la collecte de l'heure, de l'IP, de la capture d'écran du message, de l'action déclenchante, et en distinguant s'il s'agit d'un blocage au niveau réseau ou d'un captcha au niveau applicatif. Ne changez pas fréquemment d'IP ni ne modifiez l'empreinte du navigateur pour contourner le problème, car cela masquerait la cause réelle et violerait les conditions de certaines plateformes.
