この記事で分かること
「Geminiに接続できない」「Clash経由だとタイムアウトする」「ブラウザでは開けるのにAPIやCLIだけ失敗する」といった問題は、ノードの品質だけでなく、Clashの動作モード、ルール分流、DNS、アプリ側のプロキシ解釈が重なって起きます。特にGeminiのように認証、API、ストリーミング通信を複数のGoogleホストへ分けて行うサービスでは、ひとつの接続先だけをPROXYへ送っても完全には直らないことがあります。
本稿では、Clash Verge RevやMihomo系クライアントを前提に、まず現象を再現してログを確認し、次にノード、動作モード、Google関連ルール、DNS、TUNの順番で見直します。いきなり設定を大きく変更するのではなく、どの段階で接続が止まっているかを一つずつ切り分ける構成です。ブラウザだけでなく、Gemini APIを使う開発ツールやターミナルにも応用できます。
最初に確認したい症状と原因の候補
同じ「接続できない」という表示でも、実際の原因は異なります。Clashのログとアプリのエラーを同じ時刻に確認すると、ネットワーク全体の障害なのか、特定の宛先だけの問題なのかを判断しやすくなります。
- ページ自体が開かない：選択中のノードが停止している、遅延が大きい、またはDNS解決に失敗している可能性があります。
- ログイン画面までは進むが、Geminiの回答生成で止まる：認証ホストは通っていても、生成APIやストリーミング用の接続先が別ルールでDIRECTになっていることがあります。
- 数十秒待つとタイムアウトする：対象ドメインが直結経路へ漏れている、ノードの上流が混雑している、あるいは長時間接続に向かないノードを使っている状態が考えられます。
- 成功と失敗を繰り返す：自動選択グループが不安定なノードを選んでいる、IPv4とIPv6の経路が分かれている、または複数のプロキシアプリが同時に動作しています。
- ブラウザは正常だがCLIやIDEだけ失敗する：ブラウザはシステムプロキシを利用していても、CLIやSDKは環境変数を設定しない限りDIRECTで通信している場合があります。
この段階では、設定ファイルを何度も書き換えるより、Clashの接続ログを開いたままGeminiへアクセスする方法が有効です。ログに対象ホスト、使用ルール、プロキシグループ、接続結果が表示される場合は、失敗した行を保存しておきましょう。後でルールを追加したあと、同じ操作を再実行して比較できます。
Clashの動作モードとシステムプロキシを確認する
最初に見るべき項目は、Clashのモードです。通常はRuleモードを選び、ドメインごとにDIRECTまたはPROXYを判断させます。Globalモードは原因の切り分けには便利ですが、すべての通信を同じノードへ送るため、国内サービスや社内システムまで迂回して別の問題を生むことがあります。Directモードでは当然ながらGemini関連の通信も直結するため、接続確認中は避けてください。
デスクトップアプリのブラウザ通信を確認する場合は、Clash Verge Revでシステムプロキシを有効にします。設定後は、すでに開いているブラウザを完全に終了し、再起動してからGeminiを開いてください。アプリによっては起動時にしかOSのプロキシ設定を読み取らないため、タブの再読み込みだけでは変更が反映されません。
ただし、システムプロキシを有効にしても、すべてのアプリが自動的に従うとは限りません。ターミナル、Docker、Node.js、Python、IDEの拡張機能などは、それぞれ独自のネットワーク層を持つことがあります。CLIを使う場合は、現在のシェルがプロキシ変数を持っているかを確認します。
env | grep -i proxy
curl -I -v https://generativelanguage.googleapis.com/結果に古いポートや別アプリのアドレスが表示された場合は、Clashの混合ポートと一致しているかを確認してください。Windowsでは環境変数、macOSやLinuxではシェルの設定ファイルやIDEの起動環境が残っていることがあります。確認後に新しいターミナルを開き、プロセスを再起動することも忘れないでください。
Gemini関連ドメインをルール分流へ追加する
RuleモードでGeminiを安定させるには、生成APIだけでなく、認証や補助通信も同じ方針にそろえる必要があります。接続先はサービスの更新によって変わる可能性があるため、以下を絶対的な一覧として扱うのではなく、Clashログに表示された実際のホスト名と照合してください。
- 生成APIの代表：
generativelanguage.googleapis.com。Gemini APIや一部の開発ツールが利用します。 - Google Cloud系のAPI：
aiplatform.googleapis.com。Vertex AIやSDK経由の呼び出しで現れることがあります。 - 認証関連：
accounts.google.com、oauth2.googleapis.com。ログインやトークン更新がここで行われる場合があります。 - Googleの補助サービス：
www.googleapis.comなど。アプリやSDKによって使用先が異なります。
設定画面でルールを直接編集できる場合は、対象ドメインをPROXYグループへ送ります。YAMLを編集する場合は、既存のルール記法やインデントを崩さないようにしてください。例えば、次のようなルールを追加した後、最後のMATCHルールより上に置く必要があります。
DOMAIN-SUFFIX,googleapis.com,PROXY
DOMAIN-SUFFIX,google.com,PROXYただし、google.com全体をPROXYにすると、通常は直結したい検索、仕事用サービス、社内アカウントまで同じ経路に入ることがあります。広いルールで一時的に動作確認し、ログで必要なホストが分かったら、より限定的なDOMAINまたはDOMAIN-SUFFIXへ絞る方法が安全です。ルールを変更した後は、プロファイルを再読み込みし、古い接続を閉じるためにブラウザやCLIも再起動してください。
ノードとプロキシグループを実測する
ルールが正しくても、選択中のノードがGeminiとの通信に適していなければタイムアウトは解消しません。速度テストの数値が高いノードでも、Google APIへの経路や長時間接続が不安定なことがあります。したがって、単純なHTTP速度だけでなく、対象サービスへの接続結果を見て選ぶことが重要です。
まずプロキシグループを自動選択から手動選択へ切り替え、候補のノードを一つずつ試します。各ノードについて、同じブラウザ、同じURL、同じ操作で結果を比較してください。あるノードだけ認証画面が速く、回答生成も最後まで完了するなら、そのノードを一時的な基準にできます。逆に、遅延が低くても生成途中で切れるノードは、Geminiの利用には向いていません。
| 確認項目 | 見るポイント | 判断の目安 |
|---|---|---|
| 遅延 | テストURLへの応答時間 | 極端な揺れがなく、複数回の結果が近いか |
| 接続成功率 | 同じ操作を数回繰り返した結果 | 成功と失敗が交互に出ないか |
| ストリーミング | 回答生成中に接続が維持されるか | 長い回答でも途中切断しないか |
| DNS経路 | ドメイン解決の場所と方式 | 意図しないローカルDNSへ漏れていないか |
ノードを変更してもログ上の接続先がDIRECTのままなら、ノード選びではなくルールの問題です。一方、同じルールでノードごとに結果が大きく変わるなら、プロバイダー側の出口や上流経路が原因かもしれません。何度も自動切り替えを行うより、安定して完了するノードを選び、後から自動選択へ戻す方が切り分けしやすくなります。
DNSとTUNモードを調整する
Geminiだけでなく複数のサイトで接続が不安定な場合は、DNSも確認します。Clashが通信をPROXYへ送っていても、ドメイン解決だけが別のDNSへ流れると、地域やネットワーク環境によって誤ったアドレスが返されることがあります。設定変更の前に、現在のDNSモード、Fake-IPまたはRedir-Hostの方式、IPv6の有効状態を記録しておくと、元へ戻す作業が簡単です。
Fake-IPを使う構成では、特定のアプリや企業向けソフトが仮想アドレスを正しく扱えない場合があります。逆にRedir-Hostでは、DNS応答がローカル環境の影響を受けやすいことがあります。どちらが正しいというより、OS、Clashコア、利用アプリの組み合わせで相性を確認する必要があります。DNSを変更した後はキャッシュが残るため、ブラウザ、Geminiアプリ、CLIを再起動し、必要ならOSのDNSキャッシュも更新してください。
TUNモードは、システムプロキシを無視するアプリや、環境変数を設定できないアプリの通信をClash側へ取り込む方法です。ブラウザは動くのにデスクトップアプリやIDEだけが失敗する場合に有効ですが、最初から常用するのはおすすめしません。TUNを有効にすると、VPN、Docker、仮想マシン、企業向けセキュリティソフトと経路が競合する可能性があります。
試すときは、他のVPNやネットワーク拡張を一時停止し、ClashのTUNを有効にしてから対象アプリを再起動します。Geminiの通信が成功した場合でも、すぐに全通信をPROXYへ送るのではなく、TUNのルール設定、DNS hijack、IPv6、LANアクセスの各項目を確認してください。TUNでしか動かない状態は、アプリがシステムプロキシを読んでいないという重要な手掛かりです。
タイムアウトが続くときの復旧手順
複数の変更を同時に行うと、直った理由も悪化した原因も分からなくなります。次の順番で一項目ずつ確認すると、設定を安全に戻しやすくなります。
- Clashのログを開き、Geminiへアクセスした時刻と失敗したホスト名を記録します。
- Ruleモード、システムプロキシ、選択中のプロキシグループを確認します。
- 対象ホストがPROXYへ送られているかを確認し、必要なルールをMATCHより上へ追加します。
- 自動選択を一時停止し、安定性を比較できるノードを手動で選びます。
- ブラウザ、Gemini関連アプリ、ターミナルを再起動し、古い接続を残さないようにします。
- それでもアプリだけ失敗する場合に限り、TUNを短時間だけ有効にして再テストします。
エラーが「timeout」から「401」や「403」に変わった場合、通信経路は前進している可能性があります。認証情報、APIキー、プロジェクト設定、利用地域、アカウント権限の問題へ切り分けを移してください。逆に、DNS解決エラーやTLSエラーが出る場合は、ノードを頻繁に切り替える前にDNS方式、システム時刻、別のVPNや証明書検査ソフトを確認します。
また、Clashの設定ファイルを配布元から定期更新している場合、更新によってルールの順序やDNS設定が変わることがあります。問題が解決したら、使用したプロファイルの更新日時、ノード名、モード、追加したルールを簡単にメモしておきましょう。次回同じ症状が出たとき、毎回ゼロから調査せずに済みます。
まとめ：変更後に確認するポイント
GeminiのClash経由接続がタイムアウトするときは、まず「ノードが遅い」と決めつけず、ブラウザとCLIのどちらで起きているかを分けて考えます。次にRuleモードとシステムプロキシを確認し、ログに出たGoogle関連ホストをPROXYへ送ります。そのうえでノードの安定性を比較し、DNSの解決経路を見直し、最後の手段としてTUNを試す流れが再現性の高い方法です。
無料の拡張機能や単機能のプロキシアプリは導入が簡単な反面、アプリごとのプロキシ対応、ルール編集、DNS切り替え、接続ログの確認が分かれていて、Geminiのように認証とストリーミングを使うサービスでは原因を追いにくいことがあります。ClashならRule、ノードグループ、DNS、TUN、ログを同じ管理画面で確認でき、ブラウザから開発ツールまで同じ方針で調整できます。複雑な設定を一度に増やさず、今回の確認手順を自分の環境に合わせて記録しながら運用したい場合は、対応プラットフォーム向けのClashをダウンロードして試すのが自然です。