TavilyProxyManager: 複数の Tavily プロキシプールアカウント API クレジットを一括管理するリバースプロキシツール

TavilyProxyManagerは Tavily Tavily APIはTavily APIによって設計されたオープンソースの透過的なリバースプロキシのシステムです。そのコア機能は、プロキシプールに複数のTavily APIキー（キー）統一収束の手の開発者は、外部のみセキュリティ認証のためのカスタムマスターキーを公開することです。このマルチアカウントプーリング管理メカニズムを通じて、システムはインテリジェントに各キーの残りのクォータを監視し、自動的にコールタスクを割り当てることができ、効果的に単一のフリーアカウントのインターフェイスに限られたコールの問題を解決し、低い同時実行頻度（Rate Limit）とクォータの断片化。

基本的なプロキシ転送機能に加え、Vue 3をベースにしたビジュアルなWeb管理パネルも内蔵しており、いつでもAPIキーを追加/削除したり、ワンクリックで全アカウントの残りクォータを同期したり、過去のコール量とクォータ消費傾向をグラフィカルに表示したりすることができます。完全に透過的なプロキシ戦略により、TavilyProxyManagerはオリジナルの公式インターフェースのすべてのリクエストパスとパラメータと互換性があります。AIアシスト開発エコシステムのために、TavilyProxyManagerはHTTP MCP (Model Context Protocol)エンドポイントをネイティブに提供します。 Claude このプロジェクトは、Dockerコンテナ化ソリューションを備えた軽量のGo言語シングルファイルコンパイルアーキテクチャを採用し、迅速なデプロイを完了します。このプロジェクトは、Dockerコンテナ化スキームを備えた軽量のGo言語シングルファイルコンパイルアーキテクチャを採用しており、極めて少ないリソース消費を前提に、迅速なデプロイを可能にしています。

機能一覧

• インテリジェントなキープールの同時スケジューリングTavily APIキー: 複数のTavily APIキーを統合し、各キーの残りのクォータを自動的に決定します。十分なクォータを持つキーの呼び出しが優先され、同じクォータを持つキーにはランダムな分散戦略が採用されます。これにより、1つのキーへの同時アクセスの圧力が大幅に軽減され、429リクエストオーバーランエラーが回避されます。
• 自動障害遮断とシームレスな切り替えリクエストのディザスタリカバリの仕組みは、ダウンストリームのコールが、 401(認可されていない)、429(頻度が高すぎるリクエスト)、432/433などのような 公式な例外ステータスコードに遭遇したときに、プロキシレイヤーが 自動的にエラーレポートをインターセプトし、再試行するためにリクエストを 次の健全な代替キーに静かに切り替えるように設定されている。
• Webビジュアライゼーション 集中管理パネル完全なGUIコンソール(Vite + Vue 3)を内蔵し、複数アカウントの最新クォータ情報の追加、削除、変更、一括同期機能を提供すると同時に、トレンドチャートでリクエストの消費量と全体的な運用状況を表示します。
• グローバル・リクエスト・ログ監査エージェントによって転送されたすべての検索リクエストとレスポンスの詳細（ステータスコード、消費量、消費時間などを含む）をリアルタイムで記録します。条件付きフィルタリング検索履歴ログの使用をサポートし、手動および自動クリーニングメカニズムの長期保存が付属しています。
• ネイティブHTTP MCPエンドポイントのサポート準拠 Model Context Protocol 仕様、システム内蔵 /mcp エンドポイント・サービスと、ステートフルおよびステートレス動作モードの両方をサポートすることで、AIインテリジェンス（エージェント）や編集者のネットワーク検索機能を構成するための敷居を大幅に下げる。
• マスターキー統一アクセス認証クライアントとビジネスコードは、Tavilyアカウントがいくつ接続されているかを気にする必要はなく、APIドメイン名をプロキシアドレスに置き換えて、標準の Authorization: Bearer 認証を呼び出すことができる。
• 周期的に自動化されるO&Mタスクバックグラウンドのタイミングスクリプトは、毎月1日に自動的にクォータリセットロジックをトリガーし、同時に、自動的に期限切れと放棄されたログデータをクリアすることができます。
• 超軽量配備バックエンド（Go 1.23+）とフロントエンドの静的リソースはコンパイルされ、単一の非常にコンパクトなバイナリ実行ファイルにバンドルされています。

ヘルプの使用

🛠️ TavilyProxyManager 詳細インストールおよび使用ガイド

本ガイドでは、複数のTavily APIクォータをスムーズに管理・利用できるよう、Docker環境の構築から設定ファイルの設定、パネルの管理、APIやAPIの利用方法まで詳しく解説します。 MCP 顧客とのドッキングの操作手順を完成させる。

I. 推奨されるインストール：Docker Composeベースの環境展開

このプロジェクトは、フロントエンドとバックエンドを単一のバイナリファイルにパッケージ化するアーキテクチャに基づいているため、Dockerを使用したコンテナ化されたデプロイは、ホスト環境の汚染を避けるための最も効率的な方法です。サーバにDockerとDocker Composeプラグインがインストールされていることを確認してください。

