著者 SearXNGは安全？検索語を本当に隠せる範囲
SearXNGは検索エンジンに自分のIPではなくサーバーのIPを見せます。公開インスタンスの運用者や自分のVPS、ISPに検索語がどう見えるか、隠せない範囲まで解説します。
SearXNG は安全ですか？短い答え
SearXNG は、ある方向では安全ですが、別の方向では安全ではありません。そのため、「SearXNG は安全か」という問いには、誰から身を隠したいのかを明確にして初めて答えられます。SearXNG はメタ検索エンジンです。検索語を受け取り、Google、Bing、DuckDuckGo、および有効にしたその他の検索エンジンへ送信し、返された結果を 1 つの結果ページにまとめます。検索エンジンから見えるのはインスタンスです。インスタンスから見えるのはあなたです。
見知らぬ人が運用する公開インスタンスでは、入力した検索語がすべて平文でその運用者に渡ります。about ページに何が書かれていても、その運用者が検索語をどう扱うかを証明することはできません。自分のサーバーを使う場合、上流の検索エンジンからは自宅のアドレスではなく、サーバーのアドレスが見えます。この置き換えがプライバシーに関する仕組みのすべてであり、その効果は実行先のサーバーがどれだけ信頼できるかに完全に依存します。
この仕組みだけでは、自分のネットワークから検索内容を隠せません。インターネットサービスプロバイダー（ISP）には、引き続きインスタンスへの接続が見えます。DNS（domain name system）リゾルバーには、引き続きホスト名が見えます。以降を読む際は、この境界を意識してください。
検索リクエストで SearXNG が変更する内容
Google に直接検索を送ると、Google は IP アドレス、Cookie、User-Agent ヘッダー、直前に閲覧していたページを受け取ります。これらは、セッション終了後も保持されるプロファイルに関連付けられます。SearXNG はその間に入ります。SearXNG のドキュメントでは、実行する処理を「検索サービスへ送信するリクエストから個人情報を削除すること」と「リクエストごとにランダムなブラウザープロファイルを生成すること」と説明しています。Cookie が検索エンジンへ転送されることはありません。設定はサーバー上のアカウントではなく、自分のブラウザーに保存されます。
2 つのレスポンスヘッダーがデフォルトで有効になっており、どちらも実際に機能します。
default_http_headers:
X-Robots-Tag: noindex, nofollow
Referrer-Policy: no-referrerReferrer-Policy: no-referrer により、検索結果をクリックしても、遷移先のサイトはどの検索ページから来たのかを知ることができません。ブラウザーが Referer ヘッダーを省略するためです。X-Robots-Tag: noindex, nofollow により、SearXNG のインスタンスとその検索結果ページが検索インデックスに登録されないようにします。
SearXNG が変更しないのは、検索クエリ自体です。TLS (transport layer security) がそこで終端されるため、クエリは完全な状態で読み取り可能なままインスタンスに到達します。以下の各点は、すべてこの事実から導かれます。
公開インスタンスでは、運用者がすべての検索クエリを確認できます
プロジェクトの公式ドキュメントには、明確にこう書かれています。公開インスタンスのユーザーは「そのインスタンスの管理者を信頼する必要があり」、自分の「リクエストが記録、集計され、第三者に送信または販売されているかどうか」を知ることはできません。ランディングページにあるログを保存しないという説明も、あくまで説明です。外部から検証する方法はないため、信頼するか、利用しないかのどちらかになります。
ログへの保存は、最も手間のかからない方法でもあります。出荷時のデフォルトでは、検索クエリが URL に含まれるためです。
server:
method: "GET"GET を使用すると、リクエスト行ではクエリが ?q=... として送信されます。通常のリバースプロキシはこのリクエスト行をアクセスログに書き込むため、誰かが記録を決めていなくても検索クエリが保存されます。
203.0.113.5 - - [20/Aug/2026:09:14:02 +0000] "GET /search?q=redundancy+pay+notice+period&category_general=1&language=en HTTP/1.1" 200 15321 "-" "Mozilla/5.0 (X11; Linux x86_64)"自分のインスタンスで確認してみてください。
sudo tail -n 5 /var/log/nginx/access.log検索内容がそこに含まれるのは、nginx の combined ログ形式が $request を書き込むためです。これは、クエリ文字列を含む完全なリクエスト行です。SearXNG がこれを制御することはありません。インスタンスを method: "POST" に切り替えると、クエリはリクエストボディに移されます。そのため、アクセスログとブラウザー履歴には表示されなくなります。公式ドキュメントも、POST には「エンドユーザーの使いやすさを大幅に制限する」欠点があると正直に説明しています。主な問題は、ブラウザーの戻るボタンに関するものです。これは、意図的に選択するトレードオフです。
公開インスタンスについて、2 つの結果が生じます。運用者が検索クエリを収集するつもりがなくても、クエリを読み取ることができます。バックアップや侵害によって、同じログにアクセスされる可能性もあります。
自分の VPS では、検索エンジンに表示されるのはあなたではなくサーバーです
VPS（virtual private server）上で自分のインスタンスを運用すると、変化は明確です。Google は検索クエリとともに自宅の IP アドレスを受け取らなくなります。代わりに、検索クエリとサーバーの IP アドレスを受け取ります。その検索を、ログイン中のアカウント、スマートフォン、家庭の接続に紐づいた広告プロファイルに関連付けることはできません。構築手順はVPS 上で自分の SearXNG インスタンスを運用するガイドで説明しています。
変わらない点も明確にしておきます。検索エンジンには、検索クエリの内容、検索した時刻、指定した言語と地域、数か月にわたる検索内容の傾向が引き続き表示され、すべてが1つの安定したアドレスにまとめられます。利用者があなただけの場合、そのアドレスは名前のない個人単位の検索履歴になります。この関連付けを分断するには、インスタンスから外向きプロキシまたは Tor 経由で検索エンジンへ接続する必要があります。SearXNG はこれらをサポートしていますが、別途対応が必要です。
ISP、リゾルバー、ホストから引き続き見える情報
この構成の影響を受けない観測者が 4 者います。
- ISP からは、インスタンスの IP アドレスへの TLS 接続が見えます。また、ハンドシェイク中に平文で送信される SNI（server name indication）フィールドのホスト名も見えます。クエリの内容は見えません。
- DNS リゾルバーからは、そのホスト名の名前解決が見えます。ページの読み込み中にクライアント上で
sudo tcpdump -ni any port 53を監視すると、インスタンスの A レコードに対するリクエストが表示されます。 - VPS プロバイダーはハードウェアを運用しているため、仮想マシンのディスクとメモリを読み取れます。実行中のシステムが暗号鍵を保持しているため、レンタルした VM 内でディスクを暗号化しても、この問題は解消されません。
- インスタンス上で root 権限を持つ者には、すべてが見えます。そこにはあなた自身も含まれます。また、後から侵入した者も含まれます。
もう 1 つ、忘れられがちな観測者がいます。サーバーからの送信リクエストは、サーバー自身のネットワークから見えるため、プロバイダーは、そのマシンが常に Google や Bing と通信していることを確認できます。これはクエリそのものではなく、通信パターンですが、そこからも情報が得られます。
ここで VPN の疑問が出てきます。VPN（virtual private network）は、ISP から見える情報を VPN 会社から見える情報に置き換えます。インスタンスの運用者から見える情報は変わりません。また、検索エンジンから見える情報も変わりません。検索エンジンはあなたではなく、あなたのサーバーと通信しているためです。この 2 つは、VPS と VPN の違いで正しく比較しています。
SearXNG がブロックする理由と、429 の本当の意味
「SearXNG にブロックされた」と表現される事象には、異なる 2 種類があります。それぞれ必要な対処が異なります。
1 つ目は、自分で設定した limiter が HTTP 429 を返す場合です。これは SearXNG の bot protection で、デフォルトでは無効です。
server:
limiter: true
valkey:
url: valkey://localhost:6379/02026 年 8 月時点では、limiter に Valkey データベースが必要で、ルールを /etc/searxng/limiter.toml から読み込みます。不特定の利用者が実際にこのホストを使う場合は、server.public_instance: true も設定してください。デフォルトでは false であり、公開利用を想定した動作を制御するためです。
limiter は複数の検査を実行します。http_user_agent は User-Agent が未設定の場合、または curl や wget など既知のツールに一致する場合に bot と判定します。http_accept は、リクエストの Accept ヘッダーに text/html が含まれていない場合に bot と判定します。link_token は、通常のブラウザーが読み込む /client<token>.css URL をクライアントが一度も取得しない場合に、そのクライアントを疑わしいと判定します。検査に該当すると、SearXNG は 429 を返し、botdetection logger に ERROR 行を書き込みます。
そのため、次の処理は失敗します。これは想定された動作です。
curl -s -o /dev/null -w '%{http_code}\n' 'https://searx.example.com/search?q=test'curl は User-Agent: curl/8.5.0 と Accept: */* を送信するため、2 つの検査に同時に該当します。このため、ブラウザーでは問題なく動作するインスタンスでも、スクリプトや AI agent には 429 が返ります。自分のインスタンスを agent の検索機能の接続先にする前に、ここを修正してください。原因と設定の全体像については、SearXNG の rate limit と 429 エラーに関するガイドを参照してください。
limiter には、もう 1 つ注意すべき点があります。reverse proxy の背後では、その proxy を信頼するよう設定しない限り、SearXNG からは訪問者のアドレスではなく proxy のアドレスが見えます。
[botdetection]
ipv4_prefix = 32
ipv6_prefix = 48
trusted_proxies = ['127.0.0.0/8', '::1']
[botdetection.ip_limit]
link_token = false
[botdetection.ip_lists]
pass_ip = []
block_ip = []デフォルトのリストには、同じホスト上の proxy が含まれています。別の Docker network にある proxy からは、172.18.0.5 のようなアドレスで接続されます。このアドレスはリストにないため、すべての訪問者が 1 つの client として数えられ、最初にアクセスが集中した利用者によって他の全員がブロックされます。その subnet を trusted_proxies に追加してください。
2 つ目のブロックは upstream で発生します。ある engine が、多数の検索を実行する datacenter のアドレスを scraper と判断し、サーバーへの応答を停止します。この場合、429 は返りません。その engine の結果が欠落した results page が返り、該当 engine の failure が記録されます。失敗が繰り返されると、SearXNG はその engine をしばらく suspend します。原因は VPS が使用するアドレスにあるため、対処は limiter の設定変更ではなく、engine の選択と時間を置くことです。
見知らぬ人とインスタンスを共有すると、プライバシーの保護に役立つのでしょうか、それとも損なうのでしょうか？
両方です。作用する方向が逆なので、答えが分かりにくくなります。匿名性は集団によって生まれます。利用者の多い公開インスタンスでは、あなたの検索クエリは何千人もの他の利用者のクエリと同じアドレスから送信されます。そのため、どの検索エンジンもあなたのクエリだけを集団から取り出せません。単一ユーザー用のインスタンスでは、そのアドレスから送信されるクエリはすべてあなたのものです。検索エンジンには、名前が付いていない、1 人だけの明確な通信ストリームが届きます。
運用者側では、状況が逆になります。大きな集団を利用すると、見知らぬ人である運用者が、集団全体の平文の検索クエリを保持します。あなた自身のサーバーを使えば、あなたが自分のクエリだけを保持し、他人のクエリは保持しません。
そのため、実際に想定する脅威に応じて選んでください。広告プロファイリングやサイト間トラッキングが心配なら、集団を利用する方法が有効で、運用者に関するリスクも小さくなります。特定の個人や企業に、実行した特定の検索を読まれることが心配なら、集団を利用しても役に立ちません。運用者には検索内容の平文が見えるからです。適切な中間案は、知っている少人数でインスタンスを共有することです。小規模な集団を利用しつつ、確認可能な運用者を選べます。その運用者があなた自身だからです。
SearXNG の検索結果は Google より優れていますか？
いいえ。SearXNG は独自のインデックスを保持していません。そのため、ページ上の各結果はアップストリームエンジンから取得され、品質の上限は有効にしたエンジンの品質で決まります。Google と Bing を無効にすると、一般的な Web の大部分を両者がカバーしているため、その日のうちに品質が低下します。
変わるのは、検索結果に対して適用される処理です。検索クエリから広告用プロファイルを作成する処理はなく、先週クリックした内容に基づいて結果の順序を変更する処理もありません。これは一長一短です。パーソナライズには、地域に応じた検索意図も反映されるためです。たとえば「今開いている薬局」のような検索は、SearXNG では結果が弱くなります。SearXNG のエンジンには、サーバーが設置されているデータセンター以外の位置情報がないためです。地域に応じた結果が必要な場合は、設定で地域を指定してください。
結果を閲覧している間にインスタンスからどれだけ情報が漏れるかは、2 つの設定で決まります。image_proxy はデフォルトで false です。そのため、サムネイルはホスト元のサイトから直接読み込まれ、それらのサイトにはブラウザーのアドレスが通知されます。image_proxy: true に設定すると、サムネイルはインスタンス経由になります。ただし、帯域幅とメモリの使用量が増えます。また、formats は html だけで提供されるため、JSON (JavaScript object notation) リクエストは 403 Forbidden で拒否されます。
curl -s -o /dev/null -w '%{http_code}\n' 'https://searx.example.com/search?q=test&format=json'公開インスタンスで json を有効にすると、無料のスクレイピング API を公開することになります。これは、依存しているエンジンによってサーバーのアドレスをブロックされる最短の原因です。無効のままにするか、認証の背後で使用してください。
SearXNG のプライバシー保護の限界
SearXNG は、誰が検索しているかを検索エンジンから隠します。ただし、ネットワーク上で何をしているかまでは隠しません。ここから、4 つの境界が分かります。
- 検索ボックス以外では、ネットワークトラフィックは変わりません。そのマシンが行うその他すべての通信は、これまでどおりネットワークから出ていきます。
- 1 台のサーバー上の 1 ユーザーは、すべての検索エンジンに対して安定した識別子になります。その識別子に名前は含まれません。メリットはそれだけです。
- どのインスタンスの運用者も、クエリを平文で読み取れます。これを自分で検証できるのは、自分自身で運用する場合だけです。
- 自分のアクセスログによって、避けようとしていた記録が再構成されます。ログを確認し、空のままにしたい場合は
method: "POST"に切り替えてください。
SearXNG は監視者を変えます。監視そのものをなくすわけではありません。どの監視者を問題視するかを決め、それに合うインスタンスを選んでください。検索フロントエンドを匿名化ソフトウェアとして扱わないでください。
FAQ
SearXNG を公開インスタンスで使用しても安全ですか？
検索エンジンからは安全ですが、運営者に対しては安全ではありません。検索クエリは平文でそのサーバーに到達します。プロジェクトのドキュメントにも、「そのインスタンスの管理者を信頼する必要がある」とあり、「リクエストが記録、集約され、第三者に送信または販売されているかどうか」を利用者は知ることができないと記載されています。method: "GET" の標準設定では、運営者が意図していなくても、クエリはリクエスト行の一部としてリバースプロキシのアクセスログにも記録されます。広告によるプロファイリングを懸念している場合は、通常の検索に公開インスタンスを使用してください。所有者に渡したくない情報は入力しないでください。
SearXNG はインターネットプロバイダーから検索内容を隠しますか？
検索クエリの文字列は隠されます。ただし、通信自体は隠されません。プロバイダーには、インスタンスのアドレスへの TLS 接続と、ハンドシェイクの暗号化されていない SNI フィールドに含まれるホスト名が見えます。また、DNS リゾルバーには、そのホスト名の名前解決が見えます。接続は暗号化されているため、どちらにも検索内容は見えません。SearXNG は VPN ではなく、マシン上のその他の通信を保護する機能もありません。
SearXNG が 429 エラーを返すのはなぜですか？
429 はインスタンス自身のリミッターが返しています。これは Google からのメッセージではなく、ボット対策です。検査機能は、Accept ヘッダーに text/html がないリクエストを検出します。また、User-Agent が未設定であるか、curl や wget などのツールと一致する場合も検出します。3 つ目の検査であるリンクトークンは、ブラウザーが読み込む /client<token>.css URL を一度も取得しないクライアントを検出します。/etc/searxng/limiter.toml の trusted_proxies にリバースプロキシが登録されていない場合、すべての訪問者が 1 つのクライアントとして数えられます。そのため、1 人の利用者によるアクセス集中で、他の利用者までブロックされます。アップストリームの検索エンジンがサーバーをブロックしている場合は、その検索エンジンの結果だけがページからなくなり、429 は返りません。
SearXNG をセルフホストすると検索結果の品質は下がりますか？
下がることがあります。主な理由は 2 つあります。検索結果はアップストリームの検索エンジンから取得されるため、検索エンジンがデータセンターのアドレスをスロットリングすると、応答する検索エンジンが減り、結果ページの情報量も少なくなります。また、パーソナライズされたランキングがなくなります。これにより、広告に基づく並べ替えがなくなる一方、地域に応じた検索意図も反映されなくなります。設定で地域を指定するまで、地域依存の検索では結果が弱くなることがあります。