Slik selvhoster du SearXNG i 2026: Search API, rate limits og TLS

De fleste installasjonsnotater for SearXNG stopper etter den første sidelastingen. Det er for tidlig: Engines blokkerer serverens IP-adresse, eller formater utelater json for API-klienter. En nyttig produksjonstest er mer krevende — send både HTML- og JSON-søk, bekreft at flere engines bidrar med resultater, og utløs den konfigurerte limiteren fra en testklient.

SearXNGs rolle er enkel: en personvernfokusert metasearch engine og et search API. Den operasjonelle grensen omfatter mer enn webprosessen, så dependency, lagret state og offentlig route må navngis eksplisitt før reelle data ankommer.

Definer først hva som er vellykket for SearXNG

Ikke la SearXNG-imaget velge produksjonsarkitekturen ved et uhell. Imaget leverer en prosess på 8080; storage, routing og eksterne krav trenger fortsatt bevisste livssykluser. Network contract for SearXNG er Redis eller Valkey når limiter- og bot-detection-funksjoner er aktivert. Hold private endpoints på intern DNS, tillat bare nødvendige utgående kall og gi SearXNG en avgrenset service credential.

Deployeringen er klar for mer omfattende testing når den kan sende både HTML- og JSON-søk, bekrefte at flere engines bidrar med resultater og utløse den konfigurerte limiteren fra en testklient. Følg transaksjonen i loggene og følg med på latency mot upstream-engines, samtidige spørringer, parsing av resultater og bans som er lagt på serverens IP-adresse. Disse observasjonene viser om den nåværende topologien isolerer riktig komponent.

Skill utskiftbare containere fra varige data

Lag et recovery-manifest for SearXNG: settings.yml, limiter-konfigurasjon og eventuelle lokale plugins. Mount /etc/searxng før bootstrap, skriv ufarlige eksempeldata og bytt ut containeren for å bevise at banen faktisk er persistent. Kontroller ownership og ledig plass nå, fordi en mountet, men ikke skrivbar bane i praksis oppfører seg som om persistence mangler helt.

Ta backup til et failure domain som er separat fra serveren som kjører. Opprett SearXNG på nytt fra det pinnede imaget, og bekreft at custom engines, formater, limiter-regler og proxy-innstillinger kommer tilbake, og at et kjent søk gir resultater fra flere engines. Guiden for persistent volumes hjelper deg med å omsette denne øvelsen til en policy for snapshots og retention.

Lukk midlertidig tilgang til oppsettet

Bootstrap credentials er midlertidige; trust-modellen er permanent. Med SearXNG må du passe på å ikke ta i bruk eksempelverdien for secret_key eller deaktivere rate controls på et offentlig endpoint. Bruk en secret key som ikke er standard, aktiver abuse controls og eksponer JSON bare når en agent eller applikasjon trenger det.

Behandle SEARXNG_SECRET i tråd med SearXNG-rollen: hold sensitive verdier ute av Git, dokumenter konsekvensene av rotation og bruk aldri et offentlig eksempel i produksjon. Kjør imaget uten unødvendige Linux capabilities og eksponer bare den offentlige application-routen. Sørg for at administratoraktivitet er synlig uten å logge secret-verdier.

Dokumenter en SearXNG-deployering som fungerer

Gjør SearXNG smoke-testen om til en repeterbar release-kommando eller en kort runbook. Resultatet må vise følgende: send både HTML- og JSON-søk, bekreft at flere engines bidrar med resultater, og utløs den konfigurerte limiteren fra en testklient. Registrer application-versjon, container-digest, route-hostname og identifikatoren for testdata sammen med resultatet.

Kjør den samme kontrollen etter et vanlig containerbytte og etter at settings.yml, limiter-konfigurasjon og eventuelle lokale plugins er gjenopprettet et annet sted. Gjenopprettingen er vellykket når custom engines, formater, limiter-regler og proxy-innstillinger kommer tilbake, og et kjent søk gir resultater fra flere engines. Sammenlign timing og forbruk knyttet til latency mot upstream-engines, samtidige spørringer, parsing av resultater og bans som er lagt på serverens IP-adresse. En stor endring bør undersøkes selv om den endelige handlingen fortsatt lykkes.

Test deretter en trygg feiltilstand: nekt testidentiteten midlertidig tilgang til Redis eller Valkey når limiter- og bot-detection-funksjoner er aktivert. Bekreft at SearXNG synliggjør feilen og går tilbake til normal drift uten destruktive manuelle endringer. Ta vare på bare det nødvendige, redigerte loggutdraget. Denne firetrinnskontrollen dekker oppstart, persistence, recovery og feilhåndtering.

Kjør den første produksjonslignende instansen

Bruk containeren som en utskiftbar runtime, ikke som stedet der sannheten lagres.

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

