なぜターミナルの Gemini CLI は途切れやすいのか

2026 年現在、エディタ統合やローカル実行の ターミナル向け AI / CLI は一層日常的になっています。Google 側の Gemini CLI（名称やパッケージはアップデートで変わり得ますが、ここでは OAuth と長めの HTTPS セッションを張るコマンドラインツール全般を指します）を使う場面では、応答途中の切断、再試行ループ、認証まわりのタイムアウトといった「不安定さ」がバランスよく報告されます。

原因は単純な回線速度だけに帰められません。HTTP/2 や多重化されたストリーム、長時間キープアライブされるコネクション、地域とリージョンによる出口の差、さらに DNS の分断（ブラウザとターミナルで別リゾルバ） が重なると、GUI アプリではそこそこ通るのに CLI だけ失敗率が跳ねる、というパターンが出ます。また Go や Rust 製の CLI は システムプロキシ設定を読まずに直接ソケットを開く実装が散見されるため、ブラウザ用に整えた「システムプロキシだけ」の構成がターミナルに伝わらないことがあります。

Clash Verge Rev は Mihomo（旧 Clash Meta） をコアに載せたデスクトップ GUI で、ルール分流・TUN（仮想 NIC）・DNS（fake-ip など）を一つの設定言語にまとめられます。本稿の狙いは、感覚的な「たまに切れる」を、再現手順とログで説明できる状態に落とし込み、運用力を上げることです。前提操作の骨格は Clash Verge Rev 設定ガイドと接続してください。

以下の手順は特定の VPN ベンダーや購読 URL に依存しません。ルールに書く PROXY や 节点选择 などのプロキシグループ名は、あなたの購読 YAML に合わせて読み替えてください。

ステップ 1：症状を時刻・コマンド・エラー文で記録する

まずは観測です。いつ、どのサブコマンドで、どの HTTP ステータスや DNS エラーが出たかをメモアプリに残し、同じPCのブラウザで同一サービスにアクセスした場合の差分も一行書いておきます。CLI だけ悪いなら、プロキシ非適用や DNS 分断、長めのコネクション欠損を疑うのが筋です。

切り分けのコツは 「再現のボタン」を減らすことです。同時に動いている別 VPN、社内透明プロキシ、コンテナネットワーク、別ターミナルタブで固定されている古い HTTP_PROXY など、経路を二重化する要素がないかを一覧にします。この段階で数字が揃うと、以降の八段階が一気に速くなります。

ステップ 2：Rule モードと購読プロファイルを確認する

Clash Verge Rev のモードは Rule を既定にします。続けて Subscriptions がフェッチ済みで、Profiles で意図したプロファイルがアクティブかを確認します。Proxies 画面で遅延テストを走らせ、選択中ノードが過去のログと矛盾しない応答であることを見ます。

ここで Global に頼りっぱなしにすると、国内サイトまで遠回りして遅延が増えたり、逆に Direct 指定のアプリまで巻き込むリスクが出ます。Gemini CLI の安定化は「海外 API だけを的確に迂回し、それ以外は静かに直結する」ことが長期的に健全です。

ステップ 3：Google / Gemini 向けホストをルールで PROXY へ流す

ルールは Clash の強みです。購読に標準で入っているルールセットが強力なら追記は最小で構いませんが、CLI 特有のホストが抜けていると、断続的に直結へ落ちて不安定に見えます。Profiles → Override → タイプ Merge で、次のような追記をイメージしてください（グループ名は必ず自分の環境に合わせる）。

rules:
  - DOMAIN-SUFFIX,googleapis.com,PROXY
  - DOMAIN-SUFFIX,google.com,PROXY
  - DOMAIN-KEYWORD,generativelanguage,PROXY

実運用では OAuth のドメインや認可エンドポイントが増えるため、コアのログに出た実ホスト名をログベースで追記するのがもっとも確実です。ルールは増えすぎると評価コストが上がるので、DOMAIN-SUFFIX でまとめられるところはまとめ、細かい例外だけ DOMAIN で切る、と整理すると保守しやすいです。

同サイトの設定ガイドでは rules: と rule-providers の扱いを深掘りしています。コミュニティのルールセットを足す場合も、ライセンスと更新頻度を README で確認してください。

ステップ 4：TUN を有効化してターミナル全体を載せる

Settings から TUN をオンにします。管理者権限や macOS のパスワード要求が出たら、説明を読んだうえで許可します。スタックはまず Mixed から試し、UDP 系や特定アプリで挙動がおかしい場合は System 側へ寄せるのが一般的です。

TUN は「システムから見える経路にコアを挟む」方式なので、システムプロキシを読まない実装でもトラフィックを観察しやすくなります。その代わり、選択ノードの品質が悪いと全体が不安定に見える課金効果もあります。先に Proxies で十分な応答であることを確認してから有効化すると安全です。

企業端末では仮想アダプタのポリシーでブロックされることがあります。その場合は運用者と調整するか、HTTP プロキシだけに寄せる設計へ戻す判断が必要です。

ステップ 5：DNS を fake-ip などで一元化する

