SearXNGのCAPTCHAエラーを解決する方法

SearXNG の CAPTCHA エラーが意味すること

SearXNG の CAPTCHA エラーは、インスタンスが検索するエンジンに起因します。サーバーがエンジンに検索結果を要求すると、エンジンは結果ではなくチャレンジページを返します。SearXNG は、応答を解析できる内容がなかったため、そのエンジンに対するエラーとして記録します。インスタンスは正常です。管理していないマシンが、リクエストを人間からのものではないと判断しただけです。

この事実によって、以下の対処方法がすべて決まります。判断はエンジン側のハードウェアで行われるため、settings.yml の設定で覆すことはできません。変更できるのは、リクエストの送信元アドレス、そもそも検索するエンジン、そしてエンジンが拒否を開始した後のインスタンスの動作です。

同じように見える2つの障害と、その見分け方

最初の障害は、自分のブラウザーに対して自分のインスタンスが HTTP 429（リクエスト過多）を返すケースです。これは、検索エンドポイントの前段にあるボット検出層、SearXNG のリミッターによるものです。自分のサーバー上で動作し、自分で設定できます。自分のユーザーに 429 を返すリミッターは、設定も別の別問題です。以下の説明は適用されません。

2つ目の障害は上流側にあります。結果ページは正常に読み込まれますが、結果に1つ以上のエンジンが表示されないか、エラー通知が付いています。インスタンスが何かを拒否したわけではありません。エンジンが自分のサーバーからのリクエストを拒否しています。

• ページを読み込めない、または検索エンドポイントが 429 を返す場合: リミッターを確認します。
• ページは読み込めるものの結果が少ない、またはエンジンにエラーが表示される場合: 上流側を確認し、このまま読み進めます。

同じインスタンスで両方が発生することもあります。また、相互に影響します。リミッターの設定が緩すぎると、送信クエリのレートを押し上げるトラフィックが通過するためです。1つずつ切り分けてください。

VPS では SearXNG のエンジンが CAPTCHA エラーを返すのに、ノート PC では返さないのはなぜですか？

原因は、リクエストの送信元アドレスです。自宅の接続には、一般消費者向け ISP（internet service provider）のアドレス範囲に属するアドレスが割り当てられます。この範囲は、多くの一般利用者が時間を共有しています。一方、VPS にはデータセンターのアドレス範囲に属するアドレスが割り当てられます。これらの範囲は公開されているため、どのアドレスがホスティングプロバイダーに属するかを誰でも調べられます。スクレーパーを排除したいエンジンは、まずホスティング範囲からのリクエストを疑わしいものとして扱います。この範囲では、ブラウザーを使う人間の通信がごく少ないためです。

アドレス以外の要因も重なります。インスタンスは、ユーザーが検索するたびにエンジンごとに 1 件のリクエストを送信します。そのため、少数のユーザーだけでも、1 つのアドレスから、1 人の利用者では発生しない頻度でリクエストが送られます。SearXNG は設計上、エンジンとのセッションを保持せず、長期間有効な Cookie も送信しません。そのため、各リクエストは過去の履歴を伴わずに到着します。また、そのアドレスに、あなたが作成していない履歴が残っている場合もあります。プロバイダーはアドレスを再利用するため、以前の利用者がそのアドレスから数か月にわたってスクレイピングしていた可能性があります。

拒否は、常に明らかな失敗として現れるとは限りません。エンジンは 403、429、または HTTP 200 とチャレンジページを本文に含む応答を返すことがあります。最後のケースは、ステータスコードの確認ではエンジンが正常に見える一方、SearXNG が応答から結果を 0 件しか検出しないため、混乱を招きます。そのため、エンジンに curl を実行してステータス行を確認するのではなく、自分のインスタンスのエラーレポートを確認します。

変更する前に、インスタンスの報告内容を確認する

以下の対処はすべて、失敗しているエンジン名と、インスタンスが記録した失敗理由を確認することから始めます。SearXNG はその両方を提供します。/stats ページには、エラー数と信頼性を含むエンジン一覧が表示されます。/stats/errors はエラーの詳細を JSON で返すため、保存して来週と比較しやすくなります。インスタンスで通常使用しているブラウザーで開いてください。

コンテナのログには、発生したイベントが同じ内容で記録されます。ここで使用しているサービス名は、コンテナのドキュメントに掲載されている compose ファイルで使われている名前です。異なる場合は、自分のサービス名に置き換えてください。

