IPv64-Blocklisten erklärt: welche Listen es gibt und was sie sperren

IPv64.net stellt kostenlose IP-Blocklisten bereit: bewährte öffentliche Listen wie Spamhaus DROP, FireHOL und blocklist.de, die eigene v64 Blocklist aus dem Honeypot64-Netz der Community, Länderlisten und Listen für Sonderfälle wie DoH-Server, Cloud-Netze und KI-Crawler. Hier steht, was jede Liste enthält, woher sie kommt, wie riskant sie ist und welche du für deinen Zweck nimmst.

Wozu Blocklisten? First-Level-Protection

Eine IP-Blocklist ist eine Liste von Adressen und Netzen, von denen bekannt ist, dass sie angreifen, scannen, Spam verschicken oder Botnetze steuern. Deine Firewall, dein Router oder dein Reverse-Proxy verwirft Verbindungen von diesen Adressen, bevor sie deine Dienste erreichen. IPv64.net nennt das First-Level-Protection: die erste Verteidigungslinie ganz vorne an deinem Netz.

• Weniger Angriffsfläche: Brute-Force auf SSH, Mail und Login-Seiten, bekannte Exploits und Massenscans kommen gar nicht erst an.
• Weniger Last und Lärm: Deine Dienste beantworten weniger unerwünschte Anfragen und schreiben weniger Logs.
• Fertig aufbereitet: IPv64.net lädt die Quelllisten, bereinigt sie und stellt sie in einheitlichen Formaten bereit. Du bindest nur eine Adresse ein; die Liste bleibt von selbst aktuell.

Alle Listen samt aktueller Größe und Stand siehst du auf ipv64.net/v64_blocklists. Wie du sie in pfSense, OPNsense, MikroTik, nftables und andere Systeme einbaust, steht unter Blocklisten einbinden.

Grenzen und Risiken von Blocklisten

Blocklisten sind ein nützlicher Filter, aber kein vollständiger Schutz. Bevor du eine Liste einschaltest, solltest du ihre Grenzen kennen:

• Fehlalarme (False Positives): Viele Adressen werden geteilt oder neu vergeben – Mobilfunk, CGNAT, VPN-Anbieter, Tor, öffentliches WLAN, dynamische Anschlüsse. Steht eine solche Adresse auf einer Liste, sperrst du auch harmlose Nutzer aus, im schlimmsten Fall dich selbst.
• Eingehend nach Absender: Die meisten Listen sind dafür gedacht, Verbindungen aus dem Internet nach Absender-Adresse zu verwerfen. Nur einige Listen sind ausdrücklich für ausgehenden Verkehr gedacht: Spamhaus DROP (ein- und ausgehend), Feodo Tracker (ausgehend, damit infizierte Geräte ihre Steuerserver nicht erreichen) und die DoH-Server-Liste (nur ausgehend). Sperrst du eine Adresse, verwirft die Firewall auch deren Antworten auf Verbindungen, die du selbst aufbaust.
• Nicht in Echtzeit: Die Listen werden mehrmals täglich erneuert, der freie Tagesstand der v64 Blocklist einmal am Tag. Neue Angreifer fehlen also noch, und Angreifer wechseln ihre Adressen.
• Kein Ersatz für Updates, sichere Passwörter, Zwei-Faktor-Anmeldung und nur so viele offene Ports wie nötig. IPv64.net bittet ausdrücklich darum, sich nicht allein auf die Listen zu verlassen.
• Größe: Große Listen (Länder, Kontinente, Cloud-Netze) können die Tabellengrenzen kleiner Router oder Firewalls sprengen. Prüfe, wie viele Einträge dein Gerät verträgt.
• Bedingungen der Quellen: Die Einträge stammen aus den jeweiligen Projekten, deren Lizenz gilt weiter (siehe Übersicht). DShield steht zum Beispiel unter CC BY-NC-SA 2.5, also nicht für kommerzielle Nutzung.

Alle Listen im Überblick

Jede Liste hat eine ID; sie steckt im Dateinamen und in der index.json. „In all“ heißt: Die Liste ist Teil der Gesamtliste all. Die Größe ist die Zahl der Einträge (Adressen und Netze) laut index.json, Stand 26.10.2026; sie ändert sich laufend.

Die Einstufung der Fehlalarme stammt aus dem Integrationsleitfaden von IPv64.net. „Gewollt“ heißt: Die Liste trifft genau die Gruppe, die sie beschreibt (z. B. alle Tor-Nutzer) – ob das ein Fehlalarm ist, entscheidest du mit deinem Einsatzzweck.

