SearXNG: CAPTCHA-Fehler von Engines beheben

Was ein CAPTCHA-Fehler in SearXNG bedeutet

CAPTCHA-Fehler in SearXNG werden von den Engines verursacht, die Ihre Instanz abfragt. Ihr Server hat eine Engine nach Ergebnissen gefragt. Die Engine hat statt der Ergebnisse eine Challenge-Seite zurückgegeben. SearXNG hat deshalb einen Fehler für diese Engine protokolliert, weil die Antwort keine auswertbaren Ergebnisse enthielt. Ihre Instanz funktioniert ordnungsgemäß. Ein Rechner, den Sie nicht kontrollieren, hat entschieden, dass Ihre Anfrage nicht wie die Anfrage einer Person aussieht.

Diese Tatsache bestimmt jede der folgenden Fehlerbehebungen. Die Entscheidung wurde auf der eigenen Hardware der Engine getroffen. Daher kann nichts in Ihrer settings.yml sie außer Kraft setzen. Sie können jedoch ändern, über welche Adresse die Anfrage gesendet wird, welche Engines Sie überhaupt abfragen und wie sich Ihre Instanz verhält, sobald eine Engine Anfragen ablehnt.

Zwei Fehler, die gleich aussehen, und wie Sie sie unterscheiden

Der erste Fehler besteht darin, dass Ihre eigene Instanz auf die Anfragen Ihres eigenen Browsers mit HTTP 429 (zu viele Anfragen) antwortet. Dafür ist der SearXNG-Limiter zuständig, also die Bot-Erkennungsschicht vor dem Suchendpunkt. Sie läuft auf Ihrem Server und wird von Ihnen konfiguriert. der Limiter, der Ihren eigenen Benutzern 429 zurückgibt ist ein separates Problem mit eigenen Einstellungen. Keine der folgenden Empfehlungen gilt dafür.

Der zweite Fehler liegt beim Upstream. Die Ergebnisseite wird normal geladen, aber eine oder mehrere Engines fehlen in den Ergebnissen oder zeigen einen Fehlerhinweis. Ihre Instanz hat nichts abgewiesen. Eine Engine hat Ihren Server abgewiesen.

• Die Seite wird nicht geladen oder der Suchendpunkt antwortet mit 429: Prüfen Sie Ihren Limiter.
• Die Seite wird geladen, aber die Ergebnisse sind unvollständig, oder eine Engine ist mit einem Fehler gekennzeichnet: Prüfen Sie den Upstream und lesen Sie weiter.

Beide Fehler können auf derselben Instanz auftreten und sich gegenseitig verstärken. Ein zu großzügig konfigurierter Limiter lässt mehr Datenverkehr zu, wodurch die Rate Ihrer ausgehenden Anfragen steigt. Diagnostizieren Sie die Fehler nacheinander.

Warum liefern SearXNG-Engines auf einem VPS CAPTCHA-Fehler, aber nicht auf meinem Laptop?

Das liegt an der Adresse, von der die Anfrage kommt. Ihre Verbindung zu Hause verwendet eine Adresse aus dem Bereich eines Consumer-ISPs (Internetdienstanbieters). Diese Adresse wurde im Laufe der Zeit von vielen normalen Nutzern verwendet. Ihr VPS verwendet eine Adresse aus einem Rechenzentrumsbereich. Diese Bereiche sind öffentlich dokumentiert: Jeder kann nachschlagen, welche Adressen zu einem Hosting-Anbieter gehören. Eine Engine, die Scraper abwehren möchte, behandelt Anfragen aus Hosting-Bereichen daher zunächst als verdächtig. In diesen Bereichen gibt es nur sehr wenige Nutzer, die mit einem Browser arbeiten.

Zusätzlich zur Adresse kommen weitere Faktoren hinzu. Ihre Instanz sendet pro Nutzersuche eine Anfrage an jede Engine. Daher erzeugen bereits wenige Nutzer eine Anfragerate von einer einzelnen Adresse, die kein einzelner Mensch verursacht. SearXNG unterhält absichtlich keine Sitzung mit der Engine und sendet keine langlebigen Cookies. Jede Anfrage kommt daher ohne bisherigen Verlauf an. Außerdem kann die Adresse eine Vorgeschichte haben, die Sie nicht verursacht haben. Anbieter verwenden Adressen wieder, und der vorherige Nutzer könnte diese Adresse monatelang zum Scraping verwendet haben.