docker compose logs -f core

ログを追跡しながら、失敗する検索を実行します。検索の実行中に、失敗したエンジンのエントリが表示されるはずです。エンジン名と、インスタンスが出力した正確な理由文字列を書き留めてください。この記事を含め、ブログ記事からエンジン名をコピーしないでください。データセンターのアドレスを拒否するエンジンの構成は月ごとに変わります。自分の環境で失敗するエンジンが、記事の執筆者の環境では問題なく動作することもあります。

結果ページにエラーがまったく表示されず、結果だけが少ない場合は、そのエンジンの display_error_messages を確認してください。デフォルト値は true です。これを無効にしたインスタンスでは、必要なメッセージが非表示になっています。

SearXNG が失敗するエンジンを再試行して一時停止する仕組み

SearXNG は、要求を拒否するエンジンに対してリクエストを繰り返し送信し続けません。失敗したエンジンは一時停止され、一時停止中は完全にスキップされます。そのため、壊れたエンジンが何も通知されない欠落エンジンになります。

これを制御する層は 2 つあり、どちらも settings.yml 内の search: 配下にあります。これらのキー名はリリース間で移動しているため、何かを貼り付ける前に、実際に実行しているバージョンの設定ドキュメントで確認してください。2026 年 9 月 2 日時点で文書化されているデフォルト値は次のとおりです。

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

第 1 層は、タイムアウトなどの通常の失敗を処理します。禁止期間は ban_time_on_fail 秒から始まり、連続して失敗するたびに延長され、最大 max_ban_time_on_fail まで増加します。デフォルトでは上限が 2 分なので、問題が解消すれば、不安定なエンジンは数分以内に自動的に復旧します。

第 2 層は、このガイドで扱う失敗を処理します。SearXNG が応答を一般的なエラーではなくチャレンジまたは拒否として認識すると、suspended_times の該当するエントリを適用します。これらの値ははるかに大きく設定されています。86400 秒は 1 日です。604800 秒は 1 週間です。1296000 秒は 15 日です。cf_ で始まるキーは、チャレンジが Cloudflare のものと認識された場合に適用されます。recaptcha_ で始まるキーは、reCAPTCHA と認識された場合に適用されます。

これで、最も時間を浪費する症状の理由が分かります。原因を見つけて修正しても、エンジンは何時間も結果を返しません。エンジンはまだ一時停止中だからです。一時停止状態は実行中のプロセスに保持されるため、コンテナを再起動すると解除され、次の検索で再びエンジンが試行されます。ここでは通常の再起動で十分です。理由もなくイメージの再ビルドを始める前に、再起動だけで十分な場合とコンテナの再作成が必要な場合を確認しておくとよいでしょう。再起動直後にエンジンが再び失敗する場合、修正は機能していません。

エンジンごとに設定する項目のうち、1 つには注意が必要です。retry_on_http_error は、エンジンが指定したステータスコードで応答した場合にリクエストを再試行します。アクセスをブロックしているエンジンに対して再試行すると、サーバーを bot と判断したシステムへ、さらに多くのトラフィックを送信することになります。本当に断続的に失敗するエンジンへの対処でない限り、この設定は変更しないでください。

SSH トンネルの上流ドキュメントと、解決できない問題

2026 年 9 月 2 日に確認したところ、SearXNG の管理者向けドキュメントでは、この問題への対処として手動トンネルを案内しています。サーバー経由の SOCKS プロキシを開き、デスクトップのブラウザーをそこに接続します。そのうえで、エンジンからはサーバーのアドレスに見える状態で、チャレンジに手動で回答します。

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

-D 8080 は、SSH 接続を経由して転送するローカル SOCKS サーバーを port 8080 で開きます。-N はリモートコマンドを実行せず、-q は出力を抑制します。そのため、トンネルが正常なら何も表示されず、コマンドは終了しません。2 つ目のターミナルで確認します。

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

最初のコマンドではサーバーのアドレスが表示され、2 つ目のコマンドではデスクトップのアドレスが表示されるはずです。2 つの結果が同じ場合、リクエストはトンネルを経由していません。次に、ブラウザーのネットワーク設定で、SOCKS5 プロキシとして 127.0.0.1 port 8080 を指定します。同じアドレス確認サービスをブラウザーで開き、サーバーのアドレスが表示されることを確認します。その後、チャレンジを表示しているエンジンにアクセスし、そこでチャレンジに回答します。

