Bot-Erkennung per IP: Was die IP Ihnen sagen kann und was nicht

Diese Lücke ist wichtig, weil Bots inzwischen die Mehrheit der Anfragen ausmachen. Impervas 2026 Bad Bot Report stellte fest, dass automatisierter Traffic 2025 53 % des beobachteten Web-Traffics ausmachte und schädliche Bots allein 40 %. Die nützliche Frage an Ihrem Login-Formular lautet also selten "Ist das ein Bot?", sondern "Welche Art von Bot, und kommt er durch?"

Die Arten sind es wert, benannt zu werden: verifizierte Crawler, nicht verifizierte deklarierte Bots, Imitatoren, KI-Agenten und nutzerausgelöste Fetcher, Content- und Preis-Scraper, Credential Stuffer und Scanner. Unten zeigen wir, was eine Abfrage für fünf IPs geliefert hat, eine pro Bot-Klasse, und verweisen dann auf den Leitfaden, der jede Aufgabe ausführlich behandelt: Crawler per IP, Reverse DNS und veröffentlichten Bereichen verifizieren, Registrierungen und Checkout schützen sowie Rate Limiting, ohne echte Nutzer auszusperren.

Wie Sie Bots anhand der IP-Adresse erkennen: sechs Signale

Um Bots anhand der IP-Adresse zu erkennen, fragen Sie die Quell-IP ab und lesen sechs Signale: den Netzwerktyp, Reverse DNS, veröffentlichte Crawler-Bereiche, Anonymitäts-Flags, Scanner-Flags und wie viele Anfragen ihr Präfix an Sie sendet. Die IP ist aus einem einfachen Grund ein besserer Ausgangspunkt als der User-Agent. Ein Header ist Text, den der Client wählt, aber eine HTTP-Anfrage erfordert einen abgeschlossenen TCP-Handshake, sodass sich die Quell-IP nicht einfach fälschen lässt. Der eigentliche Umweg besteht darin, die IP eines anderen zu mieten oder darüber zu proxyen, was die folgenden Abschnitte behandeln.

Wir haben am 07.10.2026 pro Bot-Klasse eine anonyme Abfrage an die GeoIPHub-API gestellt:

Lesen Sie die Score-Spalte von oben nach unten, und die wichtigste Lehre wird sichtbar. In den GeoIPHub-Abfragen vom 07.10.2026 wurde nur der Tor-Exit blockiert (fraud_score 100). Googlebot erhielt 0, der Censys-Scanner 0, der Egress von iCloud Private Relay 9 und der DigitalOcean-Server 15, alle allow. Der Score beantwortet "Wie riskant ist diese IP?", nicht "Ist das ein Bot?" Ein Rechenzentrumsserver mit 15 und ein Scanner mit 0 sind beide Automatisierung, und keiner von beiden ist für sich genommen riskant. Listentreffer sind hier die zuverlässigsten Signale; Netzwerktyp-Flags sind Ableitungen, weshalb sie den Score nur wenig bewegen. Das sind fünf einzelne Abfragen, kein Benchmark, und die Werte ändern sich, wenn sich Bereiche ändern.

Das sagt Ihnen jedes Signal, und hier finden Sie die Details:

• Netzwerktyp (asn.asn_type, asn.user_type, detection.is_hosting). Das ASN, also das Netzwerk, das die IP ankündigt, sagt Ihnen, wessen Netzwerk es ist. Eine Rechenzentrums-IP (Hosting), in der API detection.is_hosting, ist der erste Filter, weil die meisten Bots in Rechenzentren laufen und die meisten Menschen nicht. Für sich genommen ist das ein schwaches Urteil, weshalb DigitalOcean 15 erhielt. Unser Erklärartikel dazu, was eine Rechenzentrums-IP-Adresse ist, behandelt, wie Hosting erkannt wird und wann es legitim ist.
• Reverse DNS (network.ptr_record, fcrdns_valid). Ein forward-bestätigter Hostname kann den Betreiber benennen. Der PTR des Tor-Exits endet auf tor-exit.artikel10.org, was rdns_tor auslöste. Eine Einschränkung auf unserer Seite: Die API speichert keinen PTR für die IPs von Googlebot und DigitalOcean, obwohl dig -x für beide live Namen zurückgibt, daher wird bei ihnen no_ptr_datacenter ausgelöst. Führen Sie die DNS-Prüfung selbst durch, wenn der Hostname wichtig ist.
• Veröffentlichte Crawler-Bereiche (threat.crawler). Eine IP der eigenen Bereichsdatei eines Betreibers zuzuordnen, ist der sauberste Beweis, dass ein Bot der ist, für den er sich ausgibt. GeoIPHub lädt 19 offizielle Bereichsfeeds von Google, Microsoft (Bing), Apple, DuckDuckGo, OpenAI, Anthropic, Perplexity, Mistral, Common Crawl und Ahrefs, die täglich neu abgerufen werden.
• Tor-, VPN-, Proxy- und Relay-Flags (detection.is_tor, is_vpn, is_proxy, is_relay). Sie besagen, dass der echte Client hinter dem Netzwerk eines anderen verborgen ist. Siehe wie Sie Tor-Traffic per IP erkennen und wie VPN- und Proxy-Erkennung funktioniert.
• Scanner-Flags (threat.is_scanner). Internetweite Scanner sondieren jede Adresse, die sie erreichen können.
• Rate pro Präfix. Dieses Signal gehört Ihnen, nicht uns: Zählen Sie Anfragen pro /64 bei IPv6, wie der Abschnitt zum Rate Limiting unten erklärt.

Das Scanner-Ergebnis hat uns überrascht, daher hier ein Auszug aus der echten Antwort:

Das Scanner-Flag ist gesetzt, trägt aber nichts zum Score bei, und das Netzwerk von Censys ist nicht als Hosting klassifiziert. Wenn Sie nur nach recommended_action entscheiden, kommt Scanner-Traffic durch. Lesen Sie threat.is_scanner direkt aus, wenn Sie ihn aus Ihren Analysen entfernen oder an der Firewall blockieren möchten.

Bot-IP-Adresse prüfen: Ist dieser Crawler der, für den er sich ausgibt?

Eine Prüfung der Bot-IP-Adresse bestätigt einen deklarierten Crawler, indem seine IP mit der vom Betreiber veröffentlichten Bereichsdatei oder mit einem forward-bestätigten Reverse-DNS-Namen abgeglichen wird, niemals, indem man dem User-Agent vertraut. Jeder Client kann Googlebot in diesem Header senden. Nur der Betreiber kontrolliert seine IP-Bereiche.

Unsere API sieht nur die IP, niemals Ihre Anfrage-Header, daher führt Ihr Code den Vergleich durch: den Betreiber des behaupteten Bots gegen threat.crawler.verified und threat.crawler.operator. Schlüsseln Sie nicht auf threat.crawler.name: Das ist das Label der Datei, und eine Datei kann mehrere Bots abdecken. In unseren Abfragen lieferte 66.249.66.1 verified: true, name: "Googlebot", verification_method: "ip_range_list". Der DigitalOcean-Server lieferte name: "none", ein Googlebot-Anspruch von dort ist also nicht verifiziert. Das bedeutet "nicht als dieser Bot verifiziert", nicht den Beweis einer Fälschung.

ClaudeBot und PerplexityBot sind durch die Bereichsdateien abgedeckt, die Anthropic und Perplexity veröffentlichen: Am 08.10.2026 lieferte 216.73.216.10 verified: true, name: "ClaudeBot", operator: "Anthropic". Bots, die keine Bereichsdatei veröffentlichen, brauchen weiterhin die eigene Methode des Betreibers, etwa Reverse DNS. Bots, die ihre Anfragen mit Web Bot Auth signieren, lassen sich über die Signatur statt über die IP prüfen.

