Gemini・AI Studio を Clash 分流と固定ノードで安定

「Gemini が開けない」の裏で、ウェブ版と Google AI Studio は別のホスト列を踏みやすい

ブラウザの Google Gemini（gemini.google.com 周辺）は、会話 UI 本体に加えて認証、アセット、計測、グローバル CDN への並列リクエストが重なります。Google AI Studioはエディタ、モデル一覧、プレビュー、課金やクォータに関する呼び出しが短時間に走り、多くの環境では ai.google.dev や関連ドメインが目立ちます。SDK やバックエンドから叩く Generative Language API（generativelanguage.googleapis.com など）まで含めると、画面は開いているのに API だけタイムアウト、といった部分的成功が起きやすい構造です。

ここで Clash 分流が「広い GEOIP や国内直結に先に吸われる」「url-test 由来でノードが頻繁に入れ替わる」状態だと、ホストごとに別出口へ落ちたり、セッション途中で上流が変わったりして、体感では読み込みが止まる、ストリームが途中で切れるように見えます。サーバ側の障害は制御できませんが、手元ではルール命中と固定ノードを揃えるだけでも改善することが多いです。DNS 汚染や DoH の設計そのものは既稿の Gemini＋DoH ガイドに譲り、本稿はドメイン束ねとポリシー設計に集中します。

💡

他 AI ツール稿との棲み分け OpenAI エコシステムはChatGPT／OpenAI API 向けの記事、Anthropic はClaude 向けの記事で整理しています。本稿はGoogle 系ドメインと、ウェブ UI と AI Studio の経路の分け方に限定します。

三つの面：会話ウェブ、AI Studio、API

設定を分けて考えると運用が楽になります。第一に、一般利用者が触る会話ウェブ。第二に、プロンプトやキー管理を含むGoogle AI Studio。第三に、本番ワークロードのAPI。いずれも HTTPS 前提ですが、失敗ログに出る名前と、許容したい出口リージョンが異なることがあります。例えば会話だけは手近なノード、AI Studio のプレビューはレイテンシ優先、API は課金アカウントの想定リージョンに合わせる、といった住み分けはポリシーグループを分けることで表現できます。

実際のホスト名は UI の更新で変わるため、ログに出た名前を正とするのが安全です。初期のたたき台として gemini.google.com、google.com 配下の OAuth やアセット、ai.google.dev、generativelanguage.googleapis.com、ならびに *.googleapis.com や *.gstatic.com が候補に挙がりがちです。サフィックスを広げすぎると国内向けトラフィックまで巻き込むので、ログで根拠のある行から足す方針を推奨します。

YAML の例：ウェブ用と AI Studio 用を分ける

以下は概念デモです。ノード名・購読名は環境に合わせて置き換えてください。コメントは英語のみです。

proxy-groups:
  # Browser Gemini (consumer UI)
  - name: GEMINI-WEB
    type: select
    proxies:
      - JP-GEMINI-WEB
      - US-GEMINI-WEB
      - DIRECT
  # Google AI Studio (developer console)
  - name: AI-STUDIO
    type: select
    proxies:
      - US-AISTUDIO-STABLE
      - JP-AISTUDIO-STABLE
      - DIRECT
  # Generative Language API (SDK / server)
  - name: GEMINI-API
    type: select
    proxies:
      - US-GEMINI-API
      - DIRECT

rules:
  # Keep these before broad GEOIP / MATCH
  - DOMAIN-SUFFIX,gemini.google.com,GEMINI-WEB
  - DOMAIN-SUFFIX,ai.google.dev,AI-STUDIO
  - DOMAIN-SUFFIX,generativelanguage.googleapis.com,GEMINI-API
  # Optional: tighten googleapis if other traffic is sensitive
  # - DOMAIN-SUFFIX,googleapis.com,GEMINI-API
  # ... GEOIP / MATCH

googleapis.com は BigQuery や他クラウド API と共有されるため、誤爆が気になる場合はまず API 用に限定し、不足ホストだけログから追加します。購読の再取得で消える手編集を避けるなら、prepend-rules やマージによる先頭挿入がオーバーライドと相性がよいです。

固定ノードとポリシー：ヘルスチェックだけに頼らない

長めの TLS とストリーミング応答では、間隔の狭い url-test だけを載せると、チェックのたびに別上流へ寄り、ハンドシェイク途中の切断や再試行のスパイクが出やすくなります。Google AI Studioでプレビューを回すときも同様で、体感の「Gemini が開けない」に近い不安定さは、ノード品質以前に出口のブレが効いているケースがあります。

現実的なのは、検証済みの 1 ノードを select で手動固定するか、計測間隔を長めにした fallback と組み合わせて乗り換え頻度を下げることです。マルチリージョンが必要でも、まずは単一リージョンに固定して症状が消えるかを見ると切り分けが速いです。接続ログで、失敗行に選ばれているノード名がセッション中に変わりすぎていないかも併せて確認してください。

ルール順と「部分的成功」：Clash 分流で取りこぼさない

