Les raisons du score de risque : lire detection_methods champ par champ

Un client est bloqué au paiement et écrit pour demander pourquoi. « Notre fournisseur a dit 92 » met mal fin à la conversation. « Votre connexion provenait d'un serveur VPN répertorié avec un port OpenVPN ouvert » est une réponse que vous pouvez défendre, réviser ou ajuster. C'est ce qu'apporte un score de fraude explicable : des codes de raison, pas seulement un nombre.

Cette page est le dictionnaire de ces réponses. Pour comprendre ce que signifie le nombre lui-même et où se situent les tranches, commencez par ce qu'est un score de fraude IP et comment le lire. Ci-dessous, nous montrons l'arithmétique, retraçons une vraie réponse raison par raison, présentons les cinq raisons qui soustraient des points, et listons chaque valeur de detection_methods que notre code de scoring peut renvoyer, avec son poids et ce qui la déclenche.

Les raisons du score de risque s'additionnent : points multipliés par la confiance, puis un bornage

Dans le scoring de GeoIPHub, chaque raison apporte ses points multipliés par sa confiance, et le score est le total arrondi, borné entre 0 et 100. Il n'y a aucun modèle caché par-dessus. Voici l'étape de scoring de notre API (scoring.service.ts), réduite à son arithmétique :

Deux détails induisent souvent en erreur. Premièrement, la confidence de la réponse n'est pas la probabilité de fraude. Elle augmente avec le nombre de raisons et leur taille moyenne : quatre raisons modestes peuvent donc porter plus de confiance qu'une seule raison importante. Une requête sans aucune raison renvoie 0,1. Deuxièmement, l'ordre de detection_methods est celui dans lequel le code les vérifie, pas celui de leur importance. Ne considérez pas la première entrée comme la raison principale.

D'autres fournisseurs exposent leurs raisons différemment. Les réponses minFraud de MaxMind contiennent des risk_score_reasons : des multiplicateurs du score de risque, chacun avec des codes comme ANONYMOUS_IP, et MaxMind précise qu'ils « ne sont généralement renvoyés que pour les transactions à risque moyen à élevé » (« are usually only returned for medium to high risk transactions »). Sigma Identity Fraud de Socure associe un score compris entre 0,001 et 0,999 à des codes de raison qui « fournissent des informations détaillées pour vous aider à comprendre les facteurs qui ont influencé le score de risque de fraude ». Les raisons de GeoIPHub sont des points additifs, et chaque raison qui a fait bouger le score est listée, quel que soit le score.

Nous avons vérifié que l'arithmétique tient sur des données réelles. Ces sept requêtes sans clé ont été exécutées le 29 octobre 2026 entre 04:43:09 et 04:43:54 UTC, à environ sept secondes d'intervalle, et chaque score et chaque confiance se reconstruisent exactement à partir de leurs raisons :

Retracer une vraie réponse : AhrefsBot à 35, review

L'adresse 5.39.1.230 d'AhrefsBot a obtenu 35, review, parce que trois raisons ont ajouté 63,5 points et que sa correspondance de robot d'exploration vérifié en a retiré 28,5. C'est le meilleur cas pédagogique, car ses raisons tirent dans les deux sens. Voici la réponse abrégée de la requête de 04:43:09 UTC (meta.last_classified_at 2026-10-29T04:43:09.547Z), valeurs non modifiées :

Chaque raison correspond à une ligne d'arithmétique :

Retirez la correspondance de robot d'exploration et la somme est de 63,5, arrondie à 64 : vérification renforcée. Le fichier de plages vérifié a fait passer un vrai robot d'exploration déclaré d'un challenge à un examen journalisé. Il ne l'a pas fait passer à allow, car une raison disculpante est un poids, pas une liste d'autorisation. Une inscription sur Spamhaus de la même adresse compte toujours.

Là où cette réponse se trompe

