なぜ Mac アプリはログインが「回ったまま」になりやすいか

2026 年に報道が集中した週を境に、Gemini のネイティブ Mac クライアントを試す人が増えています。一方で Clash や企業プロキシ下では、起動直後のログイン画面が終わらない、同期やアップデート確認だけ固まる、といった報告も増えやすいタイミングです。ブラウザで gemini.google.com を開く話とは別レイヤで、デスクトップアプリは OS のネットワークスタックに直接乗るため、システムプロキシを読む場合と読まない場合、証明書ピンやタイムアウトの扱いがブラウザと一致しない場合があります。まず押さえたいのは「単一ドメインの障害」ではなく、短時間に複数ホストへ分散するフローだという点です。Google AI Studio や Generative Language API をブラウザ前提で整理した Gemini／Google AI Studio のドメイン分流 とセットで読むと、名前空間の重なりと差分が掴みやすくなります。

Mac アプリのログインは典型的に OAuth とアカウント同意、続けて バックエンド API（*.googleapis.com）、さらに 静的アセットやフォント類の CDN（*.gstatic.com など）へ連鎖します。ここで accounts.google.com だけプロキシに乗り、googleapis.com が DIRECT のまま劣化した経路に落ちる、逆に gstatic が広告ブロックや誤ったルールでブロックされる——出口が行ごとに割れると、UI は「読み込み中」のまま進まず、原因はサーバーダウンではなくルーティングと DNS の不整合であることが多いです。本稿はその切り分けに必要な Clash のドメイン分流・ルールセット・DNS に絞ります。

ℹ 観測のコツ：Clash Verge／Mihomo 系のライブ接続、またはログの Policy 行で、ログイン操作中に現れたホストをメモします。oauth2.googleapis.com、securetoken.googleapis.com、www.googleapis.com、clientservices.googleapis.com など、製品版や地域によって名前が増減します。同じポリシーグループに揃っていない行が混ざっていないかを最初に見ると、当て推量より早く終わります。

アプリが踏む Google API・OAuth・CDN の地図

まず大枠を三束ねに分けると説明がしやすいです。① アカウントと同意：accounts.google.com、myaccount.google.com、地域によっては play.google.com 系の同意画面など。② API とトークン：*.googleapis.com にまとまる OAuth トークン端末、各種 REST／RPC、Firebase 周辺の一部エンドポイント。③ 静的 CDN：*.gstatic.com の JS／CSS／フォント、場合によっては fonts.googleapis.com など。Mac クライアントは起動時に ①→③→② のように短いバーストを連発しがちで、どこか一つが別出口に落ちると「ログインだけ終わらない」ように見えます。Apple 側のクラウドと CDN が分かれる話は別名前空間ですが、「本体と CDN を同じポリシーへ」という発想の練習には Apple／iCloud のドメイン分流 も参考になります。

分流の設計では、DOMAIN-SUFFIX,googleapis.com と DOMAIN-SUFFIX,gstatic.com を同じポリシーグループ（例：GOOGLE_GEMINI_PROXY）へ揃えるのが第一歩です。次に accounts.google.com を DOMAIN で明示するか、職場用途なら DOMAIN-SUFFIX,google.com の広い行を許容するかを決めます。広い行は Gmail や検索まで巻き込むため、自宅用途でも巻き込み範囲と相談が必要です。ルールの書き方と順序の一般的な型は ルール分流のベストプラクティス に整理してあります。増え続けるホストは ルールセットで取り込みつつ、Gemini 固有の欠けだけを手元の短いリストで補うとメンテが楽です。

ライブ接続が読みやすい GUI を選ぶと、ログイン操作中の「未整理ホスト」を拾いやすくなります。クライアントの選び方 で、プロファイル編集とログの往復がしやすい製品を先に決めてから分流を詰めると、試行錯誤の回数が減ります。

最小ルール例とルールセット運用

下の YAML は出発点のイメージです。環境の proxy-groups 名に合わせ、ログに出たホストへ追記してください。DOMAIN-SUFFIX,google.com を入れると検索や Workspace まで同じ出口に乗る点に注意します。国内トラフィックは従来どおり GEOIP や国内リストで DIRECT に逃がし、Gemini 関連だけを束ねるのが典型です。

Illustrative YAML fragment

rules:
  - DOMAIN,accounts.google.com,GOOGLE_GEMINI_PROXY
  - DOMAIN-SUFFIX,googleapis.com,GOOGLE_GEMINI_PROXY
  - DOMAIN-SUFFIX,gstatic.com,GOOGLE_GEMINI_PROXY
  - DOMAIN-SUFFIX,google.dev,GOOGLE_GEMINI_PROXY
  - DOMAIN-SUFFIX,gvt1.com,GOOGLE_GEMINI_PROXY
  - DOMAIN-SUFFIX,google.com,GOOGLE_GEMINI_PROXY
  - GEOIP,JP,DIRECT
  - MATCH,DIRECT

gvt1.com はソフトウェア配信や計測で現れることがあり、製品版によっては更新チェックの一部として現れます。不要ならログで確認してから外します。ルールプロバイダを複数重ねると、更新順で意図しない行が上に来る事故が起きます。購読とノード保守 で、購読 URL とルールセット URL がプロキシループに落ちていないかも併せて確認してください。