Die Details stehen in vier Beiträgen. Der Leitfaden zur Crawler-Verifizierung behandelt Reverse DNS, CIDR-Dateien und Web-Bot-Auth-Signaturen. Wie Sie Googlebot verifizieren und gefälschte Googlebots erkennen behandelt die drei Crawler-Gruppen von Google und ihre Bereichsdateien. GPTBot vs. OAI-SearchBot vs. ChatGPT-User behandelt, welchen OpenAI-Bot Sie blockieren sollten und wie Sie jeden einzelnen prüfen. Unsere Liste verifizierter Crawler-IPs enthält alle 19 Dateien mit ihren Daten und dem Allowlist-Code.

Was IP-basierte Bot-Erkennung Ihnen nicht sagen kann

IP-basierte Bot-Erkennung kann Ihnen nicht sagen, ob eine private IP als Residential Proxy vermietet wird, und GeoIPHub erkennt keine Residential Proxies. Ein Residential-Proxy-Netzwerk leitet die Anfrage eines Bots über den Heimanschluss einer anderen Person. Auf der IP-Ebene sieht diese Anfrage wie der eigene Traffic des Haushalts aus: ein Privatkunden-ISP, eine echte Stadt, kein Hosting-Flag.

Unser Feld is_residential_proxy ist eine grobe ASN-basierte Ableitung, keine Erkennung, behandeln Sie es also als kein Signal. Rotation verschärft das Problem. Ein Pool kann jeder Anfrage eine andere private IP zuweisen, sodass Zähler pro IP nie ansteigen.

Botnetze teilen denselben blinden Fleck. Infizierte Heimgeräte senden Bot-Traffic von gewöhnlichen privaten IPs, und Botnetz-Feeds decken bekannte Infrastruktur wie Command-and-Control-Server ab, nicht jedes infizierte Gerät. Bots umgehen IP-Erkennung auf vier gängige Arten: rotierende Adressen, gemietete Residential Proxies, das Durchwechseln eines IPv6-/64 und das Routing über mobile Proxies, die sich Carrier-IPs mit echten Smartphones teilen.

• Residential Proxies. Nicht erkannt. Erfassen Sie sie über Verhalten: Velocity pro Konto, Abweichungen bei Gerät und Sitzung.
• Der User-Agent und andere Header. Die API sieht sie nie. Vergleichen Sie den Anspruch in Ihrem eigenen Code.
• Wer tippt. Ein Headless-Browser und ein Mensch hinter derselben Büro-IP sehen auf dieser Ebene identisch aus.
• In den letzten zwei Tagen veröffentlichte Bereiche. Wir rufen Crawler-Bereichsdateien täglich neu ab und bauen die Abfragedatenbank täglich neu auf, sodass ein brandneuer Bereich bis zu etwa zwei Tage lang unverifiziert bleiben kann.
• Crawler außerhalb unserer 19 Feeds. Keine verifizierte Identität, was auch immer sie behaupten.
• Scanner-Risiko. is_scanner ist gesetzt, erhöht in unserer Abfrage aber fraud_score nicht.

Die Ebenen, die diese Lücken abdecken, liegen neben der IP: Verhalten und Velocity, Device Fingerprinting, TLS-Fingerprints wie JA3 und JA4, Challenges und Web Bot Auth für Bots, die sich selbst deklarieren. Für die Residential-Seite lesen Sie Erkennung von Residential-Proxy-Betrug, um zu erfahren, was eine Abfrage zeigen kann und was nicht, und warum so viele Residential Proxies in Ihrem Traffic auftauchen, um zu erfahren, warum es so viele sind.

Wie Sie Bot-Traffic bei Registrierungen, Logins und Checkout erkennen

Um Bot-Traffic bei Registrierungen, Logins und Checkout zu erkennen, führen Sie die IP-Abfrage im Moment der Aktion durch und kombinieren sie dann mit dem, was Ihre App bereits weiß: Versuche pro Konto, pro Präfix und pro Gerät. Die IP grenzt das Feld ein. Ihre eigenen Zähler treffen die Entscheidung.

