Как исправить ошибку CAPTCHA в SearXNG

Что означает ошибка CAPTCHA в SearXNG

Ошибки CAPTCHA в SearXNG возникают из-за поисковых движков, к которым обращается ваш экземпляр. Ваш сервер запросил результаты у движка, но движок в ответ прислал страницу с проверкой вместо результатов. SearXNG зафиксировал ошибку для этого движка, так как в ответе не было данных для обработки. Ваш экземпляр работает исправно. Сторонняя система, которую вы не контролируете, решила, что ваш запрос не похож на действия человека.

Этот факт определяет все способы решения проблемы, описанные ниже. Решение принимает оборудование самого движка, поэтому никакие настройки в вашем settings.yml не могут его отменить. Вы можете изменить только IP-адрес, с которого уходит запрос, список используемых движков или поведение вашего экземпляра в случае, если движок начинает отклонять запросы.

Две ошибки, которые выглядят одинаково, и способы их различения

Первая ошибка — это когда ваш собственный экземпляр отвечает HTTP 429 (слишком много запросов) вашему же браузеру. Это срабатывает ограничитель SearXNG — уровень обнаружения ботов, расположенный перед поисковым эндпоинтом. Он работает на вашем сервере, и вы можете его настраивать. Ограничитель, возвращающий 429 вашим пользователям — это отдельная проблема с другими настройками, и приведенные ниже советы к ней не относятся.

Вторая ошибка связана с вышестоящим узлом (upstream). Страница результатов загружается нормально, но один или несколько поисковых движков отсутствуют в результатах или содержат уведомление об ошибке. Ваш экземпляр ничего не отклонял. Это движок отклонил запрос вашего сервера.

• Страница не загружается или поисковый эндпоинт отвечает 429: проверьте свой ограничитель.
• Страница загружается, но результатов мало или движок помечен ошибкой: проверьте вышестоящий узел и продолжайте чтение.

Обе ситуации могут происходить на одном экземпляре и влиять друг на друга, так как слишком мягкий ограничитель пропускает трафик, который увеличивает частоту ваших исходящих запросов. Выполняйте диагностику по очереди.

Почему поисковые движки SearXNG выдают ошибки CAPTCHA на VPS, но не на моем ноутбуке?

Это связано с адресом, с которого поступает запрос. Ваше домашнее интернет-соединение использует адрес из диапазона потребительского провайдера (ISP), который со временем разделяется между множеством обычных пользователей. Ваш VPS использует адрес из диапазона дата-центра, а эти диапазоны являются публичными: любой может проверить, какие адреса принадлежат хостинг-провайдеру. Движок, стремящийся ограничить доступ для парсеров, в первую очередь считает подозрительными запросы из диапазонов хостинга, так как в этих сетях крайне редко работают реальные люди через браузер.

На ситуацию с адресом накладываются и другие факторы. Ваш экземпляр отправляет по одному запросу на каждый движок для каждого поиска пользователя, поэтому даже небольшое количество пользователей создает интенсивность запросов с одного адреса, которую не может обеспечить один человек. По своей архитектуре SearXNG не поддерживает сессии с движками и не использует долгоживущие cookie, поэтому каждый запрос поступает без какой-либо истории. Кроме того, адрес может иметь историю, которую создали не вы, поскольку провайдеры перераспределяют адреса, и предыдущий владелец мог использовать этот IP для парсинга в течение многих месяцев.

Сам отказ не всегда выглядит как очевидная ошибка. Движок может ответить кодом 403, 429 или кодом 200 с страницей проверки (challenge) в теле ответа. Последний случай сбивает пользователей с толку, так как проверка кода состояния показывает, что с движком всё в порядке, в то время как SearXNG не находит результатов в ответе. Именно поэтому следует изучать отчет об ошибках вашего собственного экземпляра, а не просто выполнять curl к движку и проверять строку состояния.

Прочитайте отчет вашего экземпляра перед внесением изменений

Каждое исправление, описанное ниже, начинается с названия неработающего движка и причины, которую зафиксировал ваш экземпляр. SearXNG предоставляет оба этих параметра. На странице /stats перечислены движки с количеством ошибок и показателями надежности, а /stats/errors возвращает подробную информацию об ошибках в формате JSON, которую удобнее сохранять и сравнивать на следующей неделе. Откройте их в браузере, который вы обычно используете для работы с экземпляром.

Лог контейнера содержит те же события в момент их возникновения. Имя сервиса здесь соответствует тому, что указано в файле compose, опубликованном в документации к контейнеру, поэтому используйте свое имя, если оно отличается.

docker compose logs -f core

