2026年、ClashでGeminiとGoogle AI Studioを分流する：Googleドメイン・ルールと接続失敗の切り分け

なぜGemini／AI Studioだけ分流を切り出すのか

Googleのサービスはドメインが広く、購読ルールでは「google.com 系はこのポリシー」といった 粗い束ね方 になりがちです。一般の検索やWorkspaceと同じ出口でも動くことはありますが、生成AI利用では次のようなズレが出やすくなります。第一に、ブラウザのタブ はシステムプロキシや拡張の影響で通っていても、ターミナル上のPythonやNode が別経路になること。第二に、長めのストリーミング応答やAPIのKeep-Aliveまわりで、遅延の大きいノードでは タイムアウト が先に来ること。第三に、googleapis.com を丸ごと同じポリシーにすると、意図しないGCP系APIまで巻き込む 副作用 が出ることです。

そこで本稿では、ChatGPTやClaude向けに書いた記事とは別軸として、Gemini・AI Studio・Generative Language API に関連しそうなホストをログで確認しながら DOMAIN／DOMAIN-SUFFIX で拾う、という順序を推奨します。ルールは上から最初の一致だけが有効なので、AI Studio用のブロックを広い MATCH や粗いGEOIPより 上 に置くこと、例外をさらにその上に重ねること——この順序が崩れると、「画面ではつながっているのにAPIだけ別ルート」という現象が残ります。

意識したいホスト：AI Studio、Gemini、generativelanguage.googleapis.com

公式のエンドポイントやフロントのホスト名は更新されうるため、ここに挙げる名前は 設定時点での一般的な呼び方 として扱い、必ずクライアントのログやブラウザの開発者ツールで 実際の接続先 を確認してください。Google AI Studio のUIやドキュメント周辺では aistudio.google.com や ai.google.dev がよく見えます。ブラウザ向けのGemini体験では gemini.google.com などが使われることがあります。

Gemini API（Generative Language API）の代表的なホストは generativelanguage.googleapis.com です。SDKやRESTクライアントがここへ向かう一方で、認証フローによっては oauth2.googleapis.com や www.googleapis.com など、別ホストへの追加リクエスト が挟まるケースがあります。「APIキーだけで叩いているのにタイムアウト」でも、ライブラリ内部でトークン取得やメタデータ取得が走っていれば、ログ上は複数ホストに分かれます。

ポリシーグループ：「Google-AI用」出口を汎用PROXYと分ける

実装の型は、他の生成AI向け分流と同じく二層が扱いやすいです。汎用の出口（例：PROXY）と、レイテンシや安定性を優先して選び直したいGoogle-AI用（例：GOOGLE-AI-EXIT）です。GOOGLE-AI-EXIT は select で地域を固定するか、url-test で応答の良いノードを選ぶかは運用次第ですが、APIの長時間接続では「テストURLには速いが実APIには不安定」というノードもあるため、実際に generativelanguage.googleapis.com へ試し打ちした結果 を優先してください。

proxy-groups の種類別の挙動は、YAML分流ガイド と同じです。コアのプロトコル対応やバグ修正差は環境ごとに出るため、古いビルドでHTTP/2や特定のTLS挙動だけ不調、ということもあり得ます。必要に応じて Clash Meta（mihomo）のアップグレード も検討してください。

proxy-groups:
  - name: "GOOGLE-AI-EXIT"
    type: select
    proxies:
      - "node-low-latency-1"
      - "node-stable-1"
      - "DIRECT"
  - name: "PROXY"
    type: url-test
    # ...

ルール例：DOMAINを先に、サフィックスは必要な分だけ

以下は たたき台 です。購読プロファイルでは、これらの行を GEOIP や MATCH より上に置き、ポリシー名は自環境に合わせて置き換えてください。APIの核となるホストを明示し、UI用のGoogleドメインを続け、認証で詰まりやすいホストを必要に応じて足す、という並びがわかりやすいです。

rules:
  - DOMAIN,generativelanguage.googleapis.com,GOOGLE-AI-EXIT
  - DOMAIN-SUFFIX,aistudio.google.com,GOOGLE-AI-EXIT
  - DOMAIN-SUFFIX,gemini.google.com,GOOGLE-AI-EXIT
  - DOMAIN-SUFFIX,ai.google.dev,GOOGLE-AI-EXIT
  - DOMAIN,oauth2.googleapis.com,GOOGLE-AI-EXIT
  # Then your generic rules, e.g. GEOIP / MATCH

