Gemini CLIがClashで接続タイムアウトになる理由
Gemini CLI を起動したときに、認証画面が開かない、モデル一覧を取得できない、または connection timeout と表示される場合があります。Clashをオンにしているからといって、すべての通信が自動的に正しい経路を通るとは限りません。コマンドラインツールはブラウザと異なる通信方式を使うため、ブラウザではGeminiを利用できるのに、Gemini CLIだけが失敗するケースも珍しくありません。
主な原因は、Clashの動作モード、Gemini関連ドメインのルール、DNS解決、ノードの品質、そしてCLIが参照する環境変数の不一致です。特に、システムプロキシだけを有効にしている状態では、ターミナルから直接送信されたHTTPS通信がClashを経由しないことがあります。本記事では、設定を闇雲に変更するのではなく、どの段階で通信が止まっているかを確認しながら、再現性のある切り分け方法を説明します。
この記事の目標
Gemini CLIの通信をClashで正しく捕捉し、認証、API接続、DNS、ノードのどこに問題があるかを短時間で特定できる状態を目指します。
1最初に確認する環境とエラーの種類
いきなり設定ファイルを書き換える前に、使用しているクライアントとコアを確認しましょう。Clash Verge RevなどのGUIを使っている場合は、Profilesで現在有効なプロファイルを開き、Mihomo（Clash.Meta）コアが実際に起動しているかを確認します。プロファイルを読み込んだだけで、Clashのサービスやシステムプロキシが起動していない場合もあります。
- Clashの状態： プロキシサービスが起動し、ModeがRule、Global、Directのどれになっているかを確認します。
- CLIの状態： Gemini CLIのバージョン、Node.jsなどの実行環境、ログイン済みのアカウントを確認します。
- エラーの内容： DNSエラー、TLSエラー、認証エラー、単純なタイムアウトを区別します。
- 接続先： ブラウザのGeminiとCLIのAPI通信は、同じドメインだけを使用するとは限りません。
たとえば「名前解決に失敗した」という表示ならDNSを優先して調べます。「401」や「403」であれば、プロキシ経路よりもAPIキー、ログイン状態、アカウント権限の確認が先です。一方、長時間待った後にタイムアウトする場合は、通信がDIRECTへ流れている、ノードが応答しない、またはCLIがプロキシ設定を受け取っていない可能性が高くなります。
先に切り分けるポイント
Gemini CLIのアカウント制限やAPI利用条件は、Clashの設定だけでは解決できません。認証エラーとネットワークエラーを混同しないようにしましょう。
2ClashのモードとCLIプロキシを確認する
最も多い原因は、Clashは起動しているものの、Gemini CLIの通信がプロキシへ送られていないことです。通常のブラウザはOSのシステムプロキシを自動的に利用しますが、ターミナル上のプログラムは環境変数を参照するか、独自のHTTPクライアントを使います。そのため、まずClash側のModeを一時的に Global に変更し、同じコマンドを再実行してください。
Globalモードで接続できるなら、ノードとClash本体は動作しています。次にRuleモードへ戻し、対象ドメインのルールを追加します。Globalでも失敗する場合は、ノードの応答、ポート番号、ファイアウォール、またはCLI側のプロキシ指定を調べます。
ClashのMixed Portが 7890 の場合、シェルで次の環境変数を設定してからGemini CLIを起動します。
ただし、すべてのCLIやNode.jsライブラリがこの変数を同じように扱うわけではありません。設定後も変化がない場合は、Clash Verge RevのSystem Proxyを有効にし、後述するTUNモードを試してください。プロキシを二重に設定すると挙動が不安定になることもあるため、検証時は一度に一つの方法だけを使うのが安全です。
3Gemini関連ドメインをRuleで振り分ける
Ruleモードを使う場合、Gemini CLIが接続するドメインをプロキシグループへ明示的に割り当てます。サービス構成や地域によって接続先は変わるため、ここでは代表的なドメインを例にします。実際のログで確認できたドメインを優先し、不要なキーワードルールを増やしすぎないでください。
プロファイルによっては、すでにGoogle関連のルールや外部Rule Providerが読み込まれており、上のルールが適用されない場合があります。Clashのルールは上から順番に評価されるため、広いルールより前に置くことが重要です。管理画面のConnections、Logs、Trafficなどで、対象ドメインが実際に Gemini グループへ送られているかを確認してください。
ルール設定のポイント
最初からGoogle全体をプロキシにするのではなく、ログに表示されたドメインを一つずつ追加します。Google Driveや社内サービスまで海外ノードへ送ると、速度低下やログイン確認の増加につながります。
4実際に行う切り分け手順
ここでは、Windows、macOS、Linuxで共通して使える確認手順を紹介します。設定を変更したら、必ず同じコマンドを使って結果を比較してください。複数の項目を同時に変更すると、どの操作が効果をもたらしたのか分からなくなります。
- Clashを起動し、利用可能なノードを一つ選択します。まずは自動選択ではなく、応答が安定しているノードを固定します。
- ClashのModeをGlobalに変更し、ブラウザでGoogleの関連ページが開くことを確認します。
- ターミナルでプロキシ環境変数を設定し、DNSとHTTPSの疎通を確認します。
- Ruleモードへ戻し、Clashの接続ログでGemini関連ドメインの経路を確認します。
- 最後にSystem Proxyをオフにした状態でTUNモードを有効にし、CLIを再実行します。
nslookupは成功するのにcurlが失敗する場合、DNSではなくプロキシまたはノードの問題です。逆に、プロキシ経由のcurlは成功してGemini CLIだけが失敗するなら、CLIが環境変数を無視している、証明書検証に失敗している、または別のエンドポイントを利用している可能性があります。Clashのログに通信自体が出ない場合は、CLI側からClashへ到達していません。
5DNS、TUNモード、ノード品質を改善する
ルールが正しくても、DNSが不安定だったりノードのTLS接続が途中で切れたりすると、Gemini CLIはタイムアウトします。Mihomoを使用している場合は、DNSをClashで処理する設定を検討してください。家庭内ルーターや別のDNSサービスへ任せたままにすると、名前解決だけが別経路になり、プロキシ接続との整合性が崩れることがあります。
fake-ipで特定のアプリが動かなくなる場合は、無理に固定せず、fake-ip-filterで除外対象を調整してください。DNS設定を変更した後は、OSやClashのDNSキャッシュをクリアし、古い解決結果を使っていない状態で再テストします。
System Proxyや環境変数で捕捉できない通信には、TUNモードが有効です。Clash Verge RevでTUNを有効にする場合は、管理者権限、仮想ネットワークアダプター、Auto Routeの状態を確認します。WindowsのセキュリティソフトやmacOSのネットワーク許可がTUNインターフェースを遮断していると、Clashが起動していても通信は成立しません。
TUNモードの注意
TUNは端末全体の通信を捕捉するため、国内サービスや社内ネットワークまでプロキシへ送ることがあります。作業前に既存のVPNを停止し、必要な除外ルールとDNS設定を用意してください。
それでもタイムアウトが続く場合は、ノードを変更します。低価格の共有ノードは混雑時間帯にパケットロスやTLS遅延が発生しやすく、速度テストだけでは品質を判断できません。重要なのは、短時間の下り速度よりも、複数回の接続で応答時間が安定していること、443番ポートが正常に利用できること、長いHTTPS接続が途中で切れないことです。
6よくある設定ミスと再発防止策
接続が一度直っても、プロファイル更新やOSの再起動後に再び使えなくなることがあります。原因の多くは、設定変更が一時的なものだった、選択中のプロファイルが別ファイルだった、または自動更新によってルールの順番が変わったことです。
| 症状 | 考えられる原因 | 確認する場所 |
|---|---|---|
| ログに通信が出ない | CLIがプロキシを利用していない | 環境変数、System Proxy、TUN |
| DNSエラーになる | DNSの遅延、汚染、解決経路の不一致 | Clash DNS、nslookup、DNSログ |
| 接続先がDIRECTになる | ルール不足、ルールの順番、Modeの設定 | Rules、Connections、現在のMode |
| 数分後に切断される | ノード混雑、パケットロス、接続維持の失敗 | 別ノード、ログ、長時間の疎通 |
| 401または403が表示される | 認証、APIキー、アカウント側の制限 | Gemini CLIのログイン状態と権限 |
安定運用のためには、プロファイルをバックアップし、手動で追加したルールをメモしておきましょう。サブスクリプション更新後に設定が消えた場合は、プロバイダーの設定を直接編集するのではなく、Merge設定やローカルオーバーライドを利用すると再現しやすくなります。また、問題が解決した後もGlobalモードを常用せず、Gemini関連の通信だけをRuleで振り分ける方が、不要な通信を海外へ送らず安全です。
最終チェック
ClashのMode、選択ノード、CLIのプロキシ環境変数、DNS、接続ログの5項目を記録しておくと、次回の障害でも同じ手順で復旧できます。
Gemini CLIとClashの相性問題は、単に「プロキシをオンにする」だけでは解決しません。まずCLIの通信をClashが捕捉しているかを確認し、次にルール、DNS、TUN、ノードの順で範囲を広げて調査することが重要です。接続先やアカウントの条件が変わった場合も、ログを基準に必要なルールだけを更新すれば、設定を複雑にせず安定した環境を維持できます。