Jeder Endpunkt gewichtet die Signale anders:

• Logins. Credential Stuffing verteilt Versuche auf viele IPs, oft private, die die IP-Ebene nicht markieren kann. Tor- und Hosting-Flags erfassen trotzdem den bequemen Anteil. Unser Leitfaden zu Kontoübernahme und Credential Stuffing behandelt das mehrschichtige Playbook.
• Checkout. Eine Rechenzentrums-IP im Checkout kann ein legitimer KI-Shopping-Agent sein, daher ist Hosting ein gewichteter Input und kein Blockiergrund: Der DigitalOcean-Server erhielt 15, allow. Siehe wie Sie Betrug durch KI-Shopping-Agenten im Checkout stoppen.
• Anzeigenklicks. Hosting- und Tor-Flags markieren Klicks, die Sie aus Ihren Conversion-Daten heraushalten sollten. Unser Leitfaden zum Erkennen von Klickbetrug anhand der IP-Adresse zeigt das Scoring.
• Registrierungen. Es gelten dieselben Bänder, plus eine Prüfung auf viele Konten aus einem Präfix.

Verwenden Sie die Score-Bänder als Standardaktion: allow bis 25, review bis 50, step_up bis 75, block über 75. Ergänzen Sie eigene Regeln für die Flags, die der Score unberührt lässt, etwa is_scanner.

Wie Sie Bot-IPs per Rate Limit begrenzen, ohne echte Nutzer zu blockieren

Begrenzen Sie Bot-IPs nach der Einheit, die einem Akteur entspricht: dem /64 bei IPv6 und der einzelnen Adresse bei IPv4, angepasst für geteilte Exits wie CGNAT und iCloud Private Relay. Zählen Sie die falsche Einheit, verpassen Sie entweder den Bot oder bestrafen eine ganze Menge. Speziell für KI-Crawler wird die Entscheidung zwischen Zulassen, Verifizieren und Rate Limiting in Sollten Sie KI-Crawler blockieren? durchgearbeitet.

Bei IPv6 erhält ein Anschlussinhaber ein ganzes /64 und kann kostenlos darin rotieren, sodass ein Zähler pro Adresse nie auslöst. Unser Leitfaden zum Rate Limiting und Blockieren von IPv6 nach /64-Präfix zeigt die Schlüsselfunktion und wann Sie auf /56 oder /48 erweitern sollten.

Bei IPv4 schlägt das umgekehrte Problem zu: Viele Menschen teilen sich eine Adresse. Carrier-Grade NAT bringt eine ganze Nachbarschaft hinter eine IP. Die API markiert das als threat.is_cgnat, und das Scoring deckelt das Risiko für CGNAT-Adressen. iCloud Private Relay tut dasselbe für Apple-Nutzer: Unsere Relay-IP erhielt 9, allow, mit der Methode relay_ip.

Auch die Geolokalisierung von Relays erfordert Sorgfalt. Unsere Abfrage verortete 104.28.46.99 in Luanda, Angola. Das ist der Egress des Relays, kein Beweis dafür, wo sich der Nutzer befindet, also nutzen Sie es nicht für Geoblocking. Unser Leitfaden zum Erkennen von anonymisiertem Traffic, ohne echte Kunden zu blockieren, erklärt die von Apple veröffentlichte Egress-Liste und wie Sie mit Relays umgehen.

Wo Sie mit Bot-Erkennung per IP anfangen

Um Bot-Erkennung per IP umzusetzen, ordnen Sie jedem Signal eine Standardaktion zu (für eine einzelne verdächtige Adresse folgen Sie stattdessen dem vollständigen Playbook zur IP-Untersuchung): verifizierte Crawler zulassen, nicht verifizierte Crawler-Ansprüche per Rate Limit begrenzen, bei Tor blockieren oder eine zusätzliche Prüfung verlangen und Verhaltenssignale nutzen, wenn die IP privat aussieht. Jede Zeile unten ist ein Signal, was es beweist, eine Standardaktion und der Beitrag, der es behandelt.

