SearXNG 2026 selbst hosten: Search API, Rate Limits und TLS

Die meisten Installationsanleitungen für SearXNG enden nach dem ersten Seitenaufruf. Das ist zu früh: Engines blockieren die Server-IP oder Formate liefern für API-Clients kein json. Ein aussagekräftiger Production-Test ist anspruchsvoller – senden Sie sowohl HTML- als auch JSON-Suchen, bestätigen Sie, dass mehrere Engines Ergebnisse liefern, und lösen Sie das konfigurierte Limit von einem Test-Client aus.

Die Rolle von SearXNG ist klar: eine datenschutzorientierte Metasuchmaschine und Search API. Die betriebliche Grenze umfasst mehr als den Webprozess. Deshalb müssen Abhängigkeit, gespeicherter Zustand und öffentliche Route ausdrücklich festgelegt werden, bevor echte Daten eintreffen.

Erfolg für SearXNG zuerst definieren

Lassen Sie nicht zu, dass das SearXNG-Image versehentlich die Production-Architektur vorgibt. Das Image stellt einen Prozess auf Port 8080 bereit; Speicher, Routing und externe Anforderungen benötigen weiterhin bewusst definierte Lebenszyklen. Der Netzwerkvertrag von SearXNG umfasst Redis oder Valkey, wenn Limiter- und Bot-Detection-Features aktiviert sind. Halten Sie private Endpoints im internen DNS, erlauben Sie nur erforderliche ausgehende Verbindungen und geben Sie SearXNG ein Service-Credential mit begrenztem Berechtigungsumfang.

Das Deployment ist bereit für eingehendere Tests, wenn es sowohl HTML- als auch JSON-Suchen senden, bestätigen kann, dass mehrere Engines Ergebnisse liefern, und das konfigurierte Limit von einem Test-Client ausgelöst werden kann. Verfolgen Sie die Transaktion in den Logs und beobachten Sie die Latenz der Upstream-Engines, gleichzeitige Abfragen, das Parsen der Ergebnisse und Sperren der Server-IP. Diese Beobachtungen zeigen, ob die aktuelle Topologie die richtige Komponente isoliert.

Austauschbare Container von persistenten Daten trennen

Erstellen Sie ein Recovery-Manifest für SearXNG: settings.yml, die Limiter-Konfiguration und alle lokalen Plugins. Mounten Sie /etc/searxng vor dem Bootstrap, schreiben Sie unkritische Beispieldaten und ersetzen Sie den Container, um zu beweisen, dass dieser Pfad tatsächlich persistent ist. Prüfen Sie jetzt Besitzrechte und freien Speicherplatz, denn ein gemounteter, aber nicht beschreibbarer Pfad verhält sich überhaupt nicht persistent.

Sichern Sie in eine von dem laufenden Server getrennte Failure Domain. Erstellen Sie SearXNG aus seinem gepinnten Image neu und prüfen Sie, ob benutzerdefinierte Engines, Formate, Limiter-Regeln und Proxy-Einstellungen wiederhergestellt werden und eine bekannte Abfrage Ergebnisse von mehreren Engines liefert. Der Leitfaden zu Persistent Volumes hilft dabei, diese Übung in eine Snapshot- und Retention-Policy zu überführen.

Temporären Setup-Zugriff schließen

Bootstrap-Credentials sind temporär, das Trust Model ist dauerhaft. Achten Sie bei SearXNG darauf, nicht das mitgelieferte Beispiel für secret_key zu verwenden oder Rate Controls an einem öffentlichen Endpoint zu deaktivieren. Verwenden Sie stattdessen einen nicht standardmäßigen Secret Key, aktivieren Sie Abuse Controls und stellen Sie JSON nur bereit, wenn ein Agent oder eine Anwendung dies benötigt.

Behandeln Sie SEARXNG_SECRET entsprechend seiner Rolle in SearXNG: Halten Sie sensible Werte aus Git heraus, dokumentieren Sie die Auswirkungen einer Rotation und ersetzen Sie in Production niemals ein öffentliches Beispiel. Führen Sie das Image ohne unnötige Linux-Capabilities aus und exponieren Sie nur die öffentliche Application-Route. Machen Sie Administratoraktivitäten sichtbar, ohne Secret-Werte zu protokollieren.

Ein funktionierendes SearXNG-Deployment dokumentieren