TUN とシステムプロキシ：macOS での取り合い

Mac アプリは システムプロキシ を尊重する実装もあれば、独自のネットワークスタックで環境変数を無視する実装もあります。Clash 側が「システムプロキシモード」でも、アプリがプロキシを読まないとルールは効きません。そこで TUN で OS のルーティングテーブルに載せ、プロセスを問わず同じルール評価へ落とす方法が安定しがちです。併用時に拡張や別 VPN と衝突する典型は macOS の TUN とシステム拡張・プロキシ衝突 にまとめてあります。Gemini アプリだけ別挙動なら、まず TUN の有効／無効とシステム設定の「プロキシを使用」のオンオフを交互に試し、ライブ接続で同一ホストのポリシーが変わるかを見ます。

TUN を有効にしたあと「インターネット全体がおかしい」場合は、MATCH や国内リストの順序から疑うのが早いです。詳細な挙動の整理は TUN モード詳解 を参照してください。

DoH／fake-ip とドメインルールの整合

macOS 側で Private Relay やブラウザ DoH、Clash の fake-ip を重ねると、「名前は返ったのに証明書が合わない」「接続先 IP とポリシーが一致しない」といった症状が出ます。Google 系はサブドメイン数が多く、DNS のフォールバック順と nameserver-policy の設計がそのままログイン成功率に効きます。具体例と落とし穴は Clash Meta の DNS（nameserver／fallback／fake-ip） にまとめてあります。Gemini 用ルールを足したのに改善しないときは、ルール以前に どのリゾルバが答えているかを疑ってください。

企業ネットワークでは社内 DNS が公開ドメインを書き換えることがあり、その場合は Clash だけ直しても再現しません。IT へ渡すメモには、失敗ホスト名・得られた A／AAAA・Clash のポリシー命中行を添えます。

ログと検証：切り分けのキーワード

Clash / Mihomo 系のログでまず見るのは TCP 接続の成否、Router でのルール命中、DNS の応答コードです。i/o timeout が続くなら経路かノード、certificate や tls 行が混ざるなら名前と証明書の不一致を疑います。段階の読み分けは 接続ログの timeout と TLS がそのまま使えます。Gemini アプリのログイン中に *.googleapis.com だけ別ポリシーへ流れている、gstatic が REJECT に当たっている——そうした一行の差がスピナーの正体であることが多いです。

ルールは上から評価されるため、広い GEOIP や巨大カテゴリ行が Google 向けの具体行より上にあると、意図した分流が潰れます。更新直後に壊れたら、ルールプロバイダの版を一つ戻して差分を見るのが安全です。

ブラウザ版・AI Studio 記事との役割分担

当サイトの Gemini／Google AI Studio の分流 は、ブラウザと Generative Language API を横断するGoogle AI 全般の設計図です。本稿はその延長ではなく、ネイティブ Mac クライアントが踏みやすい OAuth・API・CDN の三層と、macOS 特有の TUN／システムプロキシに焦点を当てています。IDE 周辺のログイン話題は Cursor と Clash のログイン・タイムアウト が近いですが、対象プロセスとホスト集合が異なります。混ぜず、プロファイルを分けておくと後からの追記が楽です。

⚠ コンプライアンス：法令・組織ポリシー・Google の各種利用規約を遵守してください。本稿は許可されたネットワークでの経路衛生の話であり、不正アクセスや正当なセキュリティ回避を示すものではありません。

チェックリスト

  1. 利用地域・契約・職場方針で Gemini と Clash の併用が許可されているか確認する。
  2. ログイン操作中のホスト一覧を取り、googleapis.com・gstatic.com・accounts.google.com が同一ポリシーに揃っているか確認する。
  3. TUN とシステムプロキシの組み合わせを切り替え、ライブ接続でポリシーが変わるか比較する。
  4. DNS（DoH／fake-ip／社内リゾルバ）とルールの整合を Meta DNS の記事 の観点で点検する。
  5. 広い捕捉行が Google 向けの具体行より上に来ていないか確認する。
  6. 購読とルールセット更新がループせず成功しているか確認する。
  7. ルールを直したあとも失敗する場合のみ、ノード品質とベンダー側障害を切り分ける。

メモを残しておくと、次にアプリがアップデートでホストを増やしたときの差分追跡が楽になります。

まとめ

Gemini の Mac ネイティブアプリは、単一ドメインのチャット UI ではありません。OAuth・Google API・静的 CDNが短い連鎖で動き、Clash のドメイン分流で片道だけ別出口に落ちると、ログインが終わらないように見えます。答えは「全部海外へ」より、実測ホストを同一ポリシーへ束ね、DNS と TUN／システムプロキシの前提を一致させることにあります。

ルールセットでベースを取り、欠けたホストだけを手元で足す——このリズムは 2026 年の AI クライアント全般に通じます。ブラウザ版の整理は既存の Gemini／AI Studio 記事、macOS の衝突は TUN 記事、ログの読み方は timeout／TLS 記事へ分散させてあるので、症状に近い章から読み返すと迷子になりにくいです。

不透明な一括トンネルより、Clash の明示的なルールの方が初手は手間でも、再現性のある診断に落ちます。

→ 無料で Clash をダウンロードし、スピナーを眺める時間ではなく、Gemini の会話そのものに戻れるようにしてください。