Der schnellste Weg, um zu sehen, wo Ihr eigener Traffic steht: Nehmen Sie die 20 aktivsten IPs aus den Logs von gestern und fügen Sie jede in das kostenlose IP-Lookup-Tool ein, oder führen Sie curl -s https://api.geoiphub.com/v1/lookup/<ip> ohne Schlüssel aus (30 Abfragen pro Minute) bzw. mit einem kostenlosen Schlüssel 1.500 pro Tag. Sortieren Sie sie nach den Bot-Klassen aus der ersten Tabelle, und Sie wissen, welchen Abschnitt dieser Übersicht Sie zuerst lesen sollten.

Häufig gestellte Fragen

Kann man Bots allein anhand der IP-Adresse erkennen?

Teilweise. Eine IP-Abfrage sagt Ihnen, aus welcher Art von Netzwerk eine Anfrage kam: ein veröffentlichter Crawler-Bereich, ein Rechenzentrumsserver, ein Tor-Exit, ein VPN, ein Privacy-Relay oder ein bekannter Scanner. Sie kann Ihnen nicht sagen, ob ein Mensch oder ein Skript die Anfrage gesendet hat, und sie erkennt keine private IP, die über ein Residential-Proxy-Netzwerk vermietet wird. Nutzen Sie die IP als einen Input neben Anfragerate, Kontohistorie und Gerätesignalen.

Wie prüfe ich, ob eine Bot-IP-Adresse ein echter Crawler ist?

Gleichen Sie die IP mit der vom Betreiber veröffentlichten Bereichsdatei ab, oder führen Sie eine Reverse-DNS-Abfrage durch und bestätigen Sie sie mit einer Forward-Abfrage. Der User-Agent beweist nichts, weil jeder Client jeden beliebigen String senden kann. In unserer Abfrage vom 07.10.2026 lieferte 66.249.66.1 threat.crawler.verified true mit dem Namen Googlebot, während ein DigitalOcean-Server überhaupt keine Crawler-Identität zurückgab. Unser Leitfaden zur Crawler-Verifizierung behandelt Reverse DNS, Bereichsdateien und Web Bot Auth Schritt für Schritt.

Wie genau ist Bot-Erkennung per IP?

Das hängt vom Signal ab. Ein Treffer in einer veröffentlichten Liste ist starke Evidenz: GeoIPHub prüft 19 offizielle Crawler-Bereichsfeeds von 10 Betreibern, die täglich neu abgerufen werden, sowie die Exit-Liste des Tor Project, die alle 6 Stunden aktualisiert wird. Hosting-, VPN- und Proxy-Flags sind Ableitungen; die Hosting-Erkennung nutzt 853 kuratierte Hosting-ASNs plus offizielle Bereiche von 10 Cloud-Anbietern. Residential Proxies werden nicht erkannt. Wir veröffentlichen keinen Genauigkeitswert in Prozent, und die fünf Abfragen in diesem Beitrag sind Beispiele, kein Benchmark.

Bedeutet ein hoher Betrugsscore, dass eine IP ein Bot ist?

Nein. Der Score misst Risiko, nicht Automatisierung. In unseren fünf Abfragen erhielt ein Censys-Scanner 0 und ein DigitalOcean-Server 15, beide allow, obwohl beide eindeutig automatisiert sind. Ein Tor-Exit erhielt 100, block. Lesen Sie die Flags, um zu erfahren, was der Traffic ist, und den Score, um zu erfahren, wie riskant er ist.

Erkennt GeoIPHub Residential Proxies?

Nein. Das Feld is_residential_proxy ist eine grobe ASN-basierte Ableitung, keine Erkennung. Eine private IP, die über ein Proxy-Netzwerk vermietet wird, sieht auf der IP-Ebene wie ein gewöhnlicher Heimanschluss aus, daher braucht es zum Erkennen Verhaltens- und Sitzungssignale.