為什麼原生 Mac App 比瀏覽器更容易卡在登入轉圈

瀏覽器分頁裡的 Gemini 若已能正常對話，並不代表同一台 Mac 上的原生應用程式會自動沿用完全相同的連線路徑。桌面 App 常以獨立程序身分發起連線：可能遵循 macOS 的系統代理，也可能在部分網路堆疊下繞過你以為已開啟的 HTTP 代理，而改走系統預設路由。當 Clash 只對瀏覽器流量做了細緻網域分流，但 App 端的 googleapis.com、gstatic.com 或 OAuth 相關主機命中了另一個策略，畫面上最常見的就是登入卡住：轉圈動畫不消失、或驗證完成後仍回到空白狀態。

另一個放大器是 Google API 與靜態／CDN資源並行：登入流程可能在短時間內依序命中 accounts.google.com、oauth2.googleapis.com、各種 *.googleapis.com，同時下載圖示、字型或設定片段時又打到 gstatic.com 或 Google 邊緣網路上的主機名。若其中一條連線在跨境鏈路上逾時，UI 往往不會精確指出是哪個主機失敗，而是統一呈現「載入中」。因此排障第一步，是把問題從「App 壞了」改寫成「哪個主機名、命中哪條規則、是否與 DNS 解析一致」。macOS 上若同時啟用系統延伸與其他 VPN，路由爭奪也會讓症狀更像隨機；可先對照 macOS TUN 與系統延伸功能 釐清本機堆疊，再回頭看規則。

下文假設你已確認在所在地與 Google 服務條款下有權使用 Gemini 與相應網路出口；若雇主或校園網路禁止代理，請勿嘗試繞過資安政策。若你更在意瀏覽器與 AI Studio 場景，請優先閱讀 Gemini／AI Studio 網域分流，再把此篇當作原生用戶端補篇。

ℹ 先分層：把「App 是否走 Clash」「DNS 由誰回答」「googleapis 與 gstatic 是否同一策略組」「MATCH 預設去哪」分開核對。登入轉圈多半是其中一層錯位，而不是單一「節點壞了」可解釋。

本站 Gemini／AI Studio 網域分流 已從網頁與 API角度整理 googleapis.com、google.dev、gstatic.com 與規則順序；本篇刻意改從桌面端 App 流量切入：強調系統代理語意、TUN 接管、以及登入鏈上「帳號端點＋API＋CDN」三者要同一策略意圖，否則最容易卡在轉圈。兩篇可並存於你的設定註解裡，但請勿把瀏覽器專用的最小規則直接假設能覆蓋 App。

規則表一拉長，維護成本就上升。建議搭配 規則分流最佳實踐，維持「由上而下匹配、寬規則不遮擋細業務」的結構；並用 客戶端選型 挑一款連線日誌可讀、能清楚顯示進程或主機名的發行版，否則你很難證明是 App 沒走代理，還是規則漏了 CDN。

登入、同步與更新常見主機名：Google API、帳號與 CDN

下列主機名僅作觀測與規則設計的出發點，實際產品會隨版本與地區調整子網域；請務必以你本機連線日誌與官方文件為準。登入與權杖交換常見於 accounts.google.com、oauth2.googleapis.com、以及各種 *.googleapis.com 下的服務別名；模型或產品後端呼叫則高度依賴 Google API 命名空間。介面資源、說明圖、或部分設定片段常落在 gstatic.com，若此路徑被誤判為應直連卻在弱路由上逾時，使用者體感仍會是「登入頁轉不停」。部分更新檢查也可能走獨立的 googleapis 服務或 Google 邊緣主機，這正是為什麼「只寫一條 gemini 主網域」往往不夠用。

實務上可先在日誌中蒐集實際出現的完整主機名，再決定用 DOMAIN 精確命中，或謹慎使用 DOMAIN-SUFFIX。過寬的 DOMAIN-SUFFIX,google.com 會把整個 Google 主站與子服務全掃進同一策略，副作用大；過窄又會反覆遇到登入卡住。若你使用 fake-ip，還要確認嗅探與過濾清單是否與這些主機一致，必要時參考 Fake-IP 與嗅探 一文，避免「解析看起來正常、連線卻永遠等不到」的假性健康。

Clash 最小規則集示意與寬規則副作用

下面是一段示意用 YAML 片段：展示如何把 Google API、常見靜態後綴、以及開發者文件樹放進同一策略組（名稱請依你的訂閱修改）。是否加入整段 google.com 後綴屬於高風險寬規則，請自行衡量；較保守做法是先用日誌列出登入期間實際出現的 accounts.*、oauth2.* 等，再以 DOMAIN 逐步補齊。

Illustrative YAML fragment

rules:
  - DOMAIN-SUFFIX,googleapis.com,GOOGLE_APP
  - DOMAIN-SUFFIX,gstatic.com,GOOGLE_APP
  - DOMAIN-SUFFIX,google.dev,GOOGLE_APP
  - DOMAIN,accounts.google.com,GOOGLE_APP
  - DOMAIN,oauth2.googleapis.com,GOOGLE_APP
  - GEOIP,CN,DIRECT
  - MATCH,DIRECT

重點不在「抄這幾行就萬能」，而在於：googleapis.com 與 gstatic.com 必須與登入鏈同一策略意圖，並在 規則順序 上避免被不相關的寬規則提前命中。若你把 規則集托管在遠端 URL，也要確認更新成功，否則新子域一出現就回到轉圈狀態。