Die Listen im Detail

IPv64.net übernimmt die Einträge aus den Quellprojekten und bereitet sie auf (siehe Formate). Was auf einer Liste steht, entscheidet das jeweilige Projekt.

Spamhaus DROP (spamhaus_drop)

Quelle: Spamhaus „Don't Route Or Peer“, IPv4 und IPv6. Inhalt: Netze, die laut Spamhaus von Kriminellen kontrolliert oder gekapert sind. Einsatz: für alle, eingehend und ausgehend – die Liste mit den wenigsten Fehlalarmen und der beste Einstieg. Risiko: sehr gering.

FireHOL Level 1 (firehole_l1)

Quelle: FireHOL Level 1, eine kuratierte Sammlung mehrerer Listen (u. a. Spamhaus DROP und Feodo). Inhalt: nur IPv4. Die reservierten Netze, die FireHOL ebenfalls aufführt, entfernt IPv64.net (siehe Formate). Einsatz: guter Standard für Router und Server. Risiko: gering. Die ID schreibt sich firehole_l1 (mit „e“).

DShield (dshield1)

Quelle: DShield / SANS Internet Storm Center. Inhalt: die 20 aktivsten angreifenden /24-Netze, nur IPv4. Einsatz: zusätzlich zu einer anderen Liste. Risiko: gering. Lizenz: CC BY-NC-SA 2.5 – nicht für kommerzielle Zwecke.

blocklist.de All (blocklistde_all)

Quelle: blocklist.de. Inhalt: Adressen, die in den letzten 48 Stunden SSH, Mail, Web und andere Dienste angegriffen haben, IPv4 und IPv6 – die größte Einzelliste in all. Einsatz: Server, die aus dem Internet erreichbar sind. Risiko: mittel; darunter sind oft befallene Privatanschlüsse mit wechselnden Adressen.

Emerging Threats Compromised (et_compromised)

Quelle: Emerging Threats (Proofpoint). Inhalt: bekannt kompromittierte Hosts, nur IPv4. Einsatz: zusätzlich zu einer anderen Liste. Risiko: gering.

abuse.ch Feodo Tracker (feodo)

Quelle: abuse.ch Feodo Tracker. Inhalt: Steuerserver (Command and Control) von Botnetzen wie Emotet, Dridex und QakBot. Die Liste ist derzeit fast leer, bekommt aber bei neuen Botnetzen sofort wieder Einträge. Einsatz: vor allem ausgehend, damit infizierte Geräte ihre Server nicht erreichen. Risiko: sehr gering.

Tor Exit Nodes und Tor All Nodes (tor_exit, tor_all)

Quelle: direkt vom Tor Project (Onionoo), IPv4 und IPv6. Inhalt: tor_exit enthält die Exit-Knoten – von dort kommen Tor-Nutzer bei deinem Dienst an. tor_all enthält alle laufenden Relays. Einsatz: nur, wenn du Tor-Nutzer bewusst aussperren willst. Risiko: gewollt; beide Listen stecken in all, nicht aber in all_notor.

CINS Army (cins_army)

Quelle: CINS Army aus dem Sentinel-IPS-Netz. Inhalt: bis zu 15.000 Adressen mit schlechtem Ruf, nur IPv4. Einsatz: Server, die viel gescannt werden. Risiko: mittel; nicht in all.

IPsum Level 3 (ipsum_l3)

Quelle: IPsum. Inhalt: Adressen, die auf mindestens drei öffentlichen Sperrlisten stehen, nur IPv4. Einsatz: Server, die viel gescannt werden. Risiko: mittel; nicht in all.

DoH-Server (doh_servers)

Quelle: DoH-IP-blocklists, IPv4 und IPv6. Inhalt: öffentliche DNS-over-HTTPS-Server. Einsatz: nur ausgehend – eine LAN-Regel mit Ziel = Liste sorgt dafür, dass Geräte deinen eigenen DNS-Filter (z. B. DNS64 in Node64) nicht über DoH umgehen. Eingehend ergibt die Liste keinen Sinn. Nicht in all.

Cloud-Netze: Cloudflare, Amazon AWS, Google Cloud (cloudflare, aws, gcp)

Quelle: die Adresslisten, die Cloudflare, AWS und Google Cloud selbst veröffentlichen, IPv4 und IPv6.

