Ist SearXNG sicher? Was Ihre 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 Ergebnisse auf einer gemeinsamen Ergebnisseite zusammen. Die Suchmaschinen sehen die Instanz. Die Instanz sieht Sie.

Auf 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 belegen, wie sie diese Daten verwendet. Auf Ihrem eigenen Server sehen die Upstream-Suchmaschinen die Adresse Ihres Servers statt Ihrer privaten Adresse. Dieser Austausch ist der gesamte Datenschutzvorteil. Er ist genau so viel wert wie der Server, auf dem die Instanz 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, Ihren User-Agent-Header und die Seite, von der Sie kommen. Diese Daten sind einem Profil zugeordnet, das über die Sitzung hinaus bestehen bleibt. SearXNG wird dazwischengeschaltet. 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 nie an eine Suchmaschine weitergeleitet. Ihre Einstellungen werden im eigenen Browser statt in einem Konto auf dem Server gespeichert.

Zwei Antwort-Header sind standardmäßig aktiviert. Beide erfüllen eine konkrete Aufgabe:

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 dabei weg. X-Robots-Tag: noindex, nofollow verhindert, dass Ihre Instanz und ihre Ergebnisseiten in Suchindizes aufgenommen werden.

Was SearXNG nicht ändert, ist die Suchanfrage selbst. Sie kommt vollständig und lesbar bei der Instanz an, weil TLS (Transport Layer Security) dort terminiert wird. Jede der folgenden Aussagen ergibt sich aus dieser Tatsache.

Auf einer öffentlichen Instanz sieht der Betreiber jede Anfrage

Die eigene Dokumentation des Projekts formuliert es eindeutig: Nutzer 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“. Die Zusicherung auf einer Startseite, keine Logs zu führen, bleibt eine Zusicherung. Von außen lässt sich das nicht prüfen. Es bleibt nur Vertrauen oder Verzicht.

Protokollierung ist außerdem der einfachste Weg, weil der mitgelieferte Standard Ihre Suchanfrage in die URL setzt:

server:
  method: "GET"

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

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 Query-String. 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 weder im Access-Log noch im Browserverlauf. In der Dokumentation wird offen darauf hingewiesen, dass POST Nachteile hat, welche „die Benutzerfreundlichkeit für den Endbenutzer stark einschränken“. Das betrifft hauptsächlich die Zurück-Schaltfläche des Browsers. Sie treffen diese Abwägung bewusst.

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 führt zum selben 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 Ihrer Suchanfrage. Google kann diese Suche dann nicht mit Ihrem angemeldeten Konto, Ihrem Smartphone oder dem Werbeprofil Ihrer privaten Internetverbindung verknüpfen. Die Einrichtung selbst wird in der Anleitung zum Betrieb einer eigenen SearXNG-Instanz auf einem VPS beschrieben.

Wichtig ist, was sich nicht geändert hat. Die Suchmaschinen sehen weiterhin den Abfragetext, den Zeitpunkt, die von Ihnen angeforderte Sprache und Region sowie über Monate hinweg das Muster all Ihrer Suchanfragen. Diese Daten werden unter einer stabilen Adresse zusammengefasst. Wenn Sie der einzige Benutzer sind, entsteht dadurch ein benutzerbezogener Datenstrom ohne Namen. Um diese Zusammenfassung zu unterbrechen, muss die Instanz über einen ausgehenden Proxy oder über Tor auf die Suchmaschinen zugreifen. SearXNG unterstützt beides. Die dafür erforderliche Konfiguration ist jedoch ein separater Arbeitsschritt.

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. Überwachen Sie sie auf dem Client mit sudo tcpdump -ni any port 53, während Sie die Seite laden. Dann 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 Festplattenverschlüsselung innerhalb einer gemieteten VM ändert daran nichts, weil das laufende System den Schlüssel hält.
• Jeder mit root-Zugriff auf die Instanz sieht alles. Das schließt Sie ein und auch jeden, der später Zugriff erlangt.

