📖 教學 ⏱ 約 19 分鐘閱讀

Gemini CLI 總連線逾時？2026 年用 Clash 鎖終端請求網域與 DNS（分步實測）

如果你已經裝好 Clash（或Clash Verge Rev／Mihomo 核心），桌面瀏覽器看 Gemini大致順，換到終端跑 Gemini CLI（或相容 Google Generative Language API 的工具鏈）卻開始報請求逾時、無法完成 OAuth／裝置授權、或拉不到模型列表——多數不是你「運氣差抽到爛節點」，而是終端行程沒有走同一套代理決策，或oauth2.googleapis.com、generativelanguage.googleapis.com等鏈路上的某一段被規則早一步送去錯的出口、再疊DNS 分裂與fake-ip，外觀就會統一成莫名其妙的逾時。本站另一篇〈Google Gemini 網頁與一般 App〉偏瀏覽器體驗；本篇刻意對齊命令列／終端 AI：先證明流量真的進核心，再以連線紀錄對桶補規則、最後收斂Clash DNS。Clash 基礎教學入口若你仍需把訂閱、模式與系統 Proxy 對齊，建議並行翻閱。

症狀地圖：把「逾時」拆成可回收訊號

終端工具的錯誤訊息常只寫ECONNRESET、DeadlineExceeded或泛用的「請求逾時」，乍看像終端 AI品質問題。實務上你可以先把現象對照成三類：第一類是根本沒走到節點（直連撞上區域過濾、或走了不相容的出口）；第二類是多段請求中只有一段失手，例如身分驗證成功但後續對*.googleapis.com的呼叫被更早的規則改道；第三類是解析與真實握手指向不同終點，這在fake-ip與系統級 DoH／企業過濾並存時特別容易出現。接下來的流程都環繞：把「模糊的逾時」變成日誌上可念的網域名稱序列。

它和站內「Google Gemini 網頁」專文差在哪裡？

2026 年用 Clash 穩定存取 Google Gemini：規則與 DNS從使用者介面、Workspace 情境與瀏覽器 App出發；域名集合與本機行為對齊方式是很好的參照，但你若把終端問題直接「整段 YAML 複製貼上」，往往會漏掉兩件事：①命令列程式是否自動吃系統環境變數。②Gemini CLI 對OAuth 公開授權、令牌更新與discovery類 GET 請求的網域名稱順序可能與你瀏覽器分頁上的背景請求不同。請把兩篇文章視為同一套稽核心法、兩張不可互換的詞彙清單：Gemini CLI 逾時問題要以終端重現過程中的日誌擴充，而不是只靠記憶體中的「我上網能開就好」。

前置：證明「這個終端請求確實經過 Clash 核心」

最划算的第一步，是請你在重現問題的同一個 shell 裡，先搞清楚流量怎麼出門。許多 macOS／Linux 工作坊文件會叫你在終端export https_proxy=http://127.0.0.1:7890這類環境變數；但如果你實際的mixed-port根本不是 7890，或你只開規則模式＋瀏覽器系統代理卻未開 TUN，那麼 Chrome 仍可上網、Gemini CLI卻會直連到外面撞牆。WSL／容器／SSH 進遠端也會創造另一個網域命名空間，請不要假設宿主已代理就等於子環境自動繼承。

若你已經在 Windows 上使用圖形客戶端，對照本站Windows 11 下 Clash Verge Rev 首次安裝可把「系統代理 vs TUN」的覆蓋範圍先搞清楚；若在 macOS／Linux，可延伸閱讀Clash TUN 模式深度解析來理解為什麼有些行程不吃傳統 HTTP 代理。Gemini CLI常使用底層 HTTP 客戶端庫：TUN／透明接管往往比只靠手動HTTPS_PROXY更省事，但也更要求你的路由表沒有被第二個 VPN 搶走預設閘道——這點本站Tailscale 與 Clash類稿件已多次示範怎麼寫前置直連例外；若情境相近，可把「競爭中的本地虛擬介面網段」比照辦理，避免 OAuth 回合本該走低延遲路徑卻繞進非預期隧道。

💡 小提示 「代理群組是否存在、名稱是否跟規則裡一模一樣」仍然是硬門檻。若你對proxy-groups不熟，可先讀Clash 代理群組（proxy-groups）完全指南，再回到本文補終端視角的DOMAIN規則，避免規則寫滿但指向INVALID或空集群。

Gemini CLI／Generative Language API：日誌上常見的網域名稱類型（教學用起點）

