A SearXNG saját üzemeltetése 2026-ban: keresési API, rate limitek és TLS

A legtöbb SearXNG-telepítési útmutató az első oldalbetöltésnél véget ér. Ez túl korai: az engine-ek blokkolhatják a szerver IP-címét, vagy a formátumokból hiányozhat a json az API-kliensek számára. Hasznos production teszt, ha HTML- és JSON-kereséseket is elküldesz, megerősíted, hogy több engine is szolgáltat találatokat, és egy tesztklienssel kiváltod a konfigurált limitert.

A SearXNG szerepe egyértelmű: adatvédelem-központú metakereső és keresési API. Az üzemeltetési környezetéhez nemcsak a webprocess tartozik, ezért a tényleges adatok érkezése előtt explicit módon meg kell nevezni a függőséget, a tárolt állapotot és a nyilvános útvonalat.

Először határozd meg, mit jelent a siker a SearXNG esetében

Ne hagyd, hogy a SearXNG image véletlenül meghatározza a production architektúrát. Az image egy 8080-as porton futó processzt biztosít; a storage, a routing és a külső követelmények továbbra is tudatosan kialakított életciklust igényelnek. A SearXNG hálózati szerződésének része a Redis vagy a Valkey, ha a limiter- és botészlelési funkciók engedélyezve vannak. A privát endpointokat tartsd belső DNS-en, csak a szükséges kimenő hívásokat engedélyezd, és korlátozott jogosultságú service credentialt adj a SearXNG-nek.

A telepítés akkor áll készen a mélyebb tesztelésre, ha HTML- és JSON-kereséseket is el tud küldeni, megerősíti, hogy több engine is szolgáltat találatokat, és egy tesztklienssel kiváltja a konfigurált limitert. Kövesd végig a tranzakciót a logokban, és figyeld az upstream engine-ek késleltetését, az egyidejű lekérdezéseket, a találatok parsingját és a szerver IP-címére alkalmazott tiltásokat. Ezek a megfigyelések megmutatják, hogy az aktuális topológia a megfelelő komponenst izolálja-e.

Válaszd külön a cserélhető konténereket és a tartós adatokat

Készíts helyreállítási manifestet a SearXNG-hez: settings.yml, a limiter konfigurációja és minden helyi plugin kerüljön bele. A bootstrap előtt mountold az /etc/searxng útvonalat, írj bele veszélytelen mintaadatokat, majd cseréld le a konténert annak bizonyítására, hogy az útvonal valóban perzisztens. Ellenőrizd most a tulajdonjogokat és a szabad helyet, mert egy mountolt, de nem írható útvonal gyakorlatilag ugyanúgy viselkedik, mintha egyáltalán nem lenne persistence.

A futó szervertől különálló failure domainbe készíts biztonsági mentést. Hozd létre újra a SearXNG-et a rögzített image-ből, majd ellenőrizd, hogy visszatérnek-e az egyéni engine-ek, a formátumok, a limiter szabályai és a proxybeállítások, valamint hogy egy ismert lekérdezés több engine-ből származó találatokat ad-e. A perzisztens volume-ok útmutatója segít ezt a gyakorlatot snapshot- és megőrzési szabállyá alakítani.

Zárd le az ideiglenes setup-hozzáférést

A bootstrap hitelesítő adatai ideiglenesek; a trust modellje állandó. A SearXNG esetében figyelj arra, hogy ne használd éles környezetben a példában szereplő secret_key értéket, és ne tiltsd le a rate controlt nyilvános endpointon. Használj nem alapértelmezett secret keyt, engedélyezd a visszaélések elleni vezérlőket, és csak akkor tedd elérhetővé a JSON-t, ha egy agentnek vagy alkalmazásnak szüksége van rá.

A SEARXNG_SECRET-et a SearXNG-ben betöltött szerepének megfelelően kezeld: az érzékeny értékeket tartsd távol a Gittől, dokumentáld a rotáció következményeit, és production környezetben soha ne helyettesítsd nyilvános példával. Az image-et szükségtelen Linux-képességek nélkül futtasd, és csak a nyilvános alkalmazási útvonalat tedd elérhetővé. Az adminisztrátori tevékenységet tartsd láthatóan, de a titkos értékek rögzítése nélkül.