Die Ablehnung ist nicht immer unmittelbar als Fehler erkennbar. Eine Engine kann mit 403, mit 429 oder mit HTTP 200 und einer Challenge-Seite im Antworttext antworten. Der letzte Fall führt häufig zu Verwirrung. Eine Prüfung des Statuscodes zeigt dann, dass die Engine funktioniert, während SearXNG in der Antwort null Ergebnisse findet. Deshalb sollten Sie den Fehlerbericht Ihrer eigenen Instanz prüfen, statt die Engine mit curl aufzurufen und nur die Statuszeile anzusehen.

Lesen Sie zunächst, was Ihre Instanz meldet, bevor Sie etwas ändern

Jede der folgenden Fehlerbehebungen beginnt mit dem Namen der fehlschlagenden Engine und dem Grund, den Ihre Instanz dafür protokolliert hat. SearXNG stellt beides bereit. Die Seite /stats listet Engines mit ihrer Fehleranzahl und Zuverlässigkeit auf. /stats/errors liefert die Fehlerdetails als JSON, das sich leichter speichern und in der nächsten Woche vergleichen lässt. Öffnen Sie beide Seiten in dem Browser, den Sie normalerweise für diese Instanz verwenden.

Das Container-Log enthält dieselben Ereignisse, sobald sie auftreten. Der Servicename entspricht hier dem Namen aus der Compose-Datei, die mit der Container-Dokumentation veröffentlicht wurde. Verwenden Sie Ihren eigenen Servicenamen, falls er abweicht.

docker compose logs -f core

Führen Sie eine Suche aus, die fehlschlägt, während das Log weiter verfolgt wird. Während die Suche läuft, sollte ein Eintrag für die fehlschlagende Engine erscheinen. Notieren Sie den Namen der Engine und die genaue Begründung, die Ihre Instanz ausgegeben hat. Kopieren Sie keinen Enginenamen aus einem Blogbeitrag, auch nicht aus diesem. Die Menge der Engines, die Rechenzentrumsadressen blockieren, ändert sich von Monat zu Monat. Eine Engine, die bei Ihnen fehlschlägt, kann für den Autor des Beitrags problemlos funktionieren.

Wenn die Ergebnisseite keinen Fehler anzeigt, die Ergebnisse aber unvollständig sind, prüfen Sie display_error_messages für diese Engine. Der Standardwert ist true. Wenn eine Instanz diese Option deaktiviert hat, wird die benötigte Meldung ausgeblendet.

Wie SearXNG eine fehlerhafte Engine erneut versucht und aussetzt

SearXNG versucht nicht ununterbrochen, eine Engine zu erreichen, die Anfragen ablehnt. Eine fehlerhafte Engine wird ausgesetzt. Während dieser Zeit wird sie vollständig übersprungen. Dadurch wird aus einer defekten Engine eine scheinbar fehlende Engine.

Zwei Ebenen steuern dieses Verhalten. Beide befinden sich unter search: in settings.yml. Prüfen Sie diese Schlüsselnamen anhand der Einstellungsdokumentation für die tatsächlich verwendete Version, bevor Sie etwas einfügen. Die Namen wurden zwischen Releases geändert. Laut Dokumentation vom 2. September 2026 gelten standardmäßig folgende Werte:

search:
  ban_time_on_fail: 5
  max_ban_time_on_fail: 120
  suspended_times:
    SearxEngineAccessDenied: 86400
    SearxEngineCaptcha: 86400
    SearxEngineTooManyRequests: 3600
    cf_SearxEngineCaptcha: 1296000
    cf_SearxEngineAccessDenied: 86400
    recaptcha_SearxEngineCaptcha: 604800

