ブラウザ版 Gemini と違う「CLI が壊れる」理由

ブラウザは macOS／Windows が提示するシステムプロキシを尊重しやすく、ウィンドウ内のログインにも同じ経路が乗りがちです。一方、ターミナルから実行する CLI は、親シェルの環境変数、コンテナ／WSL／リモート SSH、CI などコンテキストが分かれた瞬間にプロキシ設定が継承されないことがあります。ここへ Clash が TUN で内核側から覆う場合と、単に mixed-port へ環境変数で向けるだけの場合では、結果がまったく違います。

Gemini 向けの公式・準公式ツールでも、モデル応答より前にデバイスフローやコード取得のような OAuth の往復が挟まれるため、体感はすべて「総タイムアウト」のように読めます。ログに出ているホスト名を層ごとに分類したうえで、同じ名前空間を同じポリシーグループに固定できているかどうかを最初に確認してください。サービス側の恒久障害を疑うより先に、この切り分けの方が安いことが多く、開発者チームでの再現ログ共有にも適しています。

ℹ 観測のコツ：問題が出ているターミナルから、失敗タイミングだけの短いウィンドウを切ります。Clash のライブ接続に SNI と選択ポリシーが並ぶ環境では、generativelanguage.googleapis.com のような名前が単独で落ちているのか、oauth2.googleapis.com と交互に赤字になるのかをメモすると、OAuth と API と CDN のどれが経路だけ割れているかがはっきりします。

ターミナルが踏むレイヤー：OAuth・API・静的 CDN・ドキュメント

実運用でのまとめどころとしては、(1) ログイン／トークン——accounts.google.com／oauth2.googleapis.com など。(2) モデルと Generative AI API——多くが *.googleapis.com、代表例として generativelanguage.googleapis.com やプロジェクト構成によっては他の Google Cloud API と共有されることがあります。(3) 静的コンテンツ——gstatic.com や証明書連鎖に関係するオブジェクト。(4) オンボード用のヘルプや開発者コンソールへの誘導ならgoogle.dev／cloud.google.com も混ざります。

「API だけ タイムアウト」は、(1)(2)(3) のどれかが別出口にいて TLS または中間タイムアウトで止まっている典型です。DOMAIN-SUFFIX,googleapis.com だけ広く書いて、(1)(3) を直結または別ノードへ誤送信していると、(2) が通ってもセットアップは途中で諦めることになります。逆も然りです。レイヤごとに ひとつの安定した出口を割り当て、必要なら DOMAIN 行で微調整するのが読みやすいです。

YAML での概念的な束ね方（例）

ポリシー名は自分の構成に置き換えてください。この断片はあくまで出発点で、リストの丸写しは推奨しません。増えた名前はログで足します。

Illustrative rules fragment — verify against your logs

rules:
  - DOMAIN-SUFFIX,accounts.google.com,GOOGLE_CLI_STABLE
  - DOMAIN-SUFFIX,oauth2.googleapis.com,GOOGLE_CLI_STABLE
  - DOMAIN-SUFFIX,googleapis.com,GOOGLE_CLI_STABLE
  - DOMAIN-SUFFIX,gstatic.com,GOOGLE_CLI_STABLE
  - DOMAIN-SUFFIX,googleusercontent.com,GOOGLE_CLI_STABLE
  - DOMAIN-SUFFIX,google.dev,GOOGLE_CLI_STABLE
  - DOMAIN-SUFFIX,google.com,GOOGLE_CLI_STABLE
  - MATCH,YOUR_FALLBACK_POLICY

DOMAIN-SUFFIX,google.com は検索まで巻き込む広さになり得るため、「CLI だけ切り離したい」なら開始時は DOMAIN 中心にしてから徐々に拡張する方が安全です。リストの並べ替えと更新の運用モデルは ルール分流のベストプラクティス を参照してください。許可されていないサービスへの迂回には使わないでください。

DOMAIN-SUFFIX とルール順：MATCH より上で揃える

Clash は一行目から順に評価し、最初に当たった行で出口が決まります。広告ブロック用のリストや GEOIP が Google 系名前を先に片付けていたり、広すぎる拒否リストが CDN を止めていたりすると、ブラウザは別経路／別プロファイルで結果だけ見えている状態になります。開発者ツール向けブロックセットを入れているプロファイルほど、この誤遮蔽を疑う価値があります。

「昨日まで CLI が動いた」なら、(a) ルールプロバイダの自動更新で順序や中身が変わった、(b) 更新取得自体がプロキシループで詰まり古いリストのまま、(c) サブスク更新後にノード品質だけが劣化——の三通りを順に見ます。購読とノード保守 と タイムアウトと TLS の読み方 をセットにすると復旧が早いです。

システムプロキシ／TUN／HTTPS_PROXY の取りこぼし

開発者環境では、ブラウザ用に Clash のシステムプロキシをオンにしている一方、ターミナルだけ ALL_PROXY を設定していなかった、コンテナだけ別ブリッジにいる——といったパターンが珍しくありません。WSL／Docker とホスト側で出口がずれるときは Docker／ターミナル向け記事 の構成と突き合わせ、すべてのプロセスが同じ Clash アップストリームに到達できるかを確認してください。

