Anubis gegen KI-Crawler: Was TecharoHQs Web AI Firewall Utility belegt

Welches Problem Anubis mit dem Wiegen der Seele löst

Die Projektbeschreibung fasst den Zweck in einem Satz zusammen: Anubis weighs the soul of incoming HTTP requests to stop AI crawlers. Gemeint ist ein Web AI Firewall Utility, das vor dem eigentlichen Ursprungsserver sitzt und jede Anfrage erst durch eine oder mehrere Aufgaben schickt, bevor sie durchgelassen wird. Das Ziel sind keine klassischen Angreifer, sondern die dauerhafte Flut automatisierter Abrufe durch KI-Unternehmen. Das README formuliert es als Schutz des kleinen Internets vor dem endlosen Sturm von Anfragen, den es endless storm of requests that flood in from AI companies nennt.

Für Betreiber eines Forums, eines Wikis oder einer Vereinsseite ist diese Belastung sehr konkret: Bandbreite, Prozesszeit und Traffic-Kosten steigen, während der Gegenwert für die eigene Community gegen null geht. Anubis verspricht an dieser Stelle keine Erkennung mit hoher Treffsicherheit, sondern eine Hürde. Wer sie nimmt, kommt durch; wer sie nicht nimmt, bekommt die Ressource nicht zu sehen. Diese Einfachheit erklärt, weshalb das Werkzeug in Go geschrieben ist und laut README so leichtgewichtig wie möglich bleiben soll, damit jeder sich leisten kann, die Gemeinschaften in seinem Umfeld zu schützen.

Wie die Anubis-Challenge den Weg zum Upstream freimacht

Zum Mechanismus macht das README wenige, aber eindeutige Angaben. Anubis setzt eine oder mehrere challenges ein, also Aufgaben, die ein Client lösen muss, bevor die Anfrage zu den geschützten upstream resources durchgereicht wird. Welche Aufgaben das im Einzelnen sind, in welcher Reihenfolge sie ablaufen und wie lange ein bestandener Zustand gültig bleibt, steht dort nicht; diese Tiefe liegt in der Dokumentation unter anubis.techaro.lol, auf die das Repository ausdrücklich verweist.

Sichtbar ist die ökonomische Grundannahme dahinter. Ein Scraper, der in kurzer Zeit tausend Seiten ziehen will, verliert seinen Vorteil, wenn jede Seite eine Rechenaufgabe kostet. Eine Person mit Browser merkt davon kaum etwas. Wie viel Rechenzeit eine Challenge pro Anfrage beansprucht und wie sich das bei vielen parallelen Verbindungen verhält, ist in der Dokumentation nicht angegeben, ebenso wenig ein Schwellwert, ab dem Anubis selbst zum Engpass wird.

Anubis aufsetzen: policies.mdx statt kopierbarer Installationszeile

An dieser Stelle ist Ehrlichkeit angebracht. Das README von TecharoHQ/anubis enthält keine kopierbare Installationszeile, also kein docker run, kein go install und keine Paketzeile für einen bekannten Paketmanager. Wer Anubis ausprobieren will, wird auf die Dokumentationsseite anubis.techaro.lol verwiesen, mit dem Satz If you want to try this out, visit the Anubis documentation site. Für den Bezug über Distributionen nennt das README einen Packaging-Status bei Repology unter dem Namen anubis-anti-crawler, ohne die dort gelisteten Distributionen oder Versionen selbst zu wiederholen.

Die inhaltliche Steuerung läuft über bot policy definitions, die im README mit dem relativen Pfad ./docs/docs/admin/policies.mdx verlinkt sind. Dort wird festgelegt, welche Clients durchgewinkt und welche gebremst werden. Welche Schlüssel eine solche Policies-Datei erwartet und wie Ausnahmen formuliert werden, geht aus dem README nicht hervor. Aus den Metadaten lassen sich ergänzend die Sprache Go, die MIT-Lizenz, der Standardbranch main sowie 21.804 Sterne und 696 Forks zum Erhebungszeitpunkt ablesen.

Die Nuklearoption Anubis: Was mit dem Internet Archive passiert

Die klarste Warnung kommt vom Projekt selbst. Anubis bezeichnet sich als eine Art nukleare Antwort, im Original a bit of a nuclear response, und sagt offen, dass die eigene Website damit für kleinere Scraper blockiert wird und dass auch gute Bots wie das Internet Archive behindert werden können. Wer Anubis aktiviert, nimmt eine schlechtere Auffindbarkeit in Kauf, denn Archiv-, Vorschau- und Suchmaschinen-Crawler fallen nicht von selbst in eine Ausnahmekategorie.