Machen Sie aus dem SearXNG-Smoke-Test ein wiederholbares Release-Kommando oder ein kurzes Runbook. Die Ausgabe muss dieses Ergebnis belegen: sowohl HTML- als auch JSON-Suchen senden, bestätigen, dass mehrere Engines Ergebnisse liefern, und das konfigurierte Limit von einem Test-Client auslösen. Dokumentieren Sie zusammen mit dem Ergebnis die Anwendungsversion, den Container-Digest, den Route-Hostnamen und die Kennung der Testdaten.

Führen Sie dieselbe Prüfung nach einem routinemäßigen Container-Austausch und nach der Wiederherstellung von settings.yml, der Limiter-Konfiguration und aller lokalen Plugins an einem anderen Ort durch. Die Wiederherstellung war erfolgreich, wenn benutzerdefinierte Engines, Formate, Limiter-Regeln und Proxy-Einstellungen wieder verfügbar sind und eine bekannte Abfrage Ergebnisse von mehreren Engines liefert. Vergleichen Sie Timing und Verbrauch im Zusammenhang mit der Latenz der Upstream-Engines, gleichzeitigen Abfragen, dem Parsen der Ergebnisse und Sperren der Server-IP. Eine deutliche Veränderung verdient auch dann eine Untersuchung, wenn die abschließende Aktion weiterhin erfolgreich ist.

Führen Sie anschließend einen sicheren Fehlerfall aus: Verweigern Sie der Test-Identität vorübergehend den Zugriff auf Redis oder Valkey, wenn Limiter- und Bot-Detection-Features aktiviert sind. Bestätigen Sie, dass SearXNG den Fehler sichtbar macht und ohne destruktive manuelle Änderungen zum Normalbetrieb zurückkehrt. Bewahren Sie nur den erforderlichen, redigierten Log-Auszug auf. Dieses vierteilige Gate deckt Start, Persistenz, Wiederherstellung und Fehlerbehandlung ab.

Die erste produktionsnahe Instanz ausführen

Verwenden Sie den Container als austauschbare Runtime, nicht als Quelle der Wahrheit.

docker run -d \
  --name searxng \
  --restart unless-stopped \
  -p 127.0.0.1:8080:8080 \
  -v searxng-data:/etc/searxng \
  -e SEARXNG_SECRET=replace-with-a-long-random-value \
  searxng/searxng:latest

Fügen Sie die geprüften Verbindungseinstellungen für Redis oder Valkey hinzu, wenn Limiter- und Bot-Detection-Features aktiviert sind; verwenden Sie für private Services private Namen. Prüfen Sie den Container-User, beschreibbare Pfade und den gebundenen Listener, bevor Sie den Dienst exponieren. Führen Sie die vollständige Aktion aus – sowohl HTML- als auch JSON-Suchen senden, bestätigen, dass mehrere Engines Ergebnisse liefern, und das konfigurierte Limit von einem Test-Client auslösen – und speichern Sie die exakte Image-Referenz, mit der das Ergebnis erzeugt wurde.

Verhindern, dass ein erfolgreicher Proxy einen Anwendungsfehler verdeckt

Stellen Sie für SearXNG einen HTTPS-Hostname bereit und halten Sie den direkten Port 8080 privat. Setzen Sie server base_url und vertrauenswürdige Proxy-Header für HTTPS. So verhindern Sie, dass Browser und API-Clients zwei konkurrierende Adressen kennenlernen.

Führen Sie die bekannte funktionierende Transaktion von einem sauberen Client aus und untersuchen Sie die erste fehlschlagende Anfrage. Verwenden Sie den Leitfaden für benutzerdefinierte Domains, wenn DNS oder TLS fehlerhaft sind. Behandeln Sie „Engines blockieren die Server-IP oder Formate liefern für API-Clients kein json“ als separate Anwendungsdiagnose, sobald die Route nachweislich funktioniert.

Logs, die die nächste Frage beantworten

Die erste nützliche Betriebsmetrik für SearXNG ist, ob sowohl HTML- als auch JSON-Suchen gesendet, mehrere Engines mit Ergebnissen bestätigt und das konfigurierte Limit von einem Test-Client ausgelöst werden kann. Kombinieren Sie dies mit Sättigungssignalen für die Latenz der Upstream-Engines, gleichzeitige Abfragen, das Parsen der Ergebnisse und Sperren der Server-IP. Ein reiner Prozess-Probe sollte keine kostenintensiven Abhängigkeiten aufrufen oder den Container neu starten, nur weil ein Upstream kurzzeitig nicht verfügbar ist.