典型パターンは、先頭に広い GEOIP,CN,DIRECT や国内直結があり、その後ろに Google AI 向け行が追いやられているケースです。DNS の結果次第で一部サブドメインが意図せず DIRECTのまま残り、トップは開くが Google AI Studio の一部 API だけ失敗——といった症状が出ます。対策は、確定したドメイン行を先に置き、広いルールは後ろへ、です。

国内サイトをプロキシに流さない大枠は国内直通と海外プロキシの分流で整え、その上に本稿の細いルールを載せるイメージです。設定ファイルを読むより、ログで実測した方が早い場面が多いです。

DNS・fake-ip と SNI：名前と経路のズレを潰す

fake-ip モードでは、画面上のホストと実転送の関係が直感とズレやすく、ルールは当たっているように見えても別経路に出る、といったホスト単位の成否分岐が起きます。ブラウザの Secure DNS と Clash の DNS を二重に競合させないよう、検証中はどちらか一方に寄せて症状が変わるかを見るのも有効です。モード比較の詳細はfake-ip と redir-host の記事へ。

HTTPS では ClientHello の SNI が証明書検証と整合している必要があります。企業の HTTPS インスペクションや透明プロキシ、ブラウザ拡張のフィルタが同居していると、Clash 以前の層で不整合が生じ、Google 系 AI への接続が不安定に見えるエラーが出ることがあります。異常時はClash のみ・拡張オフのミニマル構成で再現が消えるかを確認し、消えるなら Clash 外の層を疑います。TLS の深掘りはClaude 向け SNI 稿とも相互補完になります。

運用メモ：同一アカウントと複数出口、ログの残し方

Google アカウントは単一でも、短時間に地理的に離れた出口から同サービスへアクセスが集中すると、再認証や追加確認が出やすいことがあります。開発と日常利用でノードを分けている場合、Google AI Studioと会話ウェブで別出口にしていると差が目立つため、まずは同一リージョンに揃えて症状が変わるかを見ると判断が早いです。セキュリティ上の正当な理由がある場合を除き、利用規約に反する複数地域からの回避行為は行わないでください。

切り分けの効率を上げるには、問題が起きた時間帯のログをホスト名でフィルタし、選択されたポリシー名と実ノードをセットで保存しておくとよいです。チームで共有する場合も、API キーや個人識別情報が混ざらないようマスクしたうえで、ルール行の番号と YAML の該当ブロックを対応づけておくと、後から同じ型のトラブルに再利用しやすくなります。

TUN とシステムプロキシ：ブラウザと CLI を同じ前提に

ブラウザは OS のプロキシや TUN モードの捕捉に従います。一方、CLI やコンテナから API を叩く場合は HTTPS_PROXY／ALL_PROXY を明示する運用が多く、ループバックのアドレスと Clash の mixed-port が一致しているかを確認します。WSL や Docker からホスト側の Clash へ向ける場合は、名前解決がコンテナ内で止まっていないかも同時に見ます。

どの層でも共通なのは、「遅延」なのか「別ホストが DIRECT」なのかをルール命中で分岐させることです。長いストリームが途中で切れるときは、まず出口の品質よりホスト単位のルール抜けを疑うと早いことが多いです。

⚠️

法令と利用規約 接続先のネットワークポリシー、居住地域の法規、Google の各種利用規約を順守してください。本文は正当なアクセス権限のある環境で、Clash によって意図した経路にトラフィックを揃えるための参考情報です。

切り分けチェックリスト

会話ウェブだけ不安定

gemini.google.com と認証・アセット周辺が GEMINI-WEB に入っているかログで確認します。広いルールに先食いされていないかを直したうえで、ノードを一時固定して再現性を見ます。

Google AI Studio だけ読み込みが止まる

ai.google.dev やログに出た関連ホストが AI-STUDIO に乗っているかを優先します。API 用ポリシーと混ぜすぎていると、意図しない出口へ寄ることがあります。

API だけタイムアウト

generativelanguage.googleapis.com などが GEMINI-API に入り、DIRECT に落ちていないかを確認します。DNS が偽応答を返していないかはDoH 稿の手順と併せて切り分けます。

まとめ：ウェブ・AI Studio・API の三本柱と「束ね・固定・ログ」

2026 年時点でも、話題の生成 AI はドメイン集合がサービスごとに異なります。本稿では Google Gemini の会話ウェブ、Google AI Studio、Generative Language APIを三本柱として Clash 分流のポリシーを分け、固定ノードで出口のブレを抑え、接続ログで命中を検証する流れに整理しました。DNS の深掘りや DoH の組み立ては同テーマの別稿へ回し、OpenAI／Claude 各稿とキーワードが被りすぎないよう構成しています。

クライアントの導入や購読の取り込みがまだなら、当サイトのダウンロードページから入手し、購読 URL チュートリアルで土台を整えてから本稿のルールを足すとスムーズです。オープンソースの議論は各プロジェクトの GitHub で追えますが、初回インストールのパッケージはサイト経由で揃えると取り違えが減ります。→ Clash を無料ダウンロードし、Gemini と AI Studio の経路を手元で試す