2026、Gemini を Clash で安定接続：分流ルールと DNS

なぜ Gemini／Google AI は「別スタック」としてルールを切るのか

Google Gemini やブラウザから使う Google AI Studio、さらにアプリやスクリプトから叩く Gemini API は、見た目はひとつのプロダクトでも、ネットワーク上では google.com 系の認証、googleapis.com 上の API エンドポイント、ドキュメントや開発者向けの別サブドメイン、gstatic.com などの静的配信へと役割ごとにホスト名が分かれます。Clash 利用者がつまずきやすいのは、「チャット画面は開けるのに API だけタイムアウト」「Studio は動くが別端末の CLI だけ失敗」「ログイン直後だけ別経路に落ちて挙動が変わる」といった、部分的な漏れ代理（意図せず DIRECT へ落ちること）です。

当サイトの ChatGPT・Claude 向け分流ガイドでは openai.com や anthropic.com を軸に整理していますが、Google スタックはサフィックスの集合がまったく別です。既存の「生成 AI 用」ルールセットに丸投げすると、googleapis.com の一部だけ抜ける、accounts.google.com だけ別出口になる、といった不均衡が起きやすいです。ここからは、2026 年時点で Clash 運用で押さえておきたい 典型ドメインのかたまりと、ルール順・DNS モードの観点から組み立てます。

典型ドメインのかたまり（アカウント・Studio・API・静的配信）

サービス側の変更で増減するため「完全な固定リスト」はありませんが、実務の出発点として次のような単位で頭に置くと抜けが減ります。Google アカウントと OAuth では accounts.google.com、oauth2.googleapis.com、必要に応じて www.google.com や地域別ホストが絡むことがあります。Gemini の消費者向け UI では gemini.google.com など、プロダクト名に沿ったホストが前面に出ます。

Google AI Studio（旧来の Maker Suite 系の流れを含む開発者向け UI）では aistudio.google.com が代表例で、裏側で googleapis.com や関連する管理系ホストへ接続が伸びます。Gemini API の REST／クライアントライブラリでは、多くの場合 generativelanguage.googleapis.com を中心に、Google Cloud の他 API と同様に *.googleapis.com が束として現れます。ドキュメント・開発者ポータル では ai.google.dev などが参照され、サンプル取得やリダイレクトで追加ホストが増えることも珍しくありません。

さらに 静的アセット では gstatic.com、一部の埋め込みやメディアで googleusercontent.com 系が現れることがあります。ここで重要なのは、「画面の URL バーに出ているホスト」と「API クライアントが実際に解決しているホスト」が一致しない点です。ブラウザは快適でも、ターミナル上の SDK だけが別リゾルバを踏んでいる、というパターンは DNS 節で後述します。

DOMAIN-SUFFIX,googleapis.com のように広くまとめる手もありますが、他の Google API まで同一出口に流れ、遅延や課金境界の想定外につながる場合があります。まずは generativelanguage.googleapis.com など用途別に絞り、症状が出たらログでホストを足す運用が安全です。

ルール記述の例（ポリシーグループ名は環境に合わせて置換）

次はあくまで雛形です。自環境のポリシーグループ名（例：PROXY、GOOGLE_AI）に読み替えてください。ポイントは、GEOIP や最終 MATCH より前に、Google AI 用の塊を置くことと、認証・API・静的 CDN のいずれかだけが別経路にならないようそろえることです。

# Example only — replace YOUR_PROXY_GROUP with a real policy group name
- DOMAIN-SUFFIX,gemini.google.com,YOUR_PROXY_GROUP
- DOMAIN-SUFFIX,aistudio.google.com,YOUR_PROXY_GROUP
- DOMAIN-SUFFIX,ai.google.dev,YOUR_PROXY_GROUP
- DOMAIN-SUFFIX,generativelanguage.googleapis.com,YOUR_PROXY_GROUP
- DOMAIN-SUFFIX,accounts.google.com,YOUR_PROXY_GROUP
- DOMAIN-SUFFIX,oauth2.googleapis.com,YOUR_PROXY_GROUP
- DOMAIN-SUFFIX,gstatic.com,YOUR_PROXY_GROUP

ルールタイプの優先度や GEOSITE との併用時の順序は、ルール分流の詳解記事で述べている通り、評価順を崩すと「たまに直結する」不安定さに直結します。サブスクリプション付属ルールをそのまま使う場合でも、ローカルに 追記ファイル を用意して Gemini 用の行だけを先頭寄りに載せる運用が現実的です。

ポリシーグループの割り当て（select と自動系のトレードオフ）

ドメインがどの出口に流れるかはルールで決まりますが、実際に選ばれるノード列と切り替えロジックはポリシーグループ側です。Gemini のストリーミング応答や Studio の長めのセッションでは、途中で url-test により出口が頻繁に変わると、体感として切断や再試行が増えたように見えることがあります。切り分けの第一歩としては、select で安定しているノードに固定し、再現性を確かめるのがおすすめです。

