Så driftar du SearXNG själv 2026: Search API, rate limits och TLS

De flesta installationsanteckningar för SearXNG slutar efter den första sidinläsningen. Det är för tidigt: engines kan blockera serverns IP-adress eller så kan format utelämna JSON för API-klienter. Ett användbart produktionstest är mer krävande — skicka både HTML- och JSON-sökningar, bekräfta att flera engines bidrar med resultat och utlös den konfigurerade limiteraren från en testklient.

SearXNG:s roll är enkel: en integritetsfokuserad metasearch engine och ett search API. Dess operativa gräns omfattar mer än webbprocessen, så beroendet, det lagrade tillståndet och den publika routen måste uttryckligen definieras innan riktiga data anländer.

Definiera först vad som räknas som lyckat för SearXNG

Låt inte SearXNG-imagen av misstag bestämma produktionsarkitekturen. Imagen tillhandahåller en process på 8080; lagring, routing och externa krav behöver fortfarande medvetna livscykler. SearXNG:s nätverkskontrakt är Redis eller Valkey när limiter- och botdetekteringsfunktioner är aktiverade. Håll privata endpoints på intern DNS, tillåt endast nödvändiga utgående anrop och ge SearXNG en avgränsad service credential.

Driftsättningen är redo för mer ingående tester när den kan skicka både HTML- och JSON-sökningar, bekräfta att flera engines bidrar med resultat och utlösa den konfigurerade limiteraren från en testklient. Följ transaktionen i loggarna och övervaka upstream-engine-latens, samtidiga frågor, resultatparsning och bans som tillämpas på serverns IP-adress. Dessa observationer visar om den aktuella topologin isolerar rätt komponent.

Separera utbytbara containrar från beständiga data

Skapa ett recovery-manifest för SearXNG: settings.yml, limiter-konfiguration och eventuella lokala plugins. Montera /etc/searxng före bootstrap, skriv ofarliga exempeldata och byt ut containern för att bevisa att sökvägen faktiskt är persistent. Kontrollera ägarskap och ledigt utrymme nu, eftersom en monterad men skrivskyddad sökväg i praktiken inte ger någon persistence alls.

Säkerhetskopiera till en failure domain som är separat från den körande servern. Återskapa SearXNG från den pinnade imagen och verifiera att anpassade engines, format, limiter-regler och proxyinställningar återkommer och att en känd fråga ger resultat från flera engines. Guiden om persistent volumes hjälper dig att omsätta övningen i en policy för snapshots och retention.

Stäng tillfällig åtkomst för installationen

Bootstrap-credentials är tillfälliga; trust-modellen är permanent. För SearXNG bör du se upp med att leverera example secret_key eller inaktivera rate controls på en publik endpoint. Behåll i stället en icke-standardiserad secret key, aktivera abuse controls och exponera JSON endast när en agent eller applikation behöver det.

Hantera SEARXNG_SECRET utifrån dess roll i SearXNG: håll känsliga värden borta från Git, dokumentera effekterna av rotation och ersätt aldrig ett publikt exempel i produktion. Kör imagen utan onödiga Linux capabilities och exponera endast den publika applikationsrouten. Håll administratörsaktivitet synlig utan att logga secret-värden.

Dokumentera en fungerande SearXNG-driftsättning

Gör om SearXNG:s smoke-test till ett repeterbart release-kommando eller en kort runbook. Resultatet måste visa följande: skicka både HTML- och JSON-sökningar, bekräfta att flera engines bidrar med resultat och utlösa den konfigurerade limiteraren från en testklient. Dokumentera applikationsversion, container digest, route-hostname och testdataidentifierare tillsammans med resultatet.

Kör samma kontroll efter ett rutinmässigt containerbyte och efter att settings.yml, limiter-konfiguration och eventuella lokala plugins har återställts på en annan plats. Återställningen är lyckad när anpassade engines, format, limiter-regler och proxyinställningar återkommer och en känd fråga ger resultat från flera engines. Jämför timing och förbrukning kopplad till upstream-engine-latens, samtidiga frågor, resultatparsning och bans som tillämpas på serverns IP-adress; en stor förändring är värd att undersöka även när det slutliga testet fortfarande godkänns.

Testa sedan ett säkert fel: neka tillfälligt testidentiteten åtkomst till Redis eller Valkey när limiter- och botdetekteringsfunktioner är aktiverade. Bekräfta att SearXNG visar felet och återgår till normalt läge utan destruktiva manuella ändringar. Spara endast det nödvändiga, redigerade loggutdraget. Den här fyrdelade kontrollen täcker uppstart, persistence, återställning och felhantering.

Kör den första produktionsliknande instansen

Använd containern som en utbytbar runtime, inte som platsen där sanningen finns.

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

