Як розгорнути SearXNG на власному сервері у 2026 році: Search API, обмеження частоти запитів і TLS

Більшість інструкцій зі встановлення SearXNG закінчуються після першого завантаження сторінки. Це зарано: пошукові рушії можуть блокувати IP-адресу сервера, а деякі формати можуть не містити json для API-клієнтів. Корисніший production-тест вимагає більшого — надішліть пошукові запити в HTML і JSON, переконайтеся, що результати надходять від кількох рушіїв, і активуйте налаштований limiter із тестового клієнта.

Роль SearXNG проста: це metasearch engine і Search API, орієнтовані на приватність. Його операційна межа охоплює більше, ніж вебпроцес, тому до надходження реальних даних потрібно явно визначити залежність, збережений стан і публічний маршрут.

Спочатку визначте критерії готовності SearXNG

Не дозволяйте образу SearXNG випадково визначити production-архітектуру. Образ надає процес на порту 8080, але для сховища, маршрутизації та зовнішніх вимог усе одно потрібні продумані життєві цикли. Мережева залежність SearXNG — Redis або Valkey, якщо ввімкнено limiter і функції виявлення ботів. Приватні endpoints залишайте у внутрішньому DNS, дозволяйте лише необхідні вихідні виклики та надайте SearXNG service credential з обмеженими правами.

Розгортання готове до глибшого тестування, коли воно може надсилати пошукові запити в HTML і JSON, підтверджувати участь кількох рушіїв у формуванні результатів і активувати налаштований limiter із тестового клієнта. Відстежуйте транзакцію в логах і контролюйте latency upstream-рушіїв, одночасні запити, parsing результатів і блокування IP-адреси сервера. Ці спостереження покажуть, чи ізолює поточна топологія потрібний компонент.

Відокремте контейнери, які можна замінювати, від постійних даних

Створіть recovery manifest для SearXNG: settings.yml, конфігурацію limiter і всі локальні plugins. Підключіть /etc/searxng до bootstrap, запишіть нешкідливі тестові дані та замініть контейнер, щоб підтвердити фактичну постійність цього шляху. Перевірте власника й вільне місце вже зараз, адже підключений, але недоступний для запису шлях фактично не забезпечує persistence.

Створюйте резервні копії в failure domain, окремому від запущеного сервера. Відтворіть SearXNG із pinned image і перевірте, що custom engines, формати, правила limiter і proxy settings відновилися, а відомий запит повертає результати від кількох рушіїв. Посібник із persistent volumes допоможе перетворити цю вправу на політику snapshot і retention.

Закрийте тимчасовий доступ для налаштування

Bootstrap credentials є тимчасовими, а модель довіри — постійною. У випадку з SearXNG стежте, щоб не залишити example secret_key або не вимкнути rate controls на публічному endpoint, і використовуйте non-default secret key, увімкніть abuse controls та відкривайте JSON лише тоді, коли він потрібен агенту або застосунку.

Ставтеся до SEARXNG_SECRET відповідно до його ролі в SearXNG: не зберігайте чутливі значення в Git, документуйте наслідки ротації й ніколи не підміняйте production-значення публічним прикладом. Запускайте образ без зайвих Linux capabilities і відкривайте лише публічний application route. Активність адміністраторів має бути видимою, але без запису значень секретів.

Зафіксуйте працездатне розгортання SearXNG

Перетворіть smoke test SearXNG на повторювану release-команду або короткий runbook. Її результат має демонструвати такий сценарій: надіслати пошукові запити в HTML і JSON, підтвердити участь кількох рушіїв у формуванні результатів і активувати налаштований limiter із тестового клієнта. Разом із результатом зафіксуйте версію застосунку, digest контейнера, hostname маршруту та ідентифікатор тестових даних.

Виконуйте ту саму перевірку після звичайної заміни контейнера та після відновлення settings.yml, конфігурації limiter і всіх локальних plugins в іншому місці. Відновлення успішне, коли custom engines, формати, правила limiter і proxy settings повертаються, а відомий запит дає результати від кількох рушіїв. Порівнюйте timing і consumption, пов’язані з latency upstream-рушіїв, одночасними запитами, parsing результатів і блокуваннями IP-адреси сервера; значну зміну варто дослідити, навіть якщо фінальна перевірка все ще проходить.

Потім виконайте безпечний сценарій відмови: тимчасово забороніть тестовій identity доступ до Redis або Valkey, якщо ввімкнено limiter і функції виявлення ботів. Переконайтеся, що SearXNG повідомляє про помилку та повертається до нормальної роботи без деструктивних ручних змін. Збережіть лише необхідний, очищений фрагмент логу. Цей чотирикомпонентний gate охоплює запуск, persistence, відновлення та обробку відмов.

Запустіть перший production-подібний інстанс