Запустите поиск, который завершается ошибкой, одновременно отслеживая лог. При выполнении поиска вы должны увидеть запись о неработающем движке. Запишите название движка и точную строку с причиной, которую вывел ваш экземпляр. Не копируйте название движка из сторонних статей, включая эту. Набор движков, которые блокируют запросы с IP-адресов дата-центров, меняется ежемесячно, и движок, который не работает у вас, может отлично функционировать у автора статьи, которую вы читаете.

Если на странице результатов нет никаких ошибок, но самих результатов мало, проверьте display_error_messages для этого движка. По умолчанию установлено значение true, и экземпляр, в котором эта опция отключена, скрывает именно то сообщение, которое вам необходимо.

Как SearXNG выполняет повторные попытки и приостанавливает работу неисправного движка

SearXNG не продолжает отправлять запросы к движку, который их отклоняет. Неисправный движок переводится в состояние приостановки и полностью игнорируется на этот период; именно так сломанный движок превращается в незаметно отсутствующий.

За это отвечают два уровня настроек, оба находятся в search: в файле settings.yml. Перед тем как вносить изменения, сверьте эти ключи с документацией по настройкам для вашей версии, так как их расположение менялось в разных релизах. По состоянию на 2 сентября 2026 года значения по умолчанию следующие:

search:
  ban_time_on_fail: 5
  max_ban_time_on_fail: 120
  suspended_times:
    SearxEngineAccessDenied: 86400
    SearxEngineCaptcha: 86400
    SearxEngineTooManyRequests: 3600
    cf_SearxEngineCaptcha: 1296000
    cf_SearxEngineAccessDenied: 86400
    recaptcha_SearxEngineCaptcha: 604800

Первый уровень обрабатывает обычные сбои, такие как таймаут. Блокировка начинается с ban_time_on_fail секунд и увеличивается с каждым последующим сбоем вплоть до max_ban_time_on_fail. По умолчанию предел составляет две минуты, поэтому нестабильный движок восстанавливается самостоятельно через несколько минут после устранения проблемы.

Второй уровень обрабатывает сбои, рассматриваемые в этом руководстве. Когда SearXNG распознает ответ как проверку (challenge) или отказ, а не как общую ошибку, он применяет соответствующее значение из suspended_times, и эти числа значительно больше. 86400 секунд — это полные сутки. 604800 — неделя. 1296000 — пятнадцать дней. Ключи с префиксом cf_ применяются, если проверка распознана как Cloudflare, а recaptcha_ — если как reCAPTCHA.

Это объясняет симптом, который отнимает больше всего времени. Вы находите причину, устраняете её, но движок всё равно не возвращает результаты в течение нескольких часов. Он всё ещё находится в состоянии приостановки. Статус приостановки хранится в памяти запущенного процесса, поэтому перезапуск контейнера сбрасывает его, и при следующем поиске движок будет опрошен снова. Обычного перезапуска здесь достаточно, и полезно знать когда достаточно перезапуска, а когда нужно пересоздавать контейнер, прежде чем приступать к пересборке образов без необходимости. Если движок снова выдает ошибку сразу после перезапуска, значит, ваше исправление не сработало.

Один параметр для каждого движка заслуживает предостережения. retry_on_http_error повторяет запрос, если движок отвечает с указанными вами кодами состояния. При работе с движком, который вас блокирует, повторные попытки лишь увеличивают нагрузку на систему, которая уже определила ваш сервер как бота. Не трогайте этот параметр, если только вы не пытаетесь обойти проблемы движка, который действительно работает нестабильно.

Документация по SSH-туннелям для upstream и ограничения этого метода

Согласно документации администратора SearXNG, проверенной 2 сентября 2026 года, эта проблема решается с помощью ручного туннеля. Вы открываете SOCKS-прокси через свой сервер, направляете в него браузер на рабочем столе и вручную проходите проверку (challenge), чтобы поисковый движок увидел адрес сервера.

ssh -q -N -D 8080 user@example.org

-D 8080 открывает локальный SOCKS-сервер на порту 8080, который перенаправляет трафик через SSH-соединение. -N не выполняет удаленную команду, а -q переводит процесс в фоновый режим, поэтому работающий туннель не выводит сообщений и не завершается. Проверьте его работу из второго терминала:

curl -x socks://127.0.0.1:8080 http://ipecho.net/plain
curl http://ipecho.net/plain

Первая команда должна вывести адрес вашего сервера, а вторая — адрес вашего рабочего стола. Если ответы одинаковые, значит, запрос не проходит через туннель. После этого настройте сетевые параметры браузера на использование SOCKS5-прокси по адресу 127.0.0.1 на порту 8080, загрузите в браузере тот же сервис проверки IP, чтобы убедиться, что он показывает адрес сервера, и перейдите на сайт поискового движка, который выдал проверку. Пройдите проверку там.

