Как исправить ошибку 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 не продолжает отправлять запросы к движку, который их отклоняет. Неисправный движок переводится в состояние приостановки (suspended), и пока он находится в этом состоянии, он полностью игнорируется. Именно так сломанный движок превращается в незаметно отсутствующий.

Этим процессом управляют два уровня, оба из которых находятся в search: в файле settings.yml. Перед тем как вставлять какие-либо значения, сверьте эти ключи и их значения с searx/settings.yml для той версии, которую вы используете, так как они перемещались между релизами, а пример на странице документации по настройкам до сих пор показывает более длительные периоды приостановки, чем те, что фактически загружает SearXNG. В версии, выпущенной в searx/settings.yml 10 октября 2026 года, установлены следующие значения по умолчанию:

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

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

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

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

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

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

Проверенная 10 октября 2026 года, административная документация SearXNG предлагает решать эту проблему с помощью ручного туннеля. Вы открываете 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 нет доступа к cookies вашего браузера, поэтому единственное, что может помочь вашему экземпляру — это запись, которую движок делает для самого 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: 3.0
  extra_proxy_timeout: 10
  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 по умолчанию составляет 3.0 секунды; прокси добавляет дополнительный сетевой обмен к каждому запросу, и движки, которые раньше успевали ответить, начинают выдавать ошибки по таймауту. Параметр extra_proxy_timeout существует именно для этого и добавляет секунды при использовании прокси. Указывайте его как целое число, например 10: схема настроек ожидает целое число, и значение вроде 10.0 будет отклонено как неверный тип settings.yml.

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

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

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

Надежное решение: осознанное сокращение набора движков

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

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

Принимайте решение с учетом других ваших инструментов. Заблокированный движок незаметен для систем, считывающих результаты через 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 меняет адрес, который видит движок, что может снять блокировку, привязанную к диапазону адресов вашего дата-центра. В этом случае оператор прокси видит, какие движки и когда вы запрашиваете, вы используете общий выходной адрес с репутацией других клиентов, а дополнительные задержки приводят к таймаутам, если вы не увеличите значения request_timeout и extra_proxy_timeout. Tor доступен через using_tor_proxy, но выходные адреса Tor известны, и к ним часто предъявляются требования о прохождении проверки.

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

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