Die erste Ebene behandelt gewöhnliche Fehler, beispielsweise einen Timeout. Die Sperre beginnt bei ban_time_on_fail Sekunden und verlängert sich mit jedem aufeinanderfolgenden Fehler bis auf max_ban_time_on_fail. Standardmäßig liegt das Maximum bei zwei Minuten. Eine instabile Engine wird daher innerhalb weniger Minuten nach dem Ende des Problems automatisch wieder verfügbar.

Die zweite Ebene behandelt die Fehler, um die es in diesem Leitfaden geht. Wenn SearXNG die Antwort als Challenge oder Ablehnung und nicht als allgemeinen Fehler erkennt, verwendet es den passenden Eintrag aus suspended_times. Diese Werte sind deutlich größer. 86400 Sekunden entsprechen einem ganzen Tag. 604800 entsprechen einer Woche. 1296000 entsprechen fünfzehn Tagen. Die mit cf_ beginnenden Schlüssel gelten, wenn die Challenge als Cloudflare-Challenge erkannt wird. recaptcha_ gilt, wenn sie als reCAPTCHA erkannt wird.

Damit erklärt sich das Symptom, das am meisten Zeit kostet. Sie finden die Ursache und beheben sie. Die Engine liefert jedoch noch stundenlang keine Ergebnisse. Sie ist weiterhin ausgesetzt. Die Aussetzung wird im laufenden Prozess gespeichert. Ein Neustart des Containers hebt sie auf, und bei der nächsten Suche wird die Engine erneut verwendet. Ein normaler Neustart reicht hier aus. Informieren Sie sich unter wann ein Neustart genügt und wann Sie den Container neu erstellen müssen, bevor Sie ohne Grund Images neu erstellen. Wenn die Engine unmittelbar nach dem Neustart erneut fehlschlägt, war die Fehlerbehebung nicht erfolgreich.

Eine Einstellung pro Engine erfordert besondere Vorsicht. retry_on_http_error wiederholt eine Anfrage, wenn die Engine mit den von Ihnen angegebenen Statuscodes antwortet. Bei einer Engine, die Ihre Anfragen blockiert, erzeugen Wiederholungen zusätzlichen Netzwerkverkehr zu dem System, das Ihren Server bereits als Bot eingestuft hat. Lassen Sie diese Einstellung unverändert, außer Sie müssen eine Engine umgehen, die tatsächlich nur sporadisch fehlschlägt.

Die Upstream-Dokumentation zum SSH-Tunnel und was dadurch nicht behoben wird

Die am 2. September 2026 geprüfte SearXNG-Administrationsdokumentation beantwortet dieses Problem mit einem manuellen Tunnel. Sie öffnen über Ihren Server einen SOCKS-Proxy, konfigurieren den Browser auf Ihrem Desktop dafür und beantworten die Challenge manuell, während die Engine die Adresse des Servers sieht.

ssh -q -N -D 8080 user@example.org

-D 8080 öffnet einen lokalen SOCKS-Server auf Port 8080, der die Verbindung über die SSH-Verbindung weiterleitet. -N führt keinen Remote-Befehl aus, und -q unterdrückt die Ausgabe. Ein funktionierender Tunnel gibt daher nichts aus und kehrt nicht zurück. Prüfen Sie ihn in einem zweiten Terminal:

curl -x socks://127.0.0.1:8080 http://ipecho.net/plain
curl http://ipecho.net/plain

Der erste Befehl sollte die Adresse Ihres Servers ausgeben, der zweite die Adresse Ihres Desktops. Zwei identische Ergebnisse bedeuten, dass die Anfrage nicht durch den Tunnel läuft. Konfigurieren Sie anschließend in den Netzwerkeinstellungen Ihres Browsers einen SOCKS5-Proxy unter 127.0.0.1 auf Port 8080. Öffnen Sie im Browser denselben Adressprüfdienst, um zu bestätigen, dass er die Serveradresse meldet, und rufen Sie die Engine auf, die Sie herausfordert. Beantworten Sie die Challenge dort.

