Gemini CLI 連線逾時？Clash 無法使用的排解方法

Gemini CLI 一直顯示連線逾時、無法登入，或執行指令時卡在等待回應，不一定代表 Google 帳號、API 金鑰或本機安裝出了問題。對許多使用 Clash 或 Mihomo 的使用者來說，真正的原因可能是代理模式、分流規則、DNS 解析、TUN 接管範圍，或目前節點無法穩定連線到 Gemini 服務。本文以「先確認節點，再檢查規則，最後調整 DNS 與 TUN」的順序，帶你逐步排解 Gemini CLI 逾時問題，避免一開始就反覆重裝工具或更換帳號。

先判斷問題是否來自代理

排查逾時最重要的原則，是一次只改動一個變數。Gemini CLI 通常會依賴 Google 登入服務、Gemini API 或相關網域；如果 Clash 沒有正確接管命令列流量，瀏覽器能開啟網頁並不代表 Gemini CLI 也能使用同一條路徑。相反地，即使瀏覽器正常，CLI 仍可能因為沒有讀取系統代理而直接連線失敗。

首先開啟 Clash Dashboard，確認核心狀態為運行中，並檢查目前使用的代理組是否真的選定一個可用節點。不要只看節點旁邊的延遲數字；延遲測試通常只代表測速網址可以回應，不一定代表 Gemini 所需的 HTTPS 連線也能完成。

在 Clash 中選擇一個平時較穩定的節點，暫時不要使用自動選優或負載均衡。
將模式切換為 Global，先排除規則匹配錯誤的可能性。
重新執行 Gemini CLI 的登入或測試指令，觀察是否仍然逾時。
如果 Global 模式可以使用，再切回 Rule 模式，繼續檢查網域規則。

快速判斷方法：Global 模式成功、Rule 模式失敗，通常是分流規則或 DNS 導致；兩種模式都失敗，則應優先檢查節點品質、代理環境變數、核心日誌與本機網路。

在命令列環境中，也可以確認作業系統是否設定了代理變數。Linux 與 macOS 可使用以下指令查看：

檢查命令列代理環境變數

env | grep -i proxy

# 常見的代理變數
echo $HTTP_PROXY
echo $HTTPS_PROXY
echo $ALL_PROXY

如果你使用的是本機 HTTP 代理，常見格式如下。請依照 Clash 實際監聽的埠號修改，不能直接照抄：

設定目前終端機的代理

export HTTP_PROXY=http://127.0.0.1:7890
export HTTPS_PROXY=http://127.0.0.1:7890
export ALL_PROXY=socks5://127.0.0.1:7891

Windows PowerShell 可使用 $env:HTTPS_PROXY 設定環境變數，但部分 CLI 工具只支援 HTTP 或 HTTPS 代理，不一定能處理 SOCKS5。若設定後反而出現協議錯誤，建議先只保留 HTTP_PROXY 與 HTTPS_PROXY，並使用 Clash 的 HTTP 監聽埠。

檢查 Gemini CLI 需要的分流網域

確認節點可以使用後，下一步是檢查 Rule 模式下的網域是否命中正確策略。Gemini CLI 的登入流程可能會跳轉到多個 Google 相關網域，API 請求也可能使用不同的主機名稱。只加入一個網域，往往只能解決部分問題；瀏覽器登入成功，但 CLI 回呼、權杖交換或 API 請求仍然可能逾時。

在 Dashboard 的「連線」頁面啟動 Gemini CLI，搜尋包含 google、googleapis、generativelanguage、gstatic 或登入服務的連線。重點觀察以下資訊：

目標網域：確認請求是否真的送往預期的 Google 服務，而不是未知的重新導向網域。
命中規則：查看是走代理、直連、拒絕，還是落入了錯誤的策略組。
使用節點：確認請求與瀏覽器使用的是同一個可用出口。
連線狀態：若連線建立後立即中斷，問題可能是節點或 TLS；若一直停留在等待，則可能是 DNS 或路由沒有完成。

為了測試規則是否生效，可以暫時把相關網域加入一個明確的代理規則。規則順序非常重要，因為 Clash 會採用第一條匹配到的規則；如果前面已有更寬泛的直連規則，後面的代理規則不會被執行。

