Gemini CLIだけがClashでタイムアウトする理由

ブラウザ版の Gemini は、macOS や Windows のシステムプロキシ、ブラウザ拡張、OS 側の名前解決設定を比較的素直に利用します。一方、Gemini CLI はターミナルから起動する Node.js ベースの開発者ツールであり、シェルの環境変数、親プロセス、認証フロー、Node の HTTPS 実装に依存します。そのため、Clash の画面でシステムプロキシを有効にしていても、ターミナルから実行した CLI だけが DIRECT 接続になったり、別の DNS を使ったりすることがあります。

表示されるエラーが「timeout」「fetch failed」「socket hang up」「ETIMEDOUT」のどれであっても、最初から Gemini API の障害と決めつけないことが重要です。実際には、(1) CLI がプロキシポートを知らない、(2) Clash のルールが Google 系ドメインを誤って DIRECT に送る、(3) DNS 解決だけが別経路になる、(4) 選択中のノードが TLS やストリーミング通信に弱い、(5) OAuth 認証と API 通信で出口が分かれる、といった複数の原因が重なっています。

まず Gemini CLI を実行するターミナルを一つに固定し、Clash のConnections またはライブ接続画面を同時に開いてください。ログイン、モデル一覧の取得、実際のプロンプト送信を別々に行うと、どの段階で通信が止まっているかを見分けやすくなります。認証画面が表示されたからといって API 接続まで成功したとは限りません。OAuth のリダイレクトだけ通り、トークン交換や推論リクエストが別のホストで止まるケースもあります。

ℹ 先に記録する情報：エラーが発生した時刻、Clash のモード、使用中のプロキシグループ、表示されたホスト名、ターミナルの種類、そして同じ操作を別ノードで試した結果をメモします。購読設定をいきなり全面変更するより、成功と失敗の差分を残したほうが原因を早く特定できます。

最初に確認するプロキシモードとターミナル設定

Clash のモードが Global、Rule、Direct のどれになっているかを確認します。接続テストの初期段階では、複雑なルールの影響を減らすため、一時的に信頼できるノードを選んだ Global モードで Gemini CLI を実行すると比較がしやすくなります。Global で成功し、Rule で失敗するなら、ノードそのものよりもルール順序、ルールプロバイダー、または DNS の判定が疑わしくなります。

次に Clash の mixed-port または HTTP ポートを確認してください。多くのクライアントでは 7890、7897、9090 などが使われますが、番号は環境ごとに異なります。CLI を起動するシェルで、実際のポートに合わせて次のような環境変数を設定します。 

export HTTP_PROXY=http://127.0.0.1:7890
export HTTPS_PROXY=http://127.0.0.1:7890
export ALL_PROXY=socks5://127.0.0.1:7891

すでに別の VPN、企業プロキシ、開発用の PAC 設定を使っている場合は、HTTP_PROXY と HTTPS_PROXY が意図せず上書きされていないか確認します。大文字と小文字の両方を読むプログラムもあれば、片方だけを参照するプログラムもあります。不要な設定を一度外し、Clash の mixed-port だけを明示して再試行すると、プロキシの二重化を切り分けられます。

シェルの設定ファイルに環境変数を追加した場合は、既存のターミナルへ自動反映されません。macOS の zsh なら新しいターミナルを開くか、設定ファイルを読み直します。Windows の PowerShell では環境変数の記法が異なり、WSL、Git Bash、通常の PowerShell でも継承関係が変わります。IDE 内蔵ターミナルは、IDE を起動した時点の環境を保持していることがあるため、設定後に IDE とターミナルを再起動してください。 

echo $HTTP_PROXY
echo $HTTPS_PROXY
npm config get proxy
npm config get https-proxy
⚠ 注意：環境変数へ購読 URL や API キーを直接書き込まないでください。シェル履歴、CI ログ、診断レポートに秘密情報が残ることがあります。プロキシ設定だけを確認し、認証情報は公式の Gemini CLI のログインフローで管理してください。

DNS と Google API の疎通を段階的にテストする

プロキシポートが正しくても、DNS 解決が不安定なら Gemini CLI は接続先の IP を得られずタイムアウトします。Clash の DNS 設定で fake-ip、redir-host、IPv6 の扱いが混在している場合、ブラウザと CLI で結果が異なることがあります。特にローカル DNS、ルーターの DNS、企業ネットワークの DNS が同時に有効になっている環境では、名前解決だけ DIRECT になっていないかを確認してください。

