Ist SearXNG sicher? Was die Instanz wirklich sieht

Ist SearXNG sicher? Die kurze Antwort

SearXNG ist in eine Richtung sicher und in die andere unsicher. Die Frage „Ist SearXNG sicher?“ lässt sich daher erst beantworten, wenn klar ist, vor wem Sie sich verbergen möchten. SearXNG ist eine Metasuchmaschine: Sie nimmt Ihre Suchanfrage entgegen, sendet sie an Google, Bing, DuckDuckGo und alle anderen von Ihnen aktivierten Suchmaschinen und führt die Antworten auf einer Ergebnisseite zusammen. Die Suchmaschinen sehen die Instanz. Die Instanz sieht Sie.

Bei einer öffentlichen Instanz, die von einer fremden Person betrieben wird, erhält diese Person jede Suchanfrage, die Sie eingeben, im Klartext. Nichts auf der About-Seite kann beweisen, was sie damit macht. Auf Ihrem eigenen Server sehen die übergeordneten Suchmaschinen die Adresse Ihres Servers statt Ihrer privaten Adresse. Dieser Austausch ist die gesamte Datenschutzwirkung. Sie ist genau so viel wert wie der Server, auf dem SearXNG läuft.

Nichts davon verbirgt Ihre Suchanfragen vor Ihrem eigenen Netzwerk. Ihr Internetdienstanbieter (ISP) sieht weiterhin eine Verbindung zur Instanz. Ihr DNS-Resolver (Domain Name System) sieht weiterhin den Hostnamen. Behalten Sie diese Grenze im Blick, während Sie den restlichen Text lesen.

Was SearXNG an einer Suchanfrage ändert

Wenn Sie Google direkt verwenden, erhält Google Ihre IP-Adresse, Ihre Cookies, den User-Agent-Header und die Seite, von der Sie kommen. Diese Daten werden einem Profil zugeordnet, das die Sitzung überdauert. SearXNG steht dazwischen. In der Dokumentation werden zwei Aufgaben beschrieben: „private Daten aus Anfragen an Suchdienste entfernen“ und „für jede Anfrage ein zufälliges Browserprofil erzeugen“. Ihre Cookies werden niemals an eine Suchmaschine weitergeleitet. Ihre Einstellungen werden im eigenen Browser statt in einem Konto auf dem Server gespeichert.

Zwei Response-Header werden standardmäßig gesetzt. Beide erfüllen eine konkrete Funktion:

default_http_headers:
  X-Robots-Tag: noindex, nofollow
  Referrer-Policy: no-referrer

Referrer-Policy: no-referrer bedeutet, dass die Zielwebsite beim Anklicken eines Ergebnisses nie erfährt, von welcher Suchseite Sie kommen. Der Browser lässt den Referer-Header dann weg. X-Robots-Tag: noindex, nofollow verhindert, dass Ihre Instanz und ihre Ergebnisseiten in Suchindizes aufgenommen werden.

Die Suchanfrage selbst verändert SearXNG nicht. Sie kommt vollständig und lesbar bei der Instanz an, weil TLS (Transport Layer Security) dort terminiert wird. Jede folgende Aussage ergibt sich aus dieser Tatsache.

Bei einer öffentlichen Instanz sieht der Betreiber jede Suchanfrage

Die eigene Dokumentation des Projekts sagt es ausdrücklich: Benutzer einer öffentlichen Instanz „müssen dem Administrator dieser Instanz vertrauen“. Außerdem können sie nicht wissen, „ob ihre Anfragen protokolliert, aggregiert und an Dritte gesendet oder verkauft werden“. Eine No-Logs-Aussage auf einer Landingpage bleibt eine Aussage. Von außen lässt sie sich nicht überprüfen. Es gibt daher nur Vertrauen oder gar nichts. Einige öffentliche Instanzen verwenden außerdem weiterhin das ursprüngliche Searx statt dieses Forks. Das ist relevant, weil Searx seit 2023 keinen Code-Commit mehr erhalten hat und nicht gewartete Suchsoftware ein weiterer Bestandteil wäre, dem Sie blind vertrauen müssten.

Das Protokollieren ist außerdem der einfachste Weg, weil der ausgelieferte Standard Ihre Suchanfrage in die URL schreibt:

server:
  method: "GET"

Mit GET wird die Suchanfrage als ?q=... in der Request-Zeile übertragen. Jeder gewöhnliche Reverse Proxy schreibt diese Request-Zeile in sein Access-Log. Damit werden die Suchanfragen protokolliert, ohne dass jemand ihre Protokollierung ausdrücklich veranlassen muss:

