この記事で分かること

2026 年時点で、ターミナル上の コーディングエージェント／CLIは Claude Code、OpenAI Codex、Cursor 由来のツールなどと並び、Gemini CLI（Google の生成モデルをターミナルから扱う公式系 CLI）についても検索ボリュームと導入事例が増えています。一方で現場では「ブラウザの Google AI Studio やコンソールは問題ないのに、ターミナルだけがタイムアウトする」「API キーや OAuth は通ったはずなのに途中で 認証まわりのエラーが出る」といったレポートが繰り返し現れます。

本稿は GUI クライアントとして Clash Verge Rev（Mihomo／Clash Meta 互換コアを束ねるデスクトップ向けフロントエンドの一つ）を前提に、①サブスクリプションとルール分流（Rule）で Google AI API 関連トラフィックを意図したノードへ送る、②ターミナルがプロキシを読み落とす場合に HTTPS_PROXY など環境変数で明示する、③generativelanguage.googleapis.com を中心に、ログと curl で実際に張っているホストを検証する、という三段構成で整理します。万能ドメイン一覧はプロダクト更新で変わりうるため、一度ログを取ってからルールを足す前提にします。Clash Verge Rev の基礎 UI は チュートリアル記事も参照してください。別ベンダ向けの類似トピックは Codex×Verge や Claude Code×Verge と記事構造を揃えつつ、Google 側のホスト集合が異なる点に焦点を当てます。

検索に現れやすい症状と、その背後

ユーザーが検索欄に並べがちな語（「Gemini CLI」「タイムアウト」「Google AI API」「プロキシ」「generativelanguage」）と、画面／ログの事象の対応はだいたい次のパターンに収束します。

  • 長時間待ったあと接続タイムアウト：経路が迂回できず輻輳している、SNI／HTTP2 のネゴで詰まっている、あるいはプロキシへ送るべきホストが DIRECT のまま DNS だけ迷走していると起きやすいです。
  • 成功と失敗が交互に出る（フラッピング）：複数ターミナルや IDE 統合シェルが別々の環境変数セットを読んでいる、古い Keep-Alive が旧ルートに残っている、選択ノードのヘルスが不安定、など状態が二重化しているサインです。
  • 認証は通ったのに生成だけ落ちる：oauth2.googleapis.com や accounts.google.com が意図せず国内直結または逆にプロキシ側でブロックされ、トークン刷新だけ別ルートになっているケースがあります。症状が分裂しているときはまずこの疑いを置きます。

いずれも「回線が完全断」ではなく、HTTPS クライアント実装ごとに期待するプロキシチェーンがズレていることが多いです。Electron アプリ向け分流とはクライアント層が違うため、ターミナルでは HTTPS_PROXY の比重が高まります。

ルール分流と TUN：Gemini CLI 運用での現実的な選び方

Rule（ルール分流）は、ドメインや IP 属性ごとに「どのポリシー（プロキシグループ）へ送るか」を YAML で説明できるモードです。国内決済や社内 Git を DIRECT、Google AI API・補助ドメインを PROXYと切りたいときの第一選択になります。ログ一行で「そのホストがどのルールにマッチしたか」が追えるため、開発者端末だけ細かく経路を変える運用と相性がよいです。

TUN はカーネル近傍でトラフィックをキャプチャし、プロセスがプロキシ設定を無視していても一度 Mihomo 側へ引き込める強い手段です。反面、社内 VPN やゼロトラスト製品、別 NIC とスタック競合しやすく、切り分けコストも上がります。実務的には、(1) Rule とシステムプロキシでブラウザとターミナルの両方が揃うか確認、(2) それでも特定バイナリだけ直結するなら限定的に TUN を試す、(3) 常時フル TUN は最終手段、の順が安全です。

Clash Verge Rev では「システムプロキシをセット」「TUN を開始」といったトグルが並ぶため、ブラウザだけ整備され、シェルが裸のままというズレが起きやすい点に注意してください。ターミナルアプリ再起動後に env | grep -i proxy を眺める癖が効きます。

HTTPS_PROXY ほか：ターミナルエージェントが読む場所

