GeminiがClashで開けない？タイムアウトを直す設定完全ガイド

Geminiだけタイムアウトする主な原因

Clashは有効になっており、一般的なウェブサイトも表示できるのに、Geminiを開くと読み込みが終わらない、ログイン画面から先に進まない、または「接続がタイムアウトしました」と表示されることがあります。この症状は、Clash全体が停止しているとは限りません。Gemini関連のドメインだけが別のルールにマッチしている、ノードがGoogle系の通信に対応していない、DNSの応答が汚染されている、あるいはブラウザの接続方式とClashの設定が合っていないことが主な原因です。

Geminiの通信は1つのドメインだけで完結しません。画面を表示する gemini.google.com、アカウント認証に使われる accounts.google.com、APIや静的リソースに関係するGoogle系ドメインなど、複数の接続が発生します。そのため、gemini.google.com だけをプロキシに送っても、認証やAPI呼び出しが DIRECT に振り分けられると、画面の一部だけが停止したり、ログイン後に無限に待機したりします。

最初に確認したいのは「Clashが起動しているか」ではなく、「Geminiの全通信が意図した策略グループに入っているか」です。システムプロキシだけを有効にした場合、ブラウザの通信は取り込めても、他のアプリやDNS、QUIC通信が別経路になることがあります。原因を切り分けるときは、複数のVPNやプロキシを終了し、Clashだけを有効にした状態で、ログと接続テストを順番に確認してください。

最初から設定全体を作り直さない

タイムアウトが発生した直後に、DNS、TUN、ルール、ノードを一度に変更すると、どの変更が効果を出したのか分からなくなります。まず現在のノードを確認し、次にルール、DNS、最後にTUNという順番で1項目ずつ検証するのが安全です。

最初に確認するノードとClashの動作モード

Geminiを開けないときは、特定のノードだけが原因になっている可能性があります。ノードが接続済みと表示されていても、Google系サービスへの到達性、TLS接続の安定性、出口地域の制限によって、実際の利用結果は異なります。まず策略グループを開き、現在選択されているノードを別のノードへ切り替えて、同じブラウザタブを再読み込みします。1つのノードだけで失敗し、別のノードで正常になるなら、ルールより先にノード側の問題を疑います。

ClashのProfilesまたは設定画面で、現在有効な設定ファイルが最新の状態であることを確認します。ノード一覧が空、期限切れ、または更新日時が古い場合は、まず設定を更新してください。
Proxyまたは策略グループを開き、現在のノードを別のノードへ変更します。自動選択グループを使っている場合も、テスト中は手動で1つのノードを指定すると結果を比較しやすくなります。
Modeを確認します。ルールモードではルールの結果を検証でき、Globalモードでは基本的に全通信を選択した代理グループへ送れます。短時間の切り分けではGlobalを使い、正常化したらRuleへ戻します。
システムプロキシを一度オフにしてからオンに戻し、ブラウザを完全終了して再起動します。既存の接続プールやHTTP/3接続が残っていると、設定変更がすぐ反映されないことがあります。
ClashのLogsを開いた状態でGeminiを再読み込みし、gemini.google.com、accounts.google.com、Google API関連の接続がどのポリシーに振り分けられているか確認します。

GlobalモードでGeminiが開き、Ruleモードでタイムアウトする場合は、ノードの故障よりもルールの不足または順序の問題である可能性が高いです。一方、Globalモードでも複数ノードがすべて失敗する場合は、DNS、ブラウザのQUIC、TUNの経路、またはネットワーク側の接続制限を確認します。

確認結果	可能性が高い原因	次に行うこと
別ノードにすると正常	ノードの出口や回線品質	正常なノードを選択し、問題のノードを一時的に避ける
Globalでは正常、Ruleでは失敗	Gemini関連ルールの不足・順序ミス	接続ログを見て対象ドメインを追加する
どのモードでもDNSエラー	名前解決またはDNS経路	Clash DNS、fake-ip、dns-hijackを確認する
ページは開くがログイン後に停止	認証ドメインやCookie関連通信の経路不一致	accounts.google.comなどの判定結果を確認する

