Gemini CLI が「ずっと待つ」のはなぜか

2026 年、ターミナルから動かす無料の AI エージェントとして Gemini CLI（@google/gemini-cli）の利用が広がっています。npm install -g @google/gemini-cli で入れて gemini を起動した直後から、OAuth ログインの途中で止まる、API Key の検証が返ってこない、プロンプト送信後に ETIMEDOUT や UNAVAILABLE が出る——こうした相談が開発者コミュニティで増えています。原因の多くは単一ノードの「弱さ」だけではなく、ターミナルプロキシがブラウザと別経路のまま残っていること、そして Clash の分流ルールが Google API 向けホストを拾えていないことにあります。

本稿は、ブラウザ中心の Gemini／AI Studio 向け分流や、企業コンソール寄りの Gemini Enterprise 向け分流と役割を分け、CLI から見た認証チェーンと API 呼び出しに焦点を当てます。ホスト名は Google 側のアップデートで増減し得るため、最終判断は公式ドキュメントと、ご自身の環境で Clash が記録した実ホストを優先してください。

注意：本稿はネットワーク設定の出発点であり、Google の利用規約、API Key の取り扱い、勤務先のセキュリティ方針を代替するものではありません。社内ガイドがある場合はそちらを優先してください。

症状の切り分け：どの段階で止まるか

Gemini CLI タイムアウトは、表面上同じ「待ち続ける」でもフェーズごとに必要なホストが異なります。大まかには次の四つに分けられます。

npm 取得段階：npm install -g @google/gemini-cli 自体が ETIMEDOUT や ECONNRESET で止まる。対象は registry.npmjs.org や tarball ホストで、npm 向け分流記事の領域です。
OAuth 認証段階：gemini auth login でブラウザは開くのに、ターミナル側が「Waiting for authentication…」のまま進まない。accounts.google.com、oauth2.googleapis.com などが絡みます。
API Key 検証段階：環境変数や設定ファイルの Key を読み込んだ直後に失敗する。generativelanguage.googleapis.com への軽い REST 呼び出しが典型です。
モデル実行段階：会話やツール呼び出し中にだけ遅延・切断が出る。ストリーミング応答や長めの TLS セッションで出口の安定性が問われます。

どの段階かを先に特定すると、Clash 分流 Google API のルールを足す位置と、端末 AI プロキシ（環境変数か TUN か）の優先順位がはっきりします。

AI Studio 記事・Enterprise 記事との違い

AI Studio 向け記事では gemini.google.com や aistudio.google.com など Web UI 向けホストを主に扱いました。Enterprise 向けは console.cloud.google.com や Vertex AI 系の束が中心です。これに対し Gemini CLI は Node.js 上で動き、Generative Language API（代表例 generativelanguage.googleapis.com）へ REST で往復しつつ、初回は Google アカウント OAuth のトークン交換も行います。

そのため「ブラウザで Gemini のページは開けるのに CLI だけ失敗する」「npm は通ったのに gemini 実行時だけ API が落ちる」というギャップが出やすいのが CLI 固有の論点です。Web UI 用ルールだけ複製しても、oauth2.googleapis.com 行が欠けていると認証段階で再現が続きます。

npm インストール：先にパッケージ取得を安定させる

本体取得が不安定なまま認証を疑うと時間を浪費します。グローバルインストールは registry.npmjs.org 上の @google/gemini-cli メタデータと tarball 取得に依存します。社内ミラーや国内レジストリだけ通して npm install は成功するが、実行時 API だけ失敗する——というパターンも、ホストが分離しているだけです。

Clash では DOMAIN-SUFFIX,registry.npmjs.org,NPM_REGISTRY のように npm 専用グループを切り、詳細は npm タイムアウト向け記事を参照してください。インストールが完了したら、同じターミナルセッションで gemini --version まで通ることを確認してから認証・API の切り分けに進むと混乱が少ないです。

Google API 側でよく登場するホスト

公式ドキュメントとコミュニティのトラブルシュートを踏まえると、Gemini CLI 利用中に Clash 接続一覧で確認したい代表例は次のとおりです（環境により増減します）。

generativelanguage.googleapis.com — Generative Language API の本体。モデル一覧・推論の中心。
googleapis.com — 上記を含む広いサフィックス。初期のたたき台に使われがちです。
accounts.google.com — Google アカウント OAuth の入口。
oauth2.googleapis.com — トークン交換・更新。
www.googleapis.com — 一部クライアントライブラリやメタデータ取得。
ai.google.dev — ドキュメントや開発者向けリダイレクトが絡む場合あり。