• cloudflare ist als Freigabeliste gedacht: Läuft dein Server nur über Cloudflare, lässt du nur diese Netze zu.
• aws (alle AWS-Netze) und gcp (Kundennetze von Google Cloud, ohne Google-Dienste) sperren Rechenzentren, aus denen viele Scanner und Bots kommen. Damit sperrst du aber auch jeden legitimen Dienst, der dort läuft.

Alle drei sind nicht in all.

KI-Crawler: v64 AI Bots (ai_bots) und User-Agent-Liste

Quelle: die offiziellen Adresslisten der Betreiber: OpenAI (GPTBot, OAI-SearchBot, ChatGPT-User), Perplexity (PerplexityBot, Perplexity-User), Common Crawl (CCBot), Mistral (MistralAI-User) und Google-Agent. Inhalt: rund 310 Netze, auch Abrufe, die ein Nutzer im Chat auslöst. Netze, die mit der normalen Suche geteilt werden (Googlebot, Bingbot, Applebot), sind bewusst nicht dabei. Welches Netz aus welcher Quelle stammt, zeigt ipv64_blocklist_ai_bots_sources.txt. Fällt eine Quelle aus, gilt ihr letzter gültiger Stand weiter. Nicht in all.

Dazu gibt es eine User-Agent-Liste – keine IP-Liste – als täglicher Spiegel von ai.robots.txt (MIT): ipv64_ai_useragents.txt (eine Kennung je Zeile), ipv64_ai_useragents.json (mit Betreiber, Zweck und Kennzeichen für Abrufe im Auftrag von Nutzern) und ipv64_ai_robots.txt (fertiger robots.txt-Block). Vergleiche die Kennungen ohne Groß- und Kleinschreibung mit dem User-Agent im Webserver oder Reverse-Proxy.

Gesamtlisten: all und all_notor

Die Gesamtlisten fassen alle Listen mit „in all = ja“ zusammen, ohne Duplikate: Spamhaus DROP, FireHOL Level 1, DShield, blocklist.de, ET Compromised, Feodo Tracker und – nur in all – die beiden Tor-Listen.

• all – alles zusammen, mit Tor (rund 37.800 Einträge). Tor-Nutzer werden mitgesperrt.
• all_notor – dasselbe ohne Tor (rund 29.400 Einträge). Für Server, die Angreifer sperren sollen, aber keine Tor-Nutzer.

Nicht enthalten sind die großen Reputationslisten (CINS, IPsum), die Sonderlisten (DoH, Cloud, KI-Bots) und die v64 Blocklist. Die nimmst du bei Bedarf zusätzlich. Fehlalarme: mittel, vor allem wegen blocklist.de.

Die v64 Blocklist aus dem Honeypot64-Netz

Die v64 Blocklist ist die eigene Liste von IPv64.net. Sie entsteht aus den Meldungen der Honeypot64-Sensoren der Community. Ein Honeypot ist eine Falle ohne echten Dienst: Wer sich dort anmelden will, eine Lücke ausnutzt oder Ports abklappert, hat dort nichts zu suchen. Honeypot64 läuft als Modul in Node64, dem Heimnetz-Container von IPv64.net, und meldet seine Beobachtungen alle 10 Minuten an IPv64.net.

So kommt eine Adresse auf die Liste

• IPv64.net bewertet die Meldungen alle 30 Minuten über ein Fenster von 14 Tagen.
• Gelistet wird eine Adresse erst, wenn Sensoren von mindestens drei unabhängigen Accounts sie gemeldet haben. Gezählt werden Accounts, nicht Sensoren; Accounts, deren Sensoren im selben Netz stehen, zählen zusammen nur einmal. Melden mehr als 150 Accounts, sind es 2 % davon (aufgerundet, höchstens zehn). Die Art der Angriffe spielt dafür keine Rolle; neue Accounts und Sensoren, deren Meldungen kaum jemand bestätigt, zählen weniger. Anonyme Sensoren (Meldung ohne API-Key) zählen alle zusammen wie ein Account mit halbem Gewicht: Sie bestätigen Angreifer, bringen eine Adresse aber nie allein auf die Liste.
• IPv6 je /64: Meldungen aller Adressen eines /64-Netzes zählen zusammen, und gelistet wird das ganze /64 – wer im eigenen Netz die Adresse wechselt, entgeht der Liste nicht. Freigaben gelten ebenso für das ganze /64. IPv4 bleibt bei einzelnen Adressen.
• Nie gelistet werden private und reservierte Adressen, die Sensoren selbst, Infrastruktur von IPv64.net, Cloudflare und freigegebene Adressen. Forschungs-Scanner (z. B. Shodan, Censys) stehen ebenfalls nicht auf der Liste.
• Jede gelistete Adresse hat einen Vertrauenswert von 0 bis 100, den die IP-Auskunft anzeigt. Er dient der Auskunft, Anmeldeversuche und Exploits wiegen darin schwerer als bloße Scans; ob gelistet wird, entscheidet die Schwelle.

