2026:Clash で Google Gemini を安定利用する分流ルールと DNS(実測手順)
生成式 AI のGoogle Geminiは、ブラウザの Web 版やスマホアプリ、Workspace 連携など接続経路が複数に分かれます。IDE 向けの分流記事とは違い、ここでは一般ユーザーがブラウザと Google エコシステムで触る前提に立ち、Clash の分流ルールで Gemini 関連ホストを整理し、DNS と動作モードをどう選ぶと「つながったり切れたり」が減るかを、ログを見ながら再現できる手順でまとめます。ドメイン名はサービス更新で変わり得るため、例示は出発点とし、実測で自分の環境に合わせてください。
Gemini が不安定に見える典型パターン
まず症状を分類すると切り分けが速くなります。(1) ページは開くが応答が遅い・タイムアウト、(2) ログインや同意画面でループする、(3) モバイルアプリだけ失敗する、といった具合です。(1) は出口ノードの品質や輻輳、(2) は認証ドメインが意図せず DIRECT や別経路に流れている、(3) はシステムプロキシを読まない通信や DNS の取り違え、が起きやすいです。VPN で端末全体を一本化するとシンプルですが、国内向け通信まで遠回りになりがちです。Clash のルールモードなら、Gemini と Google アカウント周りだけを選んだプロキシグループへ寄せ、それ以外は従来どおり、という設計が可能です。
用語の前提は チュートリアルページ で押さえ、ルールの書き方は カスタムルールの解説 と併読すると理解が早いです。開発者向けに Cursor/GitHub を分けた記事(別稿)とは対象が異なり、本稿はブラウザと Google AI 製品全般にフォーカスします。
分流の土台:proxy-groups に「Gemini 用」を用意する
購読テンプレに ♻️ 自動選択 や PROXY があっても、用途別に名前の付いたグループを一つ増やしておくと運用が楽です。例として GeminiProxy という select または url-test グループを作り、rules 側では実ノード名ではなくこのグループ名を指します。ノードを差し替えてもルール本文をいじらずに済みます。ネストしたグループの型は proxy-groups のガイド も参照してください。
rules に書いた名前の綴りが一致しているかを最初に確認してください。ここがずれると「ルールを足したのに効かない」になりがちです。
ドメイン分流:Google/Gemini でよく使われるホストの考え方
Web 版 Gemini は gemini.google.com を中心に、認証では accounts.google.com、静的資産や API では *.google.com や *.gstatic.com、生成系 API では generativelanguage.googleapis.com など、実際の接続先は利用シーンで増えます。サービス側の変更でサブドメインが増えることもあるため、下記は設定の出発点として捉え、後述のログで自分の端末が向いているホスト名を正としてください。
方針として、(A) Google アカウントまわりは同じ出口に揃える(ログイン Cookie の地域ブレを減らす)、(B) 巨大すぎる DOMAIN-SUFFIX,google.com 一括は、国内向けも巻き込みやすいので、まずはログで必要なサフィックスだけに絞る、(C) うまくいかないときは RULE-SET と併用しつつ例外ルールを上に積む、が現実的です。順序の基本は カスタムルール記事 のとおり、上から先にマッチした行が優先されます。
rules:
# Examples only — tune group name (GeminiProxy) and domains to your logs
- DOMAIN-SUFFIX,gemini.google.com,GeminiProxy
- DOMAIN-SUFFIX,generativelanguage.googleapis.com,GeminiProxy
- DOMAIN-SUFFIX,accounts.google.com,GeminiProxy
- DOMAIN-SUFFIX,googleapis.com,GeminiProxy
googleapis.com は他サービスとも共有されるため、影響範囲が広がる可能性があります。問題が出たらログでホストを特定し、DOMAIN で一段狭めるか、順序を調整してください。
DNS:名前解決がボトルネックになるとき
ルールが正しくても、DNS が意図しない応答を返すと「接続できない」「証明書エラー」に見えます。Clash/Mihomo 系では dns ブロックで fake-ip や redir-host、DoH の有無などを制御しますが、購読テンプレの推奨から大きく外すと、かえって切り分けが難しくなることもあります。まずはテンプレ既定で再現する→ それでもダメなら、(1) DoH のエンドポイント、(2) nameserver-policy で Google 系だけ別 DNS、(3) IPv6 の有無、を一度に一項目ずつ試すのが安全です。
ブラウザの「DNS over HTTPS」機能と Clash 側の DNS が二重に効いて挙動が読みにくくなる場合は、ブラウザ側を一時オフにして比較する方法もあります。アプリがシステム DNS を使わない場合は、TUN モード でトラフィックをコア側に寄せる検討も有効です。
動作モード:Rule・Global・Direct の使い分け
Rule(ルールに従う)が基本です。Global は検証用に「すべてをプロキシへ」として一時的に使うと、ルール不足かノード品質かを切り分けしやすくなります。ただし常時 Global は国内サイトまで遠回りになるためおすすめしません。Direct は Clash を事実上オフに近い状態にするモードで、Baseline 計測に使います。Gemini だけ不安定なときは、まず Rule に戻し、該当ドメインが意図したグループにマッチしているかをログで確認する流れが定石です。トンネル型 VPN との違いは Clash と VPN の比較記事 も参照してください。
実測手順:ログで「宛先」と「採用ルール」を確認する
-
1
Baseline(Clash オフまたは Direct)
まず Clash を止めるか Direct で、同じブラウザから Gemini を開き、エラーや遅延が再現するかを記録します。これで「そもそもプロバイダ側・ローカル回線」の可能性も見えます。
-
2
Rule に戻し、接続ログを空読みする
クライアントの接続一覧/コアログで、Gemini 操作時にどのドメインに向かっているか、どのルール行にマッチしたか(またはポリシー名)をメモします。ここにないホストをルールに足すのが次の一手です。
-
3
ルールを一行ずつ追加して再計測
DOMAIN-SUFFIXや必要ならDOMAIN-KEYWORDを追加し、同じ操作を繰り返します。一度に大量変更すると、どの変更が効いたか分からなくなります。マッチ順が意図とずれているときは、より具体的な行を上へ移動します。 -
4
DNS クエリログがあれば併記する
名前解決結果が期待と違う場合、ルールより先に DNS を直します。クライアントが DNS ログを出せない場合は、一時的に詳細ログレベルを上げる/別ツールで確認する、など環境に合わせてください。
この繰り返しが本稿でいう「実測」です。検索で見つかるドメイン一覧は参考程度にし、自分のログが正という前提でメンテすると、2026 年以降の UI 変更にも追従しやすくなります。
よくある質問
スマホアプリだけ失敗する
アプリが独自の証明書ピン留めやプロキシ無視をしている場合、ブラウザと同じルールでも通らないことがあります。TUN モードの可否、別アカウントでのログイン、公式のネットワーク診断の有無を順に確認してください。
ルールを足したのに Global と同じように遅い
ルールが正しくても、選択中のノードの遅延・損失が大きいと体感は変わりません。別ノードや url-test の計測間隔、フォールバック先の見直しを検討してください。
職場・学校のポリシーは?
組織ネットワークではプロキシ迂回が禁止されている場合があります。技術的に可能でも、規程と情報システム部門の指示を優先してください。
まとめ
Google Gemini のような生成式 AI は、認証・フロント・API が別ホストに分かれやすく、分流ルールとDNS、そしてRule モードでのログ検証をセットで扱うと、「つながるが不安定」な状態をかなり整理できます。本稿のドメイン例は出発点であり、サービス更新に合わせてログに基づきルールを育てることが重要です。
安定したクライアントを試す場合は、パッケージの入手先として 本サイトのダウンロードページ を第一にすると、記事との対応も追いやすくなります。ルールの基礎を固めたい場合は カスタムルール完全ガイド も併せてどうぞ。