Gründe für den Risikoscore: detection_methods Feld für Feld lesen

Ein Kunde wird im Checkout blockiert und schreibt, um zu fragen, warum. "Unser Anbieter sagte 92" beendet das Gespräch schlecht. "Ihre Verbindung kam von einem gelisteten VPN-Server mit einem offenen OpenVPN-Port" ist eine Antwort, hinter der Sie stehen, die Sie revidieren oder feinjustieren können. Genau das bringt ein erklärbarer Betrugsscore: Reason Codes, nicht nur eine Zahl.

Diese Seite ist das Wörterbuch für diese Antworten. Was die Zahl selbst bedeutet und wo die Bänder liegen, erfahren Sie zuerst in Was ein IP-Betrugsscore ist und wie man ihn liest. Unten zeigen wir die Arithmetik, verfolgen eine echte Antwort Grund für Grund, behandeln die fünf Gründe, die abziehen, und listen jeden detection_methods-Wert auf, den unser Scoring-Code zurückgeben kann, mit seinem Gewicht und dem, was ihn auslöst.

Gründe für den Risikoscore summieren sich: Punkte mal Konfidenz, dann eine Begrenzung

Im Scoring von GeoIPHub trägt jeder Grund seine Punkte multipliziert mit seiner Konfidenz bei, und der Score ist die gerundete Summe, begrenzt auf 0 bis 100. Darüber liegt kein verborgenes Modell. Das ist der Scoring-Schritt in unserer API (scoring.service.ts), reduziert auf seine Arithmetik:

Zwei Details bringen Leute ins Straucheln. Erstens ist confidence in der Antwort nicht die Wahrscheinlichkeit von Betrug. Sie wächst mit der Anzahl der Gründe und ihrer durchschnittlichen Größe, sodass vier moderate Gründe mehr Konfidenz tragen können als ein großer. Eine Abfrage ohne Gründe liefert 0,1. Zweitens ist die Reihenfolge von detection_methods die Reihenfolge, in der der Code sie prüft, nicht ihre Größe. Behandeln Sie den ersten Eintrag nicht als Hauptgrund.

Andere Anbieter legen Gründe anders offen. MaxMinds minFraud-Antworten enthalten risk_score_reasons: Multiplikatoren auf den Risikoscore, jeweils mit Codes wie ANONYMOUS_IP, und MaxMind merkt an, dass sie "are usually only returned for medium to high risk transactions" (in der Regel nur bei Transaktionen mit mittlerem bis hohem Risiko zurückgegeben werden). Socures Sigma Identity Fraud kombiniert einen Score zwischen 0,001 und 0,999 mit Reason Codes, die "provide detailed information to help you understand the factors that influenced the fraud risk score" (detaillierte Informationen liefern, damit Sie die Faktoren verstehen, die den Betrugsrisikoscore beeinflusst haben). Die Gründe von GeoIPHub sind additive Punkte, und jeder Grund, der den Score verändert hat, wird aufgelistet, unabhängig vom Score.

Wir haben geprüft, ob die Arithmetik bei Live-Daten aufgeht. Diese sieben Abfragen ohne Schlüssel liefen am 29.10.2026 zwischen 04:43:09 und 04:43:54 UTC, jeweils etwa sieben Sekunden auseinander, und jeder Score und jede Konfidenz lässt sich exakt aus den Gründen nachrechnen:

Eine echte Antwort nachverfolgt: AhrefsBot bei 35, review

AhrefsBots 5.39.1.230 erhielt 35, review, weil drei Gründe 63,5 Punkte addierten und der Treffer als verifizierter Crawler 28,5 abzog. Es ist das beste Lehrbeispiel, weil seine Gründe in beide Richtungen ziehen. Hier ist die gekürzte Antwort aus der Abfrage um 04:43:09 UTC (meta.last_classified_at 2026-10-29T04:43:09.547Z), Werte unverändert:

Jeder Grund entspricht einer Zeile Arithmetik:

Nimmt man den Crawler-Treffer weg, beträgt die Summe 63,5, gerundet 64: Step-up. Die verifizierte Bereichsdatei hat einen echten, deklarierten Crawler von einer Challenge zu einer protokollierten Prüfung verschoben. Zu allow hat sie ihn nicht verschoben, weil ein entlastender Grund ein Gewicht ist, keine Allowlist. Ein Spamhaus-Eintrag für dieselbe Adresse zählt weiterhin.