Rögzíts egy ismert módon működő SearXNG-telepítést

Alakítsd át a SearXNG smoke tesztjét ismételhető release-paranccsá vagy rövid runbookká. A kimenetének ezt az eredményt kell bizonyítania: HTML- és JSON-kereséseket is elküld, megerősíti, hogy több engine is szolgáltat találatokat, és egy tesztklienssel kiváltja a konfigurált limitert. Az eredménnyel együtt rögzítsd az alkalmazás verzióját, a konténer digestjét, az útvonal hostname-ét és a tesztadatok azonosítóját.

Futtasd le ugyanezt az ellenőrzést egy szokásos konténercsere után, valamint a settings.yml, a limiter konfigurációja és a helyi pluginok máshol történő visszaállítása után. A visszaállítás akkor sikeres, ha visszatérnek az egyéni engine-ek, a formátumok, a limiter szabályai és a proxybeállítások, továbbá egy ismert lekérdezés több engine-ből származó találatokat ad. Hasonlítsd össze az upstream engine-ek késleltetését, az egyidejű lekérdezéseket, a találatok parsingját és a szerver IP-címére alkalmazott tiltásokhoz kapcsolódó időzítést és erőforrás-felhasználást; a jelentős eltérés kivizsgálást érdemel akkor is, ha a végső művelet továbbra is sikeres.

Ezután hajts végre egy biztonságos hibatesztet: ideiglenesen vond meg a tesztidentitás hozzáférését a Redishez vagy a Valkeyhez, amikor a limiter- és botészlelési funkciók engedélyezve vannak. Erősítsd meg, hogy a SearXNG jelzi a hibát, majd manuális, romboló módosítások nélkül visszatér normál állapotba. Csak a szükséges, kitakart logrészletet őrizd meg. Ez a négy részből álló kapu az indulást, a perzisztenciát, a helyreállítást és a hibakezelést fedi le.

Indítsd el az első production jellegű példányt

A konténert cserélhető runtime-ként használd, ne az igazság forrásaként.

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

Add hozzá a Redishez vagy a Valkeyhez áttekintett kapcsolati beállításokat, amikor a limiter- és botészlelési funkciók engedélyezve vannak; a privát szolgáltatásokhoz használj privát neveket. Mielőtt elérhetővé tennéd, vizsgáld meg a konténer felhasználóját, az írható útvonalakat és a bindolt listenert. Futtasd le a teljes műveletet — HTML- és JSON-kereséseket is küldj el, erősítsd meg, hogy több engine is szolgáltat találatokat, és egy tesztklienssel váltsd ki a konfigurált limitert —, majd mentsd el a pontos image-hivatkozást, amely az eredményt produkálta.

Ne hagyd, hogy a proxy sikere elfedje az alkalmazás hibáját

A SearXNG számára egyetlen HTTPS-hostnevet tegyél elérhetővé; a nyers 8080-as port maradjon privát. Állítsd be a server base_url értékét és a trusted proxy headereket HTTPS-hez. Ezzel megakadályozod, hogy a böngészők és az API-kliensek két egymással versengő címet ismerjenek meg.

Egy tiszta kliensről futtasd le az ismert módon működő tranzakciót, és vizsgáld meg az első sikertelen kérést. Ha a DNS vagy a TLS hibás, használd a custom-domain útmutatót. Az „engine-ek blokkolják a szerver IP-címét, vagy a formátumokból hiányzik a json az API-kliensek számára” jelenséget külön alkalmazásszintű problémaként diagnosztizáld, miután az útvonal működését már igazoltad.

A következő kérdésre választ adó logok

A SearXNG első hasznos üzemeltetési metrikája az, hogy képes-e HTML- és JSON-kereséseket is elküldeni, megerősíteni, hogy több engine is szolgáltat találatokat, és egy tesztklienssel kiváltani a konfigurált limitert. Ezt egészítsd ki az upstream engine-ek késleltetésére, az egyidejű lekérdezésekre, a találatok parsingjára és a szerver IP-címére alkalmazott tiltásokra vonatkozó telítettségi jelekkel. A kizárólag a processzt ellenőrző probe ne hívjon költséges függőségeket, és ne indítsa újra a konténert csak azért, mert egy upstream rövid ideig nem érhető el.