ここからが重要です。この方法には 4 つの制限があります。エンジンが発行する cookie はデスクトップのブラウザーに保存されます。SearXNG はブラウザーの cookie にアクセスできません。そのため、インスタンスに役立つ可能性があるのは、エンジンがアドレス自体に記録する情報だけです。その記録は、エンジンが決めたスケジュールで期限切れになります。期限は公開されていません。手順は自動化されていないため、次回もキーボードの前に戻って手動で対応する必要があります。また、他のユーザーも利用するインスタンスでは、チャレンジの原因になったクエリレートが継続しているため、チャレンジが再び表示されます。

この方法は、今日の午後に 1 つのインスタンスを動作させるために使用してください。この方法を前提にインスタンスを構築しないでください。

長期的に有効な対策: 問題になるエンジンを無効化するか、重みを下げる

最も安価で持続的な対策は、サーバーに結果を返せないエンジンへの問い合わせを停止することです。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 未満の重みを設定すれば、影響の小さいエンジンを残しつつ、1 ページ目を独占させずに済みます。

編集後にコンテナを再起動し、いくつか検索を実行してから、もう一度 /stats を確認します。正常に動作するエンジンが 6 個ある状態でエラーのない統計ページのほうが、20 個のエンジンが並んで大量のエラーが表示されるページより有用です。

長期的に機能する対策: 外向きのリクエストをプロキシ経由にする

SearXNG は外向きのエンジンリクエストをプロキシ経由で送信できます。これにより、エンジンから見えるアドレスが変わります。全体に適用する場合は outgoing: で設定し、問題が 1 つのエンジンだけに限られる場合はエンジンごとに設定します。

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

プロキシにホスト名を解決させる場合は、socks5:// より socks5h:// を使用してください。h を指定すると、名前解決をサーバー上で行わず、名前がプロキシに送信されるためです。同時にタイムアウトの予算も増やしてください。request_timeout の既定値は 2.0 秒です。プロキシを使用すると各リクエストに追加の往復が発生するため、これまで時間内に応答していたエンジンがタイムアウトで失敗することがあります。extra_proxy_timeout はこの用途のために用意されており、プロキシ使用時の待機時間を秒単位で追加します。

プロキシの利用で発生するコスト:

• プロキシの運営者には、インスタンスがどのエンジンへ、いつクエリを送信したかが見えます。TLS (transport layer security) により、クエリは暗号化されたリクエスト内に含まれるため、検索語が運営者のログに残ることは防げます。ただし、通信の形状とタイミングは運営者に把握されます。
• 共有の出口アドレスは、その料金を支払う他の利用者とも共有されます。他の利用者がスクレイピングを行うと、回避しようとしていたブロックより早く、その利用者の評判を引き継ぐことがあります。
• 安価な residential proxy プールは、所有者が通信の中継に同意したことを認識していない一般消費者向けデバイスで構成されていることがよくあります。購入するサービスの実態を把握してください。
• using_tor_proxy: true は Tor 経由で通信しますが、出口ノードのアドレスはすべて公開されています。データセンターの IP レンジに対してチャレンジを行うエンジンは、通常、出口ノードに対しても同程度以上の対策を行います。
• 検索はサーバー外部のサービスに依存するため、そのサービスが独自の都合で停止すると、検索結果も取得できなくなります。

プロキシはブロックを解消するのではなく、ブロックされる場所を移します。また、インスタンスのプライバシーには第三者が関わるようになります。自己ホストする理由がプライバシーを確保することにあるなら、何かに申し込む前に、自己ホストしたインスタンスが実際に隠せるものと隠せないもの と比較して検討してください。

意図的に少数のエンジンだけを使う、長期的に安定する対策

多くの人が見落とす選択肢は、使用するエンジンを減らすことです。SearXNG の価値は結果の統合にあります。常に応答する 6 個のエンジンによる統合のほうが、半数が丸 1 日停止する 20 個のエンジンより優れています。/stats を 1 週間監視し、自分のアドレスから安定して応答するエンジンを残します。

API key で認証するエンジンは動作が異なります。エンジンは利用者を識別できるため、利用者が人間かどうかを推測する代わりに、quota を適用します。その代わり、アカウント、settings file に保存する key、通常は料金が必要です。重要なエンジンが 1 つか 2 つだけなら、この方法が最も手間の少ない解決策になることがよくあります。