Abhelfen lässt sich dem nur über eine Allowlist in den genannten bot policy definitions. Das README schreibt, dass an einer kuratierten Sammlung bekanntermaßen guter Bots gearbeitet wird, als Kompromiss zwischen Auffindbarkeit und Verfügbarkeit. Ob diese Sammlung in v1.27.0 schon enthalten ist, lässt sich dem README nicht entnehmen; das Release trägt den Namen Moenbryda Wilfsunnwyn und schweigt dazu. Ein konkretes Gegenbeispiel: Eine öffentliche Dokumentation, deren alte Versionen über das Internet Archive zitierfähig bleiben sollen, verliert genau diese Eigenschaft, sobald eine pauschale Challenge-Pflicht ohne Ausnahme greift.

Anubis oder Cloudflare: Wo die Entscheidung tatsächlich fällt

Die Alternative benennt das README selbst und ungewöhnlich deutlich. In den meisten Fällen, so die Autoren, brauche man Anubis nicht und komme zum Schutz eines Origins vermutlich mit Cloudflare aus; Anubis sei für die Fälle gedacht, in denen man Cloudflare nicht nutzen kann oder nicht nutzen will.

Der Unterschied liegt im Ort der Entscheidung. Ein kommerzielles CDN filtert an seinem Netzrand, mit fremder Infrastruktur und eigenen Regeln, und sieht dabei sämtliche Anfragen. Anubis läuft dagegen vor dem eigenen Ursprungsserver, in eigener Verantwortung, ohne dass Verkehr an einen Dritten abgetreten wird. Für Selbsthoster, Vereine oder Hochschulinstanzen mit strenger Datenschutzvorgabe ist das der Punkt, der zählt. Der Preis ist Komfortverlust: keine verwaltete Bot-Liste vom Anbieter, keine Oberfläche mit Schaltern, niemand, der den Betrieb übernimmt. Wer Hilfe braucht, findet im README einen Verweis auf den Issue-Tracker und auf einen Live-Chat im Patreon-Discord, Kanal #anubis. Eine Reaktionszeit wird nicht zugesagt.

Anubis v1.27.0 im Betrieb: Release-Takt, Issues und MIT-Lizenz

Für die Pflegeplanung helfen die Metadaten. Zum Erhebungszeitpunkt weist das Repository 364 offene Issues auf, der letzte erfasste Push stammt vom 8. August 2026. Die Release-Liste zeigt v1.27.0-pre3, v1.27.0-pre4 und schließlich v1.27.0 innerhalb weniger Tage im August 2026, also einen kurzen Takt aus Vorabversionen und einem stabilen Abschluss. Das belegt rege Arbeit am Code und sagt zugleich nichts über die Dauer der Pflege in späteren Jahren.

Die MIT-Lizenz erlaubt Nutzung, Veränderung und Weitergabe auch in kommerziellen Umgebungen, solange der Lizenzvermerk erhalten bleibt; sie schließt jede Gewährleistung aus. Fällt Anubis aus oder blockiert es versehentlich zahlende Besucher, liegt die Verantwortung beim Betreiber. Vor einem Einsatz auf einer Shop- oder Behördenseite sollte geklärt sein, was ein fehlschlagender Challenge-Durchlauf dort kostet, und die eingesetzte Version sollte auf v1.27.0 festgeschrieben werden, damit ein Minor-Update das Verhalten nicht unangekündigt ändert.

Redaktionelles Fazit

Anubis eignet sich für Betreiber, die einen eigenen Ursprungsserver ohne fremdes CDN gegen KI-Scraper abschirmen müssen und dafür Nebenwirkungen auf Archiv- oder Vorschau-Crawler tragen wollen. Ungeeignet ist es für Angebote, deren Sichtbarkeit von Suchmaschinen abhängt und die keine Allowlist in policies.mdx pflegen möchten, sowie überall dort, wo Cloudflare einsetzbar ist. Wer es trotzdem versucht, sollte v1.27.0 gegen eine Staging-Instanz stellen und messen, ob die Anubis-Challenge reguläre Seitenaufrufe verzögert.

Offizielle Quellen

1. Official documentation
2. Official README
3. Project repository
4. Release notes