Legg til de gjennomgåtte connection settings for Redis eller Valkey når limiter- og bot-detection-funksjoner er aktivert, og bruk private navn for private services. Kontroller container-brukeren, skrivbare baner og den bundne lytteren før du eksponerer den. Kjør hele handlingen — send både HTML- og JSON-søk, bekreft at flere engines bidrar med resultater, og utløs den konfigurerte limiteren fra en testklient — og lagre den nøyaktige image-referansen som produserte resultatet.

Unngå at proxy-suksess skjuler feil i applikasjonen

Eksponer ett HTTPS-hostname for SearXNG, og hold den rå porten 8080 privat. Angi server base_url og trusted proxy headers for HTTPS. Dette hindrer nettlesere og API-klienter i å lære to konkurrerende adresser.

Kjør den kjente, fungerende transaksjonen fra en ren klient, og undersøk den første forespørselen som feiler. Bruk guiden for custom domains når DNS eller TLS er feil. Behandle «engines blokkerer serverens IP-adresse, eller formater utelater json for API-klienter» som en separat applikasjonsdiagnose når routen er bekreftet.

Logger som besvarer det neste spørsmålet

Den første nyttige driftsmålingen for SearXNG er om den kan sende både HTML- og JSON-søk, bekrefte at flere engines bidrar med resultater og utløse den konfigurerte limiteren fra en testklient. Kombiner dette med saturation-signaler for latency mot upstream-engines, samtidige spørringer, parsing av resultater og bans som er lagt på serverens IP-adresse. En probe som bare kontrollerer prosessen, bør ikke kalle dyre dependencies eller restarte containeren fordi en upstream-tjeneste er utilgjengelig en kort periode.

Behandle oppgraderinger som dataendringer, fordi syntax for settings, engine-definisjoner og limiter-adferd kan endres. Deploy derfor konfigurasjons- og image-endringer som én samlet review. Pin versjoner, øv på gjenopprettet state og behold det forrige imaget tilgjengelig så lenge rollback fortsatt er mulig. Når engines blokkerer serverens IP-adresse, eller formater utelater json for API-klienter, må du ta vare på logger fra før restart. De inneholder vanligvis den utløsende meldingen.

Knytt SearXNG til Dockups livssyklus

Plattformlaget for SearXNG består av port 8080, ingress, TLS, runtime-konfigurasjon, storage og tilgang til dependencies. Dockup kan gjenskape disse delene for sin egen infrastruktur eller for en server kunden kobler til.

Deretter fullfører operatøren produktlaget: angi server base_url og trusted proxy headers for HTTPS, håndhev denne tilgangsregelen — bruk en secret key som ikke er standard, aktiver abuse controls og eksponer JSON bare når en agent eller applikasjon trenger det — og kjør «send både HTML- og JSON-søk, bekreft at flere engines bidrar med resultater, og utløs den konfigurerte limiteren fra en testklient». Når denne testen registreres sammen med deployeringen, unngår man å forveksle automatisert provisioning med at applikasjonen er klar.

Vanlige spørsmål

Hva trenger SearXNG for en produksjonsdeployering?

Rout SearXNG-containeren på port 8080 gjennom én HTTPS-origin. Det støttende network-kravet er Redis eller Valkey når limiter- og bot-detection-funksjoner er aktivert. Ikke betrakt SearXNG som klar før du kan sende både HTML- og JSON-søk, bekrefte at flere engines bidrar med resultater og utløse den konfigurerte limiteren fra en testklient.

Hvilke SearXNG-data bør inngå i en backup?

Gjør /etc/searxng persistent, og ta med settings.yml, limiter-konfigurasjon og eventuelle lokale plugins i det samme recovery-manifestet. En ren SearXNG-gjenoppretting er bare vellykket når custom engines, formater, limiter-regler og proxy-innstillinger kommer tilbake, og et kjent søk gir resultater fra flere engines.

Krever SearXNG HTTPS bak en reverse proxy?

Bruk HTTPS for den offentlige SearXNG-originen, og hold port 8080 på den interne routen. Bruk SearXNG-innstillingen riktig: angi server base_url og trusted proxy headers for HTTPS. For SearXNG beskytter HTTPS credentials eller brukerinnhold under overføring og sørger for at origin-følsom klientadferd er konsistent.

Hvordan bør en SearXNG-oppgradering testes?

Gjenopprett gjeldende SearXNG-state i en isolert deployment, bruk kandidatversjonen og gjenta akseptansetransaksjonen. Vær spesielt oppmerksom på at syntax for settings, engine-definisjoner og limiter-adferd kan endres. Deploy derfor konfigurasjons- og image-endringer som én samlet review. Behold det forrige SearXNG-imaget til grensene for datamigrering og rollback er forstått.