L'une des quatre raisons relève d'une lacune de notre côté. no_ptr_datacenter indique que l'adresse n'a pas de DNS inverse, mais dig -x 5.39.1.230 à 04:44 UTC a renvoyé proxy-fr005-cip7.ahrefs.net. La raison lit nos enregistrements PTR stockés, et cet enregistrement est manquant.

Combler cette lacune ne ferait pas baisser ce score, et le code montre pourquoi. Notre classificateur PTR interprète tout nom d'hôte contenant « proxy » comme un motif de proxy. Avec l'enregistrement stocké, no_ptr_datacenter (+5) serait donc remplacé par rdns_proxy (+14), et le score monterait à au moins 44. Ce serait toujours review, mais pour un nom d'hôte qu'Ahrefs a choisi pour la sortie de son robot d'exploration, pas pour un anonymiseur. Nous avons consigné les deux problèmes. Considérez no_ptr_datacenter et les raisons rdns_* comme des preuves faibles, ce que leurs poids indiquent déjà.

Les raisons disculpantes : cinq peuvent soustraire, et elles s'arrêtent à zéro

Les raisons disculpantes portent des points négatifs : elles abaissent donc la somme, mais le score ne descend jamais sous 0. La configuration de scoring de GeoIPHub en compte six, et cinq peuvent se déclencher aujourd'hui :

La remise pour robot d'exploration vérifié est visible dans la requête sur Googlebot. datacenter_ip a ajouté 10, verified_crawler a retiré 28,5, et l'API a renvoyé 0. Le reliquat de moins 18,5 est ignoré. Il ne constitue pas un crédit contre une raison ultérieure, ce qui est le bon comportement : une plage vérifiée ne doit pas pouvoir masquer une inscription sur une liste de botnets. Les 19 fichiers de plages derrière verified_crawler sont listés, avec leurs dates et un générateur de liste d'autorisation, dans notre liste d'IP de robots d'exploration vérifiés ; comment vérifier Googlebot par IP détaille les fichiers de Google.

Nous ne pouvons pas vous montrer la remise résidentielle sur une adresse réelle, car publier la requête d'une connexion domestique permettrait d'identifier un foyer. Voici donc le chemin du code, décrit en prose. Les raisons résidentielles dépendent du DNS inverse : notre code ne considère une ligne comme résidentielle que lorsque son nom d'hôte PTR correspond à un motif domestique comme dsl, pool ou dynamic. Dans ce cas, sauf si la ligne est aussi signalée comme mobile ou CGNAT, residential_isp (-17) et rdns_residential (-16) se déclenchent ensemble, soit moins 33. Une ligne mobile ou CGNAT reçoit mobile_carrier (-12) à la place de residential_isp : cette paire vaut donc moins 28. Une ligne domestique dont le FAI ne publie pas de DNS inverse, ou nomme ses hôtes selon un motif que nous ne reconnaissons pas, ne reçoit aucune des deux remises. Sans rien d'autre contre elle, elle obtient simplement 0. C'est le même score : la lacune ne compte donc que lorsque d'autres raisons se déclenchent.

Les remises peuvent aussi s'inverser. Si une ligne résidentielle présente des preuves de proxy, de Tor ou de protocole VPN (une simple étiquette IPsec ne compte pas), residential_isp est remplacé par residential_with_threat (+21,25). Une ligne mobile fait de même avec mobile_with_threat (+16). La remise accordée parce qu'une ligne ressemble à un foyer est retirée dès que ce foyer commence à relayer du trafic.

Deux plafonds accompagnent les remises. Une adresse de relais est plafonnée à 60 : une sortie iCloud Private Relay ne peut donc jamais atteindre block ; nous expliquons comment détecter le trafic Private Relay et WARP et pourquoi le laisser passer. Une adresse que notre étape CGNAT signale est plafonnée à 50, sauf si elle présente ses propres preuves de VPN, de proxy, de Tor, de protocole VPN, de botnet ou d'abus.

Chaque valeur de detection_methods, champ par champ