Теперь о недостатках. Этот метод ограничен четырьмя факторами. Cookie, который выдает движок, сохраняется в браузере на вашем рабочем столе, а у SearXNG нет доступа к cookie вашего браузера, поэтому помочь вашему экземпляру может только запись, которую движок делает для самого IP-адреса. Срок действия этой записи истекает по графику, который движок выбирает самостоятельно и не публикует. Процедура никак не автоматизирована, поэтому в следующий раз вам снова придется делать всё вручную. Кроме того, если экземпляром пользуются другие люди, частота запросов, вызвавшая проверку, сохранится, и проверка появится снова.

Используйте этот метод, чтобы заставить экземпляр работать сегодня. Не стройте архитектуру экземпляра вокруг этого решения.

Постоянное решение: отключение или изменение веса движков, вызывающих ошибки

Самый простой и надежный способ — прекратить отправку запросов к движку, который не обслуживает ваш сервер. Ваш settings.yml начинается с use_default_settings: true в образе контейнера, что означает, что запись в engines: с соответствующим name переопределяет только указанные вами ключи, оставляя остальные параметры конфигурации по умолчанию без изменений.

use_default_settings: true

engines:
  - name: <engine name from your stats page>
    disabled: true
  - name: <another engine name>
    weight: 0.3

disabled: true отключает движок по умолчанию, но оставляет его на странице настроек, чтобы пользователь мог включить его обратно для своих поисковых запросов. inactive: true полностью удаляет его из настроек пользователя, что и требуется для движка, который никогда не будет работать с вашего адреса. weight выполняет другую задачу: он масштабирует значимость результатов этого движка при объединении и ранжировании их в SearXNG. Вес ниже 1 позволяет оставить второстепенный движок, не давая ему доминировать на первой странице выдачи.

После внесения правок перезапустите контейнер, выполните несколько поисковых запросов, а затем снова проверьте /stats. Чистая страница статистики с шестью работающими движками полезнее, чем страница, заполненная ошибками от двадцати.

Постоянное решение: отправка исходящих запросов через прокси

SearXNG может отправлять исходящие запросы к поисковым движкам через прокси-сервер, что меняет адрес, который видит движок. Настройте это глобально в outgoing: или для конкретного движка, если проблема возникает только с одним из них.

outgoing:
  request_timeout: 2.0
  extra_proxy_timeout: 10.0
  proxies:
    all://:
      - socks5h://user:password@proxy:1080

engines:
  - name: <engine name>
    proxies:
      http: socks5h://user:password@proxy:1080
      https: socks5h://user:password@proxy:1080

Отдавайте предпочтение socks5h:// перед socks5://, если вы хотите, чтобы прокси-сервер разрешал имена хостов, так как h означает, что имя отправляется на прокси вместо того, чтобы разрешаться на вашем сервере. Одновременно с этим увеличьте лимит времени ожидания. Значение request_timeout по умолчанию составляет 2.0 секунды; прокси добавляет дополнительный сетевой запрос (round trip) к каждому обращению, и движки, которые раньше успевали ответить, начинают выдавать ошибки по таймауту. Параметр extra_proxy_timeout существует именно для этого и добавляет секунды при использовании прокси.

Что вы теряете при использовании прокси:

• Оператор прокси видит, к каким движкам и когда обращается ваш экземпляр. TLS (transport layer security) скрывает поисковые запросы от их логов, так как запрос находится внутри зашифрованного пакета, но характер и время вашего трафика становятся им известны.
• Общий выходной адрес используется всеми, кто за него платит. Если другие пользователи занимаются парсингом, вы наследуете их репутацию, иногда быстрее, чем блокировку, от которой пытались уйти.
• Дешевые пулы резидентных прокси часто строятся на базе потребительских устройств, владельцы которых не давали осознанного согласия на пропуск чужого трафика. Знайте, что вы покупаете.
• using_tor_proxy: true направляет трафик через Tor, но адреса выходных узлов полностью опубликованы, и движок, который блокирует диапазоны дата-центров, обычно блокирует выходные узлы Tor как минимум с такой же строгостью.
• Поиск теперь зависит от стороннего сервиса вне вашего сервера, который может выйти из строя в любой момент и остановить работу ваших результатов.

Прокси лишь переносит блокировку, а не устраняет её, а политика конфиденциальности вашего экземпляра теперь включает третью сторону. Если краткая политика конфиденциальности — это причина, по которой вы используете self-hosted решение, взвесьте это с тем, что на самом деле скрывает self-hosted экземпляр, а что нет, прежде чем подписываться на какие-либо услуги.

Надежное решение: намеренное использование меньшего набора движков

Вариант, который большинство пользователей игнорирует — это ограничение количества движков. Ценность SearXNG заключается в объединении результатов, и шесть движков, которые отвечают всегда, лучше двадцати, половина из которых заблокирована на сутки. Наблюдайте за /stats в течение недели и оставьте только те движки, которые показывают стабильную работу для вашего IP-адреса.

