Clash で Google Gemini／AI Studio に分流：DOMAIN-SUFFIX ルールとノード選定の実測メモ（2026）

2026 年も続く Gemini／AI Studio：Clash の分流が効く理由

2026 年も、業務ドキュメントの要約、コード補助、プロトタイプ検証のために Google Gemini をブラウザで開きつつ、同じ日に AI Studio のコンソールでモデルや API キーを触る——という使い方は珍しくありません。検索やコミュニティでは「ブラウザは動くのに SDK だけ失敗する」「AI Studio が途中で止まる」「別の生成 AI は安定なのに Google 系だけ不安定」といった相談も根強く、原因の多くは単一ノードの品質だけではなく、Clash の分流（ルールで出口を変える設計）とDNS の経路が噛み合っていないことにあります。

本稿は、すでに公開している ChatGPT／Claude 向け分流ガイドや Grok・xAI 向けガイドと役割を分け、openai.com や x.ai ではなく、Google エコシステム特有のホスト（Gemini の Web UI、AI Studio、generativelanguage.googleapis.com などの API）に焦点を当てます。購読プロバイダーの巨大ルールセットに丸投げするのではなく、DOMAIN-SUFFIX で必要ドメインを明示し、用途別のプロキシグループへ振ると、長時間セッションやストリーミング応答の切れにくさが体感しやすくなります。

なぜ Gemini 向けに「独立したプロキシグループ」を作るのか

デフォルト構成では、海外サイトがまとめて一つの select や url-test に乗ることが多いです。動画視聴や一般ブラウジングと同じ出口に、Gemini のストリーム応答や AI Studio のプレビュー通信が載ると、帯域の輻輳やプロバイダー側のレート制限の影響を受けやすくなります。また Google 系は認証・静的アセット・計測・API が別ホストに分かれやすく、1 画面あたりの接続先が多いのが特徴です。

そこで GEMINI_PROXY のような名前の独立プロキシグループを切り、ルール側で関連サフィックスだけそこへ流す構成が実務では扱いやすいです。メリットは次のとおりです。(1) 一般トラフィックのノード切り替えと独立して、生成 AI だけ低遅延ノードに固定できる。(2) クライアントの接続ログを見たときに、どのホストがどの出口か追いやすい。(3) 「API だけ別地域にしたい」といった細かい運用にも展開しやすい。

コピー用：よく参照されるホスト例（Gemini／AI Studio／API）

2026 年時点で、ブラウザや SDK から頻繁に現れやすい名前として、次のような DOMAIN-SUFFIX が実務の出発点になります。サブドメイン追加や CDN の変更があり得るため、ホワイト画面やタイムアウトのときは必ず実測ログで足し引きしてください。

• Gemini の Web UI：gemini.google.com、および同画面が参照する google.com 配下の認証・リダイレクト（必要に応じて個別の DOMAIN で補強）
• AI Studio（コンソール）：aistudio.google.com、開発者向けドキュメントやプレビュー周りで ai.google.dev が絡むことがある
• Generative Language API（REST／SDK が叩くホスト）：generativelanguage.googleapis.com。CLI やサーバーサイドから叩くときはブラウザとは別経路になるため、ここを抜かすと「UI だけ動く」症状になりやすい
• 補助的に確認したいサフィックス：静的配信や OAuth チェーンで gstatic.com、googleusercontent.com、広い googleapis.com 全体を一括でプロキシに載せると他サービスまで巻き込むため、まずは上記の狭いサフィックスから始め、ログで漏れを足すのが安全

DOMAIN-KEYWORD,google のような雑な書き方は、意図しない Google サービスまで同じ出口に乗せてしまう恐れがあるため、まずは DOMAIN-SUFFIX で足りるかを検討してください。全体のルールの型はルール分岐の詳解ガイドと共通なので、あわせて読むと評価順序の理解が早いです。

評価順序：AI 用の行をどこに置くか

Clash 系の rules: は上から順に評価され、最初の一致で打ち切られます。Gemini 向けの行を末尾に追記したつもりが、すでに上段の GEOIP や巨大 RULE-SET に飲み込まれている——というパターンは珍しくありません。

実務的には、より具体的な Google AI 向け行を、大雑把な締め行より上に置きます。GUI の「ルール追加」が先頭挿入か末尾追記かで結果が変わるため、保存後は必ず順序を目視し、外部ルールプロバイダーを併用している場合は Gemini 用の明示ルールが埋もれていないか確認してください。

YAML の骨格例（概念サンプル）

実際のキー名やインデントは、利用中のコア・GUI のスキーマに合わせてください。ここでは proxy-groups に GEMINI_PROXY を用意し、rules から参照するイメージだけ示します。

proxy-groups:
  - name: GEMINI_PROXY
    type: select
    proxies:
      - 🇺🇸 低遅延
      - 🇯🇵 安定
      - 🌐 自動選択

rules:
  - DOMAIN-SUFFIX,gemini.google.com,GEMINI_PROXY
  - DOMAIN-SUFFIX,aistudio.google.com,GEMINI_PROXY
  - DOMAIN-SUFFIX,ai.google.dev,GEMINI_PROXY
  - DOMAIN-SUFFIX,generativelanguage.googleapis.com,GEMINI_PROXY