Gemini 相關網域的測試規則

rules:
  - DOMAIN-SUFFIX,googleapis.com,Gemini
  - DOMAIN-SUFFIX,generativelanguage.googleapis.com,Gemini
  - DOMAIN-SUFFIX,google.com,Gemini
  - DOMAIN-SUFFIX,gstatic.com,Gemini
  - MATCH,DIRECT

這段配置中的 Gemini 必須是你實際存在的策略組名稱。如果你的策略組叫做「Proxy」或「自動選擇」，就要替換成完全相同的名稱。測試完成後，可以再依照實際連線紀錄縮小規則範圍，避免把所有 Google 服務都不必要地送往代理。

不要盲目加入大量網域：把所有 Google 網域全部代理雖然容易測試，但可能造成國內服務變慢、登入狀態不一致，還會讓日後很難判斷究竟是哪一條規則生效。建議先看 Dashboard 的實際連線記錄，再增加必要規則。

排查 DNS 解析與 fake-ip 問題

DNS 錯誤是 Gemini CLI 逾時中相當常見、卻容易被忽略的一環。當本地 DNS 回傳錯誤 IP、解析結果被污染，或 fake-ip 映射沒有正常建立時，CLI 可能表現為長時間等待，最後才回報 timeout。這種情況下，單純更換帳號或重新安裝 Gemini CLI 通常沒有幫助。

先在 Clash Dashboard 的 DNS 或連線頁面確認相關域名是否能正常解析，再清除 DNS 快取並重新啟動 Clash。Windows 可使用 ipconfig /flushdns；macOS 和 Linux 的清除方式依系統服務而異，若不確定，直接重新啟動網路服務或電腦通常更簡單。

對於支援 fake-ip 的 Clash 或 Mihomo 核心，可以使用較穩定的基本配置作為測試起點。以下配置只是一個方向，DNS 監聽埠、上游伺服器與 fake-ip 過濾項目仍應依你的環境調整：

DNS 測試配置

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - https://223.5.5.5/dns-query
    - https://1.1.1.1/dns-query
  fallback:
    - https://8.8.8.8/dns-query
    - https://dns.google/dns-query
  fallback-filter:
    geoip: true
    geoip-code: TW

  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - localhost

如果使用 fake-ip 後只有 Gemini CLI 出問題，可以暫時把相關網域加入 fake-ip-filter，重新載入配置後再測試。這樣做的目的不是永久關閉 fake-ip，而是判斷問題是否來自應用程式無法處理假 IP。若排除後恢復正常，應再確認核心版本、CLI 使用的網路庫，以及是否有其他 DNS 規則與它衝突。

另外要注意 nameserver 與 fallback 的分工。前者通常負責一般解析，後者在符合條件時提供替代結果。如果 fallback 使用了無法從目前網路連出的 DNS over HTTPS 服務，解析請求本身也會等待逾時。因此排查時不要一次加入太多上游，先保留兩至三個可連通的伺服器，並從核心日誌確認查詢是否成功。

檢查 TUN 模式與系統代理

如果你的 Gemini CLI 不會讀取 HTTP_PROXY 或 HTTPS_PROXY，TUN 模式可能是更可靠的接管方式。TUN 會在系統層攔截符合條件的流量，讓不支援代理設定的應用程式也能經過 Clash。不過，TUN 並不是開啟後就一定正常；路由、DNS 劫持、系統權限和 IPv6 都可能影響結果。

啟用 TUN 前，先關閉其他 VPN、企業安全軟體或同類型虛擬網卡，避免多個程式同時修改預設路由。接著確認 Clash 已取得管理員或系統權限，並檢查 TUN 的設定是否包含自動路由與 DNS 劫持：

TUN 基本測試配置

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

stack: mixed 通常對桌面應用具有較好的相容性，但不同核心可能支援不同欄位。若載入配置時出現 unknown field 或格式錯誤，應以目前核心版本的文件為準，不要把其他版本的設定直接混用。啟用 TUN 後，先重新開啟終端機，再執行 CLI；部分程式只在啟動時讀取網路介面與代理環境。

