Gemini 3を中国から使う方法｜Clashの接続設定と分流ルール

中国から Gemini 3 を使う前に確認したいこと

Gemini 3 のページが開かない、ログイン画面から先へ進まない、モデルの読み込みが途中で止まるという場合、原因はサービス本体だけとは限りません。ブラウザの通信、Google アカウントの認証、モデル API、画像や JavaScript を配信する CDN が、それぞれ別のホストへ接続しているためです。中国本土から利用する場合は、地域・アカウント・ネットワーク・サービス提供条件が複合的に影響します。まずは利用するサービスの規約、所属組織のネットワークポリシー、現地法令を確認し、許可された環境でのみ検証してください。

本稿では、特定の制限を無条件に回避する方法ではなく、自分が管理する端末上で Clash のプロファイル、プロキシ、ルール評価を確認する手順を扱います。Clash Verge、Clash Verge Rev、Mihomo 系クライアントでは画面の名称が多少異なりますが、確認する順序はほぼ共通です。最初から TUN を有効にして複雑なルールを投入するのではなく、システムプロキシで短い疎通試験を行い、必要な場合だけ TUN や個別ルールへ進む方が失敗原因を追いやすくなります。

重要なのは、「Gemini 3 の画面が表示されること」と「実際にモデルへリクエストを送れること」を別々に考えることです。トップページだけが表示されても、ログイン用の認証ホスト、アカウント情報を確認するエンドポイント、モデル API、ストリーミング用の接続先が別経路になっていれば、チャット送信時にエラーが発生します。反対に、モデル画面が白くても、Clash の接続ログにリクエストがまったく現れないなら、ルール以前にブラウザ、DNS、システムプロキシの設定を疑うべきです。

Clash クライアントの導入と基本設定

まず、利用中のクライアントがどのコアを使っているかを確認します。Clash Verge Rev や Mihomo 系 GUI では、画面上に「Core」「Kernel」「Mihomo」などの項目があり、バージョンと実行状態を確認できます。購読 URL を追加しただけでは、プロファイルが実際に選択されていないことがあります。Profiles または設定一覧で、更新したプロファイルを選択し、エラーなく読み込まれていることを確認してください。

購読 URL には利用者を識別するトークンが含まれることがあるため、スクリーンショットやログを共有するときは必ず伏せます。見知らぬ再配布サイトから入手したクライアントや改造版は、プロキシ設定だけでなく認証情報や購読情報の漏洩リスクもあります。入手元、署名、リリース情報を確認し、端末に別の VPN、広告ブロッカー、企業用セキュリティエージェントが常駐している場合は、検証中だけ一つずつ影響を切り分けます。

次に mixed-port、HTTP ポート、SOCKS ポートの値を確認します。ブラウザに手動設定する場合は、Clash が実際に待ち受けている HTTP または mixed-port を指定します。たとえば Clash 側が 7890 で待ち受けているのに、ブラウザが 7891 を参照していれば、システムプロキシを有効にしても通信は正しく流れません。ポート番号を変更した場合は、GUI の表示、OS のプロキシ設定、ブラウザ固有のプロキシ拡張の三箇所が一致しているか確認してください。

初回は Rule モードを使い、Global モードは短時間の比較にとどめます。Global モードで成功して Rule モードで失敗するなら、ノードそのものよりルールの順序やポリシーグループが原因である可能性が高くなります。逆に両方で失敗する場合は、ノードの品質、DNS、認証状態、サービス側の提供条件を順番に調べます。

Gemini の認証・API・CDN を分けて観測する

Gemini 3 の利用で確認したい通信は、大きく四つの層に分けられます。第一はログインとアカウント確認です。Google アカウントの認証では、Gemini の画面とは異なる認証ホストやリダイレクト先が使われます。第二はモデルや会話を処理する API です。第三は画像、フォント、JavaScript、設定ファイルなどの静的アセットを配信する CDN です。第四はブラウザやアプリの更新確認、テレメトリ、地域判定に関わる補助通信です。これらを一つの巨大な許可リストにまとめるより、ログで確認したホストを役割ごとに整理する方が後から保守しやすくなります。

ルールを書くときは、検索結果で見つけた古いドメイン一覧をそのまま貼り付けないでください。サービスの構成は変わることがあり、過度に広い DOMAIN-SUFFIX は関係のない Google サービスまで同じ出口へ送る可能性があります。まず Clash の接続ログから、実際に失敗した時刻のホストを確認し、必要最小限の DOMAIN または DOMAIN-SUFFIX を追加します。機密性の高いアカウント通信では、共有プロキシの利用規約やログ保存方針も確認してください。

ルールの順序と MATCH の確認

Clash は通常、上から順にルールを評価し、最初に一致したポリシーを採用します。そのため、Gemini 関連の明示ルールを MATCH より前に置くことが基本です。先に広い広告ブロック、GEOIP、直結ルールがあると、想定したグループへ届く前に別の処理が確定します。ルールを変更した後は、プロファイルを保存するだけでなく、クライアント側で再読み込みまたは再起動を行い、古い設定が残っていないか確認します。

rules:
  - DOMAIN-SUFFIX,google.com,GEMINI_PROXY
  - DOMAIN-SUFFIX,googleapis.com,GEMINI_PROXY
  - DOMAIN-SUFFIX,gstatic.com,GEMINI_PROXY
  - MATCH,FINAL_POLICY