203.0.113.5 - - [20/Aug/2026:09:14:02 +0000] "GET /search?q=redundancy+pay+notice+period&category_general=1&language=en HTTP/1.1" 200 15321 "-" "Mozilla/5.0 (X11; Linux x86_64)"

Auf Ihrer eigenen Instanz können Sie das selbst prüfen:

sudo tail -n 5 /var/log/nginx/access.log

Ihre Suchanfragen stehen dort, weil das nginx-Logformat combined den Wert $request schreibt. Dabei handelt es sich um die vollständige Request-Zeile einschließlich des Query-Strings. SearXNG kann darauf keinen Einfluss nehmen. Wenn Sie die Instanz auf method: "POST" umstellen, wird die Suchanfrage in den Request-Body verschoben. Dadurch erscheint sie nicht mehr im Access-Log und im Browserverlauf. In der Dokumentation wird offen darauf hingewiesen, dass POST Nachteile hat, die „die Benutzerfreundlichkeit für den Endbenutzer stark einschränken“, vor allem beim Zurück-Button des Browsers. Das ist eine bewusste Abwägung.

Für jede öffentliche Instanz ergeben sich daraus zwei Konsequenzen. Der Betreiber kann Ihre Suchanfragen lesen, unabhängig davon, ob er sie tatsächlich sammeln wollte. Ein Backup oder ein Einbruch ermöglicht denselben Zugriff auf das Log.

Auf Ihrem eigenen VPS sehen die Suchmaschinen Ihren Server statt Sie

Betreiben Sie Ihre eigene Instanz auf einem VPS (Virtual Private Server), lässt sich die Änderung einfach beschreiben. Google erhält Ihre private IP-Adresse nicht mehr zusammen mit Ihrer Suchanfrage. Stattdessen erhält Google die IP-Adresse Ihres Servers zusammen mit der Suchanfrage. Google kann diese Suche nicht mit Ihrem angemeldeten Konto, Ihrem Smartphone oder dem Werbeprofil verknüpfen, das Ihrer Verbindung zu Hause zugeordnet ist. Die Einrichtung selbst wird in der Anleitung zum Betrieb einer eigenen SearXNG-Instanz auf einem VPS beschrieben.

Machen Sie sich klar, was sich nicht geändert hat. Die Suchmaschinen sehen weiterhin den Suchtext, den Zeitpunkt, die von Ihnen angeforderte Sprache und Region sowie über Monate hinweg das Muster all Ihrer Suchanfragen, gebündelt unter einer stabilen Adresse. Wenn Sie der einzige Benutzer sind, bildet diese Adresse einen personenbezogenen Datenstrom ohne Namen. Um diese Bündelung zu verhindern, muss die Instanz über einen ausgehenden Proxy oder über Tor auf die Suchmaschinen zugreifen. SearXNG unterstützt beides; dafür ist jedoch ein separater Konfigurationsaufwand erforderlich.

Was Ihr ISP, Ihr Resolver und Ihr Host weiterhin sehen

Vier Beobachter bleiben davon unberührt.

• Ihr ISP sieht eine TLS-Verbindung zur IP-Adresse Ihrer Instanz. Außerdem sieht er den Hostnamen im SNI-Feld (Server Name Indication), das während des Handshakes im Klartext übertragen wird. Die Abfrage sieht er nicht.
• Ihr DNS-Resolver sieht die Abfrage für diesen Hostnamen. Mit sudo tcpdump -ni any port 53 können Sie sie auf dem Client überwachen, während Sie die Seite laden. Dabei erscheint die A-Record-Anfrage für Ihre Instanz.
• Ihr VPS-Anbieter betreibt die Hardware. Er kann daher den Datenträger und den Arbeitsspeicher der virtuellen Maschine lesen. Eine Datenträgerverschlüsselung innerhalb einer gemieteten VM ändert daran nichts, weil das laufende System den Schlüssel enthält.
• Jeder mit root-Zugriff auf die Instanz sieht alles. Das schließt Sie ein und auch jeden, der später Zugriff erlangt.

Wenn Sie die Instanz als Tor-Onion-Service erreichen, entfallen die ersten beiden Punkte. Es gibt dann keinen öffentlichen Hostnamen, der aufgelöst werden muss, und kein SNI-Feld, das ausgelesen werden kann. Die Anleitung zum Hinzufügen eines v3-Onion-Services zu einem VPS beschreibt die Einrichtung sowie die Leaks, die diese Adresse andernfalls mit der öffentlichen IP-Adresse Ihres Servers verknüpfen könnten.

