Gemini・AI Studio を Clash 分流と DoH で安定化

Gemini のウェブと Google AI Studio が「たまにだけ」開かない理由

Google Geminiの会話 UI は、単一オリジンに見えても認証、静的アセット、計測やグローバル CDN への並行リクエストが重なります。Google AI Studio（ai.google.dev 周辺）ではエディタとプレビュー、モデル一覧、課金やクォータに関する API 呼び出しが短時間に密集し、開発者向けの Generative Language API（generativelanguage.googleapis.com など）に至ると、SDK やサーバからの連続 HTTPSが前提になります。ここでClash 分流が「広い GEOIP ルールに先に吸われる」「ヘルスチェックで上流が頻繁に入れ替わる」状態だと、画面の一部だけ真っ白、ストリームが途中で止まる、API だけタイムアウト、といった部分的成功として現れやすいです。

サーバ側の障害や地域ポリシーはユーザーが制御できませんが、手元では名前解決が意図した IP に届いているか、意図したポリシーに乗っているか、出口が会話セッションの途中で変わっていないかを揃えるだけでも、体感の不安定さは大きく減ることがあります。本稿では Google エコシステムに特化し、ChatGPT／OpenAI 向けの整理やClaude 向けの SNI 中心稿と役割を分けます。

💡

切り分けの出発点 まずは接続ログでルール命中を確認し、失敗したホスト名と選択されたポリシー名をメモしてください。YAML を全面置換する前に、「どの行に入ったか」と「DNS が返した名前」を突き合わせると、作業時間を短縮できます。

押さえるべき Google 系ホストのイメージ

実際に出るホストは UI やクライアントのバージョンで増減するため、ログに出た名前を正とするのが安全です。それでも初期のたたき台としては、gemini.google.com、google.com 配下の認証やアセット、Google AI Studioの ai.google.dev、API の generativelanguage.googleapis.com、ならびに Google API 基盤でよく見かける *.googleapis.com や *.gstatic.com などが候補になります。広すぎるサフィックスは国内向けトラフィックまで巻き込みやすいので、まずはログで根拠のあるサフィックスから足す方針が現実的です。

国内サイトや銀行アプリまでプロキシに流さない大枠は国内直通と海外プロキシの分流で整え、その上に Google AI 向けの細いルールを置くイメージです。Clash Meta（Mihomo）であれば prepend-rules やマージによる先頭挿入がオーバーライドと相性よく、購読更新で消える手編集を避けられます。

YAML の最小例：Google AI 向けポリシーとルール

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

proxy-groups:
  # Sticky egress for Google AI surfaces
  - name: AI-GOOGLE
    type: select
    proxies:
      - US-GEMINI-STABLE
      - JP-GEMINI-STABLE
      - DIRECT

rules:
  # Place before broad GEOIP / MATCH
  - DOMAIN-SUFFIX,gemini.google.com,AI-GOOGLE
  - DOMAIN-SUFFIX,ai.google.dev,AI-GOOGLE
  - DOMAIN-SUFFIX,generativelanguage.googleapis.com,AI-GOOGLE
  - DOMAIN-SUFFIX,googleapis.com,AI-GOOGLE
  # Narrow down if too broad — verify in logs
  # ... GEOIP / MATCH

googleapis.com は他サービスとも共有されるため、誤爆が気になる場合はログで実際に失敗しているホストに絞り込みます。ポリシーグループは url-test だけに頼らず、検証済みの 1 ノードを select で固定するか、切り替え間隔の長い fallback と組み合わせて出口のブレを抑えると、長めの HTTPS やストリーミングに効きやすいです。

DNS 汚染と DoH：Clash 側の名前解決をどう設計するか

ページが「開いたように見えるがすぐ固まる」「API だけ別のエラー」などは、経路以前に名前解決が偽の応答やキャッシュの残骸でズレているケースがあります。OS の DNS をそのまま使うと、ローカルネットワークや ISP の挙動の影響を強く受けます。DoH（DNS over HTTPS）はブラウザや OS、あるいは上流のリゾルバが HTTPS でクエリを送る仕組みで、途中の改ざんに強くなります。一方で Clash のルールはドメインを材料にするため、どの DNS がどのクエリを担当するかを設計しないと、fake-ip 下で見えている IP と実転送先の関係が直感とズレ、トラブルの原因になります。

