この記事で分かること
Google AI Studioを開くとログイン画面が途中で止まる、Gemini へのリクエストを送信しても長時間待たされる、生成が始まってもストリーミング中に切断される——このような症状は、アカウントやモデルの問題だけでなく、接続先ドメインが意図しない経路へ流れていることでも起こります。本稿では、Clash Verge Rev や Mihomo 系クライアントを前提に、Google AI StudioのログインやGeminiリクエストが不安定なときに確認したい設定を、プロファイルの読み込み、モード選択、ルール分流、DNS、ログ確認の順番で整理します。
Google AI Studioは、画面を表示するためのウェブサイト、Googleアカウント認証、AIモデルへリクエストを送るAPI、生成結果を継続的に受け取るストリーミング接続など、複数の通信を組み合わせています。そのため、トップページだけ表示できても、ログイン後のプロジェクト一覧やモデル呼び出しだけが失敗する場合があります。最初から全通信を無条件にプロキシへ送るのではなく、Clashのログで実際に失敗しているホストを確認し、必要な範囲だけルールへ追加することが、安定性と管理のしやすさを両立する方法です。
Google AI Studioで起こりやすい症状と原因
設定を変更する前に、症状をできるだけ具体的に記録してください。「使えない」という一言でも、DNS解決、TLS接続、認証、APIリクエスト、ストリーム維持のどこで止まるかによって対処が変わります。ブラウザの再読み込みだけを繰り返すより、Clashの接続ログとブラウザの開発者ツールを組み合わせたほうが、原因を短時間で絞り込めます。
- ページ自体が開かない：Google関連ドメインの名前解決に失敗している、または接続先がDIRECTのままになっている可能性があります。
- ログイン画面がループする：AI Studio本体とGoogleアカウント認証の経路が分かれ、Cookieや認証リダイレクトが正常に完了していない場合があります。
- プロジェクトやAPIキーの一覧が表示されない：認証は成功していても、Google APIやCloud関連の補助通信が別のルールへ流れている可能性があります。
- Generateを押すとタイムアウトする：モデルリクエストのAPIホストがプロキシを通っていない、または選択ノードの遅延・接続維持が不安定です。
- 生成途中で文章が止まる：短いHTTPS通信は成功しても、長時間のストリーミング接続をノードや中間ネットワークが切断していることがあります。
同じ症状でも、会社や学校のネットワーク、家庭用ルーター、モバイル回線では結果が異なります。まず別回線で一度だけ試し、Clashを停止した状態と起動した状態を比較してください。原因を切り分けるためのテストであり、利用地域の法令、ネットワーク管理者の規約、Googleの利用条件に従って運用することが前提です。
ステップ1：プロファイルを読み込み、基本状態を確認する
Clashを起動したら、最初に現在選択されているプロファイルを確認します。購読URLから取得した設定と、過去に手動編集したローカル設定が混在していると、同じ名前のプロキシグループや古いルールが残り、画面上では正常に見えても実際の経路が想定と異なることがあります。新しいプロファイルを追加する前に、現在の設定をバックアップしておくと、変更後に問題が出たとき比較できます。
- Clash Verge Revの「Profiles」または「プロファイル」を開きます。
- 利用している購読URLを更新し、取得日時と更新結果を確認します。
- 読み込んだプロファイルを選択して、構文エラーやプロキシグループの欠落がないか確認します。
- 「Proxies」で、実際に利用できるノードがグループ内に表示されているか確認します。
- プロファイルを有効化したあと、古いClashプロセスや別のVPNクライアントを停止します。
購読更新に失敗している場合、ルールを何度編集しても改善しません。購読の有効期限、通信容量、同時接続数、プロバイダ側の障害も確認してください。ノード名に「AI」「Google」などの文字が含まれていても、それだけでGoogle AI Studioに最適とは限りません。遅延が低いことに加えて、TLS接続が安定し、長いレスポンスを維持できるかを実測することが重要です。
ステップ2：Rule、Global、TUNを使い分ける
通常はRuleモードから始めるのが安全です。Ruleモードでは、Google AI Studioや認証関連の通信だけを指定したプロキシグループへ送り、国内サービス、社内システム、決済サイトなどはDIRECTに残せます。普段使いの通信全体を変更しないため、速度低下や社内ネットワークとの競合を抑えやすいのが利点です。
Globalモードは、設定が原因かどうかを短時間で調べるテストに向いています。すべての通信を同じプロキシへ送るため、Google AI Studioが急に動くなら、元のルールに不足しているホストがあると推測できます。ただし、常用すると不要な通信まで遠回りになり、銀行サイトや社内ポータルで追加の認証が発生することがあります。原因調査が終わったら、Ruleモードへ戻してください。
TUNモードは、アプリがOSのシステムプロキシや環境変数を無視する場合に検討します。ブラウザは正常なのに、ローカルのスクリプトや開発ツールから送ったGeminiリクエストだけが失敗する場合、アプリ単位のプロキシ解釈が異なることがあります。TUNならプロセス側の設定に依存せず通信を捕捉しやすくなりますが、管理者権限、仮想ネットワークインターフェース、DNS設定が必要になる場合があります。
TUNを有効にする前に、別のVPN、企業用セキュリティエージェント、仮想マシンのネットワーク、Dockerの透過プロキシを停止して競合を避けます。IPv6だけが別経路へ流れる環境では、IPv4では成功してIPv6では失敗することもあります。TUNを有効化しても改善しない場合は、オンにしたまま設定を増やすのではなく、いったん無効化してRuleとシステムプロキシの状態へ戻し、比較テストを行います。
ステップ3：Google AI Studio向けのルールを確認する
ドメインルールは、最初から無制限にGoogle全体をプロキシへ送るのではなく、ログに現れた接続先を中心に作成します。Google AI Studioの画面表示、Googleアカウント認証、Gemini API呼び出しは別ホストになることがあります。代表的な候補として、aistudio.google.com、accounts.google.com、oauth2.googleapis.com、generativelanguage.googleapis.com、www.googleapis.com などがありますが、環境や機能によって追加のホストが発生する可能性があります。
ルールの順番も重要です。広いGoogle関連ルールや既存のGEOIP、MATCHルールが先にあると、後から追加したDOMAIN-SUFFIXが使われません。Clashのルール画面や設定ファイルで、個別のAI関連ルールが一般的なルールより上にあることを確認してください。使用する形式はプロファイルの記法に合わせ、既存のプロキシグループ名を正確に指定します。グループ名の綴りが異なると、設定を読み込めても意図したノードへ送られません。
- AI Studio本体：画面表示とプロジェクト操作に必要なホストを確認します。
- 認証：ログイン、再認証、OAuthリダイレクトに関係するホストを確認します。
- 生成API：Geminiのリクエストとレスポンスを担当するホストを確認します。
- 補助通信：モデル一覧、Cloudプロジェクト、利用量などを取得するホストを確認します。
認証用ドメインをPROXY、社内アカウントの管理ポータルを無条件にPROXYへ送る構成は、セキュリティポリシー上の問題になることがあります。共有PCや業務端末では、会社が指定するプロキシと証明書を優先し、個人の設定を勝手に適用しないでください。また、APIキーはClashのログや画面共有に表示させないよう注意します。
ステップ4：DNSとシステムプロキシを整える
ルールが正しくても、DNS解決だけが別の経路へ流れると接続先の判定が不安定になることがあります。ClashのDNS設定では、使用しているモードとFake-IP、Redir-Hostなどの挙動を確認し、OS側のDNS、ブラウザのSecure DNS、ルーターのDNSリダイレクトが複数存在していないかを整理します。DNS設定を変更した後は、ブラウザを完全終了して再起動し、古い名前解決結果や接続プールを残さないようにしてください。
ブラウザだけを使うなら、Clashのシステムプロキシ設定を有効にして、OSのプロキシ画面に反映されたアドレスとポートを確認します。ターミナルやスクリプトを使う場合は、ブラウザの設定とは別に、アプリがプロキシ環境変数を読むか確認する必要があります。たとえば、シェルで次の値を確認できます。
env | grep -i proxy
curl -I https://aistudio.google.com
curl -v https://generativelanguage.googleapis.comコマンドの結果だけで利用可否を断定するのではなく、Clashのログに同じ時刻の接続が現れるかを照合します。ログに出ない場合は、アプリが別のネットワークスタックを使っている、別ポートへ接続している、またはTUNが無効である可能性があります。ログに出ていてもDIRECTになっているならルール順を、PROXYになっていて失敗するならノードやTLS、接続維持の問題を調べます。
ステップ5：ログで実測し、変更を固定する
テストは「Clash停止」「Ruleモード」「別ノード」「必要ならTUN」の順に一つずつ行います。各テストでは、ログインの完了、プロジェクト一覧の表示、モデル選択、短い生成、長めの生成を分けて確認してください。短い入力だけ成功しても、ストリーミングや長いコンテキストで切断するなら、通信の維持に問題が残っています。
Clashのログでは、接続先、使用ルール、選択されたプロキシグループ、接続結果を見ます。失敗直前に毎回同じホストがDIRECTで表示されるなら、そのホストを個別ルールへ追加します。一方、同じホストが常にPROXYへ入っているのに、ノードごとに成功率が大きく違うなら、ルールよりノード選択の問題です。自動選択グループが頻繁に切り替わる場合は、テスト中だけ固定ノードにして挙動を比較すると判断しやすくなります。
ログインだけが不安定なときは、ブラウザのCookieを無闇に全削除する前に、シークレットウィンドウ、別ブラウザ、拡張機能の一時停止を試します。広告ブロッカーやプライバシー保護拡張が認証リダイレクトを遮断する場合もあります。生成だけが失敗する場合は、APIキーの有効性、選択プロジェクトの請求設定、モデルの利用権限、レート制限も確認してください。ネットワーク設定だけでアカウント側の制限を解決することはできません。
安定運用のための設定チェックリスト
一度動作した後も、購読更新やノードの入れ替えでルールが変わることがあります。設定を長く使うには、次の項目を定期的に確認してください。
- プロファイルの更新日時と購読期限を確認し、更新失敗を放置しない。
- Google AI Studio本体、認証、生成APIのルールがMATCHより上にあることを確認する。
- 通常はRuleモードを使い、Globalモードは原因切り分け専用にする。
- TUN、別VPN、企業用セキュリティソフトを同時に動かさず、競合を記録する。
- 固定ノードで成功を確認した後、自動選択へ戻して再テストする。
- 長い生成やストリーミングも試し、短いリクエストだけで判断しない。
- APIキーや認証情報をログ、スクリーンショット、設定ファイルの公開版に含めない。
また、Google AI Studioが突然使えなくなったときは、すぐに設定を大幅変更せず、Google側の障害、プロバイダのメンテナンス、回線変更、ブラウザ更新の有無を確認します。前回成功したプロファイルを保存しておけば、最新版との比較ができます。設定ファイルは、コメントや変更日を残しながら小さく編集すると、あとから元に戻しやすくなります。
ブラウザの拡張機能だけで接続を変える方法は手軽ですが、認証と生成APIで経路が分かれやすく、アプリや開発ツールには反映されないことがあります。単純な全体VPNは導入しやすい反面、国内サービスまで遠回りになり、社内ネットワークやDNSとの競合を見つけにくい場合があります。それに対してClashは、RuleモードでGoogle AI Studio関連だけを分流し、ログで接続先と経路を確認し、必要な場合だけTUNへ広げられるため、原因を説明しながら調整できます。Google AI Studioを継続的に使う環境を整えたいなら、端末と用途に合うClashクライアントを選び、公式の入手先から導入しておくと設定の再現性を保ちやすくなります。