Wo diese Antwort falsch ist

Einer der vier Gründe ist unsere Lücke. no_ptr_datacenter besagt, dass die Adresse kein Reverse DNS hat, aber dig -x 5.39.1.230 lieferte um 04:44 UTC proxy-fr005-cip7.ahrefs.net. Der Grund liest unsere gespeicherten PTR-Einträge, und dieser Eintrag fehlt.

Die Lücke zu schließen, würde diesen Score nicht senken, und der Code zeigt, warum. Unser PTR-Klassifikator liest jeden Hostnamen, der "proxy" enthält, als Proxy-Muster. Wäre der Eintrag gespeichert, würde no_ptr_datacenter (+5) also durch rdns_proxy (+14) ersetzt, und der Score stiege auf mindestens 44. Das ist immer noch Review, aber wegen eines Hostnamens, den Ahrefs für den Egress seines Crawlers gewählt hat, nicht wegen eines Anonymisierers. Wir haben beides protokolliert. Lesen Sie no_ptr_datacenter und die rdns_*-Gründe als schwache Evidenz, was ihre Gewichte bereits aussagen.

Entlastende Gründe: Fünf können abziehen, und sie enden bei null

Entlastende Gründe tragen negative Punkte, sie senken also die Summe, aber der Score fällt nie unter 0. Die Scoring-Konfiguration von GeoIPHub enthält sechs davon, und fünf können heute ausgelöst werden:

Der Abzug für verifizierte Crawler ist in der Googlebot-Abfrage sichtbar. datacenter_ip fügte 10 hinzu, verified_crawler zog 28,5 ab, und die API gab 0 zurück. Die verbleibenden minus 18,5 werden verworfen. Sie werden nicht als Guthaben gegen einen späteren Grund angespart, und das ist das richtige Verhalten: Ein verifizierter Bereich sollte keinen Botnetz-Eintrag verbergen können. Die 19 Bereichsdateien hinter verified_crawler sind mit ihren Daten und einem Allowlist-Generator in unserer Liste verifizierter Crawler-IPs aufgeführt; Wie Sie Googlebot per IP verifizieren behandelt die Dateien von Google im Detail.

Den Abzug für private Anschlüsse können wir Ihnen nicht an einer Live-Adresse zeigen, weil die Veröffentlichung einer Abfrage eines Heimanschlusses einen Haushalt identifizieren würde. Hier daher der Codepfad in Worten. Die Residential-Gründe hängen am Reverse DNS: Unser Code stuft einen Anschluss nur dann als privat ein, wenn sein PTR-Hostname einem Heimmuster wie dsl, pool oder dynamic entspricht. Ist das der Fall und ist der Anschluss nicht zusätzlich als mobil oder CGNAT markiert, werden residential_isp (-17) und rdns_residential (-16) gemeinsam ausgelöst, zusammen minus 33. Ein mobiler oder CGNAT-Anschluss erhält mobile_carrier (-12) anstelle von residential_isp, dieses Paar ergibt also minus 28. Ein Heimanschluss, dessen ISP kein Reverse DNS veröffentlicht oder seine Hosts nach einem Muster benennt, das wir nicht erkennen, erhält keinen der beiden Abzüge. Spricht sonst nichts gegen ihn, erhält er einfach 0. Das ist derselbe Score, die Lücke spielt also nur eine Rolle, wenn andere Gründe ausgelöst werden.

Die Abzüge kehren sich auch um. Trägt ein privater Anschluss Proxy-, Tor- oder VPN-Protokoll-Evidenz (ein IPsec-Tag allein zählt nicht), wird residential_isp durch residential_with_threat (+21,25) ersetzt. Ein mobiler Anschluss verhält sich mit mobile_with_threat (+16) genauso. Ein Abzug dafür, wie ein Haushalt auszusehen, wird in dem Moment zurückgenommen, in dem der Haushalt beginnt, Traffic weiterzuleiten.

Neben den Abzügen gibt es zwei Obergrenzen. Eine Relay-Adresse ist auf 60 begrenzt, sodass ein Egress von iCloud Private Relay nie block erreichen kann; wir erklären, wie Sie Private-Relay- und WARP-Traffic erkennen und warum Sie ihn durchlassen sollten. Eine Adresse, die unser CGNAT-Schritt markiert, ist auf 50 begrenzt, sofern sie nicht eigene VPN-, Proxy-, Tor-, VPN-Protokoll-, Botnetz- oder Missbrauchsevidenz trägt.

