Gemini CLI 拉包總逾時？Clash 分流 Google 與 npm 網域分步修復（2026）

1. 為什麼 CLI 場景和「只開 Gemini 網頁」不一樣

瀏覽器開 Gemini時，渲染頁面、OAuth 與一系列靜態資源往往自動跟著系統代理或擴充套件走；而 Gemini CLI是獨立行程：它可能同時向 Google 的 API 端點送請求，又透過 Node生態拉 tarball、執行安裝腳本。這些連線預設只吃作業系統解析與路由，不會因為你「瀏覽器看起來正常」就自動繼承同一套行為。當訂閱規則裡缺了某個子網域，或命中順序讓流量在 直連與代理之間切換，終端機就會出現前一次成功、下一次逾時的割裂感——這與單純「節點慢」不同，更像是路徑不一致。

Clash能做的是把 CLI 也納入可觀測的分流閉環：在 rules 前段寫清楚 Google AI與 npm registry要走哪個策略組，再用日誌核對實際命中的規則名稱。它無法替你解決API 額度、金鑰權限或上游故障，但能大幅減少「其實規則沒跟上」的假性 TLS／DNS問題。若你同時在意瀏覽器 QUIC 行為，可對照 Gemini 網頁分流與關閉 QUIC一文，兩篇合讀時請分清自己要修的是瀏覽器 HTTP/3還是終端機 TCP 為主的工具鏈。

2. 典型症狀：外掛、registry 與 API 同批不穩

實務上你可能看到：安裝延伸模組時畫面停在某個步驟很久；npm 報 ETIMEDOUT、ECONNRESET、或長時間卡在「fetching metadata」；同一段時間裡對 Google AI的呼叫也逾時或重試。若用瀏覽器測速「看起來正常」，卻只有 終端機不穩，首先要懷疑的是行程沒進 TUN／mixed-port、NO_PROXY誤排除、或某一條規則把 *.googleapis.com 類流量送去與 registry.npmjs.org 不同的出口，導致憑證鏈或連線重用行為不如預期。

先把期待說清楚：代理無法繞過帳號或地區政策，也無法保證每個 npm 套件伺服器全球同等快；目標是讓你已授權的流量穩定走你選的節點，並在 mihomo 日誌裡看見實際網域與命中規則，而不是只靠感覺換節點。接下來的網域表與 YAML 範例，都是為了讓這條路徑可重現。

3. 建議優先覆蓋的 Google AI 與 npm 網域

正式環境裡，唯一可信的主機名來源仍是本機連線日誌與 CLI 的 verbose／debug 輸出；下列為 2026 年常見、可作為起手式的整理，發現新主機名時請補規則、不要死背。googleapis.com 系譜很大，不建議一刀切整段代理或直連，除非你已評估對其他依賴 Google API 的本地服務的影響。

• Generative Language API：generativelanguage.googleapis.com；SDK 日誌若出現其他 *.googleapis.com，再逐條加入，避免過度寬泛。
• 開發者文件與入口：ai.google.dev、google.dev（依你實際頁面為準）。
• OAuth／帳號：若登入或重新授權異常，需同步檢查 accounts.google.com 等是否與 API 出口策略組一致，避免「已登入卻呼叫失敗」的假性狀態。
• npm 公有 registry：registry.npmjs.org； tarball 與 metadata 多由此主機名承載。若公司鏡像或自建倉庫，請改填實際 FQDN。
• 連帶 GitHub：若外掛從 GitHub release 拉二進位，可與 MCP／GitHub 篇併讀，避免規則散在多處難維護。

4. mihomo 規則與策略組範例

以下片段示範如何為 Gemini CLI與 npm建立共用或分拆的策略組，並把 DOMAIN-SUFFIX 放在GEOIP 或國內直連之前。範例採用單一策略組收斂出口，利於先排除「分裂路徑」；若你希望 npm 永遠直連、只代理 Google API，可再拆成兩個策略組並調整規則順序。請將節點名稱替換為訂閱中實際存在的代理；註解使用英文以利版本控管。