Gemini関連ドメインを正しいルールへ送る

RuleモードでGeminiを使う場合、対象ドメインをプロキシ用の策略グループへ明示的に送る方法が分かりやすく、検証もしやすくなります。ルールは上から下へ照合され、最初にマッチした時点で処理が終了します。上部に GEOSITE,google,DIRECT や広い範囲の DOMAIN-SUFFIX,google.com,DIRECT があると、後ろに書いたGemini向けルールへ到達しません。

利用している設定の構文とカーネルが対応している場合は、次のように個別ドメインをプロキシグループへ送るルールを追加します。Gemini は例として使用している策略グループ名なので、実際の設定にあるグループ名へ置き換えてください。

rules:
  - DOMAIN-SUFFIX,gemini.google.com,Gemini
  - DOMAIN-SUFFIX,googleapis.com,Gemini
  - DOMAIN-SUFFIX,gstatic.com,Gemini
  - DOMAIN-SUFFIX,accounts.google.com,Gemini
  - MATCH,PROXY

ただし、Google系ドメインをすべて一律にプロキシへ送ると、通常のGoogleサービスまで同じ経路になり、通信量や速度に影響することがあります。まずログに表示された実際の宛先を確認し、必要なドメインから追加してください。ルールプロバイダーを使っている場合は、手動で書いたルールがプロバイダーのルールより上にあるかも重要です。プロバイダー側で先に DIRECT と判定されると、ローカルの追加ルールは適用されません。

ログで不足しているドメインを見つける

Clashのログレベルを一時的にinfoまたはdebugへ変更し、Geminiのページを強制再読み込みします。表示されたドメインとポリシーをメモし、Gemini関連なのに DIRECT や意図しないグループへ入っているものを特定します。認証画面、ファイル添付、音声入力など、機能ごとに別ドメインが追加されることがあるため、トップページだけでなく、ログイン、チャット送信、ファイル操作まで確認することが大切です。

ルールは広げすぎない

DOMAIN-KEYWORD,google,PROXY のような広いキーワード指定は、対象外のドメインまでマッチする可能性があります。まずは DOMAIN-SUFFIX で必要なドメインだけを指定し、動作確認後にルールプロバイダーやGEOSITEへ整理してください。

DNSとTUNモードを見直す

Gemini関連ドメインが正しいルールに入っているのに接続できない場合、DNSの解決結果や端末全体の取り込み状態を確認します。DNSがローカルネットワークの応答に依存していると、誤ったIPアドレスが返る、IPv6だけ別経路になる、またはプロキシ用ドメインの名前解決が失敗するといった問題が起こります。

mihomo系の設定では、まずDNSを有効にし、nameserverとfallbackを役割に応じて分けます。DoHやDoTを使う場合は、サーバー自身のドメインを解決するための default-nameserver に到達可能なIPアドレスを指定します。設定例は環境やクライアントのバージョンによって異なるため、そのまま貼り付けるのではなく、既存のDNS項目と重複しないように調整してください。

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - https://1.1.1.1/dns-query
    - https://8.8.8.8/dns-query
  fallback:
    - tls://1.1.1.1:853
  default-nameserver:
    - 1.1.1.1
    - 8.8.8.8

fake-ip を使用すると、Clashはアプリに実際の宛先IPではなく、通常 198.18.0.0/16 の範囲にある仮想IPを返します。これにより、ドメイン名を保持したままルール判定を行いやすくなります。ただし、銀行アプリ、社内システム、ゲームなどがfake-ipと互換性を持たない場合は、fake-ip-filterに対象ドメインを追加するか、redir-hostで動作を比較してください。変更後はDNSキャッシュを消去し、ブラウザを再起動します。

TUNモードを使う場合は、ClashがシステムDNSを横取りできる状態になっているかを確認します。mihomoでは概念的に次の項目が重要です。

