リクエスト経路を把握する
お客様のインスタンスは設定されたエンジンにクエリを送信し、結果をユーザーに返します。上流側はリクエストを制限したりレート制限をかけたりする場合があります。セルフホストによって、すべての検索エンジンが無期限にトラフィックを受け入れることが保証されるわけではありません。
インターフェースを管理下に保つ
HTTPS を使用し、インスタンスをプライベート、認証済み、公開のいずれにするかを決定してください。公開検索エンドポイントには不正利用対策と容量計画が必要です。設定と管理アクセスは別々に保護してください。
クエリの保持を最小限にする
検索クエリは機密性が高い場合があります。リバースプロキシ、アプリケーション、システムのログを確認し、明確な必要がない限りクエリ文字列を保持しないでください。他者に接触する可能性のある外部の検索結果や画像リクエストについて説明してください。
維持と監視
サポート対象のリリース、応答エラー、上流の変更を追跡してください。負荷の高いリクエストを制限し、利用できないエンジンに対する明確なフォールバックを用意してください。シークレットトークンを露出せずに設定をバックアップしてください。
コンテナとプロキシの境界を可視化する
サポート対象のコンテナデプロイでも、永続的な構成、非公開のシークレット、意図的なネットワーク公開が必要です。アプリケーションを適切なTLSプロキシの背後に置き、公開する前にレート制限を確認してください。古いcomposeファイルを無期限に再利用するのではなく、現在の公式デプロイ手順を確認してください。
公式ドキュメント: SearXNG コンテナインストール
検索と AI レイヤーを分離する
Perplexicaなどのツールや別のモデル支援インターフェースを追加すると、クエリと取得したテキストがモデルプロバイダーにも送信される場合があります。その新しいデータ経路と、そのコスト、認証、保持について確認してください。プライベートなメタ検索インスタンスは、追加したAIサービスを自動的にプライベートにするものではありません。
検索エンドポイントを使用できるユーザーを選択する
プライベートな SearXNG インスタンスでは、トンネルまたは認証付きのアクセス境界を利用できます。公開インスタンスには、異なる容量と不正利用対策の計画が必要です。上流の検索エンジンは依然としてお客様のホスティング経路からリクエストを受け取り、制限や CAPTCHA を返す場合があります。新しい IP は回避を保証するものではありません。サポートされているコンテナ手順を使用し、設定を永続化し、プライベートインスタンスのシークレットを生成してください。アプリケーションは意図した TLS プロキシの背後に置いてください。
- クエリを許可されているエンジンの小さな初期セットを選択してください。
- 構成情報やシークレットを公開ファイルパスに置かないでください。
- オプションの外部画像・アイコン取得がプライバシー境界を変えるかどうかをご確認ください。
公式ドキュメント: SearXNG コンテナインストール
レートリミッターに実際のクライアントを認識させる
現在のSearXNGレートリミッターのドキュメントでは、動的状態にValkeyを使用しています。プライベートに構成し、インスタンス設計の一部である場合にレートリミッターを有効にしてください。プロキシの信頼は重要です。すべての訪問者がプロキシとして見える場合、1人の訪問者が全員の制限に影響を与える可能性があります。任意の転送ヘッダーが信頼される場合、訪問者がアドレスを偽装できます。信頼するプロキシ範囲を実際のデプロイメントに設定し、エンドポイントを公開する前に結果の動作をテストしてください。
公式ドキュメント: SearXNG のリミッターと信頼済みプロキシ
ブラウザの使用とエンジン障害をテスト
通常の検索、非ASCII文字を含むクエリ、設定済みの単一エンジンに対する検索、および意図的に利用不可としたエンジンでの検索を実行してください。上流の障害がサービス全体を利用不能にしないことを確認してください。テストしたインスタンスを、そのブラウザが対応する設定を用いてブラウザの検索プロバイダーとして追加してください。Perplexica のような AI レイヤーについては、認証、モデルプロバイダーとのデータ共有、支出上限、およびソースの帰属を別途確認してください。メタ検索フロントエンドは、これらの追加サービスを制御するものではありません。
- 新しいブラウザプロファイルから結果リンクとリダイレクトを確認してください。
- 検索語がプロキシのアクセスログや分析に記録されるかを確認してください。
- 未承認のネットワークからプライベートアクセスの境界をテストしてください。
制限を回避せずに上流の障害を修復する
エンジンが1つだけ失敗した場合は、デプロイ全体を変更する前に、そのエラーと現在のアダプター互換性を確認してください。CAPTCHAやレート制限の応答は上流のポリシーシグナルであり、それを回避して自動化する許可ではありません。HTTP 429 応答の繰り返しは、自身のリミッターやプロキシ設定に起因する場合もあります。フォールバックエンジンと更新のリハーサルを用意し、小さな設定バックアップを保持し、一度のトラブルシューティングのために恒久的なクエリログを残すことは避けてください。