Sådan self-hoster du SearXNG i 2026: Search API, rate limits og TLS

De fleste installationsnoter til SearXNG slutter efter den første sideindlæsning. Det er for tidligt: Engines kan blokere serverens IP, eller formater kan mangle json for API-klienter. En nyttig produktionstest er mere krævende — send både HTML- og JSON-søgninger, bekræft, at flere engines bidrager med resultater, og udløs den konfigurerede limiter fra en testklient.

SearXNGs rolle er enkel: en privacy-fokuseret metasearch engine og search API. Den operationelle afgrænsning omfatter mere end webprocessen, så dependency, lagrede data og public route skal navngives eksplicit, før der kommer rigtige data ind.

Definér først, hvornår SearXNG fungerer

Lad ikke SearXNG-imaget ved et tilfælde bestemme produktionsarkitekturen. Imaget leverer en proces på 8080; storage, routing og eksterne krav kræver stadig bevidste lifecycles. SearXNGs netværkskontrakt er Redis eller Valkey, når limiter- og bot-detection-funktioner er aktiveret. Hold private endpoints på intern DNS, tillad kun de nødvendige udgående kald, og giv SearXNG en afgrænset service credential.

Deploymentet er klar til mere dybdegående test, når det kan sende både HTML- og JSON-søgninger, bekræfte, at flere engines bidrager med resultater, og udløse den konfigurerede limiter fra en testklient. Følg transaktionen i logs, og hold øje med upstream-engine latency, samtidige forespørgsler, parsing af resultater og bans, der anvendes på serverens IP. Observationerne viser, om den aktuelle topologi isolerer den rigtige komponent.

Adskil containere, der kan udskiftes, fra varige data

Opret et recovery-manifest for SearXNG: settings.yml, limiter-konfiguration og eventuelle lokale plugins. Mount /etc/searxng før bootstrap, skriv harmløse eksempeldata, og udskift containeren for at bevise, at stien faktisk er persistent. Kontrollér ejerskab og ledig plads nu, for en mountet, men skrivebeskyttet sti fungerer i praksis som manglende persistence.

Tag backup til et failure domain, der er adskilt fra den kørende server. Genskab SearXNG fra det pinnede image, og kontrollér, at custom engines, formater, limiter-regler og proxy-indstillinger kommer tilbage, samt at en kendt forespørgsel giver resultater fra flere engines. Guiden til persistent volumes hjælper med at omsætte øvelsen til en snapshot- og retention-policy.

Luk midlertidig adgang til setup

Bootstrap-credentials er midlertidige; trust-modellen er permanent. Med SearXNG skal du især være opmærksom på ikke at shippe den medfølgende example secret_key eller deaktivere rate controls på et public endpoint. Behold i stedet en ikke-default secret key, aktivér abuse controls, og eksponér kun JSON, når en agent eller applikation har brug for det.

Behandl SEARXNG_SECRET i overensstemmelse med SearXNGs rolle: Hold sensitive værdier ude af Git, dokumentér konsekvenserne af rotation, og brug aldrig et offentligt eksempel i produktion. Kør imaget uden unødvendige Linux capabilities, og eksponér kun den offentlige application route. Sørg for, at administratoraktivitet er synlig, uden at secret values bliver logget.

Dokumentér et SearXNG-deployment, der fungerer

Gør SearXNGs smoke test til en gentagelig release-kommando eller en kort runbook. Outputtet skal demonstrere følgende resultat: send både HTML- og JSON-søgninger, bekræft, at flere engines bidrager med resultater, og udløs den konfigurerede limiter fra en testklient. Registrér application version, container digest, route hostname og testdataidentifikator sammen med resultatet.

Kør den samme kontrol efter en almindelig containerudskiftning og efter gendannelse af settings.yml, limiter-konfiguration og eventuelle lokale plugins et andet sted. Gendannelsen er lykkedes, når custom engines, formater, limiter-regler og proxy-indstillinger kommer tilbage, og en kendt forespørgsel giver resultater fra flere engines. Sammenlign timing og forbrug relateret til upstream-engine latency, samtidige forespørgsler, parsing af resultater og bans, der anvendes på serverens IP; en stor ændring bør undersøges, selv når den endelige handling stadig lykkes.

Udfør derefter en sikker fejltest: Afvis midlertidigt testidentitetens adgang til Redis eller Valkey, når limiter- og bot-detection-funktioner er aktiveret. Bekræft, at SearXNG synliggør fejlen og vender tilbage til normal drift uden destruktive manuelle ændringer. Gem kun det nødvendige, redigerede udsnit af loggen. Denne gate i fire dele dækker startup, persistence, recovery og fejlhåndtering.

Kør den første produktionslignende instans