Einen weiteren Punkt vergessen viele. Die ausgehenden Anfragen Ihres Servers sind im eigenen Netzwerk des Servers sichtbar. Ihr Anbieter kann daher sehen, dass Ihre Maschine den ganzen Tag mit Google und Bing kommuniziert. Das ist ein Verkehrsmuster und keine Abfrage. Es verrät trotzdem etwas.

An dieser Stelle stellt sich die VPN-Frage. Ein VPN (Virtual Private Network) verschiebt die Sicht Ihres ISP zur Sicht des VPN-Anbieters. Am Betreiber der Instanz ändert sich dadurch nichts. Auch an den Suchmaschinen ändert sich nichts, weil die Suchmaschinen mit Ihrem Server und nicht mit Ihnen kommunizieren. Beide Ansätze werden in dem Vergleich von VPS und VPN ausführlich gegenübergestellt.

Warum SearXNG Sie blockiert und was 429 tatsächlich bedeutet

Zwei unterschiedliche Ereignisse werden beide als „SearXNG hat mich blockiert“ beschrieben. Sie erfordern unterschiedliche Lösungen.

Im ersten Fall antwortet Ihr eigener Limiter mit HTTP 429. Dabei handelt es sich um den Bot-Schutz von SearXNG, der standardmäßig deaktiviert ist:

server:
  limiter: true
valkey:
  url: valkey://localhost:6379/0

Seit August 2026 benötigt der Limiter eine Valkey-Datenbank und liest seine Regeln aus /etc/searxng/limiter.toml. Setzen Sie außerdem server.public_instance: true, wenn tatsächlich fremde Personen den Server verwenden, da der Wert standardmäßig false ist und das für die öffentliche Nutzung vorgesehene Verhalten steuert.

Der Limiter führt mehrere Prüfungen durch. http_user_agent wertet einen nicht gesetzten User-Agent oder einen User-Agent, der bekannten Tools wie curl und wget entspricht, als Bot. http_accept wertet eine Anfrage, deren Header Accept nicht text/html enthält, als Bot. link_token markiert einen Client als verdächtig, wenn dieser niemals die URL /client<token>.css abruft, die ein echter Browser lädt. Wenn eine Prüfung anschlägt, gibt SearXNG 429 zurück und schreibt eine ERROR-Zeile in seinen Logger botdetection.

Daher schlägt dies erwartungsgemäß fehl:

curl -s -o /dev/null -w '%{http_code}\n' 'https://searx.example.com/search?q=test'

