為什麼「只有終端機裡的 Gemini CLI」特別容易逾時或報 OAuth／TLS 錯誤
2026 年開發者談論終端 Agent 時，除了 Claude Code、OpenAI Codex、Cursor 相關工具鏈之外，Gemini CLI這類由 Google 主推、在本機指令列互動的助理同樣常被並列討論。它表面上只是一個 CLI，背後卻會對外發起多段 HTTPS，指向 Google AI API（Generative Language API）的主要端點 generativelanguage.googleapis.com，並在登入、更新權杖或下載相依資源時觸及其他 *.googleapis.com、oauth2.googleapis.com、accounts.google.com 與可能用到的 *.gstatic.com 類網域。只要其中任意一段在 Clash 規則裡被送回 DIRECT（直連），或 TLS 交握在錯誤的出口上反覆重試，你在畫面上看到的就會是長時間無回應、間歇性逾時，甚至是看似與網路無關的憑證／授權失敗。
與透過瀏覽器操作 Google AI Studio相比，終端機場景還多了一層複雜度：執行 CLI 的行程不一定會讀系統 Proxy；即使 macOS 或 Windows 已經把 HTTP／HTTPS 代理指向本機 mixed-port，某些語言執行環境仍可能只吃 HTTPS_PROXY／ALL_PROXY，或被工具鏈在更深層略過。當你使用 Clash Verge Rev這種以 Mihomo（Clash.Meta）為核心的圖形用戶端時，最有效的起手式不是立刻開全域 TUN把所有流量硬接管，而是先用分流規則把上述 Google 相關主機穩定導向你信任的代理策略群組，再在必要時補齊終端機環境變數——這也是本篇標題裡「規則與環境變數實測」真正在意的事情。
接下來我會依同一套你在 Claude Code × Verge Rev、Codex × Verge Rev 系列文章裡已經熟悉的順序說明：如何用連線紀錄抓到「漏網之魚」、如何把 YAML 裡的規則順序調到合理位置，以及 HTTPS_PROXY 該寫進哪些啟動脈絡才能在多視窗、多 IDE、多背景工作中保持一致。你在搜尋「Gemini CLI 代理」「Google AI API 逾時」「generativelanguage.googleapis.com 連不上」時看到的零散片段，最後多半會收斂到這三個旋钮：規則、系統代理模式、環境變數所在的 shell／行程樹。
規則分流與全域 TUN：什麼時候用哪一種
先把責任切開：規則分流回答「這個目的地網域要走哪個策略」；系統代理／TUN回答「有多少比例的連線會真的進到 Clash」。在 Clash Verge Rev 的日常使用中，多數開發者會先開啟系統 Proxy，讓支援系統設定的程式自動把 HTTP 流量送到本機監聽埠；只有在規則怎麼改都像沒命中、或連線列表完全看不到 Gemini CLI 相關請求時，才把TUN 模式當成「放大鏡」來驗證路由層行為，而不是預設開到底。
| 模式 | 優點 | 風險／成本 | 較適合的訊號 |
|---|---|---|---|
| 規則分流＋系統代理 | 精準、對本機服務影響較小；便於把設定片段貼進團隊文件或共用 gist | 需維護網域清單與順序；不吃系統 Proxy 的程式要另外 export | 連線紀錄已有請求，但策略欄位顯示 DIRECT |
| 全域 TUN | 能涵蓋更多忽略環境變數的底層連線；利於 A／B 對照 | 與公司 VPN、零信任客戶端或其他路由程式並存時較易打架 | 規則看似正確，但特定子行程仍從意外出口離開 |
| 僅手動環境變數 | 對單一倉庫或一次性指令能快速試錯 | 在多個終端機分頁、CI 本機模擬器與 IDE 之間容易漂移 | 你已確認只有某條指令需要硬指定 Proxy |
實務判斷可以很機械：連線清單完全沒有 Google API 相關條目 ⟶ 先檢查系統代理開關與埠號是否對齊 Verge Rev；清單有條目但策略錯誤 ⟶ 先調規則集順序與精確 DOMAIN；策略正確但延遲或逾時仍頻繁 ⟶ 再往節點品質、IPv6 雙棧、時間同步與遠端限流方向查。
開始改設定前請先對齊的三個事實
想把「改了 YAML 卻完全沒反應」機率壓低，請先確認：
- 目前生效的是哪一份設定檔？Verge Rev 常有訂閱合併檔、本機覆寫與「啟用中」設定並存；請在 UI 確認你編輯的那份已被載入與套用，而不是僅存檔未切換。
- mixed-port 是否與
HTTPS_PROXY／IDE 設定一致：升級或還原備份後埠號變更是常見陷阱；舊的7890、新的混合埠、或拆分監聽都要與實際 UI 對過。 - 是否有第二套 VPN／零信任／安全軟體同時改寫路由：兩套程式搶路由時，連線紀錄可能在 Clash 端看似正常，封包卻在另一層被攔截；排錯期建議暫時維持單一路徑。
第一步：用連線紀錄定位「是哪個 Google／googleapis 主機在直連」
打開 Clash Verge Rev 的即時連線檢視，在另一個終端機視窗重現一次會失敗的 Gemini CLI 操作（例如會觸發模型呼叫、金鑰驗證或 OAuth 更新流程的子命令）。當錯誤訊息出現或長時間卡住時，立刻在列表中以關鍵字過濾：
generativelanguage.googleapis.com：對應 Generative Language API 的典型主機名；有些版本或相依套件也可能直接打到其他*.googleapis.com路徑。oauth2.googleapis.com、accounts.google.com：授權或瀏覽器輔助登入流程常見跳轉；若規則把它們留在 DIRECT，可能出現「偶發登入失敗」而非立即連線錯誤。gstatic.com、googleusercontent.com：下載靜態資源或使用者內容相關連線時可能出現；是否需要代理視你的網路環境而定，請以連線清單中反覆出現的紀錄為準。
若條目顯示 DIRECT，但它明顯是你希望走海外出口的低延遲／高頻寬類型連線，請把辨識出的完整主機名稱或可靠的後綴記下來，準備接到下一節的策略群組。若列表裡完全沒有這類條目，請優先懷疑請求沒進 Clash：回到系統代理開關、CLI 是否略過本機 Proxy，再決定要不要暫時啟用 TUN 做對照。
這種「以自己機器上的連線紀錄為真」的方法，比從論壇複製一份宣稱完整的網域表可靠得多：你的訂閱規則集版本、DNS 模式與公司網路策略都可能與他人不同；把觀察結果固化成幾行 YAML，比追逐永不更新的懶人包更符合 2026 年終端 Agent 迭代的速度。
第二步：把 Google AI API 相關後綴接到正確的策略群組
下方片段僅為結構示意，請將 PROXY-GROUP-YOU-USE替換為你設定檔內實際存在的策略群組名稱（例如 🚀 節點選擇）；並將整段放在會一次吃掉大型 CDN、雲端供應商或區域直連的規則集之前，避免永遠匹配不到。
# Example — replace PROXY-GROUP-YOU-USE; keep above broad DIRECT / CN rule-sets
DOMAIN-SUFFIX,generativelanguage.googleapis.com,PROXY-GROUP-YOU-USE
DOMAIN-SUFFIX,googleapis.com,PROXY-GROUP-YOU-USE
DOMAIN-SUFFIX,google.ai,PROXY-GROUP-YOU-USE
DOMAIN-SUFFIX,accounts.google.com,PROXY-GROUP-YOU-USE
DOMAIN-SUFFIX,oauth2.googleapis.com,PROXY-GROUP-YOU-USE
# Append DOMAIN-SUFFIX lines you observe in Verge Rev connection list
為什麼先寫 generativelanguage.googleapis.com再談整包 googleapis.com？因為後者的流量形態非常廣，某些團隊會希望「只有開發相關 API 走代理，其他 Google API 維持直連」；若你把過大的後綴一刀切的同時又沒做好順序與例外，可能反而拖慢不相關服務。實務上仍可先用較寬鬆後綴完成可用性驗證，確認 Gemini CLI 穩定後，再依連線紀錄縮窄到你真正需要的集合。
若你使用上游維護的 RULE-SET，請特別檢查是否含有把通用雲端 IP 段或特定國家／地區GEOIP規則放在很前面的版本；開發者 API 類服務最常卡在「粗大規則先匹配」。解法通常是上移精確 DOMAIN-SUFFIX，而不是盲目刪除整套訂閱。
搭配 fake-ip 或細緻 DNS 政策時，若解析結果與預期區域不一致，也要同步檢視 nameserver 分流是否把特定網域送進易被污染的解析路徑；否則表面規則正確，TLS 仍可能在錯誤 IP 上來回抖動。
第三步：HTTPS_PROXY／ALL_PROXY 應該寫在哪
「環境變數寫在哪」等同於在問：是哪個父行程啟動了正在跑 Gemini CLI 的那個 shell？常見情境如下：
- macOS／Linux 互動式 zsh／bash：將
export HTTPS_PROXY=http://127.0.0.1:<mixed-port>與對應的HTTP_PROXY寫進實際會被載入的~/.zshrc、~/.bashrc，或以source拆檔管理；若使用終端機多工器，請確認每個 pane 都是在修改後新開的工作階段。 - IDE 內建終端：有些整合式終端繼承 GUI 行程環境而非登入 shell；可在 IDE 設定中加入啟動前指令，或用 wrapper 腳本先 export 再啟動子行程。
- Windows PowerShell／cmd：可用
$env:HTTPS_PROXY="http://127.0.0.1:埠"做單次驗證，確認無誤後再寫入使用者或系統環境變數；留意服務帳戶與一般使用者隔離。 - 排程與背景服務：launchd、systemd user unit、工作排程器中的指令預設不一定載入互動式設定檔；請在單元檔以
Environment=或在腳本最上方 export。
實務上我會同時觀察工具鏈是否讀 ALL_PROXY，並以 NO_PROXY保留 127.0.0.1,localhost,::1與公司內部網段，避免把內部 Git、套件倉庫或區網測試機誤送往海外節點。
第四步：用 curl 與實際 Gemini CLI 做最短驗證迴圈
調整規則與環境變數後，建議依序進行：
- 使用
curl -v並透過--proxy http://127.0.0.1:<mixed-port>對https://generativelanguage.googleapis.com做一次不含私密金鑰的連線探測（僅驗證 TLS 與路由鏈路是否暢通）。若此步失敗，問題多半在本機代理或節點，而非 CLI 參數。 - 撤除
--proxy，在「與平常相同」的 shell 環境下重跑；若此次失敗而前一步成功，代表 Gemini CLI 或其相依程式沒有吃到系統 Proxy／環境變數，應回到上一節調整啟動脈絡。 - 最後再執行會實際呼叫 Google AI API的 Gemini CLI 指令，邊觀察 Verge Rev 連線清單的策略欄位是否符合預期；若策略正確但延遲仍高，再切換節點或檢查 HTTP／2、IPv6 相容性。
這個迴圈能把問題從模糊的「網路不穩」拆成可描述分支：代理鏈故障、規則漏網、環境脈絡錯誤，或純粹遠端限流與節點品質。
第五步：訂閱品質與節點型態如何放大「逾時感」
即使規則與環境變數都對了，下列因素仍會讓終端 Agent「感覺一直在逾時」：
- 長連線與多次往返：助理型 CLI 往往在單次使用者輸入背後連發多段請求；若節點對長連線或特定 TLS 指紋不友善，錯誤常以逾時呈現。
- IPv6 與雙棧：部分網路會讓 AAAA 記錄走不同出口；值得在路由器或核心設定中暫時觀察 IPv6 行為與實際命中策略。
- 時間不同步：系統時鐘偏差會讓憑證鏈驗證看似「偶發網路問題」；虛擬機與雙系統切換後尤應先校時。
仍未解時可再對照的快速清單
- 連線紀錄完全沒有 Google API 網域：優先檢查系統代理開關、mixed-port 是否被占用、CLI 是否內建忽略 Proxy。
- 規則已寫卻仍 DIRECT：檢查是否被更前面的 rule-set／GEOIP 匹配；把連線清單裡的主機名稱再上移。
- 同一網段他人正常只有你異常：檢查本機 SSL 解密、公司安全代理或 Hosts 是否改寫解析。
- 只有在特定節點出問題：先更換後端再談規則，避免把節點故障誤判成 YAML 錯誤。
為什麼開發者場景下，Clash 生態比封閉加速器更好收斂
許多「一鍵加速」類工具把應用清單寫死在自家程式裡，當雲端供應商調整子網域或 CDN 時，你只能等待更新；對需要頻繁呼叫 Google AI API、同時還得連公司內網與套件倉庫的終端 Agent 工作流程來說，這種黑箱會放大不確定性。Clash搭配 Clash Verge Rev與 Mihomo核心，讓你能用同一套可版控的設定，在「看得到連線紀錄」的前提下迭代分流規則，並用 HTTPS_PROXY精準補強終端脈絡——當下一個模型後端或區域路由再變動時，多半是調整幾行規則就能跟上，而不是整套重裝。
相較把全部網路行為押在全域 TUN或單一系統旋钮，強調規則與環境變數並用的作法，對長時間開著代理寫程式的人通常更省力：對外 API 走穩定出口，內網與本機測試維持直連，問題發生時也更容易還原真實路徑。Clash Verge Rev提供的圖形介面只是把這件事變得可視——底層仍是你能理解、可在團隊共享的規則與環境變數實測流程。