Le code de scoring de GeoIPHub peut nommer 41 raisons, et 36 d'entre elles peuvent apparaître dans une réponse aujourd'hui. Les tableaux ci-dessous listent les 36 avec leurs points, leur confiance et leur contribution, regroupées selon la question à laquelle chacune répond.

L'adresse est-elle un anonymiseur ? Ces raisons proviennent de la liste des nœuds de sortie du Tor Project, des listes de serveurs publiées par les fournisseurs, de nos propres sondes de protocoles et d'une liste de proxys tierce. Les sondes couvrent SOCKS5, SOCKS4, HTTP CONNECT, HTTP forward, OpenVPN, IKE (v1 et v2), PPTP et L2TP. Il n'y a pas de sonde WireGuard.

L'adresse s'est-elle mal comportée ? Ces raisons proviennent de trois zones DNSBL et de nos flux d'abus et de botnets.

S'agit-il d'une infrastructure de serveurs ? L'hébergement désigne l'un des 853 ASN d'hébergeurs sélectionnés, une plage de l'un des 10 fournisseurs cloud que nous chargeons, ou une plage anycast. Une seule des trois raisons datacenter_* peut se déclencher, la plus forte en premier.

Que dit son DNS inverse ? Ces raisons lisent le nom d'hôte PTR stocké à l'aide de motifs simples, c'est pourquoi chacune pèse peu.

De quel type de ligne s'agit-il, et est-ce un robot d'exploration connu ? Les raisons de type de réseau font toujours partie d'une paire : la remise en l'absence de preuve d'anonymiseur, ou la pénalité en sa présence.

Cinq raisons que le code connaît mais ne renvoie jamais

Cinq noms existent dans le code de scoring de GeoIPHub mais ne peuvent pas apparaître dans une réponse aujourd'hui ; ne construisez donc pas de règles qui les attendent :

• spoofed_crawler (+42,75). Rien dans notre pipeline ne la définit, et une requête ne voit qu'une IP, jamais un User-Agent. La comparaison entre un nom de bot revendiqué et threat.crawler se fait dans votre code.
• honeypot_hit (+33,25). Le compteur de honeypots est un espace réservé qui vaut toujours 0.
• known_vpn_asn (+22,5). Notre code ne qualifie un réseau de VPN que lorsque l'adresse est déjà un VPN : known_vpn_server l'emporte donc toujours.
• rdns_cgnat (-10,5). Notre classificateur de noms d'hôte n'a pas de motif CGNAT.
• shadowsocks_suspected (+10). Nous n'avons pas de sonde Shadowsocks, et aucune liste de fournisseur que nous chargeons ne marque Shadowsocks.

Le fichier de configuration contient aussi 11 autres poids que le chemin de requête ne lit jamais : ces noms n'atteignent donc jamais une réponse non plus. Nous préférons lister une raison dormante plutôt que de vous laisser la découvrir en l'attendant.

Écrivez vos règles sur les raisons, pas sur le nombre brut

La raison pratique d'apprendre ces noms, c'est que les règles écrites sur les raisons résistent à nos lacunes de données, alors que les règles écrites sur le total n'y résistent pas. Nos seuils de blocage pour la connexion, l'inscription et le paiement fixent les tranches ; à l'intérieur de celles-ci, quelques règles au niveau des raisons font l'essentiel du travail :

• Considérez tor_exit, socks5_open, http_proxy_open et botnet_c2 comme forts à eux seuls : chacun ajoute 33 points ou plus et provient d'une liste ou de notre propre sonde.
• N'agissez pas sur no_ptr_datacenter, fcrdns_mismatch ou une raison rdns_* seule. Elles valent de 2 à 24 points et lisent des noms d'hôte stockés qui peuvent être manquants ou périmés.
• Lisez verified_crawler conjointement avec threat.crawler.verified et un opérateur qui correspond au bot revendiqué par le User-Agent, jamais avec threat.crawler.name. Un robot d'exploration vérifié figurant sur une liste de spam, comme AhrefsBot le 29 octobre 2026, a sa place dans votre liste d'autorisation d'exploration, pas dans votre tunnel de paiement.
• Considérez wireguard_open comme une preuve issue d'une liste, pas comme un résultat de sonde. Cela signifie que la liste publiée par le fournisseur indique que le serveur fait tourner WireGuard.
• Journalisez le tableau detection_methods complet avec chaque décision. C'est la piste d'audit que vous demandera un agent du support ou la personne chargée d'examiner une rétrofacturation.