実務では次の二段構えが扱いやすいです。第一に、Clash の nameserver に信頼できる DoH／DNS over TLS を置き、海外名の解決をそこに寄せる。第二に、国内ドメイン向けのフォールバックや nameserver-policy でクエリごとに使うリゾルバを分ける。これにより「海外 AI だけはクリーンな解像度」「国内は従来どおり速い経路」といった住み分けがしやすくなります。詳しいモード比較はfake-ip と redir-host の記事と併読すると理解が早いです。

ブラウザ単体の Secure DNS と Clash の DNS を二重に競合させないよう、検証中はどちらか一方に寄せて症状が変わるかを見るのも有効です。最終的には「アプリはシステム DNS／TUN に従う」「Clash が名前とルールの一貫性を担保する」形に揃えると、Gemini に接続できないに近い体感のブレを減らしやすくなります（※本文は技術的な経路整理であり、居住地域の法規とサービス利用規約の順守を前提とします）。

TUN・システムプロキシと DoH の組み合わせ

TUN モードでは、対象アプリのトラフィックをカーネルレベルで捕捉しやすくなります。CLI やコンテナから generativelanguage.googleapis.com を叩く場合、HTTPS_PROXY を明示する運用も多く、ループバックのアドレスとプロキシスキーム（HTTP CONNECT と SOCKS5）が Clash のリスン設定と一致しているかを確認します。名前解決がコンテナ内で止まるときは、ホスト側の Clash に問い合わせる経路と、DoH エンドポイント自体がどのルールに命中するかも同時に見ます。DoH のホストが誤って DIRECT に落ちると、期待した解決結果が得られず、結果として Google AI Studioの読み込みだけ未完、という症状に繋がり得ます。

SNI と TLS：Google 側の証明書検証と整合させる

HTTPS では ClientHello に載る SNI が、接続先の仮想ホスト選びと証明書チェーンの前提と揃っている必要があります。企業の HTTPS インスペクションや透明プロキシ、ブラウザ拡張のフィルタが同居していると、Clash 以前の層で不整合が生じ、Gemini の SPA が一部だけ失敗することがあります。異常時はClash のみ・拡張オフのミニマル構成で再現するかどうかを切り分け、必要なら Claude 稿で述べている TLS まわりの考え方と同様に、中間者が増えていないかを確認します。

マルチ CDN 環境では、同じ会社のサービスでもエッジごとに挙動が微妙に異なることがあります。出口ノードの地理と、Google 側の振り分けが噛み合わないと遅延や再試行が増えるため、まずは単一リージョンの安定ノードに固定してから症状が変わるかを見ると判断が早いです。

接続ログでルール命中を検証する

設定ファイルを読むだけでは足りないのが、Google 系の複数ホストが短時間に並列で飛ぶ点です。ダッシュボードやログビューアで、失敗行のドメインまたは IP、選択されたポリシー、実際に使われたノードを確認し、YAML の評価順と突き合わせます。「思ったポリシーに入っていない」なら、広い MATCH より手前に行を挿入するか、誤って DIRECT に落ちていないかを直します。「ポリシーは正しいがタイムアウト」なら、DNS 以前にノード品質やローカルファイアウォールを疑います。

ストリーミング応答が途中で切れる場合でも、まずルール命中のブレを潰すと、不要なノード入れ替えを減らせます。ログの見方の共通型は接続ログの記事に集約してあるので、本稿では Google 向けの観点だけ補足します。

⚠️

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

チェックリスト（短時間で回す順序）

1. 名前解決

失敗ホストに対し、Clash が使うリゾルバで期待どおりのレコードが返るか。DoH を切り替えて挙動が変わるかを見ます。

2. ルール順と命中

ログで当該ホストが AI-GOOGLE など意図したポリシーに入っているか。広い国内直結ルールに先食いされていないかを確認します。

3. 固定出口

同一セッション中にノードが変わりすぎていないか。select で一時固定し、改善するかを見ます。

4. TLS／SNI

ミニマル構成で再現が消えるか。消えるなら Clash 外の層を疑います。

まとめ：Google 系は「ホスト束ね・DoH・固定出口・ログ」の四角形

話題のブランド名は変わっても、安定化の型は似ています。Gemini が開けない・不安定といった体感の揺れに悩むときは、まずGoogle AI Studioと API が参照するホストをログで確定し、Clash 分流の順序と DoH を含む DNS 設計を揃え、続いてポリシーグループで出口を固定し、必要なら SNI を含む TLS まわりへ進むと、設定の全面置換を避けられます。OpenAI や Anthropic 向けの記事と組み合わせれば、生成 AI ごとの経路を用途別に整理しやすくなります。

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