下列主機類型為教學上合理的分桶草稿，不是 Google 的永久承諾——實際產品換 API 發現檔網址、身分供應商或灰度子域時，你仍要用當時那條 Gemini CLI產出的連線紀錄擴充。把它們想成協助你搜尋「Gemini CLI 逾時」「Google Generative Language API」時對得上的詞彙，而不是論壇上背下來的神秘咒語：

  • 身分與授權：accounts.google.com、oauth2.googleapis.com（以及視流程出現的其他 Google 身分相關子域）。這一段若被送去錯的出口，常會變成登入視窗怪怪的、令牌換不到。
  • 生成式對話基底：generativelanguage.googleapis.com（以及*.googleapis.com樹底下實際被叫到的細分子域）；CLI 對模型列出、streaming 或非 streaming 請求往往在這類主機收尾。
  • 發現／中繼資料與共通基礎設施：www.googleapis.com這類發現文件中繼資料主機在某些版本流程裡會出現；另有googleapis.com寬域名稱是否要整包走同一策略組取決於你想不想把無關的 Google Cloud API也一起帶過去。
  • 靜態與載入項：gstatic.com等有時會與身分頁載入共存；對純終端來說權重可能較低，但若你混用webview式登入協助套件，仍以日誌為準。
  • 開發者或 AI Studio 周邊（視你怎麼用 CLI）：ai.google.dev、入口型makersuite.google.com這類並非每一段 CLI 都叫得到，但若你的身分或金鑰引導過程嵌了文件或重新導向頁面，請不要看到不同主機就立刻當噪音刪掉。

對終端 AI來說，真正危險的是「登入過了、令牌檔也有了，但每次推理都卡住」：Gemini CLI可能在背景仍周期性地對 OAuth 進行換發；若那一段被 GEOIP／企業規則早一步劫持，你只會在主指令上看到泛用逾時。這也是為什麼本文堅持請先收集完整對話紀錄再往設定檔加料。

YAML 起手式範例：把「可能被誤射」的出口先對齊到同一組

下面示意如何在規則前段GEMINI-CLI-OUT接上你的proxy-group名字（請替換為你檔案中真實存在的群組標籤）；重點是順序與不要過早上 MATCH：GEMINI-CLI-OUT僅為示意占位符號。

# Example only — extend from your client logs, not forums
rules:
  - DOMAIN-SUFFIX,accounts.google.com,GEMINI-CLI-OUT
  - DOMAIN-SUFFIX,oauth2.googleapis.com,GEMINI-CLI-OUT
  - DOMAIN-SUFFIX,www.googleapis.com,GEMINI-CLI-OUT
  - DOMAIN-SUFFIX,generativelanguage.googleapis.com,GEMINI-CLI-OUT
  - DOMAIN,ai.google.dev,GEMINI-CLI-OUT
  - DOMAIN-SUFFIX,googleapis.com,GEMINI-CLI-OUT
  - DOMAIN-SUFFIX,gstatic.com,GEMINI-CLI-OUT
  - MATCH,Main

DOMAIN-SUFFIX,googleapis.com非常寬，會把許多和你本次終端對話無關的 Google API 一併帶進同一出站；若你想維護精簡規則，請在日誌中挑實際 TLS SNI／Host能對上的最細粒度條件改寫。若你看到嗅探結果與 SNI 對不起來（少數企業環境會這樣），可延伸本站Clash Meta 嗅探與分流例外釐清，而不是先手忙腳亂關一整包功能。

合規提醒 本文協助你從網路連通性與路由器設計角度看終端 AI問題，不涉及規避身分驗證、違反服務區域規定或任何形式的濫用。請遵守適用地區法律、組織資安規範與 Google／Gemini API 使用者條款。

Clash DNS 與 fake-ip：為什麼「CLI 對 DNS 超敏感」？

瀏覽器可把大量解析工作外包給複雜快取鍊；許多nodejs／go系 CLI 會相對耿直地相信你作業系統回給它的位址結果。這代表：當你同時開著系統級 DoH、路由器強制指向、與fake-ip模式時，Gemini CLI那條路徑如果沒對齊，症狀在 UI 上不會像在瀏覽器那樣好察覺。Clash DNS區塊的enhanced-mode、nameserver／fallback與對DOMAIN-SUFFIX,googleapis.com是否要給-nameserver-policy級別特殊處理，請以「減少解析分裂」為目標做小步實驗，而不是在同一個網路上同時維護三套互相覆寫的答案。

對 Linux 桌面上常見的systemd-resolved爭議，請把本站Linux Clash systemd-resolved 除錯當對照：Gemini CLI 逾時可能只是「這台機子上永遠有兩份 DNS”，而 Clash 以為自己已经接管，實際上另一個 Daemon 仍以更高優先級回覆。WSL讀者可延伸WSL2、Windows Clash專題，對齊「誰對誰 NAT、誰的 /etc/resolv.conf 才是真」這類問題，否則你會花上大量時間猜疑 API Key，卻無意中始終對錯 Nameserver。