DNS が二系統だと「名前解決はうまくいくが実接続は別経路」みたいな非直観的な挙動が出ます。dns.enable と enhanced-mode を Clash 側で整え、fake-ip を選ぶのは応答速度と制御性のバランスが取りやすい定番です。設定後は必ず Reload を実行し、ブラウザのセキュア DNS や OS の追加リゾルバが競合していないかも見ます。

設定断片のイメージは次のとおりです（リゾルバの具体値はポリシーと遅延に合わせて差し替えてください）。

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.0/15
  nameserver:
    - https://dns.cloudflare.com/dns-query
  fallback:
    - https://dns.google/dns-query

外部ツールで確認するなら、まず browserleaks.com/dns などを使い、続けてターミナルから対象ゾーンへの dig や DoH が期待どおりかを見ると解像度が上がります。

ステップ 6：HTTP_PROXY とターミナル環境を揃える

TUN でも 一部ツールは明示的なプロキシ環境変数を要求します。シェルに http_proxy / https_proxy / all_proxy が入っているか、スペルや大小文字の差で読み違えていないかを確認し、必要なら ~/.zshrc などへ追記します。変更後は ターミナル全体を再起動して古いセッションを掃除します。

CLI がサブコマンドでプロキシ無効化フラグを持っている場合、ドキュメントでデフォルトを確認してください。エディタ統合ターミナルは親プロセスから環境変数が継承されないことがあるので、統合シェルでも env | rg -i proxy のように実値を一度見る習慣があると早いです。

ステップ 7：curl と Core ログで経路を検証する

推論ツールを動かす前に、まず curl でエンドポイント到達性を素で確認します。TLS 失敗と HTTP 403 / 429 の切り分けがつくので、原因がプロキシ経路なのか資格情報なのかを分けられます。Clash Verge Rev のログで、同時刻に RESET や特定の規則一致が増えていないかも見ます。

検証の心がけは 同一コマンドを 3 回連続叩いてばらつきを見ることです。一発成功は偶然であり、連続成功が出て初めて「経路は固まった」と言えます。ログの保存期間が短い場合は、その場でスクショやテキストに吐き出しておくと後追いが楽です。

ステップ 8：ノードと混雑帯を調整する

API 越しの CLI はレイテンシのムラに敏感です。URL-TEST 系の自動選択に任せる、または手動で地理的に近い安定エントリに寄せる、といった調整をします。夜間や週末にだけ悪化するなら、帯域混雑や提供側のレート制限を疑い、リトライバックオフを挟む運用とセットで考えると現実的です。

ノードを変えるたびに、上記の curl 連続試験を短く再走させて「改善した／変わらない」を記録してください。変更を一度に積み上げないのがポイントで、ルール・TUN・DNS・環境変数・ノードのどれが効いたかを後から説明できるようにします。

よくある質問

システムプロキシだけでは Gemini CLI が安定しません。TUN は必要ですか？

ブラウザは追随しやすい一方で、ターミナルツールや Go/Rust 製 CLI はシステムプロキシを迂回することがあります。途切れが CLI 特有なら TUN で OS 全体の経路を載せるのが効きやすいです。まずは Rule と DNS を整えたうえで TUN を段階的に入れるのが安全です。

どのドメインをルールに書けばよいですか？

Google OAuth や API の出口は構成やリージョンで変わるため、ログに出たホスト名を基準に DOMAIN-SUFFIX を積むのが確実です。generativelanguage.googleapis.com や googleapis.com など代表的な suffix は多くの環境で効きますが、最終的には自分の接続ログで欠けがないか確認してください。

ルールと TUN を入れても CLI が直結しているように見えます

別ターミナルセッションに古い環境変数が残っていないか、VPN やセキュリティソフトがルートを握っていないかを確認します。DNS リーク検査で ISP リゾルバが残る場合も、実際の通信経路が期待とズレていることがあり、fake-ip と Reload のあとにもう一度 curl で切り分けてください。

TUN を付けると全体が不安定に見えます

いったん TUN をオフにしてシステムプロキシだけへ戻し、問題がノード品質なのかスタック設定なのかを分けます。スタック変更とサービス再インストール（管理者権限）の順で試すと改善することがあります。

まとめ：ブラウザ単体ツールとの違いと Clash の強み

ワンタップ型の商用 VPN は手軽ですが、ドメイン単位の細かな分流や ローカル DNS の統制を CLI 開発フローに合わせて調整しづらいことがあります。ブラウザ専用拡張に寄せる案もありますが、エディタ・言語サーバ・各種 SDK が別ポートを開く場面では対象が外れがちです。

一方で Clash 系は、ルール・TUN・DNS をひと続きの YAML にまとめられるので、ターミナル AI CLI のように長く張る接続を含む開発環境全体へ同じ原則を適用しやすいです。メンテが止まった古いクライアントを抱えるより、コアと GUI が継続更新されているフォークを選ぶほうが、安全面でも長期運用でも有利になりやすい、というのが実務的な整理です。

Gemini CLI のように外部 API に強く依存するツールほど、海外出口と DNS の一貫性が効きます。本稿の手順はその「一貫性」を、ログで説明できる形に分解したものです。

Clash を無料でダウンロードし、快適なプロキシ環境を試す →