Gemini 2.5 Proを中国で使う方法｜Clash接続設定ガイド

Gemini 2.5 Proに接続できないとき、最初に確認すること

Gemini 2.5 Pro を中国本土から利用していると、「ログイン画面が開かない」「認証後に元のページへ戻れない」「プロンプト送信後に接続がタイムアウトする」といった症状が一つの問題に見えがちです。しかし実際には、Google アカウントの認証、Gemini のウェブ画面、モデル API、静的ファイル配信という複数の通信が別々に発生しています。ブラウザの一部だけが読み込めても、モデルへのリクエストが別のホストで止まれば、画面には単純な「接続エラー」しか表示されません。

本稿では、Clash または Mihomo 系クライアントを使い、購読の追加、プロキシグループの選択、システムプロキシの確認、Gemini 関連ドメインのルール分けを順番に整理します。Clash Verge、Clash Verge Rev、Clash for Windows、ClashX、Clash for Android では画面名が異なりますが、考え方は共通です。まずは複雑な TUN 設定を追加せず、通常の HTTP プロキシでブラウザ接続を確認し、その後に必要な環境だけ拡張するのが安全です。

Clashに購読を追加してプロキシを選ぶ

すでに有効な購読 URL を持っている場合は、まずクライアントを起動し、Profiles、Subscriptions、または「プロファイル追加」に相当する画面を開きます。Clash Verge Rev や Clash Verge では購読 URL を貼り付けて名前を付け、更新ボタンを押すと設定が取得されます。ClashX では Config や Managed Config に近いメニュー、Clash for Android では「設定」内のプロファイル管理から追加する構成が一般的です。

取得が完了したら、プロファイルを有効化し、プロキシ一覧または Proxy Groups を確認します。最初のテストでは、負荷分散や自動選択をいきなり使わず、応答が安定しているノードを手動で一つ選んでください。自動グループは便利ですが、接続確認のたびに出口が変わるため、認証セッションや Google 側のリスク判定を比較しにくくなります。ノード名だけで判断せず、実際に数回接続して速度、TLS 接続の安定性、長時間の応答が維持されるかを見ます。

購読更新に失敗する場合は、URL の期限切れ、トークンの誤入力、提供元側のアクセス制限、DNS の名前解決失敗を順番に調べます。購読 URL がブラウザで開けるかだけでは十分ではありません。Clash のログに HTTP 403、404、TLS handshake timeout などが出ていないかを確認し、必要なら提供元へ再発行を依頼してください。取得済みの設定を直接編集しても、次回の購読更新で上書きされることがあるため、恒久的なルール追加はローカル設定やオーバーライド機能へ分けて保存します。

ブラウザとClashのプロキシ設定を一致させる

プロファイルを有効にしても Gemini が開かない場合、次に確認するのはClash が実際に待ち受けているポートと、ブラウザが参照しているポートです。多くのクライアントでは mixed-port、HTTP ポート、SOCKS ポートのいずれかが表示されます。たとえば Clash の mixed-port が 7890 なら、ブラウザまたは OS のプロキシ設定で HTTP と HTTPS の接続先を同じポートへ指定します。SOCKS5 を使う場合は、クライアント側が要求する SOCKS ポートとプロトコルを一致させてください。

Rule モードでは、ルールに一致した通信だけがプロキシへ送られ、その他は DIRECT になります。設定確認の段階で Global モードを短時間使うと、ノード自体が動作するかを切り分けやすくなります。ただし Global モードのまま長期間運用すると、国内サービスや社内システムまで不要にプロキシへ送られることがあります。ノードの疎通確認が終わったら Rule モードへ戻し、Gemini と Google アカウント関連の通信だけが意図したグループへ入る状態を作ります。

Clash のライブ接続画面を開いたまま、Gemini のページを再読み込みしてください。ブラウザのキャッシュだけで表示された場合、接続ログに新しい通信が出ないことがあります。そのため、シークレットウィンドウで開く、サイトデータを一時的に削除する、別のブラウザで比較するという順で試すと、キャッシュ問題と経路問題を分けやすくなります。ログイン画面だけが表示され、送信後に止まる場合は、認証ドメインとモデル通信のルールが一致していない可能性が高いです。

GeminiとGoogle関連ドメインをルールで分ける

Gemini の利用では、単一のドメインだけで完結するとは限りません。ウェブ画面、Google アカウントのログイン、認証リダイレクト、画像や JavaScript などの静的ファイル、モデル応答のエンドポイントが別々に現れることがあります。正確なホスト名は時期やアカウント構成、クライアントの実装によって変わるため、最初から巨大なドメインリストを追加するより、ライブ接続ログで実際に確認できたホストを基準にしてください。

