Как да хоствате SearXNG самостоятелно през 2026 г.: Search API, rate limits и TLS

Повечето бележки за инсталиране на SearXNG приключват с първото зареждане на страницата. Това е твърде рано: engines могат да блокират IP адреса на сървъра или форматите да не включват json за API clients. Полезният production тест е по-взискателен — изпратете търсения едновременно в HTML и JSON, потвърдете, че няколко engines връщат резултати, и задействайте конфигурирания limiter от test client.

Ролята на SearXNG е ясна: privacy-focused metasearch engine и search API. Оперативният му обхват включва повече от web process, затова dependency, stored state и public route трябва да бъдат изрично описани, преди да постъпят реални данни.

Първо дефинирайте успеха за SearXNG

Не позволявайте image-ът на SearXNG случайно да определи production архитектурата. Image-ът предоставя process на 8080; storage, routing и external requirements все още изискват внимателно планирани lifecycles. Network contract-ът за SearXNG е Redis или Valkey, когато са активирани limiter и bot-detection features. Дръжте private endpoints във вътрешен DNS, разрешете само необходимите outbound calls и дайте на SearXNG service credential с ограничен обхват.

Deployment-ът е готов за по-задълбочено тестване, когато може да изпраща търсения едновременно в HTML и JSON, да потвърди, че няколко engines връщат резултати, и да задейства конфигурирания limiter от test client. Проследете транзакцията в logs и наблюдавайте upstream-engine latency, simultaneous queries, result parsing и bans, приложени към IP адреса на сървъра. Тези наблюдения показват дали текущата topology изолира правилния component.

Разделете replaceable containers от трайните данни

Създайте recovery manifest за SearXNG: settings.yml, limiter configuration и всички local plugins. Mount-нете /etc/searxng преди bootstrap, запишете безвредни примерни данни и заменете container-а, за да докажете, че този path действително е persistent. Проверете ownership и свободното пространство още сега, защото mount-нат, но недостъпен за запис path на практика се държи така, сякаш изобщо няма persistence.

Правете backup в failure domain, отделен от работещия сървър. Създайте отново SearXNG от pinned image и проверете дали custom engines, formats, limiter rules и proxy settings са възстановени и дали известна заявка връща резултати от няколко engines. Ръководството за persistent volumes помага да превърнете това упражнение в snapshot и retention policy.

Затворете временния setup достъп

Bootstrap credentials са временни; trust model-ът е постоянен. При SearXNG обърнете внимание да не качите example secret_key или да изключите rate controls на public endpoint, използвайте non-default secret key, активирайте abuse controls и предоставяйте JSON само когато agent или application го изисква.

Третирайте SEARXNG_SECRET според ролята му в SearXNG: дръжте sensitive values извън Git, документирайте ефектите от rotation и никога не заменяйте public example със стойност за production. Стартирайте image-а без ненужни Linux capabilities и expose-вайте само public application route. Поддържайте видима administrator activity, без да записвате secret values.

Документирайте SearXNG deployment, за който е потвърдено, че работи

Превърнете smoke test-а на SearXNG в repeatable release command или кратък runbook. Резултатът му трябва да демонстрира следното: изпратете търсения едновременно в HTML и JSON, потвърдете, че няколко engines връщат резултати, и задействайте конфигурирания limiter от test client. Запишете application version, container digest, route hostname и test-data identifier заедно с резултата.

Изпълнете същата проверка след обичайна container swap операция и след възстановяване на settings.yml, limiter configuration и всички local plugins на друго място. Restore-ът е успешен, когато custom engines, formats, limiter rules и proxy settings са възстановени и известна заявка връща резултати от няколко engines. Сравнете timing и consumption, свързани с upstream-engine latency, simultaneous queries, result parsing и bans, приложени към IP адреса на сървъра; голяма промяна заслужава разследване, дори когато крайната операция все още преминава успешно.

След това упражнете безопасен failure scenario: временно забранете на test identity достъпа до Redis или Valkey, когато са активирани limiter и bot-detection features. Потвърдете, че SearXNG показва fault-а и се връща към нормална работа без destructive manual edits. Запазете само необходимия, redacted log excerpt. Този four-part gate обхваща startup, persistence, recovery и failure handling.

Стартирайте първия production-shaped instance

