Gemini CLIが使えない？Clashの接続タイムアウト対策ガイド

Gemini CLIが起動するのに応答しない、またはリクエスト中に「タイムアウト」と表示される場合、原因はGemini側の障害だけとは限りません。Clashのシステムプロキシ・TUNモード・分流ルール・DNS・プロキシグループのどこかに問題があると、ブラウザでは接続できてもCLIだけが失敗することがあります。特にGemini CLIはターミナルからHTTPS接続を行うため、GUIアプリとは異なる環境変数や名前解決の影響を受けます。この記事では、ノードの疎通確認からClashのルール修正、TUNとDNSの調整、最終的なCLI側の確認まで、原因を一つずつ切り分ける実践手順を解説します。

まずタイムアウトの原因を切り分ける

最初から設定ファイルを大きく変更するのは避けてください。タイムアウトには、ノード自体が利用できないケース、Clashが通信を傍受していないケース、Gemini関連ドメインが誤ってDIRECTに送られているケース、DNS解決だけが失敗しているケースがあります。原因によって修正箇所がまったく異なるため、簡単なテストから順番に確認するのが安全です。

1. Clashのダッシュボードで現在のプロキシグループと選択中のノードを確認する。
2. 同じノードで一般的なHTTPSサイトを開き、ノードそのものの接続性をテストする。
3. ターミナルからGemini関連ホストの名前解決とHTTPS接続を確認する。
4. Clashの接続ログで、Gemini CLIの通信が表示されるか確認する。
5. 通信が表示された場合は、適用されたルールと使用された策略グループを調べる。

Clashのダッシュボードに接続がまったく表示されない場合、CLIはClashを経由していません。一方、接続は表示されるもののタイムアウトする場合は、ルール、ノード、TLS、DNSのいずれかに絞り込めます。ノードの遅延テストが成功していても、これは特定URLへの短いHTTPテストに過ぎません。Gemini APIや関連サービスへの実際の接続が成功することを保証するものではありません。

ノードとプロキシグループを確認する

最初に確認すべきなのは、Clashが実際に使っているプロキシノードです。複数の設定ファイルやサブスクリプションを読み込んでいる場合、表示上はノードが存在していても、対象のプロキシグループが別の古いノードを選択していることがあります。ダッシュボードの「Proxies」ページで、Gemini CLIが参照するグループを確認し、利用可能なノードへ手動で変更してください。

ノードの比較では、単純なping値だけを見ないことが大切です。pingはICMPまたは簡単なHTTPリクエストの応答時間であり、TLSハンドシェイク、長時間接続、ストリーミング応答の品質までは測定できません。次のような項目を比較すると、実際のCLI利用に近い判断ができます。

• HTTP遅延：テストURLへの接続時間。極端に高い場合はまず候補から外します。
• 接続の安定性：数回のテストで成功と失敗が頻繁に入れ替わらないか確認します。
• TCPまたはTLS接続：443番ポートへの接続が途中で切断されないかを確認します。
• 長時間通信：レスポンスを受信中に接続が切れないかを確認します。
• UDP依存の有無：通常のGemini CLIのHTTPS通信では、まず安定したTCP経路を優先します。

接続テスト用に、ターミナルから以下のようなコマンドを実行できます。URLやAPIエンドポイントは利用しているCLIのバージョンによって異なるため、ここではTLS接続とプロキシ経由の動作を確認する目的で使用します。

# DNS解決を確認
nslookup generativelanguage.googleapis.com

# HTTPSの詳細な接続を確認
curl -I -v --connect-timeout 15 https://generativelanguage.googleapis.com

# HTTPプロキシを明示して接続
curl -I -v --proxy http://127.0.0.1:7890 --connect-timeout 15 https://generativelanguage.googleapis.com

Clashの混合ポートが7890以外の場合は、実際のポート番号に置き換えてください。1つ目のコマンドだけが失敗するならDNSの問題、1つ目は成功して3つ目だけが失敗するならClashのポート、ノード、またはプロキシ経路の問題である可能性が高くなります。

分流ルールとGeminiドメインを修正する