DoH／DoT、fake-ip 與路由決策對齊

macOS 與部分 App 可能各自啟用 DoH／DoT，與 Clash 內建的 DNS 模組並存時，最容易出現「解析結果與路由決策不一致」：規則以為要直連，應用卻拿到另一組位址；或 fake-ip 還原失敗導致連線懸掛。建議在排障窗口內暫時統一 DNS 出口，並檢查 fallback、fake-ip-filter 與 nameserver-policy 是否涵蓋 Google 相關域。更完整的參數脈絡可讀 Meta DNS、fallback 與 fake-ip 過濾，把「DNS 層」從「代理層」拆開思考。

當你觀察到登入完成後反而卡住，優先懷疑 OAuth 回跳之後的第一個 googleapis.com 呼叫是否仍命中預期策略；此時對照 連線日誌與 TLS／逾時層級，比盲目更換節點更有效。

TUN 與系統代理：App 是否真的經過 Clash

若你僅開啟系統代理，而 Gemini Mac App 實際上未尊重該設定，則規則寫得再漂亮也不會生效；此時可評估改以 TUN 在系統層接管路由，讓 App 無法悄悄繞過。TUN 會改變預設路由與延伸功能權限模型，實作前請讀 TUN 模式深度解析，並與 macOS 系統延伸功能 一文對照，避免與公司 VPN 或防火牆軟體互相打架。

另一種常見情況是：App 已走代理，但規則集版本過舊，新 CDN 主機落在預設 MATCH 直連上，於是跨境鏈路抖動時仍表現成轉圈。這不是 TUN 與否的問題，而是清單維護節奏問題。

連線日誌關鍵字與可重現驗證清單

在連線日誌或除錯輸出中，建議關注：dial tcp 逾時、i/o timeout、TLS 握手失敗、以及 RST。當你看到某一主機名反覆在數秒內重試，卻沒有完整 TLS 完成記錄，多半是路由或 SNI 相關問題。請同步記錄「該連線命中哪條規則／哪個策略組」，並與 規則表順序 對照，確認沒有被 GEOIP 或其他寬規則提前截走。

可重現的最小實驗包括：僅在開啟 App 登入時擷取一段日誌、關閉其他併發大流量、以及暫時停用會改寫 DNS 的其他工具。若同帳號在瀏覽器可登入而 App 不行，對照兩邊日誌主機名差異，通常能在一輪迭代內縮小範圍。

訂閱、規則集更新與循環代理

若系統代理把 Clash 自己的訂閱或規則集下載請求也送進代理鏈，可能導致清單長期無法更新，新 CDN 主機永遠進不了規則集。請為更新域名保留可靠的直連或獨立策略，細節見 訂閱與節點維護 與 訂閱更新錯誤與快取。當症狀是「某天集體開始轉圈」，優先檢查規則集時間戳與更新日誌，而不是先換節點。

⚠ 合規提示：請遵守所在地法律法規與 Google 服務條款（含 Gemini、帳號、API 與地區限制）。本文僅作技術說明，不鼓勵未經授權的存取、繞過組織安全策略或任何違法用途。

合規環境下的自檢清單

  1. 確認當前網路環境允許使用 Clash 與 Google 相關服務。
  2. 校準系統時間，排除 TLS 與憑證誤判。
  3. 在登入轉圈期間擷取連線日誌，列出實際主機名與命中規則。
  4. 核對 googleapis.com、gstatic.com、帳號相關主機是否落在同一策略組。
  5. 檢查 DNS／DoH、fake-ip 與嗅探是否與路由決策一致。
  6. 驗證僅系統代理、僅 TUN、或兩者組合時 App 行為是否一致。
  7. 確認訂閱與遠端規則集更新成功，無循環代理。
  8. 對照瀏覽器登入與 App 登入的主機差異，縮小漏規則範圍。

把每一步變化寫進筆記，可重現的實驗比反覆重裝 App 更能穩定收斂問題。

結語：把「登入卡住」還原成可核對的命中

Gemini Mac 類產品在代理環境下若出現登入卡住，本質上多是 Google API、帳號端點與 CDN 路徑在 Clash 裡命中不一致，或 App 未按預期走代理。把觀測重心放在主機名、規則命中與 DNS 三者的對齊，你能用網域分流與規則集維護一份可驗證的設定，而不是把不穩定全推給「節點品質」。與 瀏覽器／AI Studio 專文 併讀時，記得在註解裡標註適用場景，避免日後混淆。

相較一鍵全局代理，願意維護一小段針對 Google 命名空間的策略組，長期回報是：當 Google 調整子網域或邊緣節點時，你能用日誌快速補規則，而不是反覆猜測「是不是今天又掛了」。若你希望把轉圈還原成證據鏈，先從連線紀錄與規則命中開始，再決定是否調整出口。

相較僅依賴瀏覽器分流經驗，為原生 Mac 用戶端單獨保留一小節網域分流與 TUN／系統代理組合說明，能顯著降低「同帳號瀏覽器可用、App 卻不行」的認知落差。當你把每一條連線都對到策略意圖上，Gemini 桌面端的體驗會更接近你在瀏覽器裡已習慣的穩定度。

→ 立即免費下載 Clash，開啟流暢上網新體驗，用可維護的規則集與網域分流，把 Gemini Mac 登入鏈上的 Google API 與 CDN 握在可核對的設定裡，而不是交給無止境的轉圈與猜測。