Go／Rust／Node 製の CLI は、参照する環境変数名が実装差分を持ちますが、実務では次のセットを揃えておくと取りこぼしが減ります。検索意図としても HTTPS_PROXY は定番キーワードなので、設定と検証をセットで覚えておく価値があります。

  • HTTPS_PROXY：TLS 付き REST／一部 gRPC ラッパがこちらを優先することが多いです。
  • HTTP_PROXY：リダイレクトや一部ライブラリの先行リクエストで参照されます。
  • ALL_PROXY：SOCKS を明示したい場合や、単一変数しか読まないツール向けの保険になります（無視される実装もあります）。
  • NO_PROXY：localhost、127.0.0.1、社内イントラのドメインをカンマ区切りで除外し、ループや中間者検査との衝突を避けます。

典型の書き場所は次のとおりです。

  • 常時：~/.zshrc／~/.bashrc。ログインシェル限定なら ~/.zprofile 等。
  • リポジトリ単位：direnv の .envrc に export HTTPS_PROXY=...。
  • 一回きりの検証：HTTPS_PROXY=http://127.0.0.1:7890 gemini ... のようにコマンド前置きでセッションを汚さない（ポートは自分の mixed-port に置き換え）。

プロキシ URL は多くの場合 http://127.0.0.1:<mixed-port> で足ります（HTTP CONNECT で TLS をトンネルするため）。SOCKS5 を明示するなら socks5://127.0.0.1:<port> ですが、社内ポリシーや DPI 環境では HTTP の方が安定することがあります。

ルールに載せたいホストの「型」（generativelanguage.googleapis.com 中心）

公開エンドポイントは変更されうるため固定リスト信仰は危険ですが、ログと公式情報で繰り返し現れるホストの型として次を押さえると、記事タイトルにある generativelanguage.googleapis.com というキーワードともつながります。

  • 生成系 REST／RPC の代表例：generativelanguage.googleapis.com。ここが DIRECT 漏れしていると、まさに「応答だけ永遠に待つ」タイムアウトが出やすいです。
  • OAuth／トークン：oauth2.googleapis.com、認可画面まわりで accounts.google.com などがログに混ざることがあります。ここが別ルートだと、一見ランダムな認証エラーに見えます。
  • 補助：www.googleapis.com や ai.google.dev 系（ドキュメント／ダウンロード誘導）が混ざる場合もあります。すべてを雑に PROXY に寄せるより、ログで実測してから足す方が安全です。
  • Vertex AI や組織ポリシー下の別エンドポイント：企業契約ではホストが増えます。一般公開記事と社内手順書を突き合わせ、想定外のリージョン URLが DIRECT に落ちていないかを見ます。

実測手順：Verge Rev のログレベルを上げ、Gemini CLI を一度動かして実際に SYN が張られたホスト名をコピーします。その文字列を DOMAIN-SUFFIX または DOMAIN ルールへ載せると、憶測で広げすぎたマッチより事故が起きにくいです。

TIP：一度だけGlobal に近いプリセット（ほぼすべてをプロキシ側へ寄せる）で CLI を叩き、タイムアウトが消えるかを見てください。消えるならルール順・MATCH より下への落下・DIRECT 漏れが本命の原因です。

ルール記述の例（ポリシー名は自分のプロファイルへ合わせる）

以下は Mihomo／Clash Meta 互換の想像上のスニペットです。PROXY は利用中のポリシーグループ名に読み替え、既存の MATCH より上へ置いてください。広めの DOMAIN-SUFFIX,googleapis.com は他の Google サービスまで巻き込むので、運用ポリシーと相談のうえ使い分けます。

# Example rules snippet — replace PROXY with your policy group name
rules:
  - DOMAIN-SUFFIX,generativelanguage.googleapis.com,PROXY
  - DOMAIN-SUFFIX,oauth2.googleapis.com,PROXY
  - DOMAIN-SUFFIX,googleapis.com,PROXY
  - DOMAIN,ai.google.dev,PROXY

GEOSITE:google のようなセットルールを既に使っている場合でも、ログで DIRECT になっているホストを個別に足すほうが早いことがあります。中国語圏ブログで見かける「AI 系をまとめて PROXY」のコピペは参考になりますが、日本の大学キャンパス網・モバイル NAT・企業プロキシでは特定サフィックスだけ劣化することがあるため、最終的にはログ準拠が安全です。

ステップ・バイ・ステップ：安定化までの現実的な順序

  1. Verge Rev でコアが稼働し mixed-port が分かっていることを確認する（プロファイルの再読み込み忘れに注意）。
  2. 同じノードでブラウザから海外サイトが開けるかを確認し、障害がターミナル限定か切り分ける。
  3. ルールでログに出た Google AI 系ホストを PROXY へ固定し、fake-ip とドメインルールの組み合わせでマッチがズレていないか見る。
  4. システムプロキシ連動をオンにしても改善しない場合、シェルに HTTPS_PROXY を載せて Gemini CLI を新しいターミナルから再起動する。
  5. curl -vI https://generativelanguage.googleapis.com などで TLS が張れるか、Clash ログでチェーンが期待どおりか確認する（403 は認証前でも起きうるので、まずはハンドシェイク完了に注目）。
  6. なお特定バイナリだけ直結するなら TUN を試すが、その前にウイルス対策ソフトや別 VPN の競合を疑う。

