Zwanzig Blocklisten im Pi-hole, mehrere Millionen gesammelte Domains und möglicherweise viel Überschneidung: Das kann Gravity-Updates unnötig aufwendig machen. Pi-hole aktualisiert die Listen standardmäßig einmal pro Woche 6 . Blocklist Insight ist ein Python-Skript, das die Überschneidung der erkannten Domains schätzt und eine Auswahl mit einem Abdeckungsziel von 99,5 Prozent vorschlägt 1 .
Das Skript schlägt eine kleinere Auswahl vor, deren erkannte Domains zusammen nahe an die Menge aller eingelesenen Listen herankommen. Es garantiert weder die mathematisch kleinste Auswahl noch denselben Schutz. Prüfe das Ergebnis und deine Listenformate, bevor du in Pi-hole etwas änderst.
Kurzantwort#
Blocklist Insight vergleicht erkannte Domains und schlägt Listen für eine Zielabdeckung von 99,5 Prozent vor. Das ist keine Garantie für vollständige Abdeckung oder unveränderten Schutz. Parser und Cache haben wichtige Grenzen.
Was das Skript tatsächlich macht#
Blocklist Insight lädt deine Listen herunter, extrahiert die Domains, entfernt Duplikate und wendet dann einen Greedy-Set-Cover-Solver an. Der Algorithmus wählt in jedem Schritt die Liste, die die meisten noch nicht abgedeckten Domains hinzufügt, und orientiert sich an einer Zielschwelle von 99,5 Prozent der erkannten Domains 1 . Heraus kommt eine Tabelle, die zeigt, welche Liste wie viel Neues zur berechneten Auswahl beiträgt.
Das Verfahren braucht kein maschinelles Lernen. Bei gleich großem Zusatzbeitrag können sich Auswahl und Reihenfolge durch die parallele Verarbeitung unterscheiden. Es ist ein klassisches Mengenüberdeckungsproblem, das der Autor auch als solches benennt 1 . Der Begriff „Greedy" bezeichnet nur die Auswahlregel: immer die aktuell größte Zusatzmenge nehmen. Das ist schnell, findet aber nicht zwingend die mathematisch kleinste Lösung. Das Ergebnis ist daher ein Vorschlag, kein bewiesenes Minimum.
Zwei Dinge solltest du vorab einordnen, damit du die Prozentzahl nicht falsch liest.
Die Abdeckung bezieht sich auf die Vereinigung deiner eigenen Listen, nicht auf „das ganze Internet". Ein Host, der in keiner deiner Listen steht, kann in der Rechnung nicht auftauchen. Wenn du also von vornherein Lücken hast, schließt das Skript sie nicht 1 .
Der Wert ist zudem kein Versprechen über deine reale Blockquote. Der Autor formuliert es selbst: Der tatsächliche Sperrerfolg hängt davon ab, welche Listen du verwendest und welche Hosts deine Geräte wirklich abfragen 1 . 99,5 Prozent Abdeckung der Listendomains heißt nicht, dass 99,5 Prozent aller Anfragen geblockt werden.
So richtest du das Skript ein#
Voraussetzung ist ein Rechner mit Python 3 und Internetzugang. Du musst Pi-hole nicht installiert haben, um das Skript laufen zu lassen; es lädt die Listen selbst herunter 1 .
- Klone das Repository:
git clone https://github.com/stevejenkins/blocklist-insight.git - Wechsle in das Verzeichnis und mach das Skript ausführbar:
cd blocklist-insightchmod +x insight.py - Lege deine aktuellen Listen in eine Datei
adlists.txtab, eine URL pro Zeile. - Starte die Analyse:
./insight.py
Die Liste der URLs holst du aus deinem Pi-hole. In der Weboberfläche findest du sie unter Adlists beziehungsweise Subscribed lists in der Gruppenverwaltung 2
. Alternativ liest du die URLs direkt aus der adlist-Tabelle der Pi-hole-Datenbank aus; dort steht jede Quelle als eigene Zeile mit ihrer Adresse 3
. Jede nicht leere Zeile in adlists.txt wird als URL interpretiert. Kommentare werden nicht erkannt, also schreibe keine #-Zeilen hinein.
Beim Lauf lädt das Skript die Listen mit einem zufällig gewählten User-Agent herunter und legt sie 24 Stunden in einem lokalen Cache ab. Läufst du es innerhalb dieses Zeitfensters erneut, werden die gecachten Dateien verwendet statt neu heruntergeladen 1 . Downloads und spätere Vergleiche laufen parallel über Thread- und Prozess-Pools; die Prozess-Pools nutzen dabei alle verfügbaren CPU-Kerne 1 . Wie viel Zeit die Parallelisierung spart, hängt von Hardware, Listen und Netzwerk ab; ein Vergleichstest liegt hier nicht vor.
Die Ausgaben lesen#
Der Lauf erzeugt mehrere Dateien 1 :
optimal_lists.md ist die entscheidende. Sie enthält die vom Greedy-Verfahren ausgewählte Kombination als Tabelle mit den Spalten ausgewählte Liste, Gesamtdomains, neu hinzugekommene Domains, Überlappung, Redundanz in Prozent und kumulierte Abdeckung.
matrix.csv und results.md liefern den vollständigen N-x-N-Vergleich. In der Matrix gibt eine Zelle an, wie viel Prozent der Domains der Spaltenliste bereits von der Zeilenliste abgedeckt sind 1
.
errors.txt protokolliert Listen, die offline waren und deshalb nicht in die Rechnung eingeflossen sind 1
.
Die wichtigste Spalte ist die kumulierte Abdeckung. In dem Beispiel, das der Autor im Repository zeigt, deckt die erste Liste, der Threat-Intelligence-Feed von Hagezi, allein 55,55 Prozent der 3.332.279 gesammelten Domains ab. Nach neun von zwanzig Listen liegt die kumulierte Abdeckung bei 99,63 Prozent. Elf weitere Listen sind im Beispiel als nicht ausgewählt mit null oder geringem zusätzlichem Beitrag aufgeführt; daraus folgt nicht, dass sie alle vollständig abgedeckt sind 1 .
Lohnend ist ein Blick auf die Redundanzspalte, denn sie erklärt, warum die späten Listen kaum noch zählen. Die Liste big.oisd.nl bringt in dem Beispiel 231.712 Domains mit, aber nur 33.152 davon sind neu. Die restlichen 198.560 Einträge, 85,7 Prozent, waren durch die zuvor gewählten Listen schon abgedeckt 1
. Genau deshalb landet eine große Liste so spät in der Reihenfolge: Ihre schiere Größe nützt wenig, wenn der Inhalt bereits woanders steht.
Nimm die konkreten Zahlen als das, was sie sind: eine Momentaufnahme einer bestimmten Listenauswahl zu einem bestimmten Zeitpunkt. Blocklisten ändern sich täglich, und deine eigene Kombination kann ganz anders ausfallen. Übertragbar ist nicht die Zahl neun, sondern das Verfahren.
Ein durchgerechnetes Beispiel#
Um die Logik greifbar zu machen, hier die Rechnung an zwei Zeilen aus dem Beispielbericht:
Die zweite gewählte Liste, eine Malware-Liste der RPiList-Sammlung, bringt 667.695 Domains mit. Davon sind 568.335 neu, die restlichen 99.360 standen schon im Threat-Intelligence-Feed. Die Redundanz liegt bei 14,9 Prozent, und die kumulierte Abdeckung springt auf 72,60 Prozent 1 .
Die fünfte gewählte Liste, Hagezi Pro++ in der Adblock-Variante, bringt 225.090 Domains mit, aber nur 112.416 davon sind neu. Rund die Hälfte – 50,1 Prozent – ist bereits abgedeckt 1 . Das ist der Punkt, an dem die Kurve abflacht: Jede weitere große Liste liefert prozentual weniger Neues.
Genau diese Abflachung ist der Nutzen des Skripts. Statt selbst zwanzig Listen gegeneinander zu halten, siehst du auf einen Blick, ab welcher Zeile der Zusatznutzen den Aufwand nicht mehr rechtfertigt.
Warum 99,5 Prozent und nicht 100#
Die Zielschwelle ist im Skript auf 99,5 Prozent gesetzt 1 . Die konkrete Auswahl kann darüber liegen; im Beispiel erreicht sie 99,63 Prozent. Der Code rundet die nötige Domainzahl bei der Berechnung ab, weshalb das Ziel bei sehr kleinen Datenmengen geringfügig unterschritten werden kann.
Welche Domains bei einer Reduktion wegfallen und ob sie im eigenen Netz wichtig sind, lässt sich aus dem Prozentsatz allein nicht ablesen. Auch eine kleine Restmenge kann relevante Domains enthalten.
Die Ergebnisliste in Pi-hole übernehmen#
Sichere zunächst deine bestehende Konfiguration und notiere die aktiven Listen samt Gruppenzuordnung. Prüfe die Auswahl aus optimal_lists.md und deaktiviere Listen schrittweise in der Weboberfläche, statt sie sofort zu löschen. Die Tabelle zeigt den Zusatzbeitrag zum jeweiligen Auswahlschritt, nicht die Qualität oder Sicherheit einer Liste.
Danach baust du die Gravity-Datenbank neu auf:
pihole -g
Pi-hole verwendet beim Gravity-Lauf die konfigurierten Quellen aus der adlist-Tabelle und verarbeitet deren Domains 3
. Standardmäßig stößt ein Cron-Job diesen Lauf einmal pro Woche an, sonntags in den frühen Morgenstunden 6
. Überschneidende Listen können zusätzlichen Download- und Verarbeitungsaufwand verursachen; wie viel Zeit sich durch Entfernen sparen lässt, hängt von der Installation ab 1
.
Der eigentliche Test ist nicht die Prozentzahl, sondern dein Alltag. Prüfe nach dem Wechsel drei Dinge:
Laden die Seiten, die du brauchst, weiterhin? Blocken Anzeigen und Tracker noch wie gewohnt? Gibt es im Haushalt neue Beschwerden?
Der Autor bewertet seine eigene Listenauswahl an genau diesem Maßstab: Ziel ist nicht eine möglichst hohe Zahl geblockter Hosts, sondern stabile Leistung bei einem Test, den er „family test" nennt. Beschweren sich die Leute im Netz nicht über das Pi-hole, passt die Balance 2 .
Fehlalarme abfedern#
Blocklisten allein erzeugen unweigerlich Kollateralschäden. Ein Tracker-Domain, den eine Liste blockt, kann gleichzeitig die Anmeldung bei einem Dienst oder einen Link aus einer Bestätigungsmail zerlegen. Der Autor seiner Pi-hole-Liste mildert das mit zwei Ergänzungen ab 2 :
Eine Whitelist erlaubt gezielt einzelne Dienste wieder. Er nutzt dafür eine Hagezi-Liste für Affiliate- und Tracking-Weiterleitungen, damit Links in Mails und Suchergebnissen weiter funktionieren 2 .
Reguläre Ausdrücke ergänzen die Blocklisten um Muster, blocken aber auch gezielt zu viel. Seine Regex-Liste geht auf Mmottis Pi-hole-Regex zurück und ist in Block-, Erlaubnis- und Exakt-Erlaubnis-Abschnitte geteilt 2 . Der Hinweis ist wichtig für dich: Nach dem Ausdünnen kann ein Muster oder eine Whitelist einen Fehlalarm schneller beheben als das Zurücknehmen einer ganzen Liste.
Wo das Skript an seine Grenze stößt#
Drei Grenzen solltest du kennen, bevor du Listen löschst.
Erstens: Abdeckung ist nicht gleich Schutzqualität. Eine Liste kann viele Domains enthalten und trotzdem schlecht gepflegt sein. Umgekehrt kann eine kleine, aber kuratierte Liste Hosts blocken, die in keiner Massenliste stehen. Die Mengenrechnung bewertet nur Überlappung, nicht Pflegezustand oder Fehlalarmquote.
Zweitens: Nicht erreichbare Listen fehlen in der Rechnung. Das Skript meldet fehlgeschlagene Downloads und schreibt sie in errors.txt 1
. Die Datei wird nur bei Fehlern neu geschrieben und kann daher auch Meldungen eines früheren Laufs enthalten. Prüfe die Ausgabe des aktuellen Laufs. Der Download-Cache gilt 24 Stunden; der separate Cache verarbeiteter Domains hat im geprüften Quellcode keine entsprechende Ablaufprüfung. Selbst nach einem frischen Download kann daher ein alter verarbeiteter Stand verwendet werden.
Drittens: Die Fehlalarm-Wahrscheinlichkeit kann sich mit der Listenauswahl ändern. Aggressivere Listen können mehr unerwünschte, aber auch mehr benötigte Domains blockieren. Bei den Hagezi-Listen ist genau das als Stufenmodell abgebildet: Light, Normal, Pro, Pro++ und Ultimate blocken zunehmend gründlich, erkaufen das aber mit mehr Kollateralschäden. Als Empfehlung nennt Hagezi selbst die Pro-Variante, ergänzt um den Threat-Intelligence-Feed für aktive Bedrohungen 5
. Wer eine möglichst unauffällige Basis will, nimmt stattdessen einen Low-False-Positive-Allrounder wie OISD; die Liste taucht in der Beispielauswertung als big.oisd.nl auf 1
, und OISD selbst bewirbt sie damit, dass sie Funktionalität vor Blockierquote stellt 7
.
Welche Listen du überhaupt füttern solltest#
Das Skript optimiert, was du ihm gibst. Es empfiehlt keine Listen, es sortiert nur deine. Deshalb entscheidet die Qualität der Eingabe über die Qualität des Ergebnisses.
Eine belastbare Grundauswahl stammt aus etablierten, kontinuierlich gepflegten Quellen. Der Autor seiner Pi-hole-Liste stützt sich aktuell auf Hagezi, RPiList, StevenBlack, OISD, Frogeye und ThreatFox; in der Repository-Beschreibung nennt er außerdem die uBlock-Origin-Assets und URLHaus als Quellen seiner Auswahl 2 . Hagezi pflegt eine breite Sammlung für Werbung, Tracker, Telemetrie, Phishing, Malware und Betrug, die mit Pi-hole und anderen DNS-Blockern zusammenarbeitet 5 .
Eine Besonderheit betrifft ThreatFox: Die entsprechende Liste setzt einen kostenlosen Autorisierungsschlüssel von abuse.ch voraus, den du in die Listen-URL einsetzen musst 2
. Ohne diesen Schlüssel lädt die Liste nicht, und genau solche Fälle landen dann in errors.txt.
Achtung beim Listenformat: Das Skript sucht mit einem regulären Ausdruck im gesamten Inhalt nach Zeichenketten, die wie Domains aussehen 1 . Dabei kann es auch Domains aus Kommentaren, URLs oder Ausnahmeregeln erfassen; das Muster prüft nicht, ob Pi-hole sie tatsächlich blockieren würde. Gerade bei gemischten Formaten ist die berechnete Abdeckung deshalb nur eine Näherung und kann von Pi-holes wirksamer Sperrliste abweichen. Prüfe die verwendeten Listen und übernimm das Ergebnis nicht ungeprüft.
Das Skript selbst geht auf die ältere Bash-Vorlage crosscheck zurück, die Blocklisten paarweise verglichen hat, um den Anteil doppelter Einträge zu messen 4
. Blocklist Insight erweitert diesen Ansatz um die automatische Auswahl einer Teilmenge.
Lohnt sich der Aufwand für dich?#
Ob sich der Vergleich lohnt, hängt von Inhalt und Größe der Listen ab, nicht von einer festen Anzahl. Bereits wenige Listen können stark überlappen; viele Listen können umgekehrt jeweils wichtige eigene Domains enthalten. Das Beispiel im Repository zeigt nur eine konkrete Auswahl 1 .
Das Skript musst du nicht auf dem Pi-hole selbst ausführen. Es braucht nur Python und Internetzugang und nutzt beim Rechnen alle verfügbaren CPU-Kerne 1 . Auf einem schwachen Einplatinenrechner mit vielen Listen ist der Lauf langsamer; du kannst das Verzeichnis genauso gut auf einem Desktop oder Laptop klonen, die Analyse dort fahren und nur die Ergebnisliste auf dem Pi-hole übernehmen.
Ein weiterer Anlass für einen Lauf ist eine größere Listenänderung. Fügst du neue Quellen hinzu, zeigt der Vergleich, welche zusätzlichen Domains der Parser erkennt. Ob diese tatsächlich geblockt werden und relevant sind, musst du separat prüfen.
Wenn etwas nicht läuft#
Drei Situationen treten beim ersten Kontakt am häufigsten auf.
Das Skript startet nicht. Dann fehlt entweder die ausführbare Markierung, Python 3, oder die Datei adlists.txt. Das Skript meldet das selbst: Ohne Datei bricht es mit „Error: adlists.txt not found!" ab, ohne URLs mit „No URLs found in adlists.txt" 1
. Prüfe beides, bevor du weitersuchst.
Einzelne Listen fehlen im Ergebnis. Ein Download kann fehlgeschlagen sein oder Zugangsdaten erfordern. Prüfe die Ausgabe des aktuellen Laufs und gegebenenfalls errors.txt 1
; ThreatFox benötigt einen abuse.ch-Schlüssel 2
.
Das Ergebnis wirkt veraltet. Der Download-Cache gilt 24 Stunden, der Cache verarbeiteter Domains hat im geprüften Code keine Ablaufprüfung. Für eine neue Berechnung lösche im Skriptverzeichnis beide Cache-Ordner .cache_lists und .cache_parsed und starte neu 1
. Prüfe anschließend, ob alle Downloads erfolgreich waren.
Nach der Übernahme bricht eine Seite. Prüfe zunächst das Pi-hole-Abfrageprotokoll und ob DNS-Filterung die Ursache ist; es kann auch ein anderes Problem vorliegen. Freigeben kannst du den Domain einzeln über die Whitelist oder gezielt über einen Regex-Allow-Eintrag 2 . Ein zurückgenommener Fehlalarm ist billiger als eine zurückgenommene Blockliste.
Vorgehen, wenn du unsicher bist#
Wenn du das erste Mal bereinigst, sichere zuerst deine Konfiguration und deaktiviere einzelne Listen statt sie zu löschen. Kontrolliere die Gruppenzuordnung, aktualisiere Gravity und beobachte über einen geeigneten Zeitraum Abfrageprotokoll und Funktionen. Treten Probleme auf oder fehlt ein wichtiger Schutz, kannst du die deaktivierten Listen wieder einschalten.
Das schrittweise Vorgehen erleichtert den Rückbau, garantiert aber weder unveränderte Blockwirkung noch das Ausbleiben von Fehlalarmen.
Weiterführende Artikel#
- iOS 27 umgeht Pi-hole: Connectivity Assist und Limit IP Address Tracking ausschalten
- RJ45-Stecker für CAT6-Verlegekabel: So schließt du den Decken-Access-Point richtig an
- Das Open-Source-Dilemma: gute Datenschutz-Tools bleiben unsichtbar
Passende Produktrecherchen#
Wenn du die praktische Seite vertiefen möchtest: Diese konkreten Produkte passen zum Thema dieses Artikels. Es ist keine Rangliste und keine Kaufpflicht, sondern eine kurze Auswahl mit Begründung, für wen sie interessant sein kann:
- Raspberry Pi 5 8 GB – Leser, die Pi-hole neu aufsetzen oder ihren bestehenden Pi ersetzen wollen – Plattform, um Pi-hole mit den optimierten Blocklisten zu betreiben; genug Reserven für Gravity-Updates und zusätzliche Dienste.
- Raspberry Pi 4 Modell B (4 GB) – Leser mit schmalem Budget, die ausschließlich DNS-Filterung betreiben – Günstigere Alternative, die für ein reines Pi-hole mit wenigen Blocklisten völlig ausreicht.
- SanDisk High Endurance microSDXC Speicherkarte 64 GB + Adapter – Leser, die Pi-hole dauerhaft und ausfallarm betreiben – Für dauerhaften Betrieb ausgelegte Speicherkarte; ob sie in deiner Installation länger hält als eine andere Karte, hängt von Nutzung und Bedingungen ab.
- offizieller Raspberry Pi 5 USB-C Netzteil 27W, USB-C Power Supply, schwarz – Leser, die einen Raspberry Pi 5 neu einrichten – Passendes 27-W-Netzteil für den Raspberry Pi 5; eine geeignete Stromversorgung vermindert das Risiko von Problemen durch Unterspannung.
- Starlink-Verfügbarkeit und Konditionen prüfen
Hinweis: Als Amazon-Partner verdient kalika.de an qualifizierten Verkäufen. Für dich ändert sich der Preis nicht.
Hinweis: Dieser Link ist ein Starlink-Empfehlungslink. Wenn du darüber bestellst, können für dich und kalika.de Vorteile nach den jeweils geltenden Starlink-Bedingungen entstehen.
Grenzen der Einordnung#
Die Quellen beschreiben den Stand zum Zeitpunkt der Recherche. Sie ersetzen keine Prüfung im konkreten Einsatz; Konfiguration, Voraussetzungen und lokale Rahmenbedingungen können Ergebnisse verändern. Vor wichtigen Entscheidungen sollten Leserinnen und Leser die genannten Primärquellen erneut prüfen.
Korrektur vom 2. November 2026: Aussagen zu verlustfreier Abdeckung, Mindestanzahl und vollständig redundanten Listen wurden präzisiert. Hinweise auf die Grenzen des Domain-Parsers und des Caches wurden ergänzt.
Transparenzhinweis#
Dieser Beitrag wurde mit Unterstützung künstlicher Intelligenz erstellt und automatisiert auf Quellen, Fakten und Qualitätskriterien geprüft.
Quellen#
[1] Blocklist Insight – GitHub-Repository (README und Quellcode)
[2] Steve Jenkins – Persönliche Pi-hole-Liste mit Nutzungshinweisen
[3] Pi-hole-Dokumentation – Domain-Datenbank und Adlist-Tabelle
[4] crosscheck – Bash-Vorlage für den Blocklisten-Vergleich
[5] Hagezi DNS-Blocklists – Listenstufen und Empfehlungen
[6] Pi-hole – Standard-Cronjob für pihole updateGravity (wöchentlich, Sonntag früh)
[7] OISD – Funktionalität vor Blockierquote, geringe Fehlalarmquote