Gemini CLIをClashで使う設定方法と安定アクセス術

Gemini CLIとClashを組み合わせる前に確認すること

Gemini CLIはターミナルから生成AIを利用できるコマンドラインツールです。ブラウザでページを開く方式とは異なり、ログイン処理、APIリクエスト、ストリーミング応答、証明書検証などがターミナル上のプロセスから実行されます。そのため、ブラウザでは正常にアクセスできるのに、Gemini CLIだけがログインエラーになったり、認証後にタイムアウトしたりすることがあります。

Clashを組み合わせる場合の基本方針は、端末全体を無条件にプロキシへ送ることではありません。Gemini CLIが実際に利用する認証・API関連のドメインをプロキシへ振り分け、ローカルネットワークや通常の国内通信は必要に応じて DIRECT に残します。こうすると、不要な通信まで遠回りさせずに、対象サービスだけを安定したノードへ送れます。

以下の設定は、Clash Verge、Clash Verge Rev、Mihomo系クライアントを想定しています。クライアントによって画面上のメニュー名は異なりますが、必要な要素は共通しています。まず有効なサブスクリプション、mihomoまたはClash Meta対応クライアント、そしてGoogleアカウントで通常のログインができる環境を準備してください。

• Clashの状態を確認する。ノードが表示され、テスト通信が成功していることを確認します。ノード一覧が空の場合は、先にプロファイルを導入してください。
• カーネルを確認する。「設定」や「バージョン情報」で、mihomo、Clash Metaなどのカーネル名を確認します。古い無印Clashでは一部の新しい設定項目が利用できない場合があります。
• ログイン方式を把握する。Gemini CLIのログインはブラウザ認証を伴うことがあるため、ターミナルだけでなく、認証画面を開くブラウザの通信も確認します。
• システム時刻を合わせる。OAuthやTLS証明書は端末時刻の影響を受けます。時刻が数分以上ずれていると、正しいノードを選んでも認証に失敗することがあります。

Gemini CLIの通信先とプロキシ方式を整理する

Gemini CLIの通信は、1つのドメインだけで完結するとは限りません。ログイン画面を開く認証ドメイン、認証後にトークンを交換するエンドポイント、モデルへのAPIリクエストを送るサービス、ストリーミング応答を維持する接続がそれぞれ別のホスト名になる場合があります。バージョンやログイン方式によって通信先が変わるため、最初から少数のドメインだけを決め打ちするより、Clashの接続ログを見ながら補う方が確実です。

一般的にはGoogleの認証関連ドメインやGemini API関連のドメインが登場します。例えば accounts.google.com、oauth2.googleapis.com、generativelanguage.googleapis.com などです。ただし、これらをすべて無条件にプロキシへ送る必要があるとは限りません。組織アカウント、Vertex AI、APIキー方式、ブラウザOAuth方式では利用先が変わるため、実際のログに表示されたホスト名を優先してください。

ブラウザだけをClashのプロキシ対象にしても、ターミナルのGemini CLIが同じ経路を使うとは限りません。逆に、システムプロキシを有効にしただけでCLIまで必ず対応するとも言えません。Node.jsなどの実行環境、CLIが使用するHTTPライブラリ、環境変数の読み込み方によって挙動が異なります。そのため、まずはClashのシステムプロキシ、必要に応じてTUNモード、最後にCLI側のプロキシ設定という順で確認します。

Clashにプロファイルを追加して基本動作を確認する

最初にClashへプロファイルを追加します。プロファイルはサブスクリプションから取得した設定ファイルで、ノード、プロキシグループ、ルール、DNSなどをまとめて管理するものです。Gemini CLI専用に新しいノードを作る必要はありませんが、AIサービス用のグループを分けておくと、通常のウェブ閲覧と切り離してノードを選択できます。

1. Clashクライアントの「Profiles」または「プロファイル」画面を開きます。
2. サブスクリプションURLを入力し、プロファイルをダウンロードします。URLの末尾が欠けていないか、余分な空白が入っていないか確認してください。
3. 取得したプロファイルを選択して有効化し、プロキシ一覧にノードが表示されることを確認します。
4. 「Proxies」画面で、応答時間だけでなく接続の安定性も確認します。Gemini CLIは短いページ表示だけでなく、生成結果を数十秒以上受信する場合があります。
5. まず「Global」または対象グループの手動選択で安定したノードを選び、ブラウザから認証ページとAPI利用ページが開くことを確認します。

自動選択グループを使う場合は、単純な遅延値だけで判断しないことが重要です。URLテストが数秒で終わっても、長時間のTLS接続やストリーミング応答で切断されるノードがあります。複数のノードで短いCLIリクエストを試し、ログに再接続や502、504、TLS handshake timeoutが頻繁に出ないものを優先してください。