Движки, для которых вы используете API-ключ, работают иначе: сервис идентифицирует вас и применяет квоты вместо того, чтобы пытаться угадать, являетесь ли вы человеком. Взамен вы получаете необходимость завести учетную запись, хранить ключ в файле настроек и, как правило, оплачивать услуги. Для одного или двух критически важных движков это зачастую самый простой путь.

Принимайте решение с учетом других ваших инструментов. Заблокированный движок незаметен для систем, считывающих результаты через API, поскольку JSON API, к которому обращаются Open WebUI и аналогичные инструменты просто возвращает меньше результатов, а не ошибку, которую мог бы зафиксировать ваш инструмент. Если от вашего экземпляра зависят автоматизированные процессы, опрашивайте /stats/errors по расписанию, вместо того чтобы ждать жалоб на ухудшение качества ответов.

Стоит ли вообще с этим бороться?

Ответ на этот вопрос зависит от количества пользователей. Экземпляр для одного человека отправляет несколько поисковых запросов в день с одного адреса — такую интенсивность многие поисковые системы даже не ограничивают. Если же ограничение сработало, решение простое: отключите этот движок, и вы едва заметите его отсутствие. Это обычная практика при запуске SearXNG на собственном небольшом VPS, для которой не требуются ни туннели, ни прокси.

Публичный или общий экземпляр — это другая история при работе с тем же ПО. Интенсивность запросов является триггером, и она растет с каждым новым пользователем, поэтому проверки безопасности будут появляться быстрее, чем их можно будет обойти настройками. Сразу планируйте использование меньшего набора движков и помните, что любой прокси, который вы добавите сейчас, будет передавать чужие поисковые запросы через ваш аккаунт.

Автоматизированные клиенты занимают промежуточное положение и ближе к более сложному случаю. Агент, выполняющий несколько поисковых запросов для ответа на один вопрос, создает всплески активности, нехарактерные для человека, поэтому экземпляр, к которому вы подключаете инструменты для написания кода и исследования, столкнется с ограничениями раньше, чем тот же экземпляр при ручном использовании. Если вы планируете такой сценарий, выбирайте набор движков исходя из надежности, а не широты охвата, и позвольте агенту работать с теми результатами, которые он реально может получить.

Правило простое: боритесь за движок, если он является причиной, по которой вы используете self-hosted решение, и отключайте его, если это не так.

FAQ

Почему движок SearXNG по-прежнему не возвращает результаты после того, как я устранил проблему?

Потому что он всё ещё находится в состоянии приостановки. Когда SearXNG распознает проверку (challenge) или отказ со стороны движка, он прекращает отправлять запросы к этому движку на период, заданный в search.suspended_times. Значения по умолчанию варьируются от одного часа до пятнадцати дней в зависимости от типа отказа. Статус приостановки хранится в оперативной памяти запущенного процесса, поэтому перезапуск контейнера сбрасывает его, и при следующем поиске система снова обратится к движку. Если движок снова выдает ошибку сразу после перезапуска, значит, ваше исправление не сработало.

Является ли ошибка CAPTCHA от движка тем же самым, что и ошибка 429, которую возвращает мой экземпляр?

Они действуют в противоположных направлениях. Ошибка 429, которую ваш экземпляр отправляет в браузер, — это результат работы собственного ограничителя SearXNG, который счел ваш запрос автоматизированным; вы можете настроить его самостоятельно. Ошибка CAPTCHA или блокировка — это отказ вышестоящего движка в обслуживании вашего сервера, решение о котором принимается на оборудовании, которое вы не контролируете. Если страница результатов загружается, но отсутствуют только некоторые движки, вы столкнулись со вторым случаем.

Поможет ли VPN или прокси на моем сервере избежать CAPTCHA от движков?

Иногда, но это сопряжено с издержками. Маршрутизация исходящих запросов через outgoing.proxies меняет адрес, который видит движок, что может снять блокировку, привязанную к диапазону IP-адресов вашего дата-центра. В этом случае оператор прокси видит, какие движки и когда вы запрашиваете, вы используете общий выходной адрес с репутацией других клиентов, а дополнительные задержки вызывают таймауты, если вы не увеличите значения request_timeout и extra_proxy_timeout. Tor доступен через using_tor_proxy, но выходные адреса Tor известны и часто подвергаются проверкам.

Могу ли я настроить SearXNG на автоматическое решение CAPTCHA?

Такой настройки не существует. Метод, описанный в документации проекта, предполагает ручное вмешательство: SSH SOCKS-туннель, ваш собственный браузер и самостоятельное прохождение проверки. Любое решение, которое вы создадите для автоматического ответа на проверки, нарушает политику движка и будет ломаться при каждом изменении типа проверки. В результате вы будете заниматься поддержкой скрапера вместо работы поискового экземпляра. Единственное надежное решение — удаление движков, которые блокируют ваш адрес.