proxy-groups:
  - name: GeminiCLI-npm
    type: select
    proxies:
      - STABLE-A
      - STABLE-B
      - DIRECT

rules:
  - DOMAIN-SUFFIX,generativelanguage.googleapis.com,GeminiCLI-npm
  - DOMAIN-SUFFIX,ai.google.dev,GeminiCLI-npm
  - DOMAIN-SUFFIX,google.dev,GeminiCLI-npm
  - DOMAIN-SUFFIX,registry.npmjs.org,GeminiCLI-npm
  # Uncomment if OAuth splits across exits:
  # - DOMAIN-SUFFIX,accounts.google.com,GeminiCLI-npm
  # Add other *.googleapis.com seen in logs, avoid over-wide rules
  # ... GEOIP and MATCH below

5. 終端機代理：TUN、mixed-port 與環境變數

只有 規則正確仍不夠：node、npm、Gemini CLI行程必須真的把流量送進 TUN或 mixed-port / 系統代理。實務上開啟 TUN最常一次解決「GUI 有代理、Shell 沒代理」的落差；若你僅依賴環境變數，請確認 HTTP_PROXY、HTTPS_PROXY指向的值與用戶端顯示的監聽埠一致，且 NO_PROXY沒有把 googleapis.com、npmjs.org 等整段排除導致意外直連。

Windows 上若要把「國內 registry 直連、海外 API 走代理」拆得更細，可交叉閱讀 Windows npm／pnpm 環境變數與分流，把環境變數層與mihomo 規則層一起校準；本篇預設你先追求「Google AI 與官方 npm 同一穩定出口」，把間歇逾時壓下來，再視需求做拆分。若你也在用其他 IDE 外掛打開發者 API，可對照 Cursor 開發者網域一文，讓終端機與編輯器不要各走各的隧道。

6. DNS、Fake-IP 與規則順序如何一起校準

Fake-IP能把「先回假位址、再由核心依網域分流」的流程變快，但若 dns 區塊的 nameserver／fallback與 rules 的命中順序不同步，會出現「解析顯示成功、策略組卻不如預期」的錯覺——這在 終端機場景特別惱人，因為錯誤常被包進 fetch failed 或長逾時。建議通讀 fake-ip 與 redir-host 選型，並在調整 DNS 模式時一次只改一個變因，用同一組 npm ping 或 CLI 呼叫對照日誌。

此外，若瀏覽器或系統開着 安全 DNS／DoH，可能與 Clash 內建 DNS形成雙重解析，讓規則看起來「偶發失效」。本站 Windows 下關閉安全 DNS專文以瀏覽器為例說明觀念，終端機排錯時亦可借鏡：先讓解析路徑單純化，再談細緻分流。想建立完整規則觀念可讀 高級規則分流，把「為什麼 registry 明明該走代理卻直連」還原成可驗證步驟。

7. 實測驗證與清單

建議依序執行：①在除錯日誌開啟的狀態下重現一次逾時；②確認 generativelanguage.googleapis.com（或日誌中的實際 API 主機）與 registry.npmjs.org命中同一策略組；③核對終端父行程與 node 子行程是否都在 TUN 或同一代理下；④暫時關閉瀏覽器 DoH／分裂 VPN 做對照，排除雙重解析；⑤若使用 url-test且節點切換頻繁，觀察長連線是否被重置，必要時改手動固定或調整 url-test／fallback參數。

8. 常見問題

為什麼 Gemini CLI 和 npm 常常要設成同一個出口？外掛安裝與模型請求往往在相近時間觸發；若一條直連、一條走代理，TLS與DNS會分裂，終端機容易出現間歇逾時。先把兩條路收斂到同一策略組，再視需要拆細。

一定要改 npm registry 成鏡像嗎？未必。若官方 registry.npmjs.org可透過穩定節點連線，維持預設並用規則走對出口即可；鏡像是備援，不能取代「規則是否命中、終端是否進隧道」的診斷。