若 TUN 開啟後瀏覽器和 CLI 都無法連線，請立即切回原本模式，查看 Clash 日誌是否出現路由循環、DNS 劫持失敗、權限不足或連接埠被佔用。若只有 CLI 無法使用，則更可能是該程式自行指定了網路介面、忽略系統代理，或受 IPv6 路由影響。

用節點測試與日誌確認修復

當規則和 DNS 看起來都正常，仍然逾時時，應把注意力放回節點本身。節點可以通過一般延遲測試，不代表它能穩定完成長連線、TLS 握手或 Google API 請求。特別是共享節點，可能出現高峰時段丟包、出口 IP 被限制、TLS 握手緩慢或連線建立後頻繁重置。

建議使用三個不同地區、不同協議的節點進行對比，而不是只在同一個策略組中重複測試相近線路。每次測試都保持其他設定不變，記錄結果：

節點 A 在 Global 模式下逾時，節點 B 可正常登入：優先判定為節點出口或線路品質問題。
所有節點都失敗，但瀏覽器可用：檢查 CLI 是否讀取代理、是否被環境變數覆蓋。
登入完成但 API 請求逾時：檢查 API 網域規則、DNS 解析與長連線穩定性。
偶爾成功、偶爾失敗：檢查丟包、策略組自動切換，以及節點是否在請求中途被更換。

在使用 url-test 或 fallback 策略組時，Gemini CLI 的登入流程不適合頻繁切換節點。登入期間如果出口 IP 改變，可能導致授權回呼失敗，或讓服務端重新要求驗證。排查時建議固定一個節點；確認穩定後，再使用自動選優。

更穩定的主備策略組範例

proxy-groups:
  - name: Gemini
    type: fallback
    proxies:
      - 節點-JP-01
      - 節點-SG-01
      - 節點-US-01
    url: https://www.gstatic.com/generate_204
    interval: 300

最後查看 Clash 核心日誌。若出現 dial tcp i/o timeout，通常表示 TCP 連線未能在期限內建立；tls handshake timeout 多半與節點、SNI 或出口品質有關；若顯示 DNS lookup timeout，則應回到 DNS 上游與 fake-ip 檢查。不同錯誤訊息代表的層級不同，先辨認發生在哪一層，能大幅縮短排查時間。

常見問題 FAQ

瀏覽器能使用 Gemini，為什麼 CLI 仍然逾時？

瀏覽器通常會自動使用系統代理或瀏覽器擴充功能，但 CLI 未必會讀取相同設定。請先檢查 HTTP_PROXY、HTTPS_PROXY 是否指向 Clash 的正確埠號；若 CLI 不支援代理變數，再使用 TUN 模式接管系統流量。

排查時需要一直切換節點嗎？

不建議。先固定一個節點完成 Global、Rule、DNS 和 CLI 代理測試，再用第二個節點交叉驗證。頻繁切換會讓登入回呼與長連線失去穩定的出口，也會使測試結果難以比較。

Gemini CLI 逾時是否代表必須關閉 fake-ip？

不一定。fake-ip 常常能改善域名規則匹配與 DNS 汙染問題。只有在加入相關網域到 fake-ip-filter 後恢復正常，才表示可能存在相容性或映射問題；確認原因後，應優先針對特定網域調整，而不是永久關閉整個 fake-ip。

所有設定都正確，仍然逾時該怎麼辦？

請比較不同節點、查看核心日誌，並確認服務端沒有暫時性限制。若只有某一個節點失敗，直接更換節點通常比繼續修改規則更有效；若所有節點和裝置都失敗，才需要進一步檢查帳號授權、API 配額或上游服務狀態。

總結來說，Gemini CLI 的連線逾時應按照「節點可用性、代理接管、分流規則、DNS 解析、TUN 路由」的順序處理。先用 Global 模式確認代理鏈路，再回到 Rule 模式精簡規則，最後透過固定節點與核心日誌驗證結果。這種分層排查方式不僅能解決 Gemini CLI，也適用於其他需要穩定 HTTPS、登入回呼與 API 連線的命令列工具。

立即開始

用 Clash 掌控您的流量

支援 Windows、macOS、Linux、Android 與 iOS，靈活規則，開箱即用。

免費下載查看設定指南 →