AIサービス用グループを分ける方法

既存の設定を直接大きく書き換えるのが不安な場合は、プロファイルのプロキシグループにAI用のセレクトグループを追加します。実際のノード名はサブスクリプションによって異なるため、下の例では分かりやすい仮名を使っています。存在しないノード名をそのまま貼り付けるとプロファイルが読み込めないので、手元の名前へ置き換えてください。

proxy-groups:
  - name: AI-SERVICE
    type: select
    proxies:
      - US-A
      - SG-A
      - AUTO
      - DIRECT

rules:
  - DOMAIN-SUFFIX,googleapis.com,AI-SERVICE
  - DOMAIN-SUFFIX,google.com,AI-SERVICE
  - MATCH,PROXY

この例では、Google関連の広いドメインをAI-SERVICEへ送っています。実運用では広すぎる指定が他のGoogleサービスまで対象にする可能性があるため、Clashのログを見ながら必要なルールだけに絞ってください。既存プロファイルにすでに GEOSITE やルールプロバイダーがある場合は、同じ対象が先にマッチしていないかも確認します。

Gemini CLI向けの分割ルールを設定する

Clashのルールは上から順番に評価され、最初に一致した行で処理が止まります。したがって、Gemini CLI用のルールは一般的な GEOIP、GEOSITE、MATCH より前に配置する必要があります。後ろに追加しただけでは、先にある包括的なルールが通信を DIRECT や別のプロキシグループへ送ってしまい、追加したルールが使われないことがあります。

まずはドメイン単位のルールを使います。DOMAIN-SUFFIX は指定したドメインとそのサブドメインに一致するため、関連エンドポイントをまとめて扱う場合に便利です。一方、DOMAIN-KEYWORD は文字列を含むだけで一致し、意図しないホストまで対象にする危険があります。Geminiという単語だけを指定するような書き方は避けてください。

proxy-groups:
  - name: AI-SERVICE
    type: select
    proxies:
      - US-A
      - SG-A
      - AUTO

rules:
  - DOMAIN,accounts.google.com,AI-SERVICE
  - DOMAIN,oauth2.googleapis.com,AI-SERVICE
  - DOMAIN-SUFFIX,generativelanguage.googleapis.com,AI-SERVICE
  - DOMAIN-SUFFIX,googleapis.com,AI-SERVICE
  - MATCH,PROXY

上の例は構造を示すための最小構成です。プロファイルの既存ルールに DOMAIN-SUFFIX,google.com,DIRECT のような行がある場合は、AI用ルールをその前に置きます。また、サービス提供者が独自のAPIエンドポイントを利用している場合は、CLIの接続ログに現れたホスト名を個別に追加します。認証ページだけが開かないなら認証ドメイン、ログイン後の生成だけが失敗するならAPIドメインを重点的に見ます。

ルール編集後は必ずプロファイルを保存して再読み込みし、Clashの設定検証でエラーがないことを確認します。YAMLではインデントに半角スペースを使い、タブ文字を混在させないでください。策略グループ名に日本語を使うこと自体は可能ですが、既存ルールとの参照名が一致しないとエラーになるため、最初は英数字とハイフンの名前が扱いやすいでしょう。

DNS、TUN、環境変数を確認する

ドメインルールを追加しても、DNS解決がClashの外で行われていると、接続先の判定や名前解決で失敗することがあります。特にTUNを使わずシステムプロキシだけを有効にしている環境では、ターミナルアプリがシステムプロキシを認識しても、DNS問い合わせはOSの設定へ直接送る場合があります。

mihomo系クライアントで端末全体を扱う場合は、まずTUNを有効にする方法があります。Windowsではサービスモードや管理者権限、macOSではネットワーク拡張やVPN構成の許可が必要になることがあります。設定を変更した後に通信できなくなった場合は、TUNを一度無効にして原因を切り分け、システムプロキシ方式で再確認してください。

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - https://dns.example.invalid/dns-query
  proxy-server-nameserver:
    - 223.5.5.5
  fallback:
    - tls://1.1.1.1:853
  fallback-filter:
    geoip: true
    geoip-code: CN

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53
    - tcp://any:53

上のDNSアドレスは説明用の値を含むため、実際の環境では利用可能なアップストリームへ置き換えてください。特に dns.example.invalid は実在しない予約ドメインです。そのまま貼り付けるとDNS解決に失敗します。DNS設定を変更する場合は、既存のプロファイルにある nameserver、fallback、proxy-server-nameserver の役割を確認し、同じキーを重複させないようにします。

また、Gemini CLIが環境変数のHTTPプロキシを利用できる実装であれば、CLI起動前に HTTP_PROXY、HTTPS_PROXY、ALL_PROXY の設定を確認できます。Clashの混合ポートが 7890 の場合の例は次の通りです。ポート番号はクライアントの「ポート」画面に表示される実値へ置き換えてください。