運用初期は DOMAIN-SUFFIX,googleapis.com,GEMINI_API のように束ね、ログに新しいサブドメインが出たら行を足すサイクルが安全です。サフィックスを広げすぎると、無関係な Google トラフィックまで同じ出口に載り、遅延診断が曖昧になる点には注意してください。

プロキシグループ：OAuth と API を同じ出口へ

実務では GEMINI_API のようなラベルで、OAuth チェーンと API 呼び出しを同じ候補ノード群へ載せます。認証だけ別地域・API だけ別地域に割くと、トークンは取れたのに推論だけ失敗する、といった不整合が起きやすいからです。url-test で定期遅延テストする運用にすると、出口劣化に気づきやすくなります。

ストリーミング応答や長めの HTTPS セッションでは、HTTP/2 互換性や中継装置のバッファリングで CLI だけ遅延する事例も報告されています。出口を地域 A/B し、可能なら HTTP/1.1 フォールバックや別プロトコル互換モードを社内規程の範囲で試す価値があります。

ルール評価順：GEOIP に飲み込まれない

分流ルールは YAML 上では上から順に評価され、最初の一致で終わります。ファイル末尾に Google 行を追記したつもりが、上段の GEOIP や巨大 RULE-SET に先にマッチしている——これは Gemini CLI Clash 設定でも典型です。設計の共通枠組みはルール分岐の詳解と同じく、具体的な DOMAIN 行を締めより上へ置くことです。

YAML の骨格例（サンプル）

キーやインデントは利用中のコアと GUI のスキーマに合わせてください。概念だけ示します。

proxy-groups:
  - name: GEMINI_API
    type: select
    proxies:
      - 🇺🇸 低遅延
      - 🇯🇵 低遅延
      - 🌐 自動選択

rules:
  - DOMAIN-SUFFIX,generativelanguage.googleapis.com,GEMINI_API
  - DOMAIN-SUFFIX,oauth2.googleapis.com,GEMINI_API
  - DOMAIN-SUFFIX,accounts.google.com,GEMINI_API
  - DOMAIN-SUFFIX,googleapis.com,GEMINI_API

実際には接続ログに出た名前を追記します。npm 用と GEMINI_API 用でグループを分けておくと、「インストールは速いが実行だけ遅い」といった切り分けがしやすくなります。

端末 AI プロキシ：環境変数が効く理由

多くの OS でブラウザは「システムプロキシ設定」を参照しますが、Unix 系シェルで動く Gemini CLI は、起動した Node プロセスが HTTP_PROXY／HTTPS_PROXY／ALL_PROXY を読むかどうかに依存します。Clash Verge 系でシステムプロキシをオンにしても、ターミナルに変数が注入されていなければ、CLI はプロキシを知らないまま直結を試み、Google API への TLS ハンドシェイクでタイムアウトします。

対策の基本は、(1) Clash の mixed ポート（例: 7890）を http://127.0.0.1:7890 形式で HTTPS_PROXY に設定する、(2) ローカルホストや社内イントラを誤ってプロキシに送らないよう NO_PROXY を整える、(3) 設定後に同じシェルから gemini を起動し直す、の三点です。

ヒント：同じシェルで curl -I --proxy "$HTTPS_PROXY" https://generativelanguage.googleapis.com を試すと、CLI が使う経路と Clash 分流の整合を短時間で確認できます。証明書エラーが出る場合は社内 SSL インスペクションの影響も疑ってください。

TUN とシステムプロキシ：CLI まで含めて揃える

TUN モードは OS より下のレイヤでトラフィックを取り込み、プロセスごとの環境変数差をまとめやすい反面、他 VPN やルーティングと競合しやすいです。一方 システムプロキシ＋環境変数は、アプリごとの挙動差が残ります。ブラウザの OAuth 画面だけ直すのか、gemini プロセスまで含めて揃えるのかで最適解が変わります。詳細は TUN モード完全ガイドやブラウザのみ通る場合の整理を併読してください。

Windows では WSL 内で gemini を動かしホスト側だけ Clash が有効、macOS では IDE 統合ターミナルに HTTP_PROXY が引き継がれない、といった「コンテキスト限定」の再現も珍しくありません。症状が閉じる範囲に合わせて、そのシェルへ変数を足すか TUN を検討してください。