Використовуйте контейнер як 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 і функції виявлення ботів; для приватних сервісів використовуйте приватні імена. Перевірте user контейнера, writable paths і bound listener до того, як відкривати до нього доступ. Виконайте повний сценарій — надішліть пошукові запити в HTML і JSON, переконайтеся, що результати надходять від кількох рушіїв, і активуйте налаштований limiter із тестового клієнта — та збережіть точне посилання на образ, який дав цей результат.

Не дозволяйте успішній роботі proxy приховати помилку застосунку

Відкрийте для SearXNG один HTTPS hostname, а raw port 8080 залиште приватним. Налаштуйте server base_url і trusted proxy headers для HTTPS. Це не дозволить браузерам і API-клієнтам дізнатися про дві конкуруючі адреси.

Із чистого клієнта виконайте перевірений сценарій і проаналізуйте перший запит, який завершується помилкою. Якщо проблема пов’язана з DNS або TLS, скористайтеся посібником із custom domain. Сприймайте ситуацію «пошукові рушії блокують IP-адресу сервера або формати не містять json для API-клієнтів» як окрему діагностику застосунку після підтвердження працездатності маршруту.

Логи, які допомагають визначити наступне питання

Перший корисний operational metric для SearXNG — чи може він надсилати пошукові запити в HTML і JSON, підтверджувати участь кількох рушіїв у формуванні результатів і активувати налаштований limiter із тестового клієнта. Доповніть його сигналами saturation для latency upstream-рушіїв, одночасних запитів, parsing результатів і блокувань IP-адреси сервера. Probe, що перевіряє лише процес, не повинен викликати дорогі залежності або перезапускати контейнер через короткочасну недоступність upstream.

Сприймайте оновлення як зміни даних, оскільки синтаксис settings, визначення рушіїв і поведінка limiter можуть змінитися, тому впроваджуйте зміни конфігурації та образу в межах одного review. Фіксуйте версії, репетируйте оновлення на відновленому стані й зберігайте попередній образ, доки rollback залишається можливим. Якщо пошукові рушії блокують IP-адресу сервера або формати не містять json для API-клієнтів, збережіть логи до перезапуску — зазвичай саме в них є причинне повідомлення.

Додайте SearXNG до життєвого циклу Dockup

Платформний шар для SearXNG складається з порту 8080, ingress, TLS, runtime configuration, сховища та доступності залежностей. Dockup може відтворити ці компоненти у власній інфраструктурі або на сервері, до якого підключається клієнт.

Після цього оператор завершує product layer: налаштовує server base_url і trusted proxy headers для HTTPS; застосовує це правило доступу — використовує non-default secret key, вмикає abuse controls і відкриває JSON лише тоді, коли він потрібен агенту або застосунку; а також виконує «надіслати пошукові запити в HTML і JSON, підтвердити участь кількох рушіїв у формуванні результатів і активувати налаштований limiter із тестового клієнта». Запис цього тесту разом із розгортанням допомагає не плутати automated provisioning із готовністю застосунку.

Поширені запитання

Що потрібно SearXNG для production-розгортання?

Маршрутизуйте контейнер SearXNG на порту 8080 через один HTTPS origin. Необхідна мережева залежність — Redis або Valkey, якщо ввімкнено limiter і функції виявлення ботів. Не вважайте SearXNG готовим, доки не зможете надсилати пошукові запити в HTML і JSON, підтверджувати участь кількох рушіїв у формуванні результатів і активувати налаштований limiter із тестового клієнта.

Які дані SearXNG потрібно включати до резервної копії?

Забезпечте persistence для /etc/searxng і додайте settings.yml, конфігурацію limiter та всі локальні plugins до того самого recovery manifest. Чисте відновлення SearXNG вважається успішним лише тоді, коли custom engines, формати, правила limiter і proxy settings повертаються, а відомий запит дає результати від кількох рушіїв.

Чи потрібен SearXNG HTTPS за reverse proxy?

Використовуйте HTTPS для публічного SearXNG origin, а порт 8080 залиште у внутрішньому маршруті. Правильно застосуйте налаштування SearXNG: встановіть server base_url і trusted proxy headers для HTTPS. Для SearXNG HTTPS захищає credentials або користувацький контент під час передавання та забезпечує узгоджену поведінку клієнта, чутливу до origin.

Як тестувати оновлення SearXNG?

Відновіть поточний стан SearXNG в ізольованому розгортанні, застосуйте candidate version і повторіть acceptance transaction. Приділіть особливу увагу тому, що синтаксис settings, визначення рушіїв і поведінка limiter можуть змінитися, тому впроваджуйте зміни конфігурації та образу в межах одного review. Зберігайте попередній образ SearXNG, доки не буде зрозумілою межа міграції даних і rollback.