Nun der wichtige Hinweis. Vier Punkte begrenzen diese Methode. Das Cookie, das die Engine ausstellt, landet in Ihrem Desktop-Browser. SearXNG hat keinen Zugriff auf die Cookies Ihres Browsers. Ihrer Instanz kann daher nur helfen, was die Engine für die Adresse selbst speichert. Dieser Eintrag läuft nach einem Zeitraum ab, den die Engine festlegt und nicht veröffentlicht. Kein Teil des Verfahrens ist automatisiert. Beim nächsten Mal müssen Sie wieder selbst eingreifen. Wenn andere Personen die Instanz verwenden, läuft die Abfragerate, die die Challenge ausgelöst hat, weiterhin. Die Challenge erscheint daher erneut.

Verwenden Sie diese Methode, um heute Nachmittag eine Instanz funktionsfähig zu machen. Bauen Sie keine Instanz darauf auf.

Dauerhafte Lösung: Engines entfernen oder neu gewichten, die Sie blockieren

Die günstigste dauerhafte Lösung besteht darin, eine Engine nicht mehr abzufragen, die Ihren Server nicht bedienen kann. Ihre settings.yml beginnt im Container-Image mit use_default_settings: true. Ein Eintrag unter engines: mit passendem name überschreibt daher nur die angegebenen Schlüssel. Die übrige Standarddefinition bleibt unverändert.

use_default_settings: true

engines:
  - name: <engine name from your stats page>
    disabled: true
  - name: <another engine name>
    weight: 0.3

disabled: true deaktiviert die Engine standardmäßig, lässt sie aber auf der Einstellungsseite sichtbar. Ein Benutzer kann sie für die eigenen Suchanfragen wieder aktivieren. inactive: true entfernt sie vollständig aus den Benutzereinstellungen. Das ist für eine Engine sinnvoll, die von Ihrer Adresse aus niemals funktionieren wird. weight erfüllt eine andere Aufgabe: Damit wird festgelegt, wie stark die Ergebnisse dieser Engine bei der Zusammenführung und Sortierung durch SearXNG gewichtet werden. Ein Wert unter 1 behält eine nur eingeschränkt brauchbare Engine bei, ohne dass ihre Ergebnisse die erste Seite dominieren.

Starten Sie den Container nach der Bearbeitung neu und führen Sie einige Suchanfragen aus. Prüfen Sie anschließend erneut /stats. Eine übersichtliche Statistikseite mit sechs funktionierenden Engines ist nützlicher als eine Seite voller Fehler mit zwanzig Engines.

Dauerhafte Lösung: Ausgehende Anfragen über einen Proxy senden

SearXNG kann seine ausgehenden Anfragen an Engines über einen Proxy senden. Dadurch ändert sich die Adresse, die die Engine sieht. Legen Sie den Proxy global unter outgoing: fest oder pro Engine, wenn nur eine Engine betroffen ist.

outgoing:
  request_timeout: 2.0
  extra_proxy_timeout: 10.0
  proxies:
    all://:
      - socks5h://user:password@proxy:1080

engines:
  - name: <engine name>
    proxies:
      http: socks5h://user:password@proxy:1080
      https: socks5h://user:password@proxy:1080

Verwenden Sie socks5h:// anstelle von socks5://, wenn der Proxy den Hostnamen auflösen soll. Das h bewirkt, dass der Name an den Proxy gesendet wird, anstatt auf Ihrem Server aufgelöst zu werden. Erhöhen Sie gleichzeitig das Timeout-Budget. request_timeout ist standardmäßig auf 2.0 Sekunden gesetzt. Ein Proxy fügt jeder Anfrage einen zusätzlichen Roundtrip hinzu. Engines, die zuvor rechtzeitig geantwortet haben, schlagen dann stattdessen wegen eines Timeouts fehl. extra_proxy_timeout ist genau dafür vorgesehen und fügt bei Verwendung eines Proxys Sekunden hinzu.

Welche Kosten ein Proxy verursacht:

• Der Proxybetreiber sieht, welche Engines Ihre Instanz wann abfragt. TLS (Transport Layer Security) hält die Suchbegriffe aus dessen Logs heraus, weil die Anfrage innerhalb der verschlüsselten Verbindung übertragen wird. Struktur und Zeitpunkt Ihres Datenverkehrs kann der Betreiber jedoch weiterhin sehen.
• Eine gemeinsam verwendete Exit-Adresse wird auch von anderen Nutzern verwendet, die dafür bezahlen. Wenn diese Nutzer Scraping betreiben, übernehmen Sie deren Reputation. Das kann schneller geschehen als die Sperre, der Sie entgehen wollten.
• Günstige Residential-Proxy-Pools bestehen häufig aus Geräten von Privatnutzern, deren Eigentümer der Weiterleitung von Datenverkehr nicht wissentlich zugestimmt haben. Informieren Sie sich, was Sie kaufen.
• using_tor_proxy: true leitet den Datenverkehr über Tor. Die Adressen der Exit-Nodes werden jedoch vollständig veröffentlicht. Eine Engine, die Rechenzentrumsbereiche blockiert, behandelt Exit-Nodes in der Regel mindestens ebenso streng.
• Die Suche hängt nun von einem Dienst außerhalb Ihres Servers ab. Dieser Dienst kann unabhängig von Ihnen ausfallen und Ihre Ergebnisse mitnehmen.

Ein Proxy verlagert die Sperre, anstatt sie zu entfernen. Außerdem umfasst der Datenschutz Ihrer Instanz nun auch einen Drittanbieter. Wenn der Datenschutz ein wesentlicher Grund für Ihr Self-Hosting ist, prüfen Sie was eine selbst gehostete Instanz tatsächlich verbirgt und was nicht, bevor Sie sich bei einem Dienst anmelden.

Dauerhafte Lösung: bewusst eine kleinere Engine-Auswahl verwenden

Die Option, die die meisten überspringen, besteht darin, weniger Engines zu akzeptieren. Der Wert von SearXNG liegt in der Zusammenführung. Eine Zusammenführung von sechs Engines, die jedes Mal antworten, ist besser als zwanzig Engines, von denen die Hälfte jeweils einen ganzen Tag lang suspendiert ist. Überwachen Sie /stats eine Woche lang und behalten Sie die Engines mit einer sauberen Historie für Ihre Adresse.

Engines, bei denen Sie sich mit einem API key authentifizieren, verhalten sich anders. Die Engine weiß, wer Sie sind, und setzt ein Kontingent durch, statt zu vermuten, ob Sie eine Person sind. Dafür benötigen Sie ein Konto, müssen einen Key in Ihrer Einstellungsdatei hinterlegen und in der Regel bezahlen. Für eine oder zwei Engines, die für Sie wichtig sind, ist das oft der unkomplizierteste Weg.

Treffen Sie diese Entscheidung im Hinblick auf Ihre anderen Tools. Eine suspendierte Engine ist für alles unsichtbar, was Ergebnisse über die API liest, weil die JSON API, die Open WebUI und ähnliche Tools abfragen einfach weniger Ergebnisse zurückgibt, statt einen Fehler zu liefern, den Ihr Tool erkennen kann. Wenn etwas Automatisiertes von Ihrer Instanz abhängt, fragen Sie /stats/errors regelmäßig ab, statt darauf zu warten, dass sich jemand über schlechtere Antworten beschwert.

Lohnt sich der Aufwand überhaupt?

Beantworten Sie diese Frage, indem Sie die Nutzer zählen. Eine Instanz für eine Person sendet täglich eine Handvoll Suchanfragen von einer Adresse aus. Diese Rate führt bei vielen Suchmaschinen nie zu einer Prüfung. Wenn eine Suchmaschine Sie doch prüft, ist die Lösung einfach: Entfernen Sie diese Suchmaschine. Sie werden kaum bemerken, dass sie fehlt. Das ist die übliche Erfahrung beim eigenen Betrieb von SearXNG auf einem kleinen VPS. Dafür benötigen Sie weder einen Tunnel noch einen Proxy.

Eine öffentliche oder gemeinsam genutzte Instanz ist ein anderer Anwendungsfall für dieselbe Software. Die Abfragerate löst die Prüfungen aus. Sie steigt mit jedem weiteren Nutzer. Deshalb treten Prüfungen schneller auf, als eine Konfiguration sie abfangen kann. Planen Sie von Anfang an mit einer kleineren Auswahl an Suchmaschinen. Denken Sie außerdem daran, dass jeder Proxy, den Sie jetzt hinzufügen, die Suchanfragen anderer Personen über Ihr Konto weiterleitet.