Gemini CLIのタイムアウトで特に多いのが、関連ドメインが誤ってDIRECTへ送られているケースです。ルールファイルの上部にある地域別ルールや一般的なGoogleルールが先にマッチすると、後から追加したPROXYルールは評価されません。Clashのルールは通常、上から下へ評価され、最初に一致したルールが適用されます。

まずダッシュボードの接続一覧を開き、対象接続の「Rule」「Rule Source」「Proxy」などの項目を確認してください。Gemini関連通信がDIRECT、REJECT、または意図しないグループになっている場合は、専用ルールを一般ルールより前に置きます。サービスによって利用ドメインは異なりますが、代表的な候補は次のとおりです。

• generativelanguage.googleapis.com：Gemini APIの主要エンドポイント。
• ai.google.dev：Google AI for Developers関連ページ。
• accounts.google.com：ログインや認証に使用される場合があります。
• googleapis.com：API関連の補助ドメインを含む可能性があります。
• gstatic.com：認証や静的リソースの一部で参照される場合があります。

すべてのGoogle通信を無条件にプロキシするのではなく、必要なドメインを確認しながら追加してください。業務ネットワークや組織のポリシーで許可された通信だけを対象にすることも重要です。

rules:
  - DOMAIN, generativelanguage.googleapis.com, Gemini
  - DOMAIN-SUFFIX, ai.google.dev, Gemini
  - DOMAIN-SUFFIX, googleapis.com, Gemini
  - DOMAIN-SUFFIX, accounts.google.com, Gemini
  - MATCH,Final

上の例では、Geminiという名前のプロキシグループがあらかじめ存在している必要があります。実際の設定では、グループ名を自分の設定に合わせて変更してください。また、YAMLではインデントが意味を持つため、タブ文字を使わず、スペースで揃えることを推奨します。設定を保存した後は、Clashの設定検証機能またはダッシュボードのリロード機能で構文エラーがないか確認します。

TUNモードとCLIのプロキシ環境変数

ブラウザはClashに接続できるのにGemini CLIだけがタイムアウトする場合、CLIがシステムプロキシを利用していない可能性があります。Clashのシステムプロキシ設定は、すべてのコマンドラインアプリに適用されるとは限りません。アプリが独自のネットワークライブラリを使っている場合、システム設定を無視することもあります。

この場合は、ClashのTUNモードを有効にしてOSレベルで通信を捕捉する方法と、CLIが参照するプロキシ環境変数を設定する方法を比較します。TUNモードはアプリ側の対応状況に左右されにくい一方、仮想インターフェース、ルート、DNS、管理者権限が関係するため、設定を慎重に行う必要があります。

一時的に環境変数を設定してテストする場合は、次のようにします。ポート番号はClashの混合ポートに合わせてください。

# macOS / Linux
export HTTP_PROXY=http://127.0.0.1:7890
export HTTPS_PROXY=http://127.0.0.1:7890
export ALL_PROXY=http://127.0.0.1:7890

# 設定を確認
env | grep -i proxy

# Windows PowerShell
$env:HTTP_PROXY="http://127.0.0.1:7890"
$env:HTTPS_PROXY="http://127.0.0.1:7890"
$env:ALL_PROXY="http://127.0.0.1:7890"

プロキシを使わないテストを行う場合は、これらの環境変数を一時的に削除してください。以前設定した無効なポートや古いプロキシアドレスが残っていると、Clashを起動していてもCLIは別の接続先へアクセスしてしまいます。なお、CLIや使用しているSDKが環境変数をサポートしているかは公式ドキュメントでも確認してください。

TUNモードを使う場合は、ClashのTUN設定で自動ルートとDNSハイジャックを確認します。別のVPN、仮想マシン、Docker、セキュリティソフトも仮想ネットワークを作成していると、ルート競合が発生することがあります。最初は他のVPNを停止し、Clashだけを有効にした状態でテストすると切り分けやすくなります。

DNSとTLSタイムアウトを調整する

ドメイン名が解決できない、または誤ったIPアドレスへ解決されると、CLIは接続開始前に停止します。ClashではDNSモードとしてredir-hostとfake-ipがよく使われます。Gemini CLIのようにドメインベースの分流を重視する場合、fake-ipはルール適用を安定させやすい選択肢です。ただし、すでに別のDNSサービスやVPNがDNSを奪っていると、期待どおりに動作しません。

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - https://1.1.1.1/dns-query
    - https://8.8.8.8/dns-query
  fallback:
    - tls://1.1.1.1:853
    - tls://8.8.8.8:853