このあとに、社内ドメインや国内 GEOIP、最後に MATCH など、環境に合った一般ルールを続けます。グループ名は既存構成と衝突しないようリネームしてください。ストリーミングや長めのセッションを重視するなら、遅延よりも切断の少なさを優先してノードを選ぶと運用が楽になります。

ノード地域の選び方（実測の観点）

Google Gemini と AI Studio は、アカウントの国・利用プラン・提供機能の組み合わせで挙動差が出やすいサービスです。プロキシの出口国が期待とズレると、画面上は「利用不可」や機能制限のメッセージに見えることがあります。実務では次の観点でノードを切り替えて試すと切り分けが速いです。

• まず UI と API を分けて観測する：ブラウザは通るが curl や IDE からの SDK だけ失敗するときは、CLI 側の HTTPS_PROXY 環境変数や、TUN 未捕捉のプロセスが原因のことが多い
• 地域を固定して A/B する：同一プロバイダー内で米国・日本・シンガポールなどを切り替え、AI Studio のプレビューと API の両方で再現性を見る
• 過度に細かい GEOIP ルールとの競合：解決済み IP が別ルールに先にマッチすると、DOMAIN-SUFFIX より IP 側が優先される構成になっていないかを確認する

DNS とルールのズレ：Fake-IP・リゾルバ不一致の罠

ルールはドメイン行と IP 行が混在します。DNS が Clash の想定とずれていると、YAML は正しそうでも実接続は別経路に落ちます。Gemini／AI Studio でも、次の典型は他の生成 AI 記事と同型です。

• OS やブラウザの Secure DNS が Clash 外で先に解決し、想定外の IP が宛先になる
• Fake-IP モードと、一部アプリだけ直叩きするシステム DNS が混在し、マッチと実接続の関係が追いにくくなる
• GEOIP 行が、解決結果の国コードと噛み合わず誤直結／誤プロキシに見える

対策の方向性は「名前解決の経路をできるだけ一本化し、TUN や DNS ハイジャックを併用するならその前提でルールを読む」ことです。手順の全体像はTUN モード完全ガイドの DNS の節が参考になります。設定変更後は DNS キャッシュのクリアと、AI Studio への再接続をセットで確認してください。

検証チェックリスト（そのまま試せる順序）

1. ブラウザの開発者ツールで Gemini または AI Studio を開き、ネットワークタブに出たホスト名をメモする（想定外の *.googleapis.com や *.gstatic.com があればルールに追加候補）
2. Clash クライアントの接続ログまたはダッシュボードで、該当ホストが GEMINI_PROXY（または同等のグループ）に乗っているか確認する
3. 同じプロファイルのままノード地域だけを切り替え、UI と API の両方で挙動差があるか比較する
4. CLI から API を叩く場合は、プロキシ環境変数と TUN の有無をブラウザと揃えて再試行する

よくある誤解と切り分け

googleapis.com を丸ごと載せる

手早い反面、Google Cloud や他プロダクトのトラフィックまで同じ出口に乗り、期待しない地域表示やコスト増につながり得ます。まず generativelanguage.googleapis.com のような狭いサフィックスから始め、ログで漏れを足すほうが安全です。

ルールを足したのに効かない

多くは順序かグループ名の綴りです。存在しないグループ名を指すと、意図しないフォールバックの原因になります。外部 RULE-SET を大量に載せている場合、明示ルールが下に埋もれていないかを確認してください。

ブラウザは通るが API だけ失敗する

SDK やバッチジョブは、ブラウザとは別の DNS／プロキシ設定を持つことがあります。TUN で全体を捕捉するか、該当プロセスだけ Clash 側に乗るよう環境変数を揃える必要があるケースがあります。

まとめ

2026 年の開発・業務シーンでは、Google Gemini・AI Studio・Generative Language API を同日に触るケースが増えています。OpenAI 系や xAI 系とはドメイン設計が異なるため、既存の「AI 用ルール 1 本」だけでは抜けやすく、DOMAIN-SUFFIX で gemini.google.com、aistudio.google.com、generativelanguage.googleapis.com などを明示し、独立プロキシグループへ寄せる構成が安定しやすいです。そのうえで評価順序とDNS（Fake-IP・Secure DNS・リゾルバ経路）をセットで設計し、ノード地域は UI と API の両方で実測すると、体感のばらつきを大きく減らせます。

用語や汎用手順は当サイトのチュートリアル・ドキュメントも参照できます。オープンソースの挙動を追う用途では GitHub 上のリポジトリも有用ですが、日々のクライアント入手と更新は説明の揃った配布ページのほうが取り違えが少ないです。Clash 系はルール表現力と可観測性のバランスが取りやすく、生成 AI 利用の長期運用向きです。Windows／macOS／Linux／モバイル向けビルドはダウンロードページから環境に合わせて選べます。ルールの基礎はルール分岐の詳解、OS 全体へ透過的に効かせたい場合はTUN ガイドと併読すると、本稿の設定がすぐ実装に落ちます。単純な常時 VPN より、トラフィックを用途別に制御できる点が、多くのチームにとって実用的な体験になりやすいでしょう。→ Clash クライアントを無料でダウンロードし、Gemini／AI Studio 向け分流を試す