1.プロジェクトカタログとコンフィギュレーションファイルの確立
サーバーターミナルに新しいフォルダーを作成し、その中に docker-compose.yml オーケストレーションファイルの

mkdir tavily-proxy && cd tavily-proxy
touch docker-compose.yml

2.設定パラメータの準備
テキストエディタで開く docker-compose.ymlを記入し、保存する：

version: "3.8"
services:
tavily-proxy:
image: ghcr.io/xuncv/tavilyproxymanager:latest
container_name: tavily-proxy
ports:
- "8080:8080"
environment:
# 代理服务内部监听地址与端口
- LISTEN_ADDR=:8080
# 设定内置 SQLite 数据库的存储路径
- DATABASE_PATH=/app/data/proxy.db
# 上游 Tavily 官方 API 基准地址
- TAVILY_BASE_URL=https://api.tavily.com
# 请求超时断开时间
- UPSTREAM_TIMEOUT=30s
# MCP 模式，默认 true 代表无状态模式，防止客户端报会话丢失
- MCP_STATELESS=true
volumes:
# 将宿主机的 data 目录映射给容器，持久化存储数据库
- ./data:/app/data
# 映射系统时间以保障日志时区正确
- /etc/localtime:/etc/localtime:ro
restart: unless-stopped

3.ミラーサービスを開始し、引っ張る
以下のコマンドを実行してコンテナを起動する。システムは自動的にGithub Container Registryから最新バージョンのイメージを取得する。

docker-compose up -d

コア・クレデンシャルの取得：マスターキーの生成

TavilyProxyManagerはサービスが悪用されないようにマスターキーシステムの使用を強制します。サービスでは初号機データベースが空の場合、システムは自動的に強度の高いランダムなマスターキーを生成する。

この初期管理パスワードは、コンテナ・ログを照会して入手してください：

docker logs tavily-proxy 2>&1 | grep "master key"

サンプル端子出力：

level=INFO msg="no master key found, generated a new one" key=sk_master_xxxxxx

⚠️ 重要な注意事項このパラグラフを直ちに key= この文字列はパスワードマネージャに保存されます。このパスワードは、ウェブモニタリングパネルにログインするための固有のパスワードであると同時に、その後のAPIリクエストのヘッダに含める必要があるベアラートークンでもあります。

ウェブ視覚化パネルの基本操作

1. ログインシステムブラウザーやバインドされたドメイン名でサーバーのIPにアクセスするには、次のようにします。 http://<服务器IP>:8080 ).ログイン画面で先ほど傍受したマスターキーを入力し、コンソールにアクセスする。
2. エージェント鍵プールの追加：
   • ログイン後、鍵管理モジュールに移動する。
   • キーを追加」をクリックして、登録した複数のTavily無料または有料APIキーを1つずつシステムに貼り付けます。
   • 入力が完了した後、“Synchronise Quota ”ボタンをクリックすることをお勧めします。システムは、すべてのキーの有効性の公式確認に送信され、リストに[現在の残りの呼び出しクォータ]を更新します。
3. 使用状況の監視ダッシュボードは、リクエスト頻度ヒストグラムとシステム成功率を直感的に表示し、ログページは、各検索コマンドの具体的な時間消費とヒットステータスを保持し、リクエストのトラブルシューティングと監査を簡単に実行できます。

コード・アクセス・ガイドライン: REST APIトランスペアレント・プロキシ・モデル

システムの公開インターフェース仕様は、Tavilyの公式文書100%と一致しており、既存のオープンソースプロジェクトをゼロコストで移行できる。

核となる変化点

• 元のリクエストのURLは https://api.tavily.com デプロイのアドレスに置き換えてください。 http://<服务器IP>:8080
• 認証情報は Master Key

CURLテストのサンプルコード：

curl -X POST "http://<服务器IP>:8080/search" \
-H "Authorization: Bearer <您的_MASTER_KEY>" \
-H "Content-Type: application/json" \
-d '{"query": "2026年最新AI模型架构解析", "search_depth": "basic"}'

注：システムは、ペイロード本体で渡すか、あるいは {"api_key": "<MASTER_KEY>"} またはURLの末尾に継ぎ足す ?api_key=<MASTER_KEY> すべて正しく識別できる。

V. 高度な統合：MCP（モデルコンテキストプロトコル）プロトコルアクセス

多くの新しいAI生産性ツール（例えば、Claudeデスクトップ・アプリケーション、VS Codeの Cline プラグインなど）は、ツール呼び出し機能を拡張するために MCP プロトコルに基づいています。このエージェントは、このエンドポイントとネイティブに統合します。

VSコードの設定変更例（mcp-remoteと組み合わせて使用）：
以下の Server ノードを VS Code MCP プロファイルに追加します：