rules:
  - DOMAIN,generativelanguage.googleapis.com,Gemini
  - MATCH,Final

DNSを変更した後は、既存のキャッシュが残っている可能性があります。ClashのDNSキャッシュ、OSのDNSキャッシュ、CLIプロセスを順番に再起動してください。fake-ipの範囲をLANやDockerで実際に使用しているネットワークと重複させると、到達不能やループが発生するため、既存のプライベートネットワークと重ならない範囲を選びます。

TLSエラーと単純なタイムアウトは別の問題です。証明書検証を無効にするskip-cert-verify: trueは、原因の確認用としても常用すべきではありません。システム時刻が大きくずれている、古いCA証明書を使っている、HTTPS検査ソフトが証明書を置き換えている場合は、TLSハンドシェイクが失敗します。まずOSの日時を自動同期し、ClashとCLIを最新版に近い安定版へ更新し、証明書エラーの内容をログで確認してください。

ログで最終確認する

設定を変更したら、推測ではなくClashのログで結果を確認します。Gemini CLIを実行する直前にログ表示を開き、次の4点を見てください。

• 宛先ホスト名が期待したGemini関連ドメインになっているか。
• 適用ルールが専用のプロキシルールになっているか。
• 使用されたノードとプロキシグループが意図したものか。
• 接続がDNS、TCP、TLS、レスポンス受信のどの段階で止まっているか。

ログに接続があり、ノードへの接続後に長時間停止する場合は、ノード側の経路や対象サービスとの相性を疑います。別の地域のノードへ切り替え、同じコマンドを再実行してください。ログにdial tcp、i/o timeout、context deadline exceededなどが表示される場合は、到達性または応答待ち時間の問題です。lookupやno such hostならDNS、x509なら証明書または時刻の確認が優先されます。

複数の変更を同時に行うと、どの変更が効果を持ったのか分からなくなります。おすすめの順番は、ノードを固定する、Geminiドメインを専用グループへ送る、環境変数またはTUNを確認する、DNSキャッシュを消去する、最後に別ノードで比較する、という流れです。復旧した後は、不要なルールや一時的な環境変数を整理し、設定ファイルをバックアップしておきましょう。

よくある質問

ブラウザではGeminiが使えるのにCLIだけ失敗するのはなぜですか？

ブラウザはシステムプロキシや拡張機能を利用していても、CLIはそれらを無視して直接接続している可能性があります。Clashの接続ログを開きながらCLIを実行し、通信が表示されるか確認してください。表示されない場合は、TUNモードまたはHTTP_PROXY、HTTPS_PROXYなどの環境変数を検討します。

ノードを変えてもタイムアウトが解消しません。次に何を確認すべきですか？

すべてのノードで同じ症状が出るなら、ノードよりも分流ルール、DNS、プロキシポート、TUNルートの可能性が高いです。特に対象ドメインがDIRECTへ送られていないか、CLIが127.0.0.1の正しいポートを参照しているかを確認してください。

TUNモードを有効にすれば必ず解決しますか？

必ず解決するわけではありません。TUNはプロキシ非対応アプリの通信を捕捉するのに有効ですが、VPNや仮想ネットワークとの競合、DNSハイジャックの不整合を増やすこともあります。まず明示的なプロキシ環境変数で動作を確認し、それで不足する場合にTUNを有効化すると原因を追いやすくなります。

skip-cert-verifyを有効にしても問題ありませんか？

証明書検証を無効にすると、通信の安全性を低下させます。タイムアウト対策として常用せず、時刻、CA証明書、HTTPS検査ソフト、ノードのTLS設定を先に確認してください。検証用に変更した場合も、テスト終了後は必ず元に戻します。

Gemini CLIの接続タイムアウトは、ノードを何度も切り替えるだけでは解決しないことがあります。Clashのログで実際の通信経路を確認し、ルール、プロキシ環境変数、TUN、DNSを一つずつ検証すれば、問題の位置をかなり正確に特定できます。設定を整理して安定した経路を作った後は、Clashを通常の開発ツールの一部として安心して利用できるようになります。