著者 SearXNGは安全？検索内容を誰が見られるか
SearXNGは検索エンジンに自分のIPではなくサーバーのIPを渡します。公開インスタンスの運用者や自分のVPS、ISP、DNSに何が見えるかを整理します。
SearXNG は安全か？簡潔な答え
SearXNG は、ある方向では安全ですが、別の方向では安全ではありません。そのため、「SearXNG は安全か」という問いには、誰から隠れたいのかを明確にして初めて答えられます。SearXNG はメタ検索エンジンです。検索クエリを受け取り、Google、Bing、DuckDuckGo、および有効にしたその他の検索エンジンへ送信し、返された結果を1つの結果ページに統合します。検索エンジンから見えるのはインスタンスです。インスタンスから見えるのはあなたです。
他人が運用する公開インスタンスでは、入力したすべての検索クエリを、その運用者が平文で受け取ります。運用者がそれをどう扱うかは、about ページの記載だけでは証明できません。自分のサーバーを使う場合、上流の検索エンジンから見えるのは自宅のアドレスではなく、サーバーのアドレスです。この置き換えがプライバシー面の全体像であり、その価値は実行先のサーバーと同じだけです。
この仕組みで、自分のネットワークから検索内容を隠せるわけではありません。インターネットサービスプロバイダー (ISP) には、インスタンスへの接続が見えます。DNS (domain name system) リゾルバーには、ホスト名が見えます。この境界を意識したうえで、以降を読んでください。
SearXNG が検索リクエストに加える変更
Google に直接検索すると、Google は IP アドレス、Cookie、User-Agent ヘッダー、アクセス元ページを受け取ります。これらは、セッション終了後も維持されるプロファイルに関連付けられます。SearXNG はその間に入ります。SearXNG のドキュメントでは、実行する処理として「検索サービスへ送信するリクエストから個人情報を削除すること」と「リクエストごとにランダムなブラウザプロファイルを生成すること」の2つを説明しています。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) がインスタンスで終端されるため、クエリは完全な状態で読み取り可能なままインスタンスに到達します。以下の各点は、すべてこの事実から生じます。
公開インスタンスでは、運用者がすべての検索クエリを確認できます
プロジェクト自身のドキュメントにも、明確に記載されています。公開インスタンスの利用者は「そのインスタンスの管理者を信頼する必要があり」、自分の「検索要求が記録、集計され、第三者に送信または販売されているかどうか」を知ることはできません。ランディングページにあるログを保存しないという主張は、あくまで主張です。外部から検証する方法はないため、信頼するか、利用しないかのどちらかになります。一部の公開インスタンスでは、現在もこのフォークではなく元の Searx が稼働しています。これは重要な点です。Searx では 2023 年以降コードコミットが行われていないため、保守されていない検索ソフトウェアも、何も確認できないまま信頼する対象になるからです。
ログの保存は最も手間のかからない方法でもあります。配布時のデフォルト設定では、検索クエリが 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（仮想プライベートサーバー）上で自分のインスタンスを実行すると、変化は簡潔に説明できます。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権限を持つ者には、すべてが見えます。そこにはあなた自身も含まれ、後から侵入する者も含まれます。
Tor onion serviceとしてインスタンスにアクセスすれば、最初の2者から見える情報をなくせます。解決すべき公開ホスト名がなく、読み取るSNIフィールドもないためです。VPSにv3 onion serviceを追加する手順では、設定方法に加えて、そのアドレスをサーバーの公開IPへ結び付ける可能性のある漏えいも説明しています。
もう1つ、忘れられがちな観測者がいます。サーバーから送信するリクエストは、サーバー自身のネットワークから見えるため、プロバイダーには、そのマシンが1日中GoogleやBingと通信していることが分かります。これはクエリではなく、通信パターンです。それでも、一定の情報を示します。
ここでVPNの問題が出てきます。VPN（virtual private network）は、ISPから見える情報をVPN会社から見える情報へ移します。インスタンスの運用者から見える情報は変わりません。また、検索エンジンから見える情報も変わりません。検索エンジンはあなたではなく、サーバーと通信しているためです。この2つの違いは、VPSとVPNを比較した説明で正しく比較しています。
SearXNG がブロックする理由と、429 が実際に意味すること
「SearXNG にブロックされた」と表現される事象には 2 種類あり、それぞれ対処方法が異なります。
1 つ目は、SearXNG 自身のリミッターが HTTP 429 を返す場合です。これは SearXNG の bot 保護機能で、デフォルトでは無効です。
server:
limiter: true
valkey:
url: valkey://localhost:6379/02026 年 8 月時点では、このリミッターに Valkey データベースが必要で、ルールを /etc/searxng/limiter.toml から読み込みます。不特定の利用者が実際にこのサーバーを使用する場合は、server.public_instance: true も設定してください。デフォルトでは false であり、公開利用向けの動作を制御するためです。
リミッターはいくつかの検査を実行します。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 のレート制限と 429 エラーに関するガイドを参照してください。
リミッターには、特に注意すべき点が 1 つあります。リバースプロキシの背後では、そのプロキシを信頼する設定がない限り、SearXNG には訪問者のアドレスではなくプロキシのアドレスが見えます。
[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 = []デフォルトのリストには、同じホスト上のプロキシが含まれています。別の Docker network にあるプロキシからは、172.18.0.5 のようなアドレスで接続されます。このアドレスはリストに含まれていないため、すべての訪問者が 1 つのクライアントとして数えられます。その結果、最初にアクセスが集中した利用者が、他の全員を締め出します。そのサブネットを trusted_proxies に追加してください。
2 つ目のブロックは upstream で発生します。ある engine が、多数の検索を実行する datacenter のアドレスを scraper と判断し、サーバーへの応答を停止します。この場合、429 は返りません。該当 engine の結果が欠落し、失敗したことが結果ページに記録されます。また、失敗が繰り返されると、SearXNG はその engine をしばらく停止します。原因は VPS が使用するアドレスにあるため、対処方法はリミッターの設定ではなく、engine の選択と時間を置くことです。
見知らぬ人と1つのインスタンスを共有すると、助けになるのか、それとも害になるのか？
どちらにもなり得ます。作用する方向が逆だからです。そのため、答えがはっきりしません。匿名性は、集団によって生まれる効果です。利用者の多い公開インスタンスでは、あなたのクエリも数千人分の他のクエリと同じアドレスから送信されます。そのため、どの検索エンジンもあなたのクエリだけを集団から取り出せません。単一ユーザー用のインスタンスでは、そのアドレスから送信されるすべてのクエリがあなたのものです。検索エンジンには、名前の付いていない、1人分だけの明確なストリームが届きます。
運用者側の事情は逆です。大きな集団を利用すると、見知らぬ第三者が集団全体の平文のクエリを保持します。あなたのクエリもその中に含まれます。自分のサーバーを使えば、保持するのは自分のクエリだけで、他人のクエリはありません。
したがって、実際に抱えている脅威を基準に選んでください。広告プロファイリングやサイト横断トラッキングが心配なら、集団型のインスタンスが有効で、運用者のリスクは小さいでしょう。特定の個人や企業に、あなたが実行した特定の検索を読まれることが心配なら、集団型のインスタンスはまったく役に立ちません。運用者には平文のクエリが見えるからです。現実的な中間案は、知り合い数人でインスタンスを共有することです。小規模な集団を得られ、運用者を確認できます。運用者があなた自身だからです。
SearXNG の結果は Google より優れていますか？
いいえ。SearXNG は独自のインデックスを保持しません。そのため、結果ページに表示される結果はすべて上流の検索エンジンから取得したものです。品質の上限は、有効にした検索エンジンの品質で決まります。Google と Bing を無効にすると、品質は同じ日に低下します。一般的な Web の大部分を両者がカバーしているためです。
変わるのは、検索結果に対して適用される処理です。検索クエリから広告プロファイルを作成するものはありません。先週クリックした内容に基づいて結果を並べ替えるものもありません。これは一長一短です。パーソナライズには、地域に関する意図を反映する機能もあるためです。「pharmacy open now」のような検索は、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" の標準設定では、運用者が意図していたかどうかにかかわらず、検索語はリクエスト行の一部として reverse proxy のアクセスログにも記録されます。広告によるプロファイリングが懸念であれば、通常の検索に公開インスタンスを使用してください。所有者に渡したくない情報は入力しないでください。
SearXNG はインターネットプロバイダーから検索内容を隠せますか？
検索語の内容は隠されます。ただし、通信した事実は隠されません。プロバイダーには、インスタンスのアドレスへの TLS 接続と、ハンドシェイクの暗号化されていない SNI フィールドに含まれるホスト名が見えます。また、DNS リゾルバーには、そのホスト名の名前解決が見えます。接続は暗号化されているため、検索した内容はどちらにも見えません。SearXNG は VPN ではありません。SearXNG を使用しても、マシン上の他の通信は保護されません。
SearXNG が 429 エラーを返すのはなぜですか？
429 はインスタンス自身のリミッターが返します。Google からのメッセージではなく、bot 対策によるものです。リミッターのプローブは、Accept ヘッダーに text/html がないリクエストを検出します。未設定の User-Agent や、curl、wget などのツールと一致する User-Agent も検出します。3 つ目のプローブであるリンクトークンは、ブラウザーが読み込む /client<token>.css URL を一度も取得しないクライアントを検出します。reverse proxy が /etc/searxng/limiter.toml の trusted_proxies に設定されていない場合、すべての訪問者が 1 つのクライアントとして数えられます。そのため、1 人の利用者が集中して使用すると、他の利用者もブロックされます。upstream engine がサーバーをブロックした場合は、その engine の結果がページから単に表示されなくなるだけで、429 は返りません。
SearXNG を自己ホストすると検索結果の品質は下がりますか？
下がることがあります。主な理由は 2 つあります。結果は upstream engine から取得されるため、engine がスロットリングするデータセンターのアドレスでは、応答する engine が減り、結果ページの情報量も少なくなります。また、パーソナライズされたランキングがなくなります。これにより、広告による並べ替えだけでなく地域に基づく検索意図も失われます。そのため、preferences で地域を設定するまでは、場所に依存する検索の結果が弱くなることがあります。