# macOS / Linux
export HTTPS_PROXY=http://127.0.0.1:7890
export HTTP_PROXY=http://127.0.0.1:7890
export ALL_PROXY=socks5://127.0.0.1:7891

# Windows PowerShell
$env:HTTPS_PROXY="http://127.0.0.1:7890"
$env:HTTP_PROXY="http://127.0.0.1:7890"
$env:ALL_PROXY="socks5://127.0.0.1:7891"

ログイン、API呼び出し、タイムアウトを順番に検証する

設定が完成したら、いきなり複雑なプロジェクトで試すのではなく、認証、簡単な問い合わせ、長めの応答という3段階で確認します。各段階でClashの接続ログを保存しておくと、どこで失敗したかを切り分けやすくなります。

1. ClashでAI-SERVICEに安定したノードを手動選択し、システムプロキシまたはTUNを有効にします。
2. ブラウザでGoogleの認証画面を開き、ページが最後まで読み込まれることを確認します。認証画面だけを開く場合でも、Clashのログに通信が表示されるか確認してください。
3. Gemini CLIのログインコマンドを実行し、ブラウザが開いた場合は同じClash経路で認証を完了します。別のブラウザプロファイルや別VPNが動作していないかも確認します。
4. ログイン後、短いプロンプトで1回だけ生成を実行します。ここでAPIドメインがログに現れ、応答が完了することを確認します。
5. 最後に、複数行の回答やストリーミング出力を試します。途中で切断される場合は、ノードを変更して同じ操作を比較します。

「ログインエラー」という表示だけでは原因を特定できません。HTTPの401や403なら認証情報、アカウント権限、API設定の問題を疑います。429なら利用制限やレート制限の可能性があり、Clashのノードを変更しても解決しないことがあります。502、503、504、connection reset、TLS handshake timeoutなら、ノード、経路、DNS、長時間接続の安定性を確認します。

DNSを確認するには、ターミナルで nslookup generativelanguage.googleapis.com または macOS・Linuxの dig generativelanguage.googleapis.com を実行します。ClashのDNSログに同じ問い合わせが現れるか、返されたアドレスがルール判定に影響していないかを見ます。fake-ipを利用している場合は、端末側で 198.18.x.x のアドレスが見えることがありますが、これはClashが内部で割り当てる偽IPであり、実際のAPIサーバーのアドレスではありません。

最後に、Clashを終了して直接接続へ戻した状態でも同じエラーが出るかを比較します。直接接続だけ失敗し、Clash経由で成功するなら経路やDNSが原因である可能性が高くなります。どちらでも同じ401や429が出る場合は、Clashではなくアカウント、APIキー、利用枠、CLIのバージョンを確認すべきです。設定を広げ続ける前に、成功したノード、時刻、エラーコード、接続ログのホスト名を記録しておくと、次回の再現と修正が容易になります。

安定運用のためのノード選択と設定管理

Gemini CLIを継続的に使うなら、毎回グローバルモードへ切り替えるより、AI-SERVICEグループを作って対象通信だけを管理する方が安全です。通常のブラウザ閲覧や社内ネットワーク、プリンター、ローカル開発サーバーまでプロキシへ送ると、遅延や名前解決の問題が増えるためです。ローカルアドレスは既存設定に従って DIRECT とし、AI関連の通信だけを明示的にグループへ送ります。

ノードを選ぶときは、表示されるping値だけで判断しないでください。Gemini CLIでは、認証画面の読み込み、トークン交換、API応答の受信が別々の接続として発生することがあります。次の3項目を同じノードで確認すると、実際の使いやすさを判断できます。

• 初期接続。認証ページやAPIエンドポイントへのTLS接続が短時間で完了するか確認します。
• 連続通信。長い生成結果を受信している途中で接続が切れないか確認します。
• 再接続。一度CLIを終了して再実行したとき、毎回同じドメインが同じ策略グループへ入るか確認します。

サブスクリプション更新後にノード名が変わった場合は、固定したプロキシ名が存在しなくなることがあります。AI-SERVICEの参照先を更新し、プロファイル検証を実行してください。設定のバックアップには、認証情報やサブスクリプションURLを含めず、ルールとグループの構造だけを保存します。

Clashやmihomo、Gemini CLIを更新した直後は、設定項目の互換性とログ形式が変わる可能性があります。更新前に現在のプロファイルを複製し、変更後は認証、短い生成、長い生成の順で再テストしてください。問題が発生したときに一度にカーネル、ノード、DNS、ルールをすべて変更すると、原因が分からなくなります。1項目ずつ変更し、成功した状態を残すことが安定運用の近道です。