Brug containeren som et runtime, der kan udskiftes, ikke som stedet, hvor sandheden ligger.

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

Tilføj de gennemgåede forbindelsesindstillinger for Redis eller Valkey, når limiter- og bot-detection-funktioner er aktiveret; brug private navne til private services. Kontrollér container-brugeren, skrivebare stier og den bundne listener, før du eksponerer den. Kør hele handlingen — send både HTML- og JSON-søgninger, bekræft, at flere engines bidrager med resultater, og udløs den konfigurerede limiter fra en testklient — og gem den præcise image-reference, der producerede resultatet.

Undgå, at proxy-succes skjuler fejl i applikationen

Eksponér ét HTTPS-hostname for SearXNG, og hold den rå port 8080 privat. Indstil server base_url og trusted proxy headers for HTTPS. Det forhindrer browsere og API-klienter i at opdage to konkurrerende adresser.

Kør den kendte, fungerende transaktion fra en ren klient, og undersøg den første fejlslagne request. Brug guiden til custom domains, når DNS eller TLS er forkert. Behandl “engines blokerer serverens IP, eller formater mangler json for API-klienter” som en separat applikationsdiagnose, når routen er dokumenteret som fungerende.

Logs, der besvarer det næste spørgsmål

Den første nyttige operationelle metrik for SearXNG er, om den kan sende både HTML- og JSON-søgninger, bekræfte, at flere engines bidrager med resultater, og udløse den konfigurerede limiter fra en testklient. Kombinér det med saturation-signaler for upstream-engine latency, samtidige forespørgsler, parsing af resultater og bans, der anvendes på serverens IP. En process-only probe bør ikke kalde dyre dependencies eller genstarte containeren, fordi en upstream-tjeneste kortvarigt er utilgængelig.

Betragt upgrades som dataændringer, fordi settings-syntaks, engine-definitioner og limiter-adfærd kan ændre sig, så deploy konfiguration og image-ændringer som én samlet review. Pin versioner, øv dig på gendannet state, og behold det tidligere image tilgængeligt, indtil en rollback stadig er gyldig. Når engines blokerer serverens IP, eller formater mangler json for API-klienter, skal du gemme logs fra før genstarten; de indeholder som regel den kausale besked.

Knyt SearXNG til Dockups lifecycle

Platformlaget for SearXNG består af port 8080, ingress, TLS, runtime-konfiguration, storage og adgang til dependencies. Dockup kan genskabe disse dele for sin egen infrastruktur eller for en server, som kunden forbinder.

Derefter færdiggør operatøren produktlaget: Indstil server base_url og trusted proxy headers for HTTPS; håndhæv denne adgangsregel — behold en ikke-default secret key, aktivér abuse controls, og eksponér kun JSON, når en agent eller applikation har brug for det; og kør “send både HTML- og JSON-søgninger, bekræft, at flere engines bidrager med resultater, og udløs den konfigurerede limiter fra en testklient”. Ved at registrere testen sammen med deploymentet undgår du at forveksle automatiseret provisioning med, at applikationen er klar.

Ofte stillede spørgsmål

Hvad har SearXNG brug for til et produktionsdeployment?

Rout SearXNG-containeren på port 8080 gennem én HTTPS-origin. Det understøttende netværkskrav er Redis eller Valkey, når limiter- og bot-detection-funktioner er aktiveret. Erklær ikke SearXNG som klar, før du kan sende både HTML- og JSON-søgninger, bekræfte, at flere engines bidrager med resultater, og udløse den konfigurerede limiter fra en testklient.

Hvilke SearXNG-data hører hjemme i en backup?

Persistér /etc/searxng, og inkludér settings.yml, limiter-konfiguration og eventuelle lokale plugins i det samme recovery-manifest. En ren SearXNG-gendannelse er kun godkendt, når custom engines, formater, limiter-regler og proxy-indstillinger kommer tilbage, og en kendt forespørgsel giver resultater fra flere engines.

Kræver SearXNG HTTPS bag en reverse proxy?

Brug HTTPS til den offentlige SearXNG-origin, og hold port 8080 på den interne route. Anvend SearXNG-indstillingen korrekt: Indstil server base_url og trusted proxy headers for HTTPS. For SearXNG beskytter HTTPS credentials eller brugerindhold under transport og sikrer ensartet client-adfærd, der afhænger af origin.

Hvordan bør en SearXNG-upgrade testes?

Gendan den aktuelle SearXNG-state i et isoleret deployment, anvend kandidatversionen, og gentag acceptance-transaktionen. Vær særligt opmærksom, fordi settings-syntaks, engine-definitioner og limiter-adfærd kan ændre sig, så deploy konfiguration og image-ændringer som én samlet review. Behold det tidligere SearXNG-image, indtil grænsen for datamigrering og rollback er forstået.