Voici ce que cela donne en code, en n'utilisant que de vrais champs :

Les raisons vous indiquent aussi d'où viennent les preuves, ce qui compte lorsqu'un client les conteste. known_vpn_server avec une vpn_confidence de 95 désigne la liste du fournisseur lui-même ; nous expliquons comment nous nommons le fournisseur VPN derrière une IP et ce que signifie chaque valeur de confiance. Côté sondes, le fonctionnement de la détection des VPN et des proxys explique d'où proviennent les raisons d'anonymiseur les plus lourdes, et la liste complète des champs de données IP documente le reste de la réponse.

Additionnez vous-même un score

Collez n'importe quelle adresse dans le vérificateur gratuit de score de fraude IP de GeoIPHub, copiez ses raisons et reconstruisez le nombre à partir des tableaux ci-dessus. Si votre somme et notre score ne concordent pas, l'un de nous a un bug, et nous aimerions savoir lequel.

Questions fréquentes

Que contient scoring.detection_methods ?

Le nom de chaque raison qui a modifié le score, dans l'ordre où le code de scoring de GeoIPHub les vérifie, pas par importance. Chaque nom a des points fixes et une confiance dans notre configuration de scoring, et le score est la somme des points multipliés par la confiance, arrondie et maintenue entre 0 et 100. Le code de GeoIPHub peut nommer 41 raisons ; 36 peuvent apparaître dans une réponse aujourd'hui.

Pourquoi un robot d'exploration vérifié obtient-il quand même un score d'examen ?

Parce que dans le scoring de GeoIPHub, verified_crawler est un poids, pas une liste d'autorisation. Il retire 28,5 points (moins 30 à une confiance de 0,95). AhrefsBot, à l'adresse 5.39.1.230, figurait aussi sur une liste Spamhaus le 29 octobre 2026 : les raisons liées au spam et aux listes de blocage ont donc pesé plus que la remise, d'où 35, review, au lieu des 64 (vérification renforcée) qu'il obtiendrait sans la correspondance de robot d'exploration.

Un score peut-il descendre sous zéro ?

La somme pondérée le peut, le score non. Googlebot, à l'adresse 66.249.66.1, totalisait moins 18,5 le 29 octobre 2026 (datacenter_ip plus verified_crawler) et l'API de GeoIPHub a renvoyé 0. Le solde négatif n'est pas reporté comme crédit pour autre chose.

wireguard_open signifie-t-il que GeoIPHub a effectué une poignée de main WireGuard ?

Non. GeoIPHub n'a pas de sonde WireGuard. wireguard_open signifie que la liste de serveurs publiée par le fournisseur VPN lui-même marque ce serveur comme WireGuard. Nos sondes couvrent SOCKS5, SOCKS4, HTTP CONNECT, HTTP forward, OpenVPN, IKE (v1 et v2), PPTP et L2TP : openvpn_open, pptp_open, l2tp_open, socks5_open et http_proxy_open sont donc des résultats de sondes.

Pourquoi vois-je no_ptr_datacenter sur une adresse qui a un DNS inverse ?

Cette raison lit les enregistrements DNS inverses stockés par GeoIPHub, pas une requête en direct, et ces enregistrements ont des lacunes. Le 29 octobre 2026, elle s'est déclenchée pour AhrefsBot 5.39.1.230 et pour le nœud de sortie Tor 185.220.101.1, alors que dig -x résolvait les deux. Elle vaut 5 points : écrivez donc vos règles sur les raisons auxquelles vous faites confiance plutôt que sur le nombre brut.