為什麼 Gemini CLI 在終端機特別容易「時好時壞」？
2026 年之後，把大型語言模型接進編輯器與工作流程的工具越來越多，其中一大類就是跑在終端機裡的 Gemini CLI 與各種 terminal AI CLI。它們看起來只是「打一指令就跑」，實務上卻比一般瀏覽器上網更挑網路路徑：長連線、大量小封包、TLS 與憑證鏈驗證、偶發的 HTTP/2 或 QUIC 行為，只要代理規則或 DNS 路徑出現抖動，就容易變成你肉眼看到的那種「一下子成功、下一次同樣指令卻卡住」。
更棘手的是行為不一致：Chrome 或 Edge 可能因為走系統代理、擴充套件或內建的 Secure DNS 而「看起來正常」，但終端機裡的 node、python、go 行程未必會遵循同一套路。此時若只以「網頁能打開」當判準，往往會誤判問題已解決。
這篇文章假設你已能使用Clash Verge Rev 的基本設定流程（訂閱、規則模式、DNS 概念），把焦點放在如何把 Gemini CLI 這類終端工具放到一條可預測、可驗證、可回歸排查的鏈路上。文內提到的域名與埠號請以你實際訂閱與本機設定為準；重點是方法而非某一組魔術數字。
先分類「斷線」訊號：逾時、拒絕、還是身分驗證？
在開始改設定前，建議先用二分法理解錯誤：它是連不上（網路／TLS／代理），還是連得上但被服務端拒絕（配額、金鑰、地區政策、帳號狀態）。兩者的處理完全不同；如果你把 401、403、配額用盡當成「代理不穩」一路調堆疊，往往會越看越混亂。
對於典型網路問題，終端機常見表象包括：卡住很久後才失敗、間歇性 RST、TLS handshake timeout、i/o timeout、偶發的 dial tcp 錯誤。這類更像路徑或節點品質問題，才與 Clash 的規則命中、TUN 接管、DNS 收斂高度相關。
另一個終端機常見坑是走了代理卻仍解析到不合適的目標：例如解析長期落在 ISP DNS、或被本機快取卡住，導致「規則看似正確，但實際連線目標與你想像的不同」。因此後半段會刻意把 DNS 與規則放在一起談，而不是把它當成獨立的「網路小白話題」。
第一步：確認訂閱可用，並切換到規則模式
請先完成最基本盤查：Clash Verge Rev 是否正在執行、訂閱是否已啟用、代理頁能否測到可用節點。若這裡就不穩，後面做再漂亮的域名規則也救不了。
接著把模式切到 Rule（規則）。目的很單純：讓「在地服務／內網／常用國內站」維持直連，把需要跨區或跨廠商 API 的流量送到代理，減少過度全域代理帶來的副作用，也降低某些站對資料中心出口的風控敏感度。
若你暫時需要判斷問題是否與規則無關，可以短時間切到 Global 做對照實驗，但不建議長期開著；一旦確認方向，就應回到 Rule，並用更精準的規則補齊，而不是靠全域模式掩蓋分流不足。
第二步：把 Gemini／Google API 相關域名放到「確定會走代理」的位置
Gemini CLI 這類工具通常會打到 Google 的生態系端點（實際域名隨版本更新而變動，以下舉例供你檢查清單時對照）：像 generativelanguage.googleapis.com、*.googleapis.com、以及與開發者入口或金鑰流程相關的頁面域名。你要的不是背域名，而是建立一個可維護的習慣：在日誌看到新的目標主機名時，能把它映射回規則與群組。
用 Merge Override 精準補規則（不必手改整份訂閱）
多數使用者不應直接編輯訂閱下來的原始 YAML（一更新就被覆蓋）。較好的做法是沿用 Clash Verge Rev 的 Override → Merge，追加一小段規則即可。概念範例（請把 PROXY 換成你訂閱裡實際的代理群組名稱）：
rules:
- DOMAIN-SUFFIX,googleapis.com,PROXY
- DOMAIN-SUFFIX,google.com,PROXY
- DOMAIN-KEYWORD,generativelanguage,PROXY實務上你可能會想比這更細：例如只讓 API 子網域走代理、或把下載大型相依與 API 呼叫分到不同群組。但無論多細，核心原則仍是：讓 CLI 會打到的主機名在規則層有明確歸宿，避免落到最後的「兜底 DIRECT 或兜底 REJECT」而製造隨機性。
第三步：啟用 TUN，讓「不吃系統代理」的行程也被接管
只開「系統代理」時，許多 CLI 仍然直接對外連線。這正是「瀏覽器沒問題、終端機卻怪怪的」高頻原因之一。TUN 模式會建立虛擬介面，在更底層接管路由，使大量 TCP／UDP 仍必須經過 Mihomo 核心處理；對 Gemini CLI、git、容器工具鏈、遊戲與語音這類程式通常更一致。
啟用步驟與權限
在設定裡開啟 Tun／TUN，依提示完成授權。Windows 常見需要管理員權限或重新安裝虛擬網路卡服務；macOS 可能要求輸入密碼以允許系統延伸。若一開啟就全機斷網，先別急著怪節點：關掉 TUN確認能否恢復，再回到訂閱可用性與防火牆攔截逐項縮小範圍。
堆疊（Stack）怎麼選
如果介面提供 Mixed、gVisor、System 等選項，建議先用Mixed作為預設；遇到特定 UDP 行為或極少數程式異常時，再嘗試 System 或 gVisor。請把每次變更與日誌片段一起記錄，否則隔兩天你一定會忘記「當時到底是哪一改生效」。
第四步：收斂 DNS，降低「解析路徑分裂」帶來的假不穩
當你使用 fake-ip 時，核心會在本機先做一層域名到「虛擬 IP」的映射，再依規則決定後續連線；這對規則一致性通常很有幫助。若你改成 redir-host，等於是更偏向「先解析再分流」，某些工具會更直觀，但你也要更認真面對上游 DNS 的選擇與快取。
一個實用原則是：不要讓 CLI 還在用一套、瀏覽器卻用另一套 DNS-over-HTTPS，然後你用網頁檢測工具得出「看似乾淨」的結論：那並不能證明終端機行程等同。
你可以在覆寫裡加入類似下列骨架（上游請換成你信任且可穩定連線的解析；細節請依你訂閱與風險偏好調整）：
dns:
enable: true
enhanced-mode: fake-ip
nameserver:
- https://dns.cloudflare.com/dns-query
fallback:
- https://dns.google/dns-query
fake-ip-filter:
- '*.lan'
- '*.local'改完務必重新載入設定檔，並觀察日誌裡與 DNS 相關的訊息是否減少異常。
第五步：對齊終端機的環境變數，補上「明確會讀代理」的程式
即使 TUN 已開，有些工具仍會對「環境變數裡的 HTTP(S) 代理資訊」更敏感，或在某些平台上需要明確指定。常見做法是設定（埠號請改用你本機 Clash 的 mixed port／HTTP port，以下僅為範例）：
export https_proxy=http://127.0.0.1:7897
export http_proxy=http://127.0.0.1:7897
export all_proxy=socks5://127.0.0.1:7897同時請設定 NO_PROXY，把 localhost、127.0.0.1、公司內網網段、以及你不想走代理的域名排除掉；否則會出現奇怪的慢速或憑證錯誤。
若你使用 fish、PowerShell、Windows Terminal 或多套 shell，請確認你是在「實際啟動 Gemini CLI 的那一層 shell／服務」注入變數；IDE 內建終端機有時會讀不同設定檔，這也是「同一台機器上兩種結果」的來源。
第六步：用可重現的指令與日誌把問題釘死
當你宣稱「比較穩定」時，最好拿得出可重複執行的證據鏈。建議至少準備三組對照：
- TLS 與 HTTP 行為：對關鍵域名做
curl -v（或你熟悉的等價工具），觀察是卡在 DNS、TCP，還是 TLS。 - 解析結果：用
dig或指定 resolver 的方式對照，避免只看到「某一次的快取結果」。 - Clash 日誌：確認命中規則、實際走的群組，以及是否有重複重試。
你也可以把「成功／失敗」各收集一段日誌與時間戳，未來若訂閱商換節點或家裡網路改版，你仍能快速判斷是新變數造成，而不是 Gemini CLI 本身「無故變壞」。
第七步：把線路本身變穩：節點、自動選線與尖峰時段策略
規則與 TUN 做的是「把封包送到正確的管道」，但管道會不會塞車仍取決於節點供應與當下出口品質。對長時間跑 CLI 的使用者，我會建議：
- 盡量用訂閱內建的 URL-Test／自動選線群組，讓客戶端能依延遲或規則做更動態的切換。
- 避免迷信單次延遲測試：短時間很低不代表長連線穩定；要看實際工作負載下的掉包與重試。
- 把高峰時段的不穩視為正常隨機因素：你要做的是用日誌把它量化，而不是靠感覺反覆手動換節點。
最後補一句很務實的話：再強的工具也無法把「完全不存在的網路」變成可用；但一個好的代理堆疊至少能讓你分清楚哪些是基礎設施上限、哪些是設定可改進之處。
第八步：寫成一頁「覆盤表」，下次三十秒對到位
規則、TUN、DNS、環境變數或節點只要動過任一項卻只靠記憶，隔幾天就難對齊。把時間戳、規則集／Merge 標籤、Proxy 地域與群組名、以及最短 curl 對照結果放在同一份備忘；若異常總發生在通勤尖峰時段或深夜，請單獨標註，避免把節點品質問題誤認成 CLI 問題。
日後 Gemini CLI、訂閱或本機環境任一項升級再打亂狀態，只要打開該頁對照：是漂移還是上線新路徑造成，通常第一波排查就能把範圍砍半。
常見問題（與你實際排查時最常撞到的牆）
瀏覽器正常、CLI 不正常，第一步該信誰？
以 CLI 為準做基準測試，因為它更接近你現在要解決的工作負載；瀏覽器只能當旁證。當兩者不一致時，優先檢查「是否只有瀏覽器走了系統代理／擴充套件」「CLI 是否另有 DNS 或憑證設定」「TUN 是否實際開啟」。
TUN 與 HTTP_PROXY 需要並存嗎？
不一定。先用最小組合驗證：只開 TUN、或只開系統代理＋環境變數，找出最低限度可穩定運作的設定，再決定要不要疊加以滿足其他軟體需求。
DNS 看起來正常但仍失敗？
請回到 curl 的錯誤階段與 Clash 日誌：很多「像 DNS」的問題其實是 TLS 或中間設備注入。若你確認 TLS 卡在特定節點，換群組或換出口地域往往比繼續改 fake-ip 更有用。
公司設備上有資安代理，還能這樣設嗎？
不一定能。部分企業會強制憑證檢查、拆 TLS、或禁止使用者安裝虛擬介面；這不是技巧問題而是政策問題。請先確認合規，再決定是否繼續。
結語：為什麼我仍會選擇以 Clash 思維處理 terminal AI CLI？
如果把問題簡化成「買一個會自動全域翻牆的 App」，短期確實可能省事；但 terminal AI CLI 的痛點往往不在「能不能連」，而在連線路徑是否可控、可驗證、可在三個月後還原當時成因。許多單一用途或過度包裝的工具，對規則粒度、DNS、TUN 與日誌的可讀性支援不足，最後會把你困在「換節點／重裝／重開」的循環裡。
相較之下，以 Mihomo 為核心的 Clash 生態更適合用規則語言描述你的真實需求：哪些域名要直連、哪些要走代理、哪些必須避免洩漏解析；搭配 TUN 與合理的 DNS 策略，才能把瀏覽器與終端機的行為收斂到同一套路。當你面對的是會長期留在工作流程裡的 Gemini CLI，這種可維運性通常比一時的「似乎能連」更重要。
若你正在找一套跨平台、社群資源多、且能沿用同一套分流哲學的客戶端，不妨從本站整理的 Clash 用戶端取得方式開始，挑一款適合你桌面環境的版本，再把本文的驗證方法嵌進你的日常維運習慣。