Automatisierte Clients liegen dazwischen und tendieren zum schwierigeren Fall. Ein Agent, der mehrere Suchanfragen für die Beantwortung einer Frage ausführt, erzeugt Lastspitzen, wie sie kein Mensch erzeugt. Deshalb wird eine Instanz, an die Sie Coding-Agenten und Recherchewerkzeuge anbinden, früher geprüft als dieselbe Instanz bei manueller Nutzung. Wählen Sie in diesem Fall die Suchmaschinen nicht nach ihrer Anzahl, sondern nach ihrer Zuverlässigkeit aus. Lassen Sie den Agenten mit Ergebnissen arbeiten, die er tatsächlich abrufen kann.

Die maßgebliche Regel lautet: Kämpfen Sie um eine Suchmaschine, wenn sie der Grund für Ihren eigenen Betrieb ist. Entfernen Sie sie, wenn das nicht der Fall ist.

FAQ

Warum liefert eine SearXNG-Engine weiterhin keine Ergebnisse, nachdem ich das Problem behoben habe?

Weil sie weiterhin ausgesetzt ist. Wenn SearXNG eine Challenge oder eine Ablehnung durch eine Engine erkennt, stellt es Abfragen an diese Engine für den in search.suspended_times festgelegten Zeitraum ein. Je nach Art der Ablehnung reichen die Standardwerte von einer Stunde bis zu 15 Tagen. Die Aussetzung wird im laufenden Prozess gespeichert. Durch einen Neustart des Containers wird sie gelöscht, und die nächste Suche versucht erneut, die Engine zu verwenden. Wenn die Engine unmittelbar nach dem Neustart wieder fehlschlägt, war Ihre Korrektur nicht erfolgreich.

Ist ein CAPTCHA-Fehler einer Engine dasselbe wie der 429-Fehler, den meine Instanz zurückgibt?

Die beiden Fehler werden in entgegengesetzte Richtungen ausgelöst. Ein 429-Fehler, den Ihre Instanz an den Browser zurückgibt, entsteht durch den eigenen Limiter von SearXNG, der Ihre Anfrage als automatisiert einstuft. Diesen Limiter können Sie konfigurieren. Ein CAPTCHA- oder Blockierungsfehler bedeutet dagegen, dass eine Upstream-Engine Ihren Server ablehnt. Diese Entscheidung wird auf Systemen getroffen, die Sie nicht kontrollieren. Wenn die Ergebnisseite geladen wird und nur einige Engines fehlen, handelt es sich um den zweiten Fall.

Behebt ein VPN oder ein Proxy auf meinem Server CAPTCHAs von Engines?

Manchmal, aber das hat seinen Preis. Wenn ausgehende Anfragen über outgoing.proxies geleitet werden, ändert sich die Adresse, die die Engine sieht. Dadurch kann eine Blockierung aufgehoben werden, die an den Adressbereich Ihres Rechenzentrums gebunden war. Der Proxy-Betreiber sieht dann, welche Engines Sie wann abfragen. Außerdem wird eine gemeinsam genutzte Exit-Adresse durch die Reputation anderer Kunden belastet. Die zusätzliche Latenz verursacht Timeouts, sofern Sie request_timeout und extra_proxy_timeout nicht erhöhen. Tor ist über using_tor_proxy verfügbar. Die Exit-Adressen werden jedoch veröffentlicht und häufig blockiert.

Kann ich SearXNG so konfigurieren, dass es das CAPTCHA automatisch löst?

Dafür gibt es keine Einstellung. Das vom Projekt dokumentierte Verfahren ist manuell: ein SSH-SOCKS-Tunnel, Ihr eigener Browser und Ihre eigene Interaktion mit der Challenge. Alles, was Sie zur automatischen Beantwortung von Challenges entwickeln, verstößt gegen die erklärte Richtlinie der Engine. Außerdem funktioniert es nach jeder Änderung der Challenge stillschweigend nicht mehr. Sie warten dann einen Scraper, statt eine Suchinstanz zu betreiben. Die blockierenden Engines aus Ihrer Konfiguration zu entfernen, ist die dauerhaft funktionierende Lösung.