📖 チュートリアル ⏱ 約18分で読めます

2026：Gemini CLI がタイムアウトになるとき｜Clash のドメイン分流と DNS を段階実測する（ターミナル AI）

Gemini CLIやターミナル向けの Google 製クライアントは、ブラウザ版と違って環境変数のプロキシや独自の TLS スタックの影響を受けやすく、Clash を入れているのにタイムアウト・OAuth 途中失敗・モデル一覧取得失敗だけが残る、という相談がよくあります。本稿ではGoogle Generative Language APIまわりを中心に、分流ルールの書き方とDNSの切り分けをログ主導で整理し、検索されやすい「Gemini CLI タイムアウト」「Clash DNS」「ターミナル AI」のキーワードに沿って再現手順まで落とし込みます。ドメインはサービス変更で増減するため、例は出発点として扱い、必ず自分の接続ログを正としてください。

なぜ「Clash は動いているのに CLI だけ死ぬ」のか

多くの場合、原因は単一ではありません。まずブラウザは OS のプロキシ設定や拡張に従う一方、Node.js や Python で動く CLIは HTTP_PROXY／HTTPS_PROXY／NO_PROXY の有無、あるいはプロキシを無視する実装で挙動が分かれます。さらに Google アカウントの OAuth は accounts.google.com や oauth2.googleapis.com へ数回飛ぶため、API 用ドメインだけを綺麗にプロキシへ送っても、認証だけ別経路になるとログイン画面で止まったり、同意後にコールバックが届かずタイムアウトに見えます。

加えて Google Generative Language API（generativelanguage.googleapis.com）は gRPC／HTTP のどちらで来るかもクライアント実装次第で、ログに出るホスト名がブラウザの gemini.google.com 中心の記事と完全一致しないことがあります。ブラウザ向けにまとめた Google Gemini と Clash の分流・DNS と本稿は棲み分けです。併せて チュートリアルページ で Rule モードの前提を押さえると読み進めやすくなります。

CLI でまず疑う三本柱：プロキシ環境変数・ルール順・DNS

（1）プロキシ環境変数　macOS のターミナルや IDE 統合ターミナルでは、GUI クラアントが書き込んだシステムプロキシとシェルの変数がズレていることがあります。mixed-port に合わせる、ALL_PROXY を足す、NO_PROXY に誤って google.com が入っている、などを一度洗います。

（2）ルール順と「狭い例外の上書き」　購読テンプレに GEOIP,CN,DIRECT や巨大な RULE-SET があると、Google 系の広いマッチより下の行に落ちて意図しない DIRECTになることがあります。カスタムルールの解説 のとおり、より具体的な行を上へ積むのが原則です。

（3）DNS　fake-ip と redir-host、DoH の組み合わせで証明書エラーや接続拒否に見える「名前解決の取り違え」が起きます。ブラウザ側の Secure DNS をオフにして A/B する、nameserver-policy で Google 系だけ別 resolver にする、といった一度に一変数の検証が安全です。理屈の補強は Meta／Mihomo の sniff と DNS も参照してください。

💡 ヒント OAuth フローは「人間がブラウザを開く」版と「デバイスコード」版などがあり、飛ぶホストが微妙に違います。失敗したセッションの直前直後だけログを切り取ると切り分けが速くなります。

分流ルール：ターミナル AI 向けの出発点（必ずログで調整）

以下は設定の叩き台です。GeminiCLI は proxy-groups に定義した select または url-test 名に置き換えてください。実際には googleusercontent.com や clients6.google.com、SDK が参照する別ホストが混ざるため、接続ビューに出た名前を順次足す形に育てます。

rules:
  # Examples only — replace GeminiCLI with your group name; order matters
  - DOMAIN-SUFFIX,accounts.google.com,GeminiCLI
  - DOMAIN-SUFFIX,oauth2.googleapis.com,GeminiCLI
  - DOMAIN-SUFFIX,generativelanguage.googleapis.com,GeminiCLI
  - DOMAIN-SUFFIX,gemini.google.com,GeminiCLI
  - DOMAIN-SUFFIX,gemini.google.dev,GeminiCLI
  - DOMAIN-SUFFIX,googleapis.com,GeminiCLI

DOMAIN-SUFFIX,googleapis.com は影響範囲が広いため、職場の他ツールまで同じ出口に寄せて困る場合は、まず generativelanguage.googleapis.com だけに留め、ログで不足が出たら DOMAIN 単位で追加する方が無難です。proxy-groups のネストや遅延テスト型の選び方は proxy-groups ガイド を参照してください。

⚠️ 注意 組織ポリシーでプロキシ迂回が禁止されている環境では、技術的に通しても規程違反になり得ます。許可範囲を優先してください。

DNS 実測：fake-ip と「CLI だけ別解決」問題