他のツールとの関係も考慮して決めてください。停止したエンジンは、API 経由で結果を読み取るツールからは見えません。Open WebUI などのツールが問い合わせる JSON API は、ツールが検知できるエラーを返さず、結果数を減らして返すだけだからです。インスタンスに依存する自動処理がある場合は、回答の品質が低下したという苦情を待つのではなく、/stats/errors を定期的にポーリングしてください。

これにこだわる価値はありますか？

ユーザー数で判断してください。1 人用のインスタンスでは、1 つのアドレスから 1 日に数件の検索を送信するだけで、多くの検索エンジンでは問題になりません。チャレンジを受ける検索エンジンがあっても、そのエンジンを外せば済むため、影響はほとんどありません。これは 小規模な VPS で SearXNG を自分用に運用する場合の一般的な状態であり、トンネルもプロキシも必要ありません。

公開または共有インスタンスは、同じソフトウェアを実行する別の環境です。トリガーになるのはクエリの頻度です。ユーザーを追加するたびに頻度が上がるため、設定で吸収できる速度を超えてチャレンジが発生します。最初から検索エンジンの構成を絞って計画してください。また、今追加するプロキシ経由の他のユーザーの検索も、自分のアカウントで実行されることを覚えておいてください。

自動化されたクライアントは中間に位置しますが、より厳しいケースに近い動作をします。1 つの質問に答えるために複数の検索を実行するエージェントは、人間が生成しないようなバーストを発生させます。そのため、コーディングエージェントや調査ツールから接続するインスタンスは、手動で利用する同じインスタンスより早くチャレンジを受けます。この用途では、検索エンジンの構成を網羅性ではなく信頼性で選び、エージェントには実際に取得できる結果を使わせてください。

原則は明確です。自分でホストする理由になっている検索エンジンなら対処し、そうでなければ外してください。

FAQ

SearXNG のエンジンを修正したのに、検索結果が返らないのはなぜですか？

まだ停止中だからです。SearXNG はエンジンからチャレンジまたは拒否を検出すると、search.suspended_times に設定された期間、そのエンジンへのクエリを停止します。拒否の種類によって、デフォルトの期間は 1 時間から 15 日間です。停止状態は実行中のプロセス内に保持されるため、コンテナを再起動すると解除され、次の検索で再びそのエンジンが試行されます。再起動直後にエンジンが再度失敗する場合は、修正が機能していません。

エンジンの CAPTCHA エラーは、インスタンスが返す 429 と同じですか？

発生する方向が逆です。ブラウザーに対してインスタンスが返す 429 は、リクエストが自動化されたものに見えると SearXNG 自身のリミッターが判断した結果であり、設定を変更できるのは管理者です。CAPTCHA またはブロックエラーは、上流のエンジンがサーバーからのアクセスを拒否した結果であり、管理者が制御できない環境で判断されます。結果ページが読み込まれ、一部のエンジンだけが表示されない場合は、後者です。

サーバー上の VPN またはプロキシで、エンジンの CAPTCHA を解決できますか？

解決できる場合もありますが、代償があります。送信リクエストを outgoing.proxies 経由で転送すると、エンジンから見えるアドレスが変わるため、データセンターのアドレス範囲に紐づいたブロックを解除できることがあります。一方、プロキシ事業者には、どのエンジンへいつクエリを送ったかが見えます。また、他の顧客と共有する出口アドレスには、その顧客の評価も影響します。さらに、遅延が増えるため、request_timeout と extra_proxy_timeout を引き上げないとタイムアウトが発生します。Tor は using_tor_proxy 経由で利用できますが、出口アドレスは公開されており、広くチャレンジの対象になっています。

SearXNG に CAPTCHA を自動的に解かせることはできますか？

そのための設定はありません。プロジェクトが文書化している方法は手動操作です。SSH SOCKS トンネル、自分のブラウザー、そしてチャレンジに対する手動操作を使用します。チャレンジに自動で応答する仕組みを構築しても、エンジンが定めるポリシーに反し、チャレンジが変更されるたびにひそかに動作しなくなります。その結果、検索インスタンスを運用する代わりにスクレーパーを保守することになります。アクセス元アドレスをブロックするエンジンを削除する方法が、継続して機能する対策です。