DNS・Fake-IP：名前解決をルールと矛盾させない

DNS が Clash の想定とズレていると、YAML のドメイン行は正しそうでも実接続は別経路に落ちます。ブラウザだけ Secure DNS、CLI は OS のリゾルバ——といった二重構成は開発者端末でよく見られます。Fake-IP を使うプロファイルでは、ドメインルールと IP ルールの境界が頭の中で一本化されていないと、「ダッシュボード上はマッチしたのに体感が違う」状態になりやすいです。

構成変更のあとは DNS キャッシュのクリアと Gemini CLI プロセスの再起動をセットで行うと再現率が下がります。geosite／geoip の更新手順は手動更新ガイドも参照してください。

ノード選定：地域と長接続の相性

Google API は地域ポリシーやレイテンシで挙動が変わることがあり、Gemini CLI の無料枠でも出口の geograf によっては認証は通るが推論だけ不安定、という報告があります。同一プロファイル内で GEMINI_API グループだけ別地域に切り替えて A/B すると、ルールミスとノード劣化の切り分けが速くなります。

UDP 依存が少ない REST 中心とはいえ、DNS や QUIC まわりで出口と相性が悪いノードもあります。接続一覧で generativelanguage.googleapis.com が意図したグループ・ノードに載っているかを、プロンプト送信のタイミングで必ず確認する習慣をつけてください。

実務フロー（接続一覧を味方にする）

npm install -g @google/gemini-cli が完了していることを確認し、gemini auth login または API Key 設定、通常のプロンプト送信を再現しながら Clash の接続ログで実ホスト名をメモする。
GEMINI_API など用途別の proxy-groups を定義し、generativelanguage.googleapis.com、oauth2.googleapis.com、accounts.google.com などを DOMAIN／DOMAIN-SUFFIX 行で、そのグループへ必ず流れる位置に書く。
ターミナルに HTTPS_PROXY=http://127.0.0.1:7890（実際の mixed ポートに置換）を設定し、同一シェルで gemini を再起動して再試行する。混在経路を直したいときは TUN も検討する。
依然としてタイムアウトする場合は、GEMINI_API の出口地域 A/B、npm 用ルールとの取り違え、DNS とルール評価順を順に疑う。
安定したらルールをコメント付きで整理し、チームや将来の自分が読める形に残す。

よくある質問

OAuth だけが終わらない

ブラウザで Google ログインは完了したのにターミナルが待ち続ける場合、oauth2.googleapis.com へのコールバック経路が 端末プロキシ未設定のまま直結しているケースが多いです。分流ルールと HTTPS_PROXY の両方を点検してください。

ルールを足したのに挙動が変わらない

評価順序かDNSです。外部 RULE-SET より上に具体的な Google 行があるか、Fake-IP とリゾルバが矛盾していないかを確認します。

API Key モードだけ失敗する

OAuth を経由しない構成では generativelanguage.googleapis.com 行が最重要です。Key 自体の権限エラーとネットワークタイムアウトはメッセージが似るため、curl で同一 Key を使った最小リクエストと Clash ログを突き合わせてください。

まとめ

2026 年の開発現場では、Gemini CLI のような端末 AI エージェントが Google API へ頻繁に接続する一方で、ブラウザ向け設定だけではターミナルプロキシが空振りしやすいのが現実です。Clash で 分流ルールを書き、npm 取得・OAuth・Generative Language API をログに沿って束ね、HTTP_PROXY 系の環境変数と TUN／システムプロキシ、DNS とルール順、出口ノードをセットで揃えると、「認証も API もずっと待つ」症状の切り分けがかなり速くなります。

一方、ワンクリック型の汎用 VPN や常時プロキシツールは手軽ですが、registry.npmjs.org と googleapis.com のように用途の異なるホストへ並列アクセスする CLI トラフィックを、出口ごとに読みながら調整する細かさには欠けがちです。設定がブラックボックスになり、Gemini CLI タイムアウト時に「どのドメインがどこへ出たか」を自分で説明しにくいこともあります。Clash 公式サイト は Clash／Mihomo 系クライアントの入手とドキュメントを一か所に揃え、ルールと接続ログを見ながらチューニングできる流れを重視しています。ターミナルから Gemini を安定させたい場合は、手順を追いやすいダウンロードページから環境に合うクライアントを選び、本文のチェックリストと合わせて試してみてください。