Eine Liste: v64 (keine Teillisten mehr)

Die v64 Blocklist gibt es als eine Liste mit der ID v64: alle gelisteten Angreifer (Logins, Exploits, Scans), ohne Forschungs-Scanner. Einsatz: Server, die aus dem Internet erreichbar sind, zusätzlich zu einer anderen Liste. Sie enthält einzelne Adressen, ist nicht Teil von all oder all_notor und steht unter CC BY 4.0 (IPv64.net Honeypot64), ohne Gewähr.

Die früheren Teillisten v64_ssh, v64_web, v64_mail, v64_rdp, v64_scanner und v64_research gibt es seit Oktober 2026 nicht mehr; IPv64.net hat ihre Dateien im Tagesstand und im Live-Stand entfernt. Hast du eine davon eingebunden, stellst du auf v64 um, z. B. https://ipv64.net/blocklists/ipv64_blocklist_v64.txt.

Wie lange eine Adresse auf der Liste bleibt

Ohne neue Angriffe fällt eine Adresse nach 14 Tagen von selbst heraus. Greift sie weiter an, bleibt sie gelistet.

Tagesstand und Live-Stand

Die v64 Blocklist bekommt jeder vollständig und kostenlos. Der Unterschied ist nur die Aktualität:

Den Live-Stand rufst du mit einem persönlichen Listen-Token ab, das du angemeldet unter ipv64.net/honeypot/token.php erzeugst. Die Berechtigung prüft IPv64.net bei jedem Abruf; ohne Berechtigung liefert dieselbe Adresse den Tagesstand. Programme holen das Token per API v2 mit GET https://ipv64.net/api/v2/honeypot/list-token; in Node64 macht PROXY64 das automatisch über deinen API-Key. Einzelheiten unter Live-Stand mit Listen-Token.

Wie groß beide Stände gerade sind und wie alt, zeigt IPv64 Secure (siehe unten).

IP-Auskunft und Freigabe (Delisting)