Използвайте container-а като replaceable runtime, а не като място, където се съхранява истината.

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

Добавете прегледаните connection settings за Redis или Valkey, когато са активирани limiter и bot-detection features; използвайте private names за private services. Проверете container user-а, writable paths и bound listener-а, преди да го expose-нете. Изпълнете цялата операция — изпратете търсения едновременно в HTML и JSON, потвърдете, че няколко engines връщат резултати, и задействайте конфигурирания limiter от test client — и запазете exact image reference, който е дал резултата.

Не позволявайте proxy success да прикрива application failure

Expose-нете един HTTPS hostname за SearXNG; дръжте raw port 8080 private. Задайте server base_url и trusted proxy headers за HTTPS. Това предотвратява браузърите и API clients да научат два конкуриращи се адреса.

От clean client изпълнете known-good transaction и проверете първата failing request. Използвайте ръководството за custom domain, когато DNS или TLS са конфигурирани неправилно. Третирайте „engines блокират IP адреса на сървъра или форматите не включват json за API clients“ като отделна application diagnosis, след като route-ът е потвърден.

Logs, които отговарят на следващия въпрос

Първият полезен operational metric за SearXNG е дали може да изпраща търсения едновременно в HTML и JSON, да потвърди, че няколко engines връщат резултати, и да задейства конфигурирания limiter от test client. Комбинирайте това със saturation signals за upstream-engine latency, simultaneous queries, result parsing и bans, приложени към IP адреса на сървъра. Process-only probe не трябва да извиква expensive dependencies или да рестартира container-а, само защото upstream временно не е наличен.

Третирайте upgrades като промени в данните, защото settings syntax, engine definitions и limiter behavior могат да се променят, затова deploy-вайте configuration и image changes като един review. Pin-вайте versions, репетирайте върху restored state и запазете предишния image достъпен, докато rollback-ът остава валиден. Когато engines блокират IP адреса на сървъра или форматите не включват json за API clients, запазете logs от преди restart-а; обикновено в тях се съдържа причинното съобщение.

Свържете SearXNG с lifecycle-а на Dockup

Platform layer-ът за SearXNG се състои от port 8080, ingress, TLS, runtime configuration, storage и dependency reachability. Dockup може да възпроизведе тези компоненти за собствената си infrastructure или за сървър, към който клиентът се свързва.

След това operator-ът завършва product layer-а: задава server base_url и trusted proxy headers за HTTPS; прилага това access rule — използва non-default secret key, активира abuse controls и предоставя JSON само когато agent или application го изисква; и изпълнява „изпратете търсения едновременно в HTML и JSON, потвърдете, че няколко engines връщат резултати, и задействайте конфигурирания limiter от test client“. Записването на този тест заедно с deployment-а предотвратява объркването между automated provisioning и application readiness.

Често задавани въпроси

Какво е необходимо на SearXNG за production deployment?

Насочете SearXNG container-а на port 8080 през един HTTPS origin. Поддържащото network requirement е Redis или Valkey, когато са активирани limiter и bot-detection features. Не приемайте SearXNG за готов, докато не можете да изпратите търсения едновременно в HTML и JSON, да потвърдите, че няколко engines връщат резултати, и да задействате конфигурирания limiter от test client.

Кои данни на SearXNG трябва да бъдат включени в backup?

Persist-вайте /etc/searxng и включете settings.yml, limiter configuration и всички local plugins в същия recovery manifest. Един clean SearXNG restore е успешен само когато custom engines, formats, limiter rules и proxy settings са възстановени и известна заявка връща резултати от няколко engines.

Изисква ли SearXNG HTTPS зад reverse proxy?

Използвайте HTTPS за public SearXNG origin и дръжте port 8080 във вътрешния route. Приложете правилно SearXNG setting-а: задайте server base_url и trusted proxy headers за HTTPS. За SearXNG HTTPS защитава credentials или user content при пренос и поддържа consistent client behavior, зависимо от origin.

Как трябва да се тества SearXNG upgrade?

Възстановете текущото SearXNG state в isolated deployment, приложете candidate version и повторете acceptance transaction-а. Обърнете специално внимание, защото settings syntax, engine definitions и limiter behavior могат да се променят, затова deploy-вайте configuration и image changes като един review. Запазете предишния SearXNG image, докато не изясните границите на data migration и rollback.