まず Clash の接続ログに、Gemini CLI 実行時の Google 関連ホストが表示されるかを見ます。ホストが一件も現れない場合は、CLI がプロキシを使っていない可能性があります。ホストが表示されても、すぐに REJECT、DIRECT、または失敗するグループへ落ちているなら、ルール評価の確認が必要です。接続が一度だけ作られて切れる場合は、TLS、HTTP/2、ノード品質、またはストリーミング応答の相性を調べます。

DNS の確認には、OS 標準のツールを使って名前が解決できるかを見ます。ただし、端末上で名前が解決できたことは、Gemini CLI の HTTPS 通信が成功することを保証しません。これはあくまで DNS 層と TCP 層を分けて観察するためのテストです。解決結果が毎回変わる場合は、Clash の DNS キャッシュをクリアし、同じノードと同じモードで再試行してください。 

nslookup generativelanguage.googleapis.com
curl -I --max-time 15 https://generativelanguage.googleapis.com
curl -I --proxy http://127.0.0.1:7890 --max-time 15 https://generativelanguage.googleapis.com

curl の直接実行だけ失敗し、Clash のプロキシを明示した実行だけ成功するなら、回線とノードは生きていて、CLI 側のプロキシ継承に問題があります。反対に、プロキシを指定しても TLS handshake や名前解決で失敗する場合は、ノード、DNS、ファイアウォール、または Clash コアの設定を調べます。API キーや認証ヘッダーを付ける必要はありません。疎通テストへ秘密情報を追加しないことが安全です。

ルール誤判定を直し、Google 系ドメインを意図した出口へ送る

Rule モードでは、Clash がルールを上から順番に評価し、最初に一致したポリシーを採用します。Google 系ドメインを対象にしたルールより先に、広い GEOIP、広告ブロック、地域別の DOMAIN-SUFFIX、あるいは大きなルールプロバイダーが置かれていると、Gemini に必要な通信だけが別の出口へ流れることがあります。「Google は全部 DIRECT」という一般的な最適化が、現在のネットワークでは逆にタイムアウトの原因になる場合もあります。

ルールを修正するときは、インターネット上の巨大な設定をそのまま貼り付けるのではなく、Clash のログで実際に確認できたホストから始めます。Gemini CLI のバージョンや認証方法によって、認証、API、ドキュメント、更新チェックに使われるホストは変化する可能性があります。まず中心となる Google API のドメインを明示し、それ以外はログに現れたものだけを追加するほうが、過剰な迂回や予期しない遅延を避けられます。 

rules:
  - DOMAIN-SUFFIX,googleapis.com,GEMINI_CLI
  - DOMAIN-SUFFIX,google.com,GEMINI_CLI
  - DOMAIN-SUFFIX,generativelanguage.googleapis.com,GEMINI_CLI
  - MATCH,YOUR_DEFAULT_POLICY

上の断片は出発点であり、実際のポリシーグループ名や必要なドメインは自分の接続ログに置き換えてください。MATCH の前にルールを追加しないと、記述しても効果がありません。ルールを更新した後は、Clash の設定をリロードし、既存の接続を閉じてから Gemini CLI を再起動します。古い TCP セッションが残っていると、設定を直したのにまだ失敗しているように見えることがあります。

なお、認証用のブラウザと CLI の API 通信を必ず同じドメイン群として扱う必要はありません。ログインだけ成功し、プロンプト送信で止まる場合は、OAuth のリダイレクトとモデル API の経路を分けて観測してください。逆に認証画面へ到達できないなら、ブラウザ側のシステムプロキシ、コールバック用の localhost 通信、ターミナルの環境変数を別々に確認します。すべてを一つの万能ルールへまとめるより、フェーズごとの意図を明確にしたほうが保守しやすくなります。

TUN モード、ノード品質、ストリーミング応答を確認する

環境変数の設定が難しい WSL、Docker、GUI から起動した IDE、リモート SSH では、TUN モードが有効な Clash のほうがアプリごとの差を減らせる場合があります。TUN は OS のネットワーク層で通信を捕捉するため、CLI が HTTP_PROXY を読まなくても経路へ乗せやすいのが利点です。ただし、TUN を有効にすれば必ず直るわけではありません。管理者権限、仮想アダプター、他の VPN、DNS の奪い合いが発生するため、まず通常の mixed-port で原因を切り分けてから導入するのが安全です。