Es gibt noch einen weiteren Beobachter, den viele vergessen. Ausgehende 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) verlagert die Sicht Ihres ISP auf den VPN-Anbieter. Am Betreiber der Instanz ändert es nichts. Auch an den Suchmaschinen ändert es nichts, weil diese mit Ihrem Server und nicht mit Ihnen kommunizieren. Beide Varianten werden in dem Vergleich von VPS und VPN ausführlich gegenübergestellt.

Warum SearXNG Sie blockiert und was ein 429 wirklich bedeutet

Zwei unterschiedliche Ereignisse werden als „SearXNG hat mich blockiert“ beschrieben. Sie erfordern unterschiedliche Maßnahmen.

Beim ersten Ereignis antwortet Ihr eigener Limiter mit HTTP 429. Das ist der Bot-Schutz von SearXNG und standardmäßig deaktiviert:

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

Stand 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 Benutzer den Server verwenden, da der Wert standardmäßig false ist und das für den öffentlichen Betrieb 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 er die URL /client<token>.css, die ein echter Browser lädt, nie abruft. 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: */*. Dadurch schlagen zwei Prüfungen gleichzeitig an. Deshalb erhalten Skripte und AI-Agenten von einer Instanz, die im Browser problemlos funktioniert, einen 429. Das müssen Sie beheben, bevor Sie die Suchfunktion eines Agenten auf Ihre eigene Instanz verweisen. Die vollständige Liste der Ursachen und Einstellungen finden Sie im Leitfaden zu SearXNG-Ratenlimits und 429-Fehlern.

Eine Besonderheit des Limiters verdient besondere Beachtung. Hinter einem Reverse Proxy sieht SearXNG 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. Diese Adresse steht nicht in der Liste. Daher werden alle Besucher als ein einziger Client gezählt, und der erste stark aktive Benutzer sperrt alle anderen aus. Fügen Sie dieses Subnetz zu trusted_proxies hinzu.

Die zweite Art der Blockierung erfolgt upstream. Eine Suchmaschine erkennt, dass eine Rechenzentrumsadresse viele Suchanfragen ausführt, und behandelt sie als Scraper. Sie erhalten dafür keinen 429. Sie erhalten eine Ergebnisseite, in der die Ergebnisse dieser Suchmaschine fehlen und bei der Suchmaschine ein Fehler vermerkt ist. Nach wiederholten Fehlern setzt SearXNG die Suchmaschine außerdem für eine gewisse Zeit aus. Die Ursache ist die Adresse, unter der Ihr VPS betrieben wird. Daher helfen hier die Auswahl anderer Suchmaschinen 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 gehen Ihre Suchanfragen von derselben Adresse aus wie die Suchanfragen Tausender anderer Personen. Keine Suchmaschine kann Ihre Anfragen aus dieser Menge herausfiltern. Auf Ihrer Einzelbenutzerinstanz stammt dagegen jede Suchanfrage von dieser Adresse von Ihnen. Die Suchmaschinen erhalten einen klaren Datenstrom von nur einer Person, dem kein Name zugeordnet ist.

Auf Betreiberseite ist der Effekt umgekehrt. Eine große Gruppe bedeutet, dass ein Fremder die Suchanfragen der gesamten Gruppe im Klartext erhält, einschließlich Ihrer Anfragen. Auf Ihrem eigenen System speichern Sie Ihre Suchanfragen und die von niemand anderem.

Wählen Sie daher anhand der tatsächlichen Bedrohung. Sorgen Sie sich um Werbeprofile und websiteübergreifendes Tracking? Dann bietet die Gruppe einen guten Schutz, während das Betreiberrisiko gering ist. Befürchten Sie, dass eine bestimmte Person oder ein bestimmtes Unternehmen eine konkrete Suchanfrage von Ihnen lesen könnte? Dann hilft die Gruppe überhaupt nicht, weil der Betreiber den Klartext sieht. Ein guter Mittelweg ist eine Instanz für einige wenige Personen, die Sie kennen. Sie erhalten eine kleine Gruppe und können dem Betreiber vertrauen, weil Sie selbst der Betreiber sind.

Sind SearXNG-Ergebnisse besser als die von Google?

Nein. SearXNG führt keinen eigenen Index. Daher stammt jedes Ergebnis auf der Seite von einer externen 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 Ihrer Klicks aus der vergangenen Woche neu sortiert. Das wirkt in beide Richtungen, weil die Personalisierung auch lokale Suchabsichten berücksichtigt. Eine Suche wie „Apotheke jetzt geöffnet“ liefert über SearXNG schlechtere Ergebnisse, weil 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 den Bedarf an Bandbreite und Arbeitsspeicher. Außerdem wird formats nur als html ausgeliefert. Eine JSON-Anfrage (JavaScript Object Notation) wird daher mit 403 Forbidden abgewiesen:

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

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

Wo die Privatsphäre von SearXNG endet

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

• Ihr Datenverkehr bleibt überall außer im Suchfeld unverändert. Alles andere, was der Rechner tut, 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. Das ist der gesamte Vorteil.
• Der Betreiber jeder Instanz liest die Anfrage im Klartext. Nur wenn Sie selbst der Betreiber sind, können Sie dies überprüfen.
• Ihre eigenen Zugriffsprotokolle stellen den Verlauf wieder her, den Sie vermeiden wollten. Lesen Sie sie und wechseln Sie zu method: "POST", wenn sie lieber leer bleiben sollen.

SearXNG verlagert den Beobachter. Es beseitigt die Beobachtung nicht. Entscheiden Sie, welcher Beobachter für Sie problematisch ist, wählen Sie die passende Instanz 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 nicht. Ihre Suchanfrage erreicht diesen Server als Klartext. In der Dokumentation des Projekts steht, 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 mitgelieferten Standardwert method: "GET" landet die Suchanfrage außerdem im Access-Log des Reverse Proxy als Teil der Request-Zeile, unabhängig davon, ob der Betreiber dies beabsichtigt hat. Verwenden Sie eine öffentliche Instanz für gewöhnliche Suchanfragen, wenn Sie vor allem Ad-Tracking vermeiden möchten. Geben Sie dort nichts ein, was Sie nicht auch dem Betreiber überlassen würden.

Verbirgt SearXNG meine Suchanfragen vor meinem Internetanbieter?

Der Text der Suchanfrage bleibt verborgen. Die Aktivität bleibt sichtbar. Ihr Internetanbieter sieht eine TLS-Verbindung zur Adresse Ihrer Instanz sowie den Hostnamen im Klartextfeld SNI des Handshakes. Außerdem sieht Ihr DNS-Resolver die Abfrage für diesen Hostnamen. Keiner von beiden sieht, wonach Sie gesucht haben, weil die Verbindung verschlüsselt ist. SearXNG ist kein VPN und schützt keine anderen Daten Ihres Computers.

Warum gibt SearXNG einen 429-Fehler zurück?

Der Fehler 429 stammt vom eigenen Rate Limiter der Instanz. Er dient dem Bot-Schutz und ist keine Meldung von Google. Seine 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, die ein Browser lädt, nie abruft. Wenn der Reverse Proxy in /etc/searxng/limiter.toml fehlt und nicht in trusted_proxies eingetragen ist, wird jeder 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.

Werden meine Suchergebnisse schlechter, wenn ich SearXNG selbst hoste?

Manchmal. Dafür gibt es zwei wichtige Gründe. Die Ergebnisse stammen von Upstream-Suchmaschinen. Wenn diese Suchmaschinen eine Rechenzentrumsadresse drosseln, antworten weniger Suchmaschinen und die Ergebnisseite enthält weniger Inhalte. Außerdem entfällt das personalisierte Ranking. Dadurch entfallen zwar werbebasierte Umordnungen, aber auch die lokale Suchintention. Standortabhängige Suchanfragen liefern daher schwächere Ergebnisse, bis Sie Ihre Region in den Einstellungen festlegen.