A frissítéseket adatváltozásként kezeld, mivel a settings szintaxisa, az engine-definíciók és a limiter működése módosulhat; ezért a konfiguráció- és image-változásokat egyetlen review részeként telepítsd. Rögzítsd a verziókat, gyakorold a folyamatot visszaállított állapoton, és tartsd elérhetően az előző image-et addig, amíg a rollback érvényes marad. Ha az engine-ek blokkolják a szerver IP-címét, vagy a formátumokból hiányzik a json az API-kliensek számára, őrizd meg az újraindítás előtti logokat; ezek általában tartalmazzák az okot feltáró üzenetet.

Kapcsold a SearXNG-et a Dockup életciklusához

A SearXNG platformrétege a 8080-as portból, az ingressből, a TLS-ből, a runtime-konfigurációból, a storage-ból és a függőségek elérhetőségéből áll. A Dockup ezeket az összetevőket a saját infrastruktúrájához vagy az ügyfél által csatlakoztatott szerverhez is reprodukálni tudja.

Ezután az üzemeltető befejezi a termékréteget: állítsd be a server base_url értékét és a trusted proxy headereket HTTPS-hez; érvényesítsd ezt a hozzáférési szabályt — használj nem alapértelmezett secret keyt, engedélyezd a visszaélések elleni vezérlőket, és csak akkor tedd elérhetővé a JSON-t, ha egy agentnek vagy alkalmazásnak szüksége van rá —; majd futtasd le ezt: „HTML- és JSON-kereséseket is küldj el, erősítsd meg, hogy több engine is szolgáltat találatokat, és egy tesztklienssel váltsd ki a konfigurált limitert”. Ha ezt a tesztet a telepítéssel együtt rögzíted, nem kevered össze az automatizált provisioninget az alkalmazás készültségével.

Gyakran ismételt kérdések

Mire van szüksége a SearXNG-nek production telepítéshez?

Irányítsd a SearXNG-konténert a 8080-as porton egyetlen HTTPS-origin mögé. A támogató hálózati követelmény a Redis vagy a Valkey, ha a limiter- és botészlelési funkciók engedélyezve vannak. Ne tekintsd késznek a SearXNG-et addig, amíg nem tudsz HTML- és JSON-kereséseket is elküldeni, nem erősíted meg, hogy több engine is szolgáltat találatokat, és egy tesztklienssel nem váltod ki a konfigurált limitert.

Mely SearXNG-adatok tartoznak a biztonsági mentésbe?

Tedd perzisztenssé az /etc/searxng útvonalat, és ugyanabban a helyreállítási manifestben szerepeljen a settings.yml, a limiter konfigurációja és minden helyi plugin. A tiszta SearXNG-visszaállítás csak akkor sikeres, ha visszatérnek az egyéni engine-ek, a formátumok, a limiter szabályai és a proxybeállítások, valamint egy ismert lekérdezés több engine-ből származó találatokat ad.

Szükséges HTTPS a reverse proxy mögött futó SearXNG-hez?

A nyilvános SearXNG-originhez használj HTTPS-t, a 8080-as port pedig maradjon a belső útvonalon. Helyesen alkalmazd a SearXNG-beállítást: állítsd be a server base_url értékét és a trusted proxy headereket HTTPS-hez. A SearXNG esetében a HTTPS védi a hitelesítő adatokat és a felhasználói tartalmakat az átvitel során, valamint egységessé teszi az originre érzékeny kliensviselkedést.

Hogyan kell tesztelni egy SearXNG-frissítést?

Állítsd vissza a jelenlegi SearXNG-állapotot egy izolált telepítésbe, alkalmazd a jelölt verziót, majd ismételd meg az elfogadási tranzakciót. Különösen figyelj arra, hogy a settings szintaxisa, az engine-definíciók és a limiter működése módosulhat; ezért a konfiguráció- és image-változásokat egyetlen review részeként telepítsd. Tartsd meg az előző SearXNG-image-et addig, amíg nem tisztázott az adatmigráció és a rollback határa.