検証のコツ（ターミナルエージェントならでは）

「環境変数は設定したつもり」でも、GUI ターミナルがログインシェルを読まず非対話セッションとして起動していると反映されません。IDE の統合ターミナル設定に明示的に環境変数を書く必要があるケースもあります。

  • 同一ホストへ curl と Gemini CLI を並べる：どちらもタイムアウトならノード品質や経路欠損が疑わしく、片方だけならプロセス側のプロキシ解釈が疑わしいです。
  • IPv6 だけ別ルートになっていないか：-4 を付けて IPv4 限定で試すと差が出ることがあります。
  • 会社 LAN の Split DNS：社内ドメインは DIRECT、外部 API だけ PROXY の二段構成が壊れにくいです。
  • API キーと OAuth の切り替え：認証方式によって叩くホスト集合が変わります。失敗ログの URL をそのままルール候補にします。
注意：ソースコードや社内資料を外部モデルへ送る操作は、利用規約とデータガバナンスの両面でレビューが必要です。ネットワーク経路を安定させることと、機密をクラウドに出してよいかは別問題です。
ダウンロードページへ

それでも直らないとき

症状：curl は TLS まで進むが Gemini CLI だけタイムアウト

想定原因：実行バイナリが標準のプロキシ環境変数を読んでいない、別の設定でエンドポイントが固定されている、gRPC まわりが独自のポートを使っている。

対処：公式ドキュメントでプロキシ関連を再確認し、ラッパースクリプトで明示 export する。PATH 上の古いバイナリがないかも見る。

症状：PROXY に載っているのに極端に遅い

想定原因：選択ノードの輻輳、HTTP/3 フォールバック、DNS の迂回失敗。

対処：別リージョンのノードへ切替、プロファイル内 DNS を明示、TLS インタセプト製品を一時停止して比較する。

症状：TUN をオンにすると社内ツールだけ失敗

想定原因：社内 IP レンジが意図せずプロキシ側へ流れた、Split routing が崩れた。

対処：TUN を戻し、NO_PROXY と Rule の PRIVATE／GEOIP 例外を厚くする。IT ガイドラインに従う。

よくある質問

ブラウザの Google AI Studio は開けるのに Gemini CLI だけタイムアウトします。なぜですか？

参照しているプロキシ設定のレイヤが違うためです。ブラウザは OS や拡張を見る一方、ターミナルはシェル環境変数に依存します。HTTPS_PROXY を揃えても効かないときは TUN で内核側から整えるか、CLI のドキュメントを確認してください。

generativelanguage.googleapis.com だけルールに足せば十分ですか？

推論の本体はそこに寄りやすいですが、認証や補助 API で別ホストが絡むことがあります。ログで DIRECT 漏れがないかを確認し、必要なら oauth2.googleapis.com などを追加してください。

HTTPS_PROXY はどこに書けばいいですか？

常時ならシェル設定ファイル、direnv、IDE のターミナル環境変数。一時検証ならコマンド前置きの export に閉じてください。

単一ベンダ VPN との比較で見える Clash の利点

ワンタップ型の商用 VPN は初期導入が楽ですが、ドメイン単位の例外やログからの逆引きには向きにくく、開発機では「Git だけ直結できない」「社内証明書と衝突する」などの摩擦が出やすいです。対して Clash 系は本文で触れたようにルール分流とログで経路を説明できるため、Google AI API だけ別ノードのようなチューニングが現実的になります。学習コストはありますが、タイムアウトのたびにブラックボックスな再接続を繰り返すより、長期的には再現可能な YAMLとして資産化しやすいのが、ターミナルエージェント用途のメリットです。

GUI は OS に合わせて選べますが、Verge Rev はプロファイル編集とログ閲覧が一体で、Gemini CLI のような HTTPS 中心ツールと並行運用しやすいです。チームで設定を共有するときも、ルール差分をテキストで渡せる点が単一アプリ VPN に対する実務的な優位になります。

無料で Clash を入手し、ターミナル向けの分流と検証を試す →