Gemini CLI のタイムアウトが特定のノードだけで発生するなら、ノード品質を疑います。短いページ取得は成功しても、モデルの応答が長く続くストリーミング通信では、パケットロス、アイドルタイムアウト、帯域制御、TLS の実装差が表面化します。自動選択グループを使っている場合は、測定 URL のレイテンシが低いノードと、長時間の HTTPS ストリームに強いノードが一致しないこともあります。固定ノードを一つ選び、同じプロンプトを短時間で再試行すると比較しやすくなります。

IPv6 が有効な環境では、CLI だけが IPv6 アドレスへ接続し、Clash のルールやノードが IPv6 を適切に処理できないことがあります。IPv4 では成功し IPv6 では失敗するなら、OS、Clash コア、TUN の IPv6 設定を個別に確認してください。また、プロキシを多段化している場合は、一時的に一つの出口へ戻します。経路を短くして成功した後、必要な構成を一段ずつ戻すのが、タイムアウトの原因を残さない進め方です。

再試行する順番

  1. Clash が起動し、選択したノードが通常のブラウザ通信で使えることを確認します。
  2. Global モードと mixed-port の明示で、Gemini CLI の最小コマンドを試します。
  3. 成功したら Rule モードへ戻し、Connections でルールと出口を確認します。
  4. 別ノード、別 DNS、必要に応じて TUN を一つずつ比較します。
  5. 最後に CLI、Node.js、Clash コア、ルールプロバイダーを更新します。

ここで重要なのは、複数の変更を同時に行わないことです。ノード変更、ルール変更、DNS 変更、CLI 更新を一度に実施すると、直ったとしてもどの操作が効いたのか分からなくなります。成功した条件を小さな表に残し、使用モード、プロキシポート、ノード名、DNS 方式、CLI のバージョンを固定してから、次の変更へ進んでください。

Gemini CLI と Clash のよくある質問

ブラウザ版 Gemini は動くのに、Gemini CLI だけ失敗します。なぜですか？

ブラウザは OS のシステムプロキシやブラウザ独自の設定を利用しますが、CLI はターミナルの環境変数や Node.js の通信設定を利用します。Clash のシステムプロキシをオンにしただけでは CLI へ継承されない場合があるため、mixed-port を確認し、失敗しているターミナルで HTTP_PROXY と HTTPS_PROXY を設定して比較してください。

TUN モードは必須ですか？

必須ではありません。通常のターミナルなら mixed-port と環境変数だけで十分なことがあります。WSL、Docker、GUI アプリ、リモート環境など、プロキシ設定が子プロセスへ届きにくい構成では TUN が有効です。ただし、TUN は仮想ネットワークや DNS の問題を増やすこともあるため、最初から有効化せず、通常モードでの結果と比較してください。

ノードを変えると一時的に直ります。設定を作り直すべきですか？

すぐに全面的な設定変更をする必要はありません。特定ノードだけで失敗するなら、ストリーミング、TLS、帯域、地域経路の品質差が考えられます。同じモードと同じルールで複数ノードを比較し、成功するノードを固定してから、url-test や fallback の測定条件を見直してください。

CLI や Clash を更新すれば解決しますか？

更新で TLS、HTTP/2、DNS、認証方式の互換性が改善する可能性はありますが、ルール誤判定やターミナルのプロキシ未設定は更新だけでは直りません。まず接続ログと環境変数を確認し、再現条件を残してから、公式のリリースノートを見ながら CLI と Clash コアを個別に更新するのが安全です。

Gemini CLI のタイムアウト対策では、専用の小さなプロキシ設定を作れるツール、ブラウザだけを対象にする VPN、手動で環境変数を毎回入力する構成では、CLI・WSL・IDE の経路が分かれやすく、原因の再現やルールの追跡に手間がかかります。Clash V.CORE なら mixed-port、Rule、TUN、DNS、接続ログを同じ運用画面で確認し、Gemini の API 通信を安定したポリシーグループへ段階的に割り当てられます。今回の切り分け結果をそのまま再利用できる環境を作りたい方は、公式のダウンロードページから Clash V.CORE を試してみてください。