Jeder detection_methods-Wert, Feld für Feld

Der Scoring-Code von GeoIPHub kann 41 Gründe benennen, und 36 davon können heute in einer Antwort erscheinen. Die folgenden Tabellen listen alle 36 mit ihren Punkten, ihrer Konfidenz und ihrem Beitrag auf, gruppiert nach der Frage, die jeder beantwortet.

Ist die Adresse ein Anonymisierer? Diese Gründe stammen aus der Exit-Liste des Tor Project, den veröffentlichten Serverlisten der Anbieter, unseren eigenen Protokoll-Probes und einer Proxy-Liste eines Drittanbieters. Die Probes decken SOCKS5, SOCKS4, HTTP CONNECT, HTTP forward, OpenVPN, IKE (v1 und v2), PPTP und L2TP ab. Es gibt keinen WireGuard-Probe.

Hat sich die Adresse auffällig verhalten? Diese Gründe stammen aus drei DNSBL-Zonen und unseren Missbrauchs- und Botnetz-Feeds.

Ist es Server-Infrastruktur? Hosting bedeutet eines von 853 kuratierten Hosting-ASNs, ein Bereich der 10 Cloud-Anbieter, die wir laden, oder ein Anycast-Bereich. Nur einer der drei datacenter_*-Gründe kann ausgelöst werden, der stärkste zuerst.

Was sagt ihr Reverse DNS? Diese Gründe lesen den gespeicherten PTR-Hostnamen mit einfachen Mustern, weshalb jeder einzelne leicht wiegt.

Um welche Art von Anschluss handelt es sich, und ist es ein bekannter Crawler? Die Netzwerktyp-Gründe sind immer einer aus einem Paar: der Abzug ohne Evidenz für einen Anonymisierer oder die Strafe mit ihr.

Fünf Gründe, die der Code kennt, aber nie zurückgibt

Fünf Namen existieren im Scoring-Code von GeoIPHub, können heute aber nicht in einer Antwort erscheinen, bauen Sie also keine Regeln, die auf sie warten:

• spoofed_crawler (+42,75). Nichts in unserer Pipeline setzt ihn, und eine Abfrage sieht nur eine IP, nie einen User-Agent. Der Vergleich eines behaupteten Bot-Namens mit threat.crawler findet in Ihrem Code statt.
• honeypot_hit (+33,25). Der Honeypot-Zähler ist ein Platzhalter, der immer 0 ist.
• known_vpn_asn (+22,5). Unser Code kennzeichnet ein Netzwerk nur dann als VPN, wenn die Adresse bereits ein VPN ist, daher gewinnt immer known_vpn_server.
• rdns_cgnat (-10,5). Unser Hostname-Klassifikator hat kein CGNAT-Muster.
• shadowsocks_suspected (+10). Wir haben keinen Shadowsocks-Probe, und keine der Anbieterlisten, die wir laden, kennzeichnet Shadowsocks.

Die Konfigurationsdatei enthält außerdem 11 weitere Gewichte, die der Abfragepfad nie liest, sodass auch diese Namen nie eine Antwort erreichen. Wir listen lieber einen ruhenden Grund auf, als Sie ihn durch Warten selbst entdecken zu lassen.

Schreiben Sie Regeln auf Gründe, nicht auf die reine Zahl

Der praktische Grund, diese Namen zu lernen, ist, dass Regeln auf Basis von Gründen unsere Datenlücken überstehen, Regeln auf Basis der Gesamtsumme dagegen nicht. Unsere Blockier-Schwellenwerte für Login, Registrierung und Checkout legen die Bänder fest; innerhalb davon erledigen einige wenige Regeln auf Ebene der Gründe den Großteil der Arbeit:

• Behandeln Sie tor_exit, socks5_open, http_proxy_open und botnet_c2 für sich allein als stark: Jeder fügt 33 oder mehr hinzu und stammt aus einer Liste oder unserem eigenen Probe.
• Handeln Sie nicht allein auf Basis von no_ptr_datacenter, fcrdns_mismatch oder einem rdns_*-Grund. Sie tragen 2 bis 24 Punkte und lesen gespeicherte Hostnamen, die fehlen oder veraltet sein können.
• Lesen Sie verified_crawler zusammen mit threat.crawler.verified und einem operator, der zu dem Bot passt, den der User-Agent angibt, niemals threat.crawler.name. Ein verifizierter Crawler auf einer Spam-Liste, wie AhrefsBot am 29. Oktober 2026, gehört auf Ihre Crawl-Allowlist, nicht in Ihren Checkout.
• Behandeln Sie wireguard_open als Listenevidenz, nicht als Probe-Ergebnis. Es bedeutet, dass die veröffentlichte Liste des Anbieters angibt, dass der Server WireGuard betreibt.
• Protokollieren Sie bei jeder Entscheidung das vollständige detection_methods-Array. Es ist der Prüfpfad, nach dem ein Support-Mitarbeiter oder ein Chargeback-Prüfer fragen wird.

