著者 Matt Connor
SearXNGのCAPTCHAエラーを解決する方法
VPSでは自宅回線より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: 配下にあります。実際に実行しているバージョンについて、何かを貼り付ける前に、これらのキー名と値を searx/settings.yml で確認してください。リリースによって配置が変更されており、settings のドキュメントページにある例では、SearXNG が実際に読み込むファイルよりも長い停止時間が示されているためです。2026 年 10 月 17 日に searx/settings.yml として提供されているデフォルト値は次のとおりです。
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第 1 の層は、タイムアウトなどの通常の失敗を処理します。停止は ban_time_on_fail 秒後に始まり、連続して失敗するたびに停止時間が延び、max_ban_time_on_fail まで増加します。デフォルトの上限は 2 分です。そのため、一時的に不安定なエンジンは、問題が解消してから数分以内に自動的に復旧します。
第 2 の層は、このガイドで扱う失敗を処理します。SearXNG が応答を一般的なエラーではなく、チャレンジまたは拒否として認識すると、suspended_times の該当するエントリを適用します。多くの値は、通常の失敗より大幅に長く設定されています。単純な拒否または 429 では 180 秒、つまり 3 分です。一般的な CAPTCHA では 3600 秒、つまり 1 時間です。86400 は 1 日、604800 は 1 週間、1296000 は 15 日です。cf_ で始まるキーは Cloudflare のチャレンジと認識された場合に適用され、recaptcha_ は reCAPTCHA と認識された場合に適用されます。
この仕組みが、最も時間を浪費しやすい症状を説明します。原因を見つけて修正しても、エンジンが 1 時間、または Cloudflare のチャレンジ後に数日間、何も返さないことがあります。エンジンはまだ停止中です。停止状態は実行中のプロセス内に保持されるため、コンテナを再起動すると解除され、次の検索でエンジンが再び試されます。この場合は通常の再起動で十分です。理由もなくイメージの再ビルドを始める前に、再起動だけで十分な場合とコンテナの再作成が必要な場合を確認しておくとよいでしょう。再起動直後にエンジンが再び失敗する場合は、修正できていません。
エンジンごとの設定には、注意が必要なものが 1 つあります。retry_on_http_error は、エンジンが指定したステータスコードで応答した場合にリクエストを再試行します。アクセスをブロックしているエンジンに対して再試行すると、サーバーをボットと判断したシステムへ、さらに多くのネットワークトラフィックを送ることになります。本当に一時的な障害が発生しているエンジンへの対処でない限り、変更しないでください。
SSH トンネルの上流ドキュメントと、この方法で解決できないこと
2026 年 10 月 17 日に確認したところ、SearXNG の管理者向けドキュメントでは、この問題に手動トンネルで対処しています。サーバー経由の SOCKS プロキシを開き、デスクトップのブラウザーをそこへ接続し、エンジンからはサーバーのアドレスに見える状態で、手動でチャレンジに回答します。
ssh -q -N -D 8080 user@example.org-D 8080 は、SSH 接続経由で転送するローカル SOCKS サーバーを port 8080 で開きます。-N はリモートコマンドを実行せず、-q は出力を抑制します。そのため、トンネルが正常なら何も表示されず、コマンドは終了しません。別のターミナルから確認します。
curl -x socks://127.0.0.1:8080 http://ipecho.net/plain
curl http://ipecho.net/plain最初のコマンドではサーバーのアドレスが表示され、2 番目のコマンドではデスクトップのアドレスが表示されるはずです。同じ結果が 2 つ表示された場合、リクエストはトンネルを経由していません。次に、ブラウザーのネットワーク設定で、127.0.0.1 port 8080 の SOCKS5 プロキシを指定します。ブラウザーで同じアドレス確認サービスを開き、サーバーのアドレスが報告されることを確認してから、チャレンジを表示しているエンジンにアクセスします。そこでチャレンジに回答します。
ここからは、この方法の制限を説明します。制限は 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.3disabled: true はデフォルトでエンジンを無効にしますが、設定ページには残します。そのため、必要なユーザーは自分の検索用に再度有効化できます。inactive: true はユーザー設定からエンジンを完全に削除します。自分のアドレスからは決して利用できないエンジンには、こちらを使います。weight は別の役割を持ちます。SearXNG が結果を統合して順位付けするときの、そのエンジンの結果の影響度を調整します。したがって、1 未満の重みを設定すれば、影響の小さいエンジンを残しつつ、1 ページ目を独占させずに済みます。
編集後にコンテナを再起動し、いくつか検索を実行してから、もう一度 /stats を確認します。正常に動作するエンジンが 6 個ある状態でエラーのない統計ページのほうが、20 個のエンジンが並んで大量のエラーが表示されるページより有用です。
長く効く対策: 外向きのリクエストをプロキシ経由にする
SearXNG は、エンジンへの外向きリクエストをプロキシ経由で送信できます。これにより、エンジンから見える接続元アドレスが変わります。全体設定は outgoing: で行い、問題が 1 つのエンジンだけに限られる場合は、エンジンごとに設定します。
outgoing:
request_timeout: 3.0
extra_proxy_timeout: 10
proxies:
all://:
- socks5h://user:password@proxy:1080engines:
- name: <engine name>
proxies:
http: socks5h://user:password@proxy:1080
https: socks5h://user:password@proxy:1080プロキシにホスト名を解決させる場合は、socks5:// より socks5h:// を優先してください。h により、名前がサーバー上で解決されず、プロキシに送信されるためです。同時にタイムアウトの予算も増やします。request_timeout のデフォルトは 3.0 秒です。プロキシを使うと各リクエストに往復通信が追加されるため、これまで時間内に応答していたエンジンが、タイムアウトとして失敗し始めます。extra_proxy_timeout はこの用途のための設定で、プロキシ使用時に秒数を追加します。10 のように整数で指定してください。小数を受け付ける request_timeout とは異なり、extra_proxy_timeout は設定スキーマで整数として定義されています。そのため、10.0 のような値は無効な settings.yml として拒否されます。外向き設定のドキュメントページにあるコメント付きの例では、その形式で記載されていますが、使用できません。
プロキシによって発生するコスト:
- プロキシ運営者には、インスタンスがどのエンジンへ、いつクエリを送信したかが見えます。TLS (transport layer security) により、クエリは暗号化されたリクエスト内に含まれるため、検索語が運営者のログに残ることは防げます。ただし、通信の形状とタイミングは運営者が確認できます。
- 共有の出口アドレスは、その料金を支払う他の利用者とも共有されます。他の利用者がスクレイピングを行っている場合、その評判を引き継ぐことになります。回避しようとしていたブロックより早く影響を受けることもあります。
- 安価な residential proxy のプールは、所有者が通信の中継に同意したことを認識していない一般消費者向けデバイスで構成されていることがよくあります。購入するサービスの実態を把握してください。
using_tor_proxy: trueは Tor 経由で通信しますが、出口ノードのアドレスはすべて公開されています。データセンターのアドレス帯域からのアクセスを警戒するエンジンは、通常、出口ノードも同じかそれ以上に厳しく扱います。- 検索がサーバー外部のサービスに依存するため、そのサービスが独自の都合で停止し、検索結果も取得できなくなる可能性があります。
プロキシはブロックを解消するのではなく、ブロックの発生場所を移します。また、インスタンスのプライバシーに関する説明に第三者が加わります。自己ホストする理由が、簡潔なプライバシー確保である場合は、何かに申し込む前に、自己ホストしたインスタンスが実際に隠せる情報と隠せない情報 と比較して検討してください。
意図的に少数のエンジン構成で運用する
多くの人が省略する選択肢は、使用するエンジンを減らすことです。SearXNG の価値は結果の統合にあります。常に応答する6個のエンジンを統合するほうが、半数が数時間から数日間停止したままの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 に設定された期間、そのエンジンへの問い合わせを停止します。標準設定では、拒否の種類に応じて3分から15日まで停止します。停止状態は実行中のプロセスに保持されるため、コンテナを再起動すると解除され、次の検索で再びエンジンへ問い合わせます。再起動直後にエンジンが再度失敗する場合、修正は機能していません。
エンジンの CAPTCHA エラーは、インスタンスが返す 429 と同じですか？
発生する方向が逆です。インスタンスからブラウザーに返る 429 は、リクエストが自動化されたものに見えると SearXNG 自身のリミッターが判断した結果であり、自分で設定できます。CAPTCHA やブロックのエラーは、上流のエンジンがサーバーを拒否した結果です。これは自分で管理できない側の環境で判断されます。結果ページが読み込まれ、一部のエンジンだけが表示されない場合は、後者です。
サーバー上の VPN やプロキシで、エンジンの CAPTCHA を解決できますか？
解決する場合もありますが、代償があります。送信リクエストを outgoing.proxies 経由にすると、エンジンから見えるアドレスが変わります。そのため、データセンターのアドレス範囲に紐づいたブロックを解除できる場合があります。一方で、プロキシの運用者には、どのエンジンへいつ問い合わせたかが見えます。また、共有出口アドレスには他の利用者の評価も付随します。さらに遅延が増えるため、request_timeout と extra_proxy_timeout を引き上げないとタイムアウトが発生します。Tor は using_tor_proxy 経由で利用できますが、出口アドレスは公開されており、広くチャレンジの対象になっています。
SearXNG に CAPTCHA を自動的に解かせることはできますか？
そのための設定はありません。プロジェクトが案内している方法は手動です。SSH SOCKS トンネル、自分のブラウザー、そしてチャレンジを自分で操作する必要があります。チャレンジに自動で応答する仕組みを構築しても、エンジンが示すポリシーに反するうえ、チャレンジが変更されるたびにひそかに機能しなくなります。その結果、検索インスタンスを運用する代わりに、スクレーパーを保守することになります。アドレスをブロックするエンジンを削除する方法が、継続して機能する解決策です。