ルールは上から順に評価され、最初に一致した行で出口が決まります。広い GEOIP ルール、広告ブロック、プライバシー用の拒否ルールが Gemini 関連行より上にあると、意図したプロキシグループへ到達しないことがあります。認証だけ失敗する場合は Google アカウント関連のホスト、モデル応答だけ止まる場合は Gemini や API 関連のホストというように、症状とログの時間を対応させて確認します。

Illustrative rules fragment — replace hosts with those observed in your logs

proxy-groups:
  - name: GEMINI_AI
    type: select
    proxies:
      - YOUR_STABLE_NODE
      - DIRECT

rules:
  - DOMAIN-SUFFIX,google.com,GEMINI_AI
  - DOMAIN-SUFFIX,googleapis.com,GEMINI_AI
  - DOMAIN-SUFFIX,generativelanguage.googleapis.com,GEMINI_AI
  - DOMAIN-SUFFIX,gemini.google.com,GEMINI_AI
  - MATCH,YOUR_DEFAULT_POLICY

上の断片は考え方を示す例であり、利用中のサービスに存在しないホストを無条件に追加するものではありません。購読設定が独自のルール形式を要求する場合や、プロバイダが外部ルールセットを配布している場合は、その書式を優先します。DOMAIN は完全一致、DOMAIN-SUFFIX はサブドメインを含む一致です。広すぎるサフィックスを使うと、Gemini とは無関係な Google サービスまで同じ経路へ送られるため、必要最小限から始めてください。

DNS の挙動も見落としやすいポイントです。Clash の DNS 設定、OS の DNS キャッシュ、ブラウザの Secure DNS が異なる方針を持つと、ログに期待した接続が現れなかったり、名前解決だけが遅延したりします。まずはブラウザの Secure DNS を一時的に同じ検証条件へそろえ、Clash の DNS ログにエラーがないかを確認します。設定を一度に複数変更せず、DNS、ルール、ノードの順に一項目ずつ差分を見ると、元へ戻す作業も簡単です。

ログインエラーとタイムアウトを段階的に直す

ログインページが開かない場合は、まずブラウザが Clash のポートを使っているか、システムプロキシが別 VPN や企業 PAC に上書きされていないかを確認します。ログイン画面は開くものの認証後に戻れない場合は、リダイレクト先のホストが DIRECT、拒否ルール、別の不安定なノードへ分かれていないかを調べます。Cookie を何度も削除する前に、同じ時刻の Clash ログを確認する方が有効です。

プロンプト送信後にタイムアウトする場合は、ノードの遅さだけでなく、長時間接続、ストリーミング応答、HTTP/2、MTU、接続のアイドルタイムアウトを疑います。短いプロンプトで再現し、次に長い入力やファイル添付を試すと、通信量による問題かどうかを分けられます。別ノードを一つだけ選び直し、同じブラウザ、同じアカウント、同じプロンプトで比較してください。複数の条件を同時に変えると、改善したように見えても原因が残ります。

1. Clash の接続ログを開く：エラー発生時刻の前後を切り出し、ホスト名とルール名を記録します。
2. 固定ノードで再試行する：自動選択や load-balance を止め、同じ出口で結果を比較します。
3. 認証とモデルを分けて検証する：ログインだけ、ページ表示だけ、プロンプト送信だけを個別に試します。
4. ルールの順序を確認する：拒否、GEOIP、広域サフィックス、MATCH が先に通信を奪っていないか見ます。
5. 最後に TUN を検討する：ブラウザ以外のアプリも同じ経路へ載せる必要がある場合だけ有効化します。

TUN モードは、アプリがシステムプロキシを継承しない場合に役立ちますが、管理者権限、仮想ネットワークインターフェース、DNS、他 VPN との競合が増えます。ブラウザの接続確認がまだ終わっていない段階で TUN を追加すると、問題の層が増えてしまいます。Gemini のウェブ利用だけが目的なら、まず通常のシステムプロキシで安定性を確認し、CLI や別アプリも同じ経路へ通したいときに TUN を段階的に試してください。

競合製品との比較では、ブラウザ拡張だけのプロキシはアプリごとの適用範囲が狭く、認証リダイレクトや別プロセスの通信を取りこぼしやすい一方、単純な VPN はドメイン単位のルール確認やノードの手動比較が難しいことがあります。Clash V.CORE なら、購読管理、固定ノードの選択、ライブ接続ログ、Gemini 関連ホストのルール分けを一つの流れで確認でき、原因を切り分けながら設定を育てられます。利用条件を確認したうえで、必要な機能を試したい方はダウンロードページから入手してください。