すでに「一般ブラウザ用」「OpenAI 用」などを分けているなら、Gemini／Google AI 専用のグループを新設し、ルールからはその名前だけを参照する形にすると、他ベンダの API と出口を混ぜないメリットがあります。設定を編集したあとは、ルールが参照するグループ名が実在するかを必ず確認してください。名前の綴り違いは地味ですが、症状としては「ランダムに直る／直らない」に見えがちです。

DNS：fake-ip と redir-host、名前解決の取りこぼし

Clash／mihomo 系では、enhanced-mode に fake-ip を選ぶ構成がよく使われます。fake-ip はコア側で名前と接続を対応付けしやすく、ドメインルールに確実に届けたいときの味方ですが、コアの外で先に解決してしまうアプリや OS のキャッシュがあると、実 IP へ直行し、ルールが意図通りに効かないことがあります。Gemini の CLI やコンテナ内の SDK は、このパターンが表出しやすいので、「ブラウザだけ正常」というときは DNS の経路を最優先で疑う価値があります。

一方、redir-host（実 IP を返す方向の挙動を取りやすいモード）は、ルールが IP ベースへ寄る場面とセットで理解すると整理しやすいです。ドメインルールに強く依存する構成では fake-ip 向き、一部ドメインだけ実解像が必須なケースでは fake-ip-filter で例外を切る、といった調整が現場では一般的です。国内向けサービスと Google AI を同居させる環境では、フィルタの広げ過ぎ／狭め過ぎの両方に副作用が出やすいため、症状が出たホストから順に足すのが安全です。

さらに、ルータや OS の「プライベート DNS」、ブラウザのセキュア DNS、別 VPN の DNS 強制などが重なると、どのレイヤが権威になっているかが曖昧になります。メモを取りながら一層ずつ無効化して比較すると、Gemini まわりの「不思議な不安定さ」がかなり減ることがあります。全トラフィックをコア側に寄せる設計は TUN モードの解説記事の文脈と相性がよいです。

Google AI Studio と API クライアントの切り分け

Studio が動いてローカルのスクリプトだけ失敗するときは、まず 同じマシン・同じプロファイルかを確認します。次に、ターミナルがシステムプロキシを参照しているか、環境変数 HTTP_PROXY などが空ではないか、コンテナ内で別の DNS が有効かを見ます。三つ目に、API キーや課金プロジェクトの境界（Google Cloud 側の制限）がネットワークとは独立して失敗していないかを、公式のエラーメッセージで切り分けます。

ネットワーク側に原因がある場合、Studio が aistudio.google.com 経由で済んでいる一方、API が generativelanguage.googleapis.com に直行してルールの穴に落ちる、といった ホスト単位のズレが典型です。ログに出たホスト名をそのまま DOMAIN-SUFFIX や DOMAIN に反映し、再評価すると早いです。サブスクリプションの陳腐化で新ホストだけ抜けるケースはサブスクリプション管理の記事で触れた通り、定期更新とローカル追記の併用が効きます。

切り分けチェックリスト（2026 年版）

（1）ブラウザと API／CLI で同じ出口・同じルールか。（2）DNS はどこで解決されているか（OS、ルータ、Clash、コンテナ）。（3）fake-ip-filter や redir-host の切り替えで挙動が変わるか。（4）セキュリティソフトや別 VPNが DNS やルーティングを横取りしていないか。（5）Google アカウントの所在地表示や保護フローが増えていないか（プロキシ以前の要因もゼロではありません）。

これらを順に潰すと、「AI 全般が不安定」という曖昧なラベルではなく、ドメイン抜け・DNS 取りこぼし・ポリシーグループの選択ミスといった Clash 側の修正ポイントに落とし込みやすくなります。用語と画面の対応を俯瞰したい場合はドキュメントページも参照してください。

運用上の注意（規約・提供地域・組織ポリシー）

Gemini／Google AI の提供形態、利用規約、組織アカウントのポリシーは変更が早い領域です。本稿は ネットワーク経路の切り分け に限定した技術メモであり、特定の回避を保証するものではありません。所属先の方針と適用法令を順守したうえで、ルールは必要最小限のサフィックスから始め、ログに基づいて拡張するのが安全です。

まとめ

2026 年時点で Gemini／Google AI Studio を Clash で安定させる要点は、OpenAI／Anthropic とは別の Google ドメイン設計を前提にすること、認証・API・静的 CDN を同じ出口にそろえること、そしてfake-ip と redir-host の違いを踏まえて DNS の取りこぼしを疑うことに集約されます。ベンダをまたいで比較したい場合は、兄弟記事の ChatGPT／Claude 向けガイドとあわせて読むと、ルールの置き場所の感覚が掴みやすくなります。

ルール表現の柔らかさとコミュニティの知見の豊富さから、用途に合わせて設定を磨き込める点は Clash エコシステムの強みです。クライアントの入手と各 OS 向けパッケージは本サイトのダウンロードページから確認できます。ソースコードやライセンスについては公式リポジトリも参照できますが、実行ファイルの入手はサイトの導線を優先すると説明とバージョンの対応が取りやすくなります。

Clash を無料ダウンロードして、設定を試す → 各プラットフォーム向けのビルドが揃っており、画面の案内に沿えば短時間で初期設定まで進められます。