{
"servers": {
"tavily-proxy": {
"command": "npx",
"args":[
"-y",
"mcp-remote",
"http://<您的服务器IP>:8080/mcp",
"--header",
"Authorization: Bearer <您的_MASTER_KEY>"
]
}
}
}

動作原理デフォルトで有効 MCP_STATELESS=true この環境変数は、プロキシがステートレス接続を維持できるようにするための ものである。MCPプロトコルは一定のSSE/WebSocket状態を維持することを意図しているため、クロスネットワークやリバースプロキシの転送は、エラーの原因となるセッションIDの切断につながりやすい。 session not foundステートレスモードでは、各命令は独立して呼び出される。ステートレスモードでは、各命令は独立して呼び出されるため、長い接続でもAIツールの究極の安定性が保証される。

アプリケーションシナリオ

1. AIアプリケーション開発チームのノルマプール管理
   小さなR&Dチームが検索エンジンに大きく依存するエージェントワークフローを構築する場合、Tavilyの公式無料版のクォータではデバッグ頻度をサポートするのに十分ではありません。開発者は、複数のテストアカウントを登録してキーを取得し、システムに注入することで、プロセスの途中で基礎となるビジネスコードを変更することなく、断片化されたクォータを巨大なクォータプールに集約することができます。
2. 高同時性ビジネスシナリオのためのアンチブロッキングとリトライ戦略
   検索結果を大量にクロールしたり、検索機能への突然の高トラフィック呼び出しが発生したりすると、単一のTavily Keyがレートリミットにヒットしやすくなり、その結果429エラーが発生してプロセスが中断されます。システムをリレーレイヤーとして配置することで、スムーズなランダムスキャッターアルゴリズムとエラーに対する自動フェイルオーバー補償により、同時ブロッキングとタスクの失敗を最小限に抑えます。
3. 没入型AI支援プログラミングのエコインテグレーション
   ローカルでIDEを使用している開発者（たとえば Cursor, AIコーディング・アシスタント（VS Code）で最新のインターネット・ドキュメントを取り込む必要があるコードを書く場合、MCPノードを使用してIDEにTavilyProxyManagerアドレスを登録するだけで、AIモデルが自律的に検索操作を実行し、開発者はAIがAPIを過剰に消費していないかどうかをウェブパネルを通じて明確に確認できるようになり、課金の透明性が向上する。
4. エンタープライズ・レベルの共有コール・インターフェース監査モニタリング
   企業イントラネットは、各部門の開発者が使用するマスターキーを統一的に提供し、IT管理者はバックエンドの使用統計とログデータを監視することで、デッドループに陥っている異常な呼び出しのあるサーバー側のスクリプトを特定することができ、同時に、全社的な資産の再利用と内部統制の要件を満たすために、毎月のクォータの再推計を自動的に実行することができます。

QA

1. Tavilyは公式にインターフェイスを頻繁にアップグレードしているので（例えば、高度な検索パラメータを追加するなど）、プロキシツールは互換性がないためにエラーを報告するのでしょうか？
   A: 非互換性はない。このシステムは「透過的かつ非破壊的な送信」というプロキシの哲学を採用しており、コード・レイヤーはAuthorisationヘッダーとプロキシ配布ロジックにのみ介入します。ビジネス・リクエストによって送信される特定のURLパスと、リクエスト・ボディ内のカスタム・パラメータは、変更されることなく公式APIにルーティングされるため、アップストリーム・アップグレードに対する免責性と完全な互換性があります。
2. ターミナルからオリジナルのマスターキーを探すことができません。
   A: 初期マスターキーは、サービス存続のための唯一のスーパー・クレデンシャルです。コンソールログがローリングベースで上書きされている場合、マスターキーをホストの /data/proxy.db（SQLiteデータベースファイルをローカルにダウンロードし、SQLiteStudioなどのツールを使って開き、設定テーブルを確認し、独自のカスタム暗号文パスワードを取得または変更する。
3. MCPアクセス中に、リクエストに失敗したり、切断が頻繁に発生したりするのはなぜですか？
   A: これは通常、ネットワークの変動によってステートフル接続が中断されることが原因です。まず docker-compose.yml 環境変数 MCP_STATELESS=true プロキシコンテナの前にNginx/Caddyのような自作ゲートウェイサービスの追加レイヤーを入れ子にしている場合、ゲートウェイが特定のリクエストヘッダを傍受せず、SSE応答フォーマットをブルートフォースバッファで切り詰めないことを確認してください。
4. 同じ残額を持つ異なるキーに対して、ポーリング戦略はどのように処理されますか？
   A: システムが、複数の利用可能なKeyが同じ最大値を持つと判断した場合、単純な 順次割り当てをスキップし、ディスパッチに基礎となるランダムシャッフ ルアルゴリズムを使用します。この動きは、最初の数Keyにおけるリクエストの固定経路を最大限に回避し、 その結果、公式の秒間同時実行制御(QPSしきい値)に触れる一点を回避する。