So sieht das im Code aus, nur mit echten Feldern:

Gründe sagen Ihnen auch, woher die Evidenz stammt, was wichtig wird, wenn ein Kunde sie anfechtet. known_vpn_server mit vpn_confidence 95 bedeutet die eigene Liste des Anbieters; wir erklären, wie wir den VPN-Anbieter hinter einer IP benennen und was jeder Konfidenzwert aussagt. Für die Probe-Seite behandelt wie VPN- und Proxy-Erkennung funktioniert, woher die gewichtigsten Anonymisierer-Gründe stammen, und die vollständige Liste der IP-Datenfelder dokumentiert den Rest der Antwort.

Rechnen Sie einen Score selbst nach

Fügen Sie eine beliebige Adresse in den kostenlosen IP-Betrugsscore-Checker von GeoIPHub ein, kopieren Sie ihre Gründe und bauen Sie die Zahl aus den obigen Tabellen nach. Wenn Ihre Summe und unser Score nicht übereinstimmen, hat einer von uns einen Bug, und wir würden gern erfahren, wer.

Häufig gestellte Fragen

Was enthält scoring.detection_methods?

Den Namen jedes Grundes, der den Score verändert hat, in der Reihenfolge, in der der Scoring-Code von GeoIPHub sie prüft, nicht nach Größe. Jeder Name hat in unserer Scoring-Konfiguration feste Punkte und eine Konfidenz, und der Score ist die Summe aus Punkten mal Konfidenz, gerundet und zwischen 0 und 100 gehalten. Der Code von GeoIPHub kann 41 Gründe benennen; 36 davon können heute in einer Antwort erscheinen.

Warum erhält ein verifizierter Crawler trotzdem einen Review-Score?

Weil verified_crawler im Scoring von GeoIPHub ein Gewicht ist, keine Allowlist. Er zieht 28,5 Punkte ab (minus 30 bei einer Konfidenz von 0,95). AhrefsBot unter 5.39.1.230 hatte am 29.10.2026 zusätzlich einen Spamhaus-Eintrag, sodass die Spam- und Blocklisten-Gründe den Abzug überwogen: 35, review, statt der 64 (step up), die die Adresse ohne den Crawler-Treffer erhalten würde.

Kann ein Score unter null fallen?

Die gewichtete Summe kann es, der Score nicht. Googlebot unter 66.249.66.1 kam am 29.10.2026 auf eine Summe von minus 18,5 (datacenter_ip plus verified_crawler), und die API von GeoIPHub gab 0 zurück. Der negative Saldo wird nicht als Guthaben für etwas anderes übertragen.

Bedeutet wireguard_open, dass GeoIPHub einen WireGuard-Handshake abgeschlossen hat?

Nein. GeoIPHub hat keinen WireGuard-Probe. wireguard_open bedeutet, dass die eigene veröffentlichte Serverliste des VPN-Anbieters diesen Server als WireGuard kennzeichnet. Unsere Probes decken SOCKS5, SOCKS4, HTTP CONNECT, HTTP forward, OpenVPN, IKE (v1 und v2), PPTP und L2TP ab, daher sind openvpn_open, pptp_open, l2tp_open, socks5_open und http_proxy_open Probe-Ergebnisse.

Warum sehe ich no_ptr_datacenter bei einer Adresse, die Reverse DNS hat?

Der Grund liest die gespeicherten Reverse-DNS-Einträge von GeoIPHub, keine Live-Abfrage, und diese Einträge haben Lücken. Am 29.10.2026 wurde er für AhrefsBot 5.39.1.230 und den Tor-Exit 185.220.101.1 ausgelöst, während dig -x beide auflöste. Er ist 5 Punkte wert, schreiben Sie Regeln also auf die Gründe, denen Sie vertrauen, statt auf die reine Anzahl.