分步實測：建議順序（可當 checklist 印在便條貼）

請避免同一輪調整動到「規則＋DNS＋訂閱＋VPN＋路由器」這五件事；這樣你永遠不知道哪一刀有效。可依序做：

  1. 固定重現情境：同一終端視窗、同一 shell 設定檔、同一種登入／金鑰方式，先跑一次最小的指令（列出模型或小額對話）。把錯誤碼複製備份。
  2. 先查核心日誌：看是否有對應的oauth2.googleapis.com、generativelanguage.googleapis.com條目，以及它被哪條規則命中。Gemini CLI如果完全沒有出現在日誌，代表問題還卡在「請求進不了核心」，回去檢環境與TUN／系統代理。
  3. 檢順序／訂閱覆寫：許多規則集習慣把早期GEOIP,CN,DIRECT或自定義國內直連區塊放很上面；一旦你某段 Google 區塊意外地落進直連或被送到不相容的出口，症狀就會統一成終端側逾時。Clash 自訂規則教學可協助你把我方覆寫與機場訂閱片斷分拆管理。
  4. 收斂 DNS：測試期暫時關閉會搶答的第三方加速器型 DNS／廣告封鎖工具的「DNS over HTTPS／VPN 內建 DNS」，只保留一條你信任且可對照 log 的道路，再復測Gemini CLI全流程。
  5. 對照 OAuth 折返埠：若問題集中在授權，網路上的討論區常忽略本機localhost折返被別的軟體占用或防火牆擋回的狀態；請與前述「終端請求是否真的進代理」並列為雙頭檢查，而不是馬上質疑gemini-cli版本。
  6. 交叉網路：在家用 Wi‑Fi、手機網路熱點各自測一輪，若只差其中一環，偏向路由器劫持或電信側策略，並非節點本身。

若你在 Windows 環境並且懷疑是「程式沒繼承 Proxy」而不是規則，亦可交叉閱讀本站Windows 11 系統代理與環形隔離對一般桌面應用行為的描述；雖然該篇主軸不在終端 AI，但對理解「為什麼你看到系統級開關了、程式卻沒進核心」仍然有幫助。

除錯心態：別把「換節點」當成唯一旋鈕

當問題被草率歸類成「API 國外慢」時，許多人會開始瘋狂切換東京／新加坡／美西，結果Gemini CLI 逾時紀錄還在原處。Google Generative Language API這類終點對延遲敏感，但更敏感的是路由一致性：同一串請求若在授權階段落到 A 國、資料面又到 B 國，身分或速率限制視角上就會像在打架。請先把出站策略組鎖成一個你願意長期信任的家族，再對照日誌看是否真有改善，而不是在每輪試誤順便扭動三到四個互不相同的參數。

常見問題

Gemini CLI 顯示已登入但仍經常換發失敗／逾時的原因？

令牌背景刷新也是 HTTP 請求：oauth2.googleapis.com若在規則上被過早DIRECT或REJECT，會讓你看到「前一晚還能用、今早全面逾時」。請把刷新期的日誌與白天的推理日誌當成一條時間線一起看。

我該為 CLI 強制 HTTPS_PROXY，還是依賴 TUN？

兩種都可行：HTTPS_PROXY好處是可精準控制單一 shell；壞處是很容易打錯埠或打到舊程式殘留的http_proxy小寫環境。TUN好處是覆蓋面大；壞處是要處理與別的 VPN／虛擬介面的路由競爭。對終端 AI日常開發來說，先選一種能讓連線紀錄出現對應主機命中的方案再長期優化會比較省時間。

規則寫得越寬會不會省事？

DOMAIN-KEYWORD,google這類規則在教學上看似浪漫，長期來看常把並非 Gemini的 Google Play、地圖、企業協作服務統一送走，換來的是延遲、授權風暴與難以審計的副作用。請堅持以日誌擴張而非以關鍵字盲補。

相較之下，許多終端 AI工作流程仍要求你獨立地維護多套設定檔、或把 SSH／容器裡的流量手動對齊到宿主mixed-port：Gemini CLI一類工具又特別常在 OAuth 與 API 之間反覆來回——只要其中一段沒對齊，外觀就全是連線錯。Clash生態優勢在於能把訂閱、路由、DNS與視覺化日誌收斂到同一決策環，對照規則命中路徑遠比在「零散 shell 環境」裡試誤更可預期；若你希望用能看清楚命中順序且貼齊 Mihomo／Meta 核心演進方向的客戶端整理Gemini CLI 逾時問題，不妨自本站下載區取得對應平台版本並依本文順序對表演練。→ 免費取得 Clash 安裝檔，親自驗證終端對 Google Generative Language API 的出站路徑。