auto-route: true——端末の経路へTUNを組み込み、対象トラフィックをClashへ送ります。
dns-hijack——端末が発行するDNS問い合わせをClashのDNSモジュールへ引き渡します。
auto-detect-interface: true——実際にインターネットへ出ているネットワークインターフェースを自動選択します。
stack: mixed——環境によってsystemとgVisorを使い分ける方式で、互換性の確認に使いやすい設定です。

WindowsではTUNやサービスモードに管理者権限とファイアウォール許可が必要になる場合があります。macOSではネットワーク拡張やヘルパーの許可、AndroidではVPN接続の許可が必要です。権限を拒否したままTUNだけをオンにすると、システムプロキシは動作しているように見えても、ブラウザ以外の通信が失敗することがあります。

ブラウザのQUICとキャッシュを切り分ける

Geminiの接続が不安定な場合、ブラウザがHTTP/3やQUICを使っていることも確認します。Clashの設定やノードがTCP中心で安定していても、ブラウザがUDPベースのQUIC接続を直接試みると、タイムアウトや接続の繰り返しが発生することがあります。特にTUNを使わずシステムプロキシだけで動作させている環境では、UDP通信がClashの管理外になりやすい点に注意してください。

切り分けでは、まずブラウザを完全終了し、再起動後にシークレットウィンドウでGeminiを開きます。拡張機能、保存されたCookie、古いService Workerが原因かどうかを分離するためです。シークレットウィンドウで正常なら、Geminiのサイトデータだけを削除し、拡張機能を1つずつ無効にして再確認します。すべてのCookieを削除すると他のサイトからもログアウトするため、対象サイトのデータだけを削除する方法が適切です。

Clashで正常なノードを選び、Ruleモードまたは短時間のGlobalモードにします。
ブラウザを完全終了し、シークレットウィンドウを開きます。
Geminiへアクセスし、ログイン、短いメッセージの送信、ページの再読み込みを順番に試します。
Clashのログで、各操作に対応するドメイン、接続結果、使用された策略グループを確認します。
正常になったら、GlobalからRuleへ戻し、個別ルールだけで同じ操作を再実行します。

これでも失敗する場合は、別のネットワーク、たとえばスマートフォンのテザリングで同じノードを試します。別ネットワークで正常なら、元のWi-Fiや通信事業者によるDNS処理、UDP制限、ファイアウォールが関係しています。どのネットワークでも同じノードだけが失敗するならノード側、すべてのノードで同じドメインだけが失敗するなら設定側の可能性が高くなります。

よくある質問

Geminiだけが開けず、YouTubeや通常のGoogle検索は使えます。なぜですか？

Geminiは画面表示、認証、API、静的リソースなど複数のドメインを使うため、Google検索とは必要な通信が異なります。Clashのログで gemini.google.com と accounts.google.com の判定先を確認し、DIRECTや別の失敗しやすいグループに入っていないかを調べてください。

Globalモードなら使えますが、Ruleモードではタイムアウトします。

ノードよりルールの問題である可能性が高いです。広いDIRECTルールやルールプロバイダーの順序を確認し、Gemini関連ドメインをプロキシ用グループへ送るルールを、それらより上に置いてください。

fake-ipに変更したらログインできなくなりました。どうすればよいですか？

fake-ip非対応のドメインやアプリが含まれている可能性があります。まずredir-hostで比較し、fake-ipを使う場合はログイン関連ドメインをfake-ip-filterへ追加します。変更後はブラウザのサイトデータとDNSキャッシュを整理して再試行してください。

TUNをオンにしても改善しません。

TUNが有効表示でも、ネットワーク拡張の許可、管理者権限、auto-route、dns-hijack、ファイアウォールの設定が不足していることがあります。ClashのログとシステムのVPN状態を確認し、まずTCPのウェブ通信がClashへ届いているかを確認してからDNSやUDPを調整してください。

設定を確認してClashを再テストする

Geminiのタイムアウトは、ノード、ルール、DNS、TUN、ブラウザの順に切り分けると原因を特定しやすくなります。設定を変更したあとは、同じノードと同じブラウザ条件で1項目ずつ再テストしてください。

前往ダウンロード使い方を見る