curl sendet User-Agent: curl/8.5.0 und Accept: */*, sodass zwei Prüfungen gleichzeitig anschlagen. Deshalb erhalten Skripte und KI-Agenten von einer Instanz, die im Browser problemlos funktioniert, eine 429-Antwort. Das müssen Sie beheben, bevor Sie die Suchfunktion eines Agenten auf Ihre eigene Instanz ausrichten. Eine vollständige Übersicht der Ursachen und Einstellungen finden Sie im Leitfaden zu SearXNG-Ratenbegrenzungen und 429-Fehlern.

Eine Falle beim Limiter hinter einem Reverse Proxy verdient besondere Beachtung. SearXNG sieht die Adresse des Proxys statt der Adresse des Besuchers, sofern dieser Proxy nicht als vertrauenswürdig eingestuft ist:

[botdetection]
ipv4_prefix = 32
ipv6_prefix = 48
trusted_proxies = ['127.0.0.0/8', '::1']

[botdetection.ip_limit]
link_token = false

[botdetection.ip_lists]
pass_ip = []
block_ip = []

Die Standardliste deckt einen Proxy auf demselben Host ab. Ein Proxy in einem separaten Docker-Netzwerk kommt von einer Adresse wie 172.18.0.5, die nicht in der Liste enthalten ist. Dadurch werden alle Besucher als ein einziger Client gezählt, und der erste Nutzer mit vielen Anfragen sperrt alle anderen aus. Fügen Sie dieses Subnetz zu trusted_proxies hinzu.

Die zweite Art der Blockierung geschieht upstream. Eine Suchmaschine erkennt, dass eine von vielen Suchanfragen verwendete Rechenzentrumsadresse zu einem Scraper gehört, und beantwortet Anfragen Ihres Servers nicht mehr. Sie erhalten dafür keine 429-Antwort. Stattdessen erhalten Sie eine Ergebnisseite, in der die Ergebnisse dieser Suchmaschine fehlen, und bei der Suchmaschine wird ein Fehler vermerkt. Nach wiederholten Fehlern deaktiviert SearXNG die Suchmaschine vorübergehend. Die Ursache ist die Adresse, unter der Ihr VPS läuft. Daher helfen hier die Auswahl einer anderen Suchmaschine und Geduld, nicht Änderungen am Limiter.

Hilft es, eine Instanz mit Fremden zu teilen, oder schadet es?

Beides, allerdings in entgegengesetzter Richtung. Deshalb ist die Antwort nicht eindeutig. Anonymität entsteht durch die Menge. Auf einer stark genutzten öffentlichen Instanz stammt Ihre Anfrage von derselben Adresse wie die Anfragen Tausender anderer Personen. Keine Suchmaschine kann Ihre Anfrage aus dieser Menge herausfiltern. Auf Ihrer Einzelbenutzerinstanz stammt dagegen jede Anfrage von dieser Adresse von Ihnen. Die Suchmaschinen erhalten einen klaren Datenstrom von nur einer Person, dem kein Name zugeordnet ist.

Auf Betreiberseite ist es umgekehrt. Eine große Gruppe bedeutet, dass ein Fremder die Klartextanfragen der gesamten Gruppe und damit auch Ihre Anfragen besitzt. Auf Ihrem eigenen Server verwalten Sie Ihre Anfragen, aber keine Anfragen anderer Personen.

Richten Sie Ihre Entscheidung daher nach der tatsächlichen Bedrohung. Befürchten Sie Werbeprofile und seitenübergreifendes Tracking? Dann bietet die Gruppe guten Schutz, und das Betreiberrisiko ist gering. Befürchten Sie, dass eine bestimmte Person oder ein bestimmtes Unternehmen eine konkrete Suche lesen könnte? Dann hilft die Gruppe überhaupt nicht, weil der Betreiber den Klartext sieht. Ein guter Mittelweg ist eine Instanz für einige Personen, die Sie kennen. Sie erhalten eine kleine Gruppe und einen Betreiber, den Sie überprüfen können, weil Sie selbst der Betreiber sind.

Sind die Ergebnisse von SearXNG besser als die von Google?

Nein. SearXNG verfügt über keinen eigenen Index. Daher stammt jedes Ergebnis auf der Seite von einer übergeordneten Suchmaschine. Die maximale Qualität entspricht der Qualität der aktivierten Suchmaschinen. Wenn Sie Google und Bing deaktivieren, sinkt die Qualität noch am selben Tag, weil der größte Teil der allgemeinen Webabdeckung von diesen beiden Suchmaschinen stammt.

Geändert wird die Verarbeitung Ihrer Suchanfrage. Niemand erstellt aus der Suchanfrage ein Werbeprofil. Außerdem werden die Ergebnisse nicht anhand dessen neu sortiert, was Sie letzte Woche angeklickt haben. Das wirkt in beide Richtungen, weil die Personalisierung auch lokale Suchabsichten berücksichtigt. Eine Suche wie „Apotheke jetzt geöffnet“ liefert über SearXNG schwächere Ergebnisse, da die Suchmaschine für Ihren Server kein Ortssignal außer dem Standort des Rechenzentrums hat, in dem er steht. Legen Sie in den Einstellungen die Region fest, wenn lokale Ergebnisse wichtig sind.

Zwei Einstellungen bestimmen, wie viele Informationen Ihre Instanz beim Anzeigen dieser Ergebnisse preisgibt. image_proxy ist standardmäßig false. Daher werden Vorschaubilder direkt von den Websites geladen, auf denen sie gehostet werden, und diese Websites sehen die Adresse Ihres Browsers. Wenn Sie image_proxy: true festlegen, werden die Vorschaubilder stattdessen über die Instanz geladen. Das erhöht jedoch den Bandbreiten- und Speicherbedarf. Außerdem wird formats ausschließlich als html ausgeliefert. Eine JSON-Anfrage (JavaScript Object Notation) wird daher mit 403 Forbidden abgelehnt:

curl -s -o /dev/null -w '%{http_code}\n' 'https://searx.example.com/search?q=test&format=json'

Aktivieren Sie json auf einer öffentlichen Instanz, stellen Sie damit eine kostenlose Scraping-API bereit. Das ist der schnellste Weg, die Adresse Ihres Servers von den Suchmaschinen sperren zu lassen, von denen Sie abhängig sind. Lassen Sie die Option deaktiviert oder schützen Sie sie durch Authentifizierung.

Wo die Datenschutzgrenzen von SearXNG liegen

SearXNG verbirgt vor den Suchmaschinen, wer eine Anfrage stellt. Vor Ihrem Netzwerk verbirgt es jedoch nicht, was Sie tun. Daraus ergeben sich vier Grenzen.

• Ihr Netzwerkverkehr bleibt überall außer im Suchfeld unverändert. Alles andere, was der Rechner ausführt, verlässt Ihr Netzwerk genau wie zuvor.
• Ein Benutzer auf einem Server ist für jede Suchmaschine ein stabiles Identifikationsmerkmal. Dieses Merkmal enthält keinen Namen, und genau darin besteht der gesamte Vorteil.
• Der Betreiber jeder Instanz kann die Suchanfrage im Klartext lesen. Nur wenn Sie selbst der Betreiber sind, können Sie dies zuverlässig ausschließen.
• Ihre eigenen Zugriffsprotokolle stellen den Verlauf wieder her, den Sie eigentlich vermeiden wollten. Lesen Sie sie, und wechseln Sie zu method: "POST", wenn die Protokolle lieber leer bleiben sollen.

SearXNG verschiebt den Beobachter. Es beseitigt die Beobachtung nicht. Entscheiden Sie, welchen Beobachter Sie vermeiden möchten, wählen Sie die passende Instanz aus, und betrachten Sie eine Suchoberfläche nicht als Anonymisierungssoftware.

FAQ

Ist die Nutzung von SearXNG auf einer öffentlichen Instanz sicher?

Vor den Suchmaschinen sind Sie geschützt, vor dem Betreiber jedoch nicht. Ihre Suchanfrage erreicht diesen Server als Klartext. Die Dokumentation des Projekts weist darauf hin, dass Benutzer „dem Administrator dieser Instanz vertrauen müssen“ und nicht wissen können, „ob ihre Anfragen protokolliert, zusammengeführt und an Dritte gesendet oder verkauft werden“. Mit dem ausgelieferten Standardwert method: "GET" landet die Suchanfrage außerdem als Teil der Request-Zeile im Access-Log des Reverse Proxy, unabhängig davon, ob der Betreiber dies beabsichtigt hat. Verwenden Sie eine öffentliche Instanz für gewöhnliche Suchen, wenn Sie vor allem Werbeprofiling vermeiden möchten. Geben Sie dort nichts ein, was Sie dem Betreiber nicht direkt übergeben würden.

Verbirgt SearXNG meine Suchanfragen vor meinem Internetanbieter?

Der Text der Suchanfrage bleibt verborgen. Die Aktivität selbst bleibt jedoch sichtbar. Ihr Anbieter sieht eine TLS-Verbindung zur Adresse Ihrer Instanz sowie den Hostnamen im Klartext-SNI-Feld des Handshakes. Ihr DNS-Resolver sieht außerdem die Abfrage für diesen Hostnamen. Keiner von beiden sieht Ihre Suchanfrage, weil die Verbindung verschlüsselt ist. SearXNG ist kein VPN und schützt keine anderen Aktivitäten Ihres Computers.

Warum gibt SearXNG einen 429-Fehler zurück?

Der Fehler 429 stammt vom Limiter der Instanz selbst. Er dient dem Bot-Schutz und ist keine Meldung von Google. Die Prüfungen markieren eine Anfrage, deren Accept-Header text/html nicht enthält, sowie einen User-Agent, der nicht gesetzt ist oder Tools wie curl und wget entspricht. Eine dritte Prüfung verwendet das Link-Token. Sie markiert einen Client, der die /client<token>.css-URL nicht abruft, die ein Browser lädt. Wenn der Reverse Proxy in /etc/searxng/limiter.toml nicht in trusted_proxies eingetragen ist, werden alle Besucher als ein einziger Client gezählt. Dadurch kann ein ausgelasteter Benutzer alle anderen blockieren. Wenn stattdessen eine Upstream-Suchmaschine Ihren Server blockiert, fehlen deren Ergebnisse einfach auf der Seite. Einen 429-Fehler erhalten Sie dann nicht.

Verschlechtert das eigene Hosting von SearXNG meine Suchergebnisse?

Manchmal, und zwar aus zwei Gründen. Die Ergebnisse stammen von Upstream-Suchmaschinen. Wenn diese Anfragen von einer Rechenzentrumsadresse begrenzen, antworten weniger Suchmaschinen und die Ergebnisseite enthält weniger Treffer. Außerdem entfällt das personalisierte Ranking. Dadurch entfallen zwar werbebedingte Umordnungen, aber auch lokale Suchabsichten. Standortabhängige Suchen liefern daher schwächere Ergebnisse, bis Sie Ihre Region in den Einstellungen festlegen.