Clash／Mihomo 系では dns enhanced-mode を fake-ip にしている構成が多く、ブラウザがキャッシュや別経路でうまくいっているように見えるのに CLI だけ奇妙というパターンが出ます。対処の筋は、(A) テンプレ既定で再現する、(B) それでもダメなら Google 向けだけ nameserver-policy で公開 resolver に寄せる、(C) IPv6 の経路が別出口になっていないか確認する、の三段です。

Linux では systemd-resolved と競合すると名前解決だけ別皿になります。関連する整理は Linux での systemd-resolved と Clash が参考になります。Windows では「クラアントログでタイムアウト」と見えるだけで実際は上位プロキシや認証プロキシが挟まっているケースもあるため、併せて Verge Rev のログパネルでタイムアウトを切り分ける の発想を CLI に転用するとよいです。

TUN モードと証明書：CLI がプロキシを読まないとき

環境変数を設定してもツールが無視する場合、TUN でトラフィックをコア側に寄せると変化することがあります。原理と副作用は TUN モードの解説 を読んだうえで試験してください。企業がHTTPS インスペクションしている環境では、OS の信頼ストアにない独自 CA で CLI が落ち、ブラウザだけ例外設定されていることもあります。その場合はルール以前の問題です。

実測ワークフロー：ログで「宛先」「ルール」「DNS」をそろえる

  1. 1

    Baseline（Direct／Clash 停止）

    同じシェルから CLI を実行し、タイムアウトが再現するか記録します。再現しないならプロキシ経路またはルール側が本命です。再現するなら回線・ISP・IPv6・時刻ずれなど上流も疑います。

  2. 2

    環境変数とポートの整合

    http://127.0.0.1:7890 のような mixed-port と一致しているか、NO_PROXY に漏れがないか確認します。IDE から起動したタスクは親プロセスの環境が引き継がれないこともあります。

  3. 3

    Rule でホストとマッチ行をメモする

    ログイン／モデル一覧／チャット送信の各フェーズで、接続一覧に現れたホスト名と採用されたポリシーを対応付けます。ここに無い名前がボトルネックなら、そのホストをルールに追加します。

  4. 4

    OAuth と API を同じ出口に揃える

    accounts.google.com と generativelanguage.googleapis.com が別グループや DIRECT に分裂していないかを優先チェックします。分裂はサイレントな認証失敗を招きやすいです。

  5. 5

    DNS を一段ずつ変える

    DoH のエンドポイント、fake-ip のオンオフ、Google 向け nameserver-policy を単独で試します。複数を同時変更すると「何が効いたか」が追えなくなります。

この繰り返しが「実測」の本体です。検索で見つかるドメインリストは参考情報に留め、ログで増えたホストをルールに育てていく運用が、2026 年以降の SDK 変更にも耐えやすくなります。

よくある質問

ブラウザの Gemini は動くのに CLI だけタイムアウトするのはなぜ？

プロキシの読み方（環境変数・システム設定）、DNS の経路、証明書ストアの差により、ブラウザと CLI で結果が分かれます。ファイアウォールが特定実行ファイルのみブロックしている場合もあります。

OAuth ログインがループしたり中断する

認証ドメインが意図せず DIRECT または別ノードに流れている可能性が高いです。該当ホストをルール上部へ寄せ、同じ proxy-groups にそろえてください。

googleapis.com を丸ごと指定すると困る

他のクラウド API まで同じ出口になります。ログでホストを特定し、必要最小限のサフィックスだけをマッチさせる運用が現実的です。

まとめ

Gemini CLI のようなターミナル AIは、Google Generative Language API と OAuth が別々のホストへ跳ぶため、Clash 分流では認証と API を同じポリシーに揃えることが安定の鍵になります。Clash DNS は fake-ip や OS 側リゾルバとの相互作用で CLI だけ不調に見えることがあるため、ログと DNS をセットで見る癖をつけると早期収束します。

パッケージの入手とクライアント選びは ダウンロードページ を起点にすると、記事との対応も追いやすくなります。ブラウザ中心の Gemini 対策は 別稿の Gemini × Clash と役割分担してください。

一方でスイッチ一つで全体をトンネル化する従来型 VPNは設定は単純でも、どのホストが詰まっているかをユーザーに見せにくく、問題が複合しているときに出口国を総当たりするだけになりがちです。Mihomo ベースの Clash クライアントはドメイン単位でログを読みながら調整できるので、ターミナルツールのように細い経路でもルール順と DNS を論理的に詰めることができます。長期的に運用したい場合は Clash をダウンロード して、本稿のワークフローを一度なぞってからノードや購読だけを差し替えるのがおすすめです。

→ Clash を無料ダウンロードして Gemini CLI 向けの分流と DNS を試す