Lägg till de granskade anslutningsinställningarna för Redis eller Valkey när limiter- och botdetekteringsfunktioner är aktiverade; använd privata namn för privata tjänster. Kontrollera containerns user, skrivbara sökvägar och bundna listeners innan du exponerar den. Kör hela åtgärden — skicka både HTML- och JSON-sökningar, bekräfta att flera engines bidrar med resultat och utlös den konfigurerade limiteraren från en testklient — och spara den exakta image-referens som gav resultatet.

Förhindra att proxyframgång döljer fel i applikationen

Exponera ett HTTPS-hostnamn för SearXNG och håll den direkta porten 8080 privat. Ange server base_url och trusted proxy headers för HTTPS. Det hindrar webbläsare och API-klienter från att upptäcka två konkurrerande adresser.

Kör den fungerande transaktionen från en ren klient och undersök den första begäran som misslyckas. Använd guiden för custom domains när DNS eller TLS är felkonfigurerat. Behandla ”engines blockerar serverns IP-adress eller format utelämnar JSON för API-klienter” som en separat applikationsdiagnos när routen väl är verifierad.

Loggar som besvarar nästa fråga

Det första användbara operativa måttet för SearXNG är om det kan skicka både HTML- och JSON-sökningar, bekräfta att flera engines bidrar med resultat och utlösa den konfigurerade limiteraren från en testklient. Kombinera det med mättnadssignaler för upstream-engine-latens, samtidiga frågor, resultatparsning och bans som tillämpas på serverns IP-adress. En probe som bara kontrollerar processen bör inte anropa dyra beroenden eller starta om containern för att en upstream-tjänst tillfälligt är otillgänglig.

Behandla uppgraderingar som dataförändringar eftersom syntaxen för settings, engine-definitioner och limiter-beteendet kan ändras. Driftsätt därför konfigurations- och imageändringar som en och samma granskning. Pinna versioner, repetera tester på återställt tillstånd och behåll den föregående imagen till dess att en rollback fortfarande är giltig. När engines blockerar serverns IP-adress eller format utelämnar JSON för API-klienter ska du spara loggarna från före omstarten; de innehåller vanligtvis det orsakande meddelandet.

Koppla SearXNG till Dockups livscykel

Plattformslagret för SearXNG består av port 8080, ingress, TLS, runtime-konfiguration, lagring och åtkomst till beroenden. Dockup kan återskapa dessa delar för sin egen infrastruktur eller för en server som kunden ansluter.

Därefter slutför operatören produktlagret: ange server base_url och trusted proxy headers för HTTPS; tillämpa den här åtkomstregeln — behåll en icke-standardiserad secret key, aktivera abuse controls och exponera JSON endast när en agent eller applikation behöver det — och kör ”skicka både HTML- och JSON-sökningar, bekräfta att flera engines bidrar med resultat och utlös den konfigurerade limiteraren från en testklient”. Om testet dokumenteras tillsammans med driftsättningen undviker man att blanda ihop automatiserad provisioning med att applikationen faktiskt är redo.

Vanliga frågor

Vad behöver SearXNG för en produktionsdriftsättning?

Routa SearXNG-containern på port 8080 via en enda HTTPS-origin. Det stödjande nätverkskravet är Redis eller Valkey när limiter- och botdetekteringsfunktioner är aktiverade. Markera inte SearXNG som redo förrän du kan skicka både HTML- och JSON-sökningar, bekräfta att flera engines bidrar med resultat och utlösa den konfigurerade limiteraren från en testklient.

Vilka SearXNG-data ska ingå i en säkerhetskopia?

Gör /etc/searxng persistent och inkludera settings.yml, limiter-konfiguration och eventuella lokala plugins i samma recovery-manifest. En ren SearXNG-återställning är godkänd först när anpassade engines, format, limiter-regler och proxyinställningar återkommer och en känd fråga ger resultat från flera engines.

Kräver SearXNG HTTPS bakom en reverse proxy?

Använd HTTPS för den publika SearXNG-originen och behåll port 8080 på den interna routen. Tillämpa SearXNG-inställningen korrekt: ange server base_url och trusted proxy headers för HTTPS. För SearXNG skyddar HTTPS credentials eller användarinnehåll under överföring och håller origin-känsligt klientbeteende konsekvent.

Hur bör en SearXNG-uppgradering testas?

Återställ aktuellt SearXNG-tillstånd i en isolerad driftsättning, tillämpa kandidatversionen och upprepa dess acceptance-transaktion. Var särskilt uppmärksam eftersom syntaxen för settings, engine-definitioner och limiter-beteendet kan ändras. Driftsätt därför konfigurations- och imageändringar som en och samma granskning. Behåll den tidigare SearXNG-imagen tills gränserna för datamigrering och rollback är förstådda.