1. 「ずっと読み込み」が示すもの：Gemini は単一ドメインではない
ブラウザで gemini.google.com を開いたとき、骨格だけ表示され本文が永遠に流れ込まない。あるいはログインは通るのに、送信ボタンを押した直後から応答が始まらない。こうした症状は、ユーザーから見ると「AI が重い」に見えがちですが、裏側では複数ホストへの並列リクエストの一部が TLS 失敗・タイムアウト・誤ルーティングで詰まっているケースが典型です。Clash の接続一覧に出るホスト名と実際に選ばれたポリシーを並べると、想像以上に早く切り分けが進みます。
設定の全体像をまだ把握していない場合は、先にサブスクリプション取り込みの記事で YAML の骨格とルールモードを押さえておくと、以降の手順が読みやすくなります。
2. 通信を「層」に分ける：フロント・認証・静的・API
実際のホスト名はプロダクト更新で変わり得るため、開発者ツールのネットワーク欄と Clash のログに出た名前を正とします。設計メモとして、次のような役割分けを頭に置くとルールが書きやすくなります。
| 層 | イメージ | 切り分けのポイント |
|---|---|---|
| Gemini Web UI | gemini.google.com、関連サブドメイン | 初期表示は出るのに会話だけ止まるなら、別ホストが DIRECT に落ちていないか。 |
| アカウント／OAuth | accounts.google.com、oauth 周辺 | ログインループや「確認」の繰り返しと相性がよい。経路が混在すると Cookie ドメイン跨ぎで読みにくい。 |
| 静的 CDN | gstatic.com、www.gstatic.com など | JS／CSS だけ欠けると真っ白に近い見え方になる。広すぎるサフィックスは副作用に注意。 |
| API／バックエンド | googleapis.com 配下（generativelanguage など） | 送信直後だけ固まるならストリーム系を疑う。サフィックス丸ごと指定は他 Google API に波及しやすい。 |
| 計測・フォント | fonts.googleapis.com、fonts.gstatic.com など | 本体より先に詰まると「壊れた UI」に見えることがある。 |
重要なのは、「Google にログインできれば Gemini も通る」ではないという点です。フロントは初期表示のあと、別ホストからスクリプト・認可・推論ストリームを引きに行くため、一枚岩のドメイン想定でルールを書くとすぐ破綻します。
3. ドメイン収集：ブラウザと Clash の両方で拾う
収集の基本は次の二系統です。どちらか片方だけでは取りこぼしが出やすいので、併用してください。
- ブラウザの開発者ツール（ネットワーク）を開き、Gemini をハードリロード。フィルタを外し、ドメイン列を眺めて
gemini.google.com、google.com、gstatic、googleapis、accounts.google、明らかに CDN らしいホストをメモする。 - Clash（Mihomo 対応 GUI なら接続ビュー）で、同じ操作のあとに現れた接続行を時系列で並べ、
DIRECTや想定外のポリシーに落ちている名前をマークする。 - 会話を一度送ってストリームを走らせた直後だけ増えるホストがあるため、そのタイミングでもう一度ログを眺める。
- 重複やワイルドカード化できそうなサフィックスを整理し、購読ルールより手前に置くべき具体ルールとして YAML に落とす。
ポートやプロセス周りの一般的な詰まりはトラブルシュート記事へ。本稿は Gemini／Google AI 特有のマルチドメイン構成に焦点を当てます。
4. 推奨する切り分け順序
- Clash が起動していること、システムプロキシかTUNのどちらでブラウザトラフィックを握っているかを確認する。
- 接続ログで Gemini 関連ホストが、意図したポリシーグループに入っているか、誤った
DIRECTがないかを見る。 fake-ipを含む DNS 設定を確認し、必要なら主要サフィックスへnameserver-policy等を当てて名前解決のブレを減らす。- フロント・認証・静的・API をホスト／サフィックス単位でルール化し、購読内の広い
DIRECTより上側に矛盾なく配置する。 - ルールが意図どおりになったあとで、遅延の揺れが少ないノードを選び、過剰な自動切替を避ける。
5. システムプロキシと TUN：ブラウザでも取りこぼしがある
OS のシステムプロキシに Clash の mixed ポートを指定する方法は手軽ですが、プロキシ設定を読まないコンポーネントや、拡張機能・別プロファイルのブラウザが混ざると、見かけ上「同じ Chrome なのに別経路」が起きます。TUN はルーティング層でトラフィックを取り込むため一貫性は上がりますが、他 VPN との競合や権限まわりのトレードオフがあります。有効化するならTUN モードの解説を参照し、有効化後に再接続ログで関連ホストがすべて期待どおりの経路になったか検証してください。
6. DNS／fake-ip：名前解決とルール判定のズレ
fake-ip は体感速度を上げる一方、設定次第では「ルールに渡る前の名前」と「実接続の宛先」の整合が崩れやすくなります。Google 系のようにサブドメインと CDN が多いサービスでは、軽いズレでもフロントがリトライを繰り返し、ユーザーにはただのローディングに見えます。Gemini まわりも同様で、認可とストリームが別ホストに分かれていると症状が読みにくくなります。対策の基本は、上流 DNS を信頼できるものにそろえ、収集した主要サフィックスへ専用の名前解決ポリシーを当てることです。フィールド名はコアのバージョンで差があるため、利用中の Mihomo／Clash Meta のドキュメントと照合してください。
社内 DNS やキャリアの DNS がフィルタされている環境では、Clash 側の DNS が正しくてもOS のキャッシュやブラウザの Secure DNSが別ルートを踏むことがあります。検証時はブラウザの「DNS over HTTPS」を一時オフにし、Clash のログと突き合わせると原因が切り分けやすくなります。
7. 分流ルールの考え方（記述例は置き換え前提）
購読ルールに「広い DIRECT」が先に入っていると、意図せず国内直結へ落ちるホストが紛れ込みます。より具体的な DOMAIN／DOMAIN-SUFFIX を、矛盾なく上側に置くのが実務的です。以下は例示であり、実際のホスト名は必ずログで確認して置き換えてください。googleapis.com のようなサフィックスは他用途にも使われることがあるため、ログに出た特定サブドメインに絞るか、ルールセットの細分化を検討してください。
# Example only — verify hostnames in your Clash logs before use
rules:
- DOMAIN-SUFFIX,gemini.google.com,PROXY
- DOMAIN-SUFFIX,accounts.google.com,PROXY
- DOMAIN-SUFFIX,googleusercontent.com,PROXY
- DOMAIN-SUFFIX,gstatic.com,PROXY
- DOMAIN-SUFFIX,generativelanguage.googleapis.com,PROXYAPI ストリームだけ別グループ（例：PROXY_AI）に分け、静的 CDN（PROXY_CDN）と切り離すと、障害時の切り分けが容易になります。グループ名は proxy-groups に定義済みである必要があります。なお、過度に広い DOMAIN-SUFFIX,google.com は他の Google サービスまで巻き込みやすいので、まずはログ根拠のある名前から足していくのが安全です。
8. Gemma／ChatGPT 記事との違い
当サイトの Gemma 4 と Hugging Face 記事は、ローカル推論向けの重み取得や開発者向けドキュメント閲覧の経路整理にスコープが寄っています。本稿は 一般ユーザーが触れる Gemini Web と Google AI フロント に絞り、ブラウザ内のマルチドメイン同期を扱います。OpenAI 系はChatGPT 向け分流記事が軸です。複数の生成 AI を併用する環境では、プロダクトごとにポリシーグループを分けておくと、片方の障害が他方のルール調整を汚染しにくくなります。
9. ノード選定：瞬間最速より「揺れの少なさ」
スピードテストで一位でも、短時間で往復遅延が跳ねるノードは、ストリーミング応答型のチャット UI には不向きです。TLS の再ハンドシェイクが増え、ブラウザ側はリトライやタイムアウトとして現れます。手動選択で様子を見たり、Gemini 専用グループを作って安定路線に固定するのが実用的です。プロトコル特性の比較はプロトコル比較記事も参考になります。
10. 追加の落とし穴：人間確認、QUIC、拡張機能、複数 VPN
Google はリスク判定で追加認証を挟むことがあり、経路や IP が頻繁に変わると「ずっと検証」のように見えることがあります。ルール調整で改善する前に、同一出口にそろえて挙動が変わるかを見ると早いです。HTTP/3（QUIC）が有効なブラウザでは、見た目は HTTPS でもUDP の別経路が絡むため、TUN とファイアウォールの組み合わせ次第で取りこぼしが出ます。切り分け中は一時的に HTTP/3 をオフにするのも有効です。
ブラウザ拡張が独自プロキシを指定していると OS 設定と二重化し結果が読みにくくなるため、検証時は一旦無効化してください。また別製品の VPN と TUN を同時に有効にしている場合、ルートの奪い合いで「ときどきだけ直結」が紛れ込みます。単一路径に戻してからログで確認するのが早道です。モバイルの公式アプリを併用する場合も、アプリとブラウザで別 DNS／別プロファイルになっていないかを確認してください。
11. まとめ：証拠ベースで Google 系 AI のホストを束ねる
Gemini の Web が読み込みのまま進まない症状は、単一設定ミスよりもモード・DNS・ルール順・ノードの揺れの積み重ねで起きがちです。本稿の順序どおりにログで確認していけば、「とりあえず別ノード」より再現性の高い改善が期待できます。2026 年も Google AI のフロントと API の境界は流動的なので、購読ルールに頼り切らず、自分の環境で一度ホスト表を更新する習慣を持つと安心です。
接続ログと購読更新を GUI でまとめられるクライアントを使うと、YAML を毎回手で触る負担も下がります。同種ツールのなかでも、ルールとコアの整合が取りやすい製品ほど長く運用しやすい印象です。Gemini を安定して使いたい方は、→ Clash を無料ダウンロードして、快適な接続体験を始める