Ob und warum eine Adresse auf der v64 Blocklist steht, zeigt die IP-Auskunft unter ipv64.net/honeypot/ip.php: Zahl der meldenden Accounts, Vertrauenswert, Art der Angriffe, Listen und Zeitraum. Dieselbe Auskunft gibt es per API v2 (GET https://ipv64.net/api/v2/threat/ip/{ip}). Andere Listen wie Spamhaus oder blocklist.de prüft diese Seite nicht.

Steht deine Adresse zu Unrecht auf der Liste, beantragst du dort die Freigabe:

1. Antrag stellen
   In der IP-Auskunft eine Begründung (10 bis 2000 Zeichen) eingeben. Angemeldet gilt der Antrag sofort; ohne Anmeldung bestätigst du ihn über einen Link per E-Mail (48 Stunden gültig). Höchstens 3 Anträge je Tag und Absender (IPv6 je /64).
2. Automatische Prüfung
   Greift die Adresse ab der Bestätigung 24 Stunden lang keinen Sensor mehr an, wird sie automatisch freigegeben und 30 Tage geschützt. Greift sie weiter an, gibt es mehrere Anträge oder gehört sie zu einem Provider- oder Cloud-Netz, prüft IPv64.net von Hand.
3. Verschwinden aus den Listen
   Aus dem Live-Stand fällt die Adresse mit der nächsten Bewertung (alle 30 Minuten), aus dem Tagesstand mit der nächsten Tagesaktualisierung.

Häufige Ursachen für einen Eintrag sind ein befallenes Gerät im eigenen Netz (Kamera, Router, NAS), eine geteilte Adresse (Mobilfunk, CGNAT, VPN) oder eine neu zugeteilte Adresse, die vorher jemand anderes hatte. Für deine eigenen Netze und DynDNS-Adressen gibt es eine Frühwarnung per Mail unter ipv64.net/honeypot/watch.php. Sie nennt je Adresse, wie oft, mit welchem Dienst, Port und welcher Art von Angriff sie in den letzten 14 Tagen aufgefallen ist – nie die Sensoren oder deren Betreiber. Für eingetragene Netze ohne Nachweis und für DynDNS-Adressen meldet sie nur Adressen, die auf der v64 Blocklist stehen; bei DynDNS-Adressen ohne Port und Regel und die letzte Sichtung nur auf den Tag genau.

IPv64 Secure und Live-Karte

Die Seite IPv64 Secure (englisch: ipv64.net/v64_secure) fasst die Schutzfunktionen von IPv64.net zusammen. Sie zeigt den Tagesstand und den Live-Stand der v64 Blocklist nebeneinander mit Anzahl und Alter, wie viele Angreifer live gerade mehr gelistet sind und wie viele Sensoren in den letzten 24 Stunden gemeldet haben. Dazu kommen die Wege zur Liste (Node64, Listen-Token, Blocklisten einbinden) und Links zu Statistik, IP-Auskunft und Live-Karte.

Die öffentliche Live-Karte unter ipv64.net/honeypot/live.php zeigt Angriffe auf die Honeypot64-Sensoren als Bögen vom Land des Angreifers zum Land des Sensors, dazu Zähler und eine Tabelle der letzten Angriffe. Sie spielt die letzte Stunde zeitversetzt ab und wird alle 2 Minuten neu geschrieben. Angreifer erscheinen nur gekürzt (IPv4 /24, IPv6 /48), Sensoren nur als Land, ohne Zugangsdaten.

Text-Listen aus dem Honeypot

Neben den IP-Listen veröffentlicht IPv64.net, was Angreifer an den Sensoren ausprobieren – für Passwort-Richtlinien, Webserver und WAF. Grundlage sind die letzten 30 Tage, aufgenommen wird nur, was mehrere Accounts gemeldet haben. Die Listen werden alle 6 Stunden neu geschrieben, Lizenz CC BY 4.0:

• ipv64_passwords.txt (bis 10.000 Passwörter, häufigste zuerst) und ipv64_passwords_sha1.txt (SHA-1, groß geschrieben, sortiert),
• ipv64_usernames.txt (bis 10.000 Benutzernamen),
• ipv64_bad_useragents.txt (bis 2.000 User-Agents von Angriffswerkzeugen) und ipv64_bad_useragents.nginx.map (nginx-map, Variable $ipv64_bad_ua),
• ipv64_attack_paths.txt (bis 5.000 angefragte Pfade) und ipv64_attack_paths.nginx.conf (nginx-location-Blöcke mit return 403, nur für Server, die diese Pfade nicht selbst ausliefern).

Ob ein eigenes Passwort auf der Liste steht, prüfst du unter ipv64.net/honeypot/password.php; dabei wird nur der Anfang des SHA-1-Hashs übertragen. Die Statistik aller Sensoren steht unter ipv64.net/honeypot/stats.php. Die Kachel „v64 Blocklist (live)“ zeigt dort auch, wie viel Prozent der Adressen auf keiner anderen Angreifer-Liste bei IPv64.net stehen (Kategorien attack und botnet, auch CINS und IPsum) – diese Angreifer kennt nur das Honeypot64-Netz.

Länder- und Kontinentlisten

Für Geoblocking gibt es eine Liste je Land (239 Länder) und je Kontinent: Europa, Asien, Afrika, Nordamerika, Südamerika und Ozeanien. Grundlage sind die offiziellen Zuteilungsdaten der fünf regionalen Internet-Registrierungsstellen (ARIN, RIPE NCC, APNIC, LACNIC, AFRINIC), die IPv64.net täglich neu lädt. Fällt eine Registrierungsstelle aus, bleiben die alten Daten stehen.

• Land (ISO-Code, groß): https://ipv64.net/blocklists/countries/ipv64_blocklist_DE.txt, nur IPv4 …/countries/ipv64_blocklist_v4_DE.txt, nur IPv6 …/countries/ipv64_blocklist_v6_DE.txt
• Kontinent: europe, asia, africa, north_america, south_america, oceania, z. B. https://ipv64.net/blocklists/countries/ipv64_blocklist_europe.txt

Welche Länder zu einem Kontinent gehören, steht in der index.json unter regions. Für Länder und Kontinente gibt es keine MikroTik-Dateien.

Für eigene Werkzeuge gibt es zusätzlich country_ranges.txt.gz: eine gepackte Textdatei mit je Zeile <Land> <erste IP> <letzte IP> (ISO-Code), erst IPv4, dann IPv6, aufsteigend sortiert, benachbarte Bereiche zusammengefasst. Honeypot64 und Node64 nutzen sie, um die Herkunft von Angreifern zu bestimmen – für die Statistik, die Weltkarte und die Live-Karte.

• Quelle: Anders als die Länderlisten nennt diese Datei den Standort einer Adresse, nicht das Land des Inhabers. Grundlage ist DB-IP „IP to Country Lite“, das IPv64.net einmal im Monat lädt; Adressen ohne Land bei DB-IP füllen die Daten der Registrierungsstellen. Fehlt eine gültige DB-IP-Datei, enthält sie wie früher nur die Daten der Registrierungsstellen. Die Kopfzeilen der Datei und das Feld geo der index.json nennen Quelle und Lizenz.
• Lizenz: Die Standortdaten von DB-IP stehen unter CC BY 4.0. Nutzt du die Datei, nennst du die Quelle, z. B. „IP-Länderdaten: DB-IP.com (https://db-ip.com)“.
• Die Länder- und Kontinentlisten oben bleiben bei den Daten der Registrierungsstellen.

Formate und Adressen

Alle Dateien liegen unter https://ipv64.net/blocklists/. Jede Liste gibt es in mehreren Varianten; <id> ist die ID aus der Übersicht:

Das gilt auch für die Gesamtlisten (all, all_notor) und die v64 Blocklist. Beispiel: https://ipv64.net/blocklists/ipv64_blocklist_v4_firehole_l1.txt.

Textformat

• Eine Adresse oder ein Netz in CIDR-Schreibweise je Zeile, ohne Kommentare und Kopfzeilen. Einzelne Adressen stehen als /32 bzw. /128.
• Doppelte Einträge und Netze, die in einem größeren Netz derselben Datei enthalten sind, sind entfernt; die Einträge sind numerisch sortiert.
• Nicht routbare Bereiche fliegen raus: private Netze, CGNAT (100.64.0.0/10), Loopback, Link-Local, Multicast und Dokumentationsnetze. Private Adressen deines Heimnetzes stehen also nie auf einer Liste.
• Eine Datei kann leer sein, z. B. die IPv6-Variante einer reinen IPv4-Liste.

192.0.2.0/24
198.51.100.17/32
2001:db8:1234::/48

MikroTik-Format

Die .rsc-Dateien sind fertige RouterOS-Skripte. Jede Datei löscht zuerst ihre eigenen alten Einträge und trägt dann die aktuellen in die Adressliste IPv64-<id> ein (z. B. IPv64-firehole_l1). So kannst du mehrere Listen nebeneinander importieren.

# IPv64.net Blocklist - 2026-10-26 18:06 UTC - https://ipv64.net/v64_blocklists
/ip firewall address-list
remove [find list=IPv64-dshield1 comment="IPv64 Blocklist"]
add list=IPv64-dshield1 address=192.0.2.0/24 comment="IPv64 Blocklist"

index.json: alle Listen maschinenlesbar

Für Skripte und Werkzeuge beschreibt https://ipv64.net/blocklists/index.json alle Listen. Der Generator schreibt die Datei bei jedem Lauf neu; Node64 baut daraus seine Auswahl. Alle Dateinamen sind relativ zu base.

Jeder Eintrag in lists hat diese Felder:

Beispiel mit jq: alle Listen mit Anzahl und Stand ausgeben.

curl -s https://ipv64.net/blocklists/index.json \
  | jq -r '.lists[] | "\(.id)\t\(.count)\t\(.in_all)\t\(.updated)"'

Die User-Agent-Liste der KI-Crawler ist für data vorgesehen, steht dort aber derzeit nicht. Ihre Dateien sind trotzdem abrufbar (siehe KI-Crawler).

Aktualisierung und Fair Use

Schlägt der Download einer Quelle fehl, bleibt die bisherige Liste stehen. Den Stand jeder Liste zeigt das Feld updated in der index.json; die Listenseite markiert Listen, die älter als zwei Tage sind, als „Outdated“.

Welche Liste für wen?

Wie du die Listen einbaust, steht unter Blocklisten einbinden. Antworten auf häufige Fragen findest du in den FAQ. Eine fehlende Liste kannst du im v64.tech-Forum vorschlagen, am besten gleich mit der Quelle.

Fehler gefunden oder etwas fehlt? Schreibt uns im v64.tech-Forum. · Stand: 2026-11-02