Как исправить ошибку 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. Перед вставкой любых значений сверьте эти имена ключей и значения с searx/settings.yml для используемой вами версии. Между выпусками они менялись. Кроме того, в примере на странице документации по настройкам по-прежнему указаны более длительные периоды приостановки, чем в файле, который фактически загружает SearXNG. В поставляемой конфигурации searx/settings.yml по состоянию на 17 October 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_ применяются, когда challenge распознан как challenge Cloudflare, а recaptcha_ — когда он распознан как reCAPTCHA.

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

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

SSH-туннель: документация и ограничения метода

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

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: 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. В отличие от request_timeout, который допускает дробные значения, extra_proxy_timeout в схеме настроек является целым числом. Поэтому значение вроде 10.0 отклоняется как недопустимый settings.yml, хотя в закомментированном примере на странице документации по исходящим настройкам оно записано именно так.

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

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

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

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

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

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

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

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

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

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

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

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

FAQ

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

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

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

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

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

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

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

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