購読中の RULE-SET が先にマッチしてしまう場合は、上記の行をその より上 に移すか、ルールセット側の設計を見直します。逆に、Google全体を一括で扱う既存ルールがあると、細かく書いた行が 届かない ことがあります。クライアントのログで どのルール名に吸われたか を確認し、競合する行の順序を入れ替えます。

開発者向け：環境変数とTUN／システムプロキシ

ターミナルからSDKやCLIを実行するとき、HTTP_PROXY／HTTPS_PROXY とClashの TUNモード や システムプロキシ の組み合わせで、意図しない経路に出ることがあります。「ブラウザのAI Studioは開くのに、同じマシンのPythonだけ失敗」というときは、そのプロセスがプロキシ設定を参照しているか、DNSがfake-ip経由で期待とずれていないか を疑うと早いです。OSやランタイムごとに差が大きいため、共通の一言解決は難しく、ログと実測が確実です。DNSモードの整理は Fake-IP／Redir-Hostの記事 も参照してください。

「Webは通るのにAPIだけタイムアウト」の切り分け

この症状は、プロキシ以前の要因もありますが、Clash利用者がまず確認するとよい観点を順に並べます。

• ルールの当たり先：ログで generativelanguage.googleapis.com が GOOGLE-AI-EXIT に割り当てられているか、それとも DIRECT や別グループに落ちていないか。ここがズレていると、ブラウザ側の別経路と結果が食い違います。
• ノード品質とタイムアウト：APIは短いページ表示より 長い応答待ち が続くことがあり、中間機器やモバイル回線、不安定なノードではタイムアウトが先に発生します。別ノードへの切り替えや、有線・別回線での再試行で切り分けます。
• TLS・HTTPバージョン：稀に特定ノードやミドルボックスとの相性でTLSハンドシェイクが遅延します。クライアントログにTLS関連のエラーが出ていないかを確認します。
• 429・クォータ・プロジェクト設定：HTTPステータスやAPIエラーメッセージが返っている場合は、プロキシではなく キー・リージョン・利用制限 側の確認が先です。タイムアウトに見えても、実際は遅いエラーレスポンスのケースがあります。
• IPv6とデュアルスタック：環境によってはIPv6経路だけ不通、というパターンがあります。クライアント設定とOSのスタックを含めてログで追います。

動作確認：ログでホスト名とマッチしたルールを追う

設定変更後は、Clashクライアントのログで 対象ホストがどのポリシーに割り当てられたか を確認するのが最短です。「generativelanguage.googleapis.com 用の行を足したのに変わらない」場合、多くは より上の行で既に一致している か、実際には別ホスト名に向いている かのどちらかです。ブラウザのネットワークタブ、SDKのデバッグログ、curl -v などでホスト名を拾い、それに合わせて DOMAIN 行を追加すると改善することがあります。

スマートフォンでは、省電力やVPN権限の制約でPCと挙動が変わることがあります。Androidでは ノードタイムアウトの切り分け も併せて参照してください。分流ルールが正しくても、端末側でトラフィックがプロキシに乗っていないケースがあります。

まとめ

2026年、Clash で Gemini と Google AI Studio を安定して使うには、「ログで実ホストを確認し、generativelanguage.googleapis.com などAPI核を DOMAIN で明示し、UI用のGoogleホストを DOMAIN-SUFFIX で整理し、ポリシーグループ で出口方針を分ける」ことが中心になります。googleapis.com を広く束ねすぎないこと、ルールの 優先順位 を購読セットと競合させないこと、そして「ブラウザは通るのに API だけ失敗」を、ルール・DNS・プロセスのプロキシ設定の三本柱で切り分けることが実務では効きます。OpenAI／Anthropic／xAI 向けの分流記事とドメインが被らないよう、本稿は Google側の生成AIスタック に絞ってあります。複数ベンダーを併用する場合は、サービスごとに出口を分けたYAMLノートを育てていくと運用が楽になります。

同じClash系ツールでも、GUIの見え方やコアの組み合わせで迷いがちです。クライアントの選定や入手は ダウンロードページ からまとめて確認でき、長く使うほど「自分用の分流メモ」をYAMLに少しずつ足していくのが、最も確実な運用になります。汎用のルール設計は YAML ルール分流ガイド、一覧から関連記事を探す場合は 技術コラム一覧 をご利用ください。

関連：ChatGPT／OpenAI API 分流、Claude／Anthropic 分流、Grok／xAI 分流。