上の例は概念を示す最小断片であり、すべての環境にそのまま適用する完成済みリストではありません。実際のサービスで要求されるホストはアカウント種別、クライアント、地域、時期によって変わる可能性があります。接続ログで必要なホストを確認し、認証系とモデル系が異なるグループへ分かれていないかをチェックしてください。特定のホストだけ接続が繰り返し失敗する場合は、ルールを増やす前に DNS 解決結果、TLS エラー、ノードの切断履歴を比較します。

また、プロキシ経由で認証を完了した後に、別の出口へ切り替えるとセッションが無効になったように見えることがあります。短時間の検証では、ログインから最初のモデルリクエストまで同じ安定したポリシーを使い、ノードを頻繁に切り替えない方が状態を追いやすくなります。負荷分散や自動選択は便利ですが、認証とストリーミングを別ノードへ分けると、原因の判定が難しくなります。

接続確認と失敗時の切り分け手順

設定後は、いきなり長いプロンプトやファイル添付を試さず、短いテストから始めます。まずブラウザで Gemini のページを開き、静的アセットが欠落していないかを確認します。次にログインを行い、リダイレクト後に画面が戻るかを見ます。その後、短い質問を一件だけ送信し、レスポンスが最後まで表示されるか確認します。各段階で Clash のライブ接続を保存しておくと、ページ表示は成功したが API だけ失敗したケースを明確にできます。

1. プロファイル確認：アクティブな設定、コアの状態、プロキシグループの選択を確認します。
2. ポート確認：Clash の待ち受けポートと OS、ブラウザのプロキシ値を照合します。
3. DNS 確認：異なる DNS モードを一度に複数変更せず、名前解決エラーの有無をログで確認します。
4. ルール確認：対象ホストが意図したルールに一致し、MATCH や直結へ落ちていないか調べます。
5. ノード確認：同じ操作を別の安定したノードで一度だけ比較し、ノード品質と設定の問題を分けます。

ページが読み込めてもログインできない場合は、認証ホストのリダイレクト、Cookie、端末時刻、ブラウザ拡張を確認します。ログインは成功するものの回答生成だけが止まる場合は、モデル API やストリーミング接続を調べます。回答が途中で切れる場合は、ノードの短時間切断、接続タイムアウト、HTTP/2 や WebSocket に関わる中継の相性が考えられます。ただし、同じ症状が複数のネットワークや公式クライアントで発生するなら、Clash のルールを増やす前にサービス側の障害やアカウント制限を確認してください。

TUN を使う場合は、システムプロキシとの二重適用を避けます。TUN が全通信を捕捉する構成で、さらにブラウザへ手動プロキシを設定すると、ループや予期しない経路が生じることがあります。TUN の DNS 機能を使うか、OS 側の DNS を使うかも一方に決め、変更後は Clash を再起動してから同じ三段テストを繰り返します。設定を一度に何項目も変更すると、成功してもどの変更が効いたのか分からなくなるため、変更は一つずつ記録してください。

よくある質問

Gemini のトップページだけ表示されるのはなぜですか？

トップページの HTML と、ログイン・モデル・ストリーミングの通信先が異なる可能性があります。Clash のライブ接続でページ表示、ログイン、質問送信を分けて確認し、後半の操作で失敗するホストがどのポリシーに一致したかを調べてください。広いドメイン指定を追加する前に、ブラウザの Cookie と拡張機能も確認します。

Gemini 3 のために TUN は必須ですか？

必須とは限りません。ブラウザだけを使うなら、まずシステムプロキシまたはブラウザの HTTP プロキシで十分な場合があります。CLI、独自アプリ、プロキシ設定を継承しないプロセスまで同じ経路へ乗せたいときに TUN が候補になりますが、DNS や他の VPN との競合が増えるため、最後に導入するのが安全です。

ログイン画面が何度も戻るときはどうすればよいですか？

端末時刻、Cookie、認証ホストの分流、ブラウザ拡張、アカウント側の追加確認を順番に確認します。ログイン中にノードを切り替えず、同じ安定したポリシーで再試行してください。それでも解決しない場合は、Clash を無効にした許可済みネットワークや公式アプリで同じアカウントが利用できるかを確認し、アカウント問題とネットワーク問題を分けます。

ドメインルールを増やせば必ず安定しますか？

いいえ。不要なルールを増やすと、関係のない通信まで同じ出口へ集まり、速度低下や認証状態の不整合を招くことがあります。接続ログ、エラー時刻、選択されたポリシーを根拠に、必要なホストだけを追加し、設定変更の履歴を残してください。

Gemini 3 の接続だけを目的にすると、Clash for Android の簡易 VPN、ブラウザ内蔵プロキシ、古い ClashX 系クライアントでも動けば十分に見えるかもしれません。しかし、クライアントによっては TUN、DNS、ルール編集、接続ログの確認機能が限定され、ログインと API の経路差を追いにくいことがあります。Clash V.CORE なら、プロファイルとポリシーを整理しながら、システムプロキシから TUN まで段階的に検証しやすく、今回のような認証・CDN・モデル通信の切り分けにも向いています。自分の利用条件と規約を確認したうえで、必要な機能を一つの環境にまとめたい方は、Clash V.CORE をダウンロードして接続確認を始めてください。