TUN はPOSIX 環境への注入漏れを減らす一方、企業 VPN やホスト側の複数 NIC と競合することがあります。TUN の深掘り を読み、「システムプロキシへの切り替えでだけ直る」のか、「TUN 必須なのか」を短時間で A/B します。両方オンにすると二重転送になりがちです。

DNS・fake-ip が原因の「名前は返るが止まる」

fake-ip を使っていると、アプリ側には合成アドレスが返り実解決は後段になります。このとき DOMAIN 規則と DNS が同じ順序論理で並んでいない と、名前解決は一瞬でも TCP が進まず API タイムアウト にしか見えません。CLI はキャッシュレイヤも薄いので、ブラウザほどユーザー操作で誤魔化せず、開発者視点ではログに残るだけで原因が単純化します。

社内ネットワークで分割 DNS を使っていると、公開向けとは別のアドレスに誘導され、ログインのみ失敗することがあります。IT の案内がある場合は順守しつつ、「家のクリーンな回線では再現しない」だけでも切り分け材料になります。一般的な確認手順は FAQ も読んでください。

Gemini／Google AI Studio のブラウザ向け記事 と対象レイヤは重なるものの、本稿はターミナルでの OAuth 連鎖と CLI のプロキシ継承 を主問題にしています。Gemini のネイティブ Mac クライアント記事 は Electron 系のアプリ話であり、名前空間は似ていても証明書ピンや子プロセスの挙動は完全一致ではありません。Cursor ログイン問題の記事 と同じように「開発者 UX のタイムアウト」でも、ベンダーが Google でも Microsoft でもログに並ぶホストが違う以上、単純な丸写しは通用しません。読者には自分が触っている名前空間の記事だけを読み、残りは辞書として参照するのが安全です。

⚠ コンプライアンス：サービス規約や法的制限、アクセス許可されていない環境での利用を前提にした迂回は説明対象ではありません。職場のセキュリティ方針に従ってください。

許可環境でのチェックリスト

  1. この CLI と Clash で Google に接続することが契約およびポリシー上許されているか確認した。
  2. 失敗ウィンドウの接続ログから、oauth・googleapis・gstatic に分類してホスト名を列挙した。
  3. そのホストたちが広域ブロックリストより上の行へ載っていることを確認した。
  4. ブラウザとターミナルでHTTPS_PROXY／TUN／システムプロキシの差を A/B した。
  5. fake-ip 利用時は nameserver と DOMAIN 規則の整合を読み直した。
  6. 購読とルール更新がループせず成功することをログで確認した。
  7. 問題が残るときだけノード総入れ替えやベンダーダウン確認に進んだ。

メモだけで済まず、設定ファイルの変更点を短文で書き添えると数日後の自分が助かります。チーム展開するときにも同様です。

よくある質問

簡単な質疑を並べました。FAQPage の構造化データは <head> にあります。

ブラウザの Gemini は動くのに CLI だけ止まりますがなぜですか。

ブラウザはシステムプロキシや拡張の経路を使い CLI は環境変数やカーネル捕捉に依存することが多く、googleapis と OAuth および静的 CDN が別出口に割れると片方だけタイムアウトに見えます。

OAuth の画面は出るがデバイス認証後に進みません。

oauth2.googleapis.com と accounts.google.com などトークン交換の名前空間が広いブロックリストや GEOIP で別ポリシーに落ちている可能性があります。順序と命中ログを確認します。

generativelanguage.googleapis.com はどう扱えばよいですか。

DOMAIN-SUFFIX,googleapis.com で束ねられることが多く、増えた API 名前にも追従しやすいです。適用範囲が広すぎると感じたらログに基づき DOMAIN で絞ってください。

gstatic.com を DIRECT にしたほうが速いですか。

地域や ISP で差があります。OAuth ウィンドウ内の読み込みだけ止まるなら CDN も API と同じ出口へ寄せ、証明書と DNS の整合を優先すると再現しにくいことが多いです。

まとめ

Gemini あるいは Google AI に接続する Gemini CLI／ターミナルツール は、単一ホストとの会話というより複数名前空間の連鎖です。MATCH まで届いているか、OAuth と API と CDN が同じ出口か、DNS がルール設計と同じ視点か——この三通りを押さえると、その他の複雑な設定より先に体感が変わります。2026 年も Google のエンドポイントは増減しますが、そのたびに黒箱の単一プリセットよりも自分のログを読んで足すモデルのほうが持続します。

黒ひつずの単一チャネルより、出口とログが追えるモデルの方が、チームのオンボードコストも下がります。一方で「どこへでも自動で張るだけ」のベンダーラッパーやクローズ志向のクライアントは名前空間の追加が不透明で、開発者側が観測できないときに時間を溶かします。Clash はドメインベースとルールプロバイダで増分更新しやすく、自分で選んだ上流が怪しいときも差し替えられます。この透明性があるからこそ許可環境でのセルフサービスにも向きます。

Clash V.CORE はこの設計語彙に沿って UI とログを並べられるため、「CLI のどのフェーズが詰まっているか」を短いセッションで切り分けやすく、再現のない総タイムアウトとの喧嘩時間を削れます。Clash を無料ダウンロードし、自分のワークステーションだけで検証するところから始めてください。OAuth の往復だけが別経路だった、というような発見はすぐログに現れます。