Behandeln Sie Upgrades als Datenänderungen, da sich Syntax der Einstellungen, Engine-Definitionen und Limiter-Verhalten ändern können. Deployen Sie Konfigurations- und Image-Änderungen daher in einem gemeinsamen Review. Pinnen Sie Versionen, proben Sie den Ablauf mit einem wiederhergestellten Zustand und halten Sie das vorherige Image verfügbar, bis ein Rollback weiterhin möglich ist. Wenn Engines die Server-IP blockieren oder Formate für API-Clients kein json liefern, sichern Sie die Logs vor dem Neustart; sie enthalten meist die ursächliche Meldung.

SearXNG an den Dockup-Lebenszyklus anbinden

Die Platform-Schicht für SearXNG besteht aus Port 8080, Ingress, TLS, Runtime-Konfiguration, Speicher und erreichbaren Abhängigkeiten. Dockup kann diese Bestandteile für die eigene Infrastruktur oder für einen Server reproduzieren, den der Kunde verbindet.

Anschließend stellt der Operator die Produkt-Schicht fertig: server base_url und vertrauenswürdige Proxy-Header für HTTPS setzen; diese Zugriffsregel durchsetzen – einen nicht standardmäßigen Secret Key verwenden, Abuse Controls aktivieren und JSON nur bereitstellen, wenn ein Agent oder eine Anwendung dies benötigt – und „sowohl HTML- als auch JSON-Suchen senden, bestätigen, dass mehrere Engines Ergebnisse liefern, und das konfigurierte Limit von einem Test-Client auslösen“ ausführen. Wenn dieser Test zusammen mit dem Deployment dokumentiert wird, lassen sich automatisiertes Provisioning und Anwendungsbereitschaft nicht verwechseln.

Häufig gestellte Fragen

Was benötigt SearXNG für ein Production-Deployment?

Routen Sie den SearXNG-Container auf Port 8080 über einen einzigen HTTPS-Origin. Die unterstützende Netzwerkanforderung ist Redis oder Valkey, wenn Limiter- und Bot-Detection-Features aktiviert sind. Betrachten Sie SearXNG erst als bereit, wenn Sie sowohl HTML- als auch JSON-Suchen senden, bestätigen können, dass mehrere Engines Ergebnisse liefern, und das konfigurierte Limit von einem Test-Client auslösen können.

Welche SearXNG-Daten gehören in ein Backup?

Persistieren Sie /etc/searxng und nehmen Sie settings.yml, die Limiter-Konfiguration und alle lokalen Plugins in dasselbe Recovery-Manifest auf. Eine saubere SearXNG-Wiederherstellung ist erst dann erfolgreich, wenn benutzerdefinierte Engines, Formate, Limiter-Regeln und Proxy-Einstellungen wieder verfügbar sind und eine bekannte Abfrage Ergebnisse von mehreren Engines liefert.

Benötigt SearXNG hinter einem Reverse Proxy HTTPS?

Verwenden Sie HTTPS für den öffentlichen SearXNG-Origin und halten Sie Port 8080 auf der internen Route. Wenden Sie die SearXNG-Einstellung korrekt an: Setzen Sie server base_url und vertrauenswürdige Proxy-Header für HTTPS. Bei SearXNG schützt HTTPS Credentials oder Benutzerinhalte während der Übertragung und sorgt für ein konsistentes, vom Origin abhängiges Client-Verhalten.

Wie sollte ein SearXNG-Upgrade getestet werden?

Stellen Sie den aktuellen SearXNG-Zustand in einem isolierten Deployment wieder her, wenden Sie die Kandidatenversion an und wiederholen Sie die Acceptance-Transaktion. Achten Sie besonders darauf, dass sich Syntax der Einstellungen, Engine-Definitionen und Limiter-Verhalten ändern können. Deployen Sie Konfigurations- und Image-Änderungen daher in einem gemeinsamen Review. Behalten Sie das vorherige SearXNG-Image, bis die Grenzen der Datenmigration und des Rollbacks verstanden sind.