Gemini 透過 Clash 仍然逾時？完整排查與修復指南

先判斷：逾時到底發生在哪一層

Gemini 在 Clash 下顯示無法連線、頁面長時間載入，或對話送出後反覆逾時，不一定代表帳號被限制。這類問題通常發生在四個環節：Clash 根本沒有接收到瀏覽器流量、目前節點無法穩定連到服務、規則把相關請求送往錯誤的出口，或 DNS 解析結果與實際代理路徑不一致。若沒有先分層判斷，直接反覆更換節點，往往只是在掩蓋真正原因。

排查前先關閉其他 VPN、系統加速器與瀏覽器代理外掛，只保留一個 Clash 用戶端處於啟用狀態。本文以 Clash Verge Rev 搭配 mihomo 核心為例，Clash for Windows、ClashX、Clash for Android 的名稱可能略有不同，但「設定檔、代理模式、策略組、系統代理、TUN」這幾個概念是一致的。

第一輪檢查：代理開關與節點品質

Clash 介面顯示「已啟動」不等於瀏覽器流量真的經過代理。桌面用戶端通常有三個彼此獨立的狀態：核心是否執行、系統代理是否開啟、目前是否選定可用的策略組。少開其中一項，Gemini 就可能直接走本地網路，或把請求送到一個已失效的節點。

1. 在 Clash Verge Rev 的設定檔頁面確認目前設定檔已啟用，並查看核心日誌是否出現 YAML 解析錯誤、埠號被佔用或啟動失敗。
2. 在代理頁面選擇實際包含節點的策略組，不要只停留在「自動選擇」但沒有可用成員的空群組。手動指定一個節點，方便觀察結果。
3. 開啟系統代理，確認系統代理位址通常是 127.0.0.1，連接埠則以設定檔中的 mixed-port 為準，不要固定猜測某一個埠號。
4. 先用瀏覽器開啟一般 HTTPS 網站，再測試 Gemini。一般網站也無法開啟時，不要把時間浪費在 Gemini 專屬規則上。
5. 在同一個策略組中連續測試兩至三個節點，觀察是否只有單一節點逾時。單節點失敗通常是出口品質或節點端問題，不代表整份設定檔失效。

節點測試不應只看延遲數字。延遲測試通常只是對測試網址發起短連線，無法完全代表長時間 HTTPS、串流回應或較大請求的穩定性。Gemini 的頁面載入、帳號驗證與對話請求可能使用不同連線階段，因此「延遲很低」仍可能在實際使用時逾時。更值得觀察的是連續測試是否穩定、握手是否成功，以及請求途中是否頻繁重置。

用代理模式區分規則問題

Rule 模式會依序執行網域、IP、程序或規則集比對；Global 模式則把進入 Clash 的請求交給目前選定的代理策略組；Direct 模式相當於不經代理。排查時可先用 Global 做對照，再切回 Rule。不要在排查過程中同時更換節點、更新設定檔、修改 DNS，否則每個變更的影響無法分辨。

第二輪檢查：規則是否把 Gemini 分到錯誤出口

在 Rule 模式下，Clash 從規則清單上方往下比對，第一個命中的規則立即決定出口。常見問題是境外網域被錯誤套用 DIRECT，或自動規則集沒有涵蓋新增加的服務網域，最後被 MATCH,DIRECT 接住。這種情況下，其他網站可能正常，只有 Gemini 相關請求逾時。

先不要急著把規則檔整份重寫。打開 Clash 的連線或請求記錄，在重現問題時觀察目標網域、命中的規則以及最後使用的策略組。若記錄顯示為 DIRECT，可暫時切換 Global 驗證；若 Global 成功，便可以確定需要修正分流，而不是繼續換節點。

規則順序與臨時測試規則

正式設定中，建議把內網與本機位址放在前面，再放明確的境內直連規則，接著處理需要代理的服務，最後以代理策略組作為兜底。針對排查，可以在自訂規則區加入少量、明確的網域後綴規則，並把它放在可能產生 DIRECT 結果的廣泛規則之前。以下只是語法示意，AI-PROXY 必須替換成你實際存在的策略組名稱，網域也應以連線記錄中看到的結果為準：

rules:
  - DOMAIN-SUFFIX,example.invalid,AI-PROXY
  - DOMAIN-SUFFIX,service.invalid,AI-PROXY
  - MATCH,PROXY

不要把一個過短的關鍵字放進 DOMAIN-KEYWORD。關鍵字規則可能誤中不相關的網域，導致大量本來應直連的流量被送往代理。若服務使用多個網域，單靠一條規則不一定足夠；應以連線記錄為依據逐項確認，而不是從網路文章複製一大串未經驗證的網域清單。

如果使用 mihomo 的 GEOSITE、RULE-SET 或遠端規則提供者，還要確認規則資料已成功下載並載入。規則提供者更新失敗、檔案格式不相容、策略組名稱被改動，都可能造成看似「規則有寫，實際卻沒有生效」的結果。設定檔頁面若顯示規則提供者為空、更新時間過久或載入錯誤，先修正規則資料，再做後續測試。

第三輪檢查：DNS、TUN 與 IPv6 路徑

DNS 錯誤會讓 Clash 取得失效位址、被污染的結果，或讓應用程式解析到與代理出口不相容的服務端點。特別是只開啟系統代理、沒有接管 DNS 的情況，瀏覽器可能透過本地網路完成解析，之後再把連線交給代理；在部分網路環境中，這會造成解析成功率不穩定或連線被導向錯誤路徑。

在 mihomo 中，fake-ip 會先回傳保留網段內的虛擬位址，待應用程式連回這個位址後，再由核心依原始網域進行分流與解析。它通常有利於按網域規則判斷，但區域網路、部分即時通訊與特殊應用程式可能不相容。遇到只有少數應用程式異常時，可先把 enhanced-mode 暫時改成 redir-host 做對照。

一份適合排查的 DNS 與 TUN 範例

mixed-port: 7890
mode: rule

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

dns:
  enable: true
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "+.lan"
    - "+.local"
  default-nameserver:
    - 192.0.2.53
  nameserver:
    - https://192.0.2.53/dns-query
  proxy-server-nameserver:
    - https://192.0.2.53/dns-query

上面使用的是文件保留的示例位址，不代表可直接提供解析服務；實際使用時必須替換成你所在網路可達、且可信任的 DNS 上游。default-nameserver 主要用來解析加密 DNS 上游本身，通常填純 IP；nameserver 是一般解析上游；proxy-server-nameserver 則可用來解析代理節點的伺服器網域，避免節點網域解析被本地網路干擾。

• 先確認 TUN 權限。Windows 需要服務模式或系統管理員權限；macOS 需要允許網路擴充功能；安卓則要允許 VPN 連線請求。沒有授權時，介面可能顯示開啟，但實際沒有接管流量。
• 處理 IPv6 分流。如果網路提供 IPv6，而 TUN 或規則沒有完整接管 IPv6，應用程式可能優先連到 AAAA 位址並繞過預期路徑。排查期間可暫時設定 ipv6: false，確認問題是否消失。
• 避免 DNS 埠衝突。若系統其他服務已佔用 53 埠，Clash DNS 可能無法監聽。可查看核心日誌，或先改用用戶端提供的自動 DNS 方案，不要同時啟用多個 DNS 代理服務。
• 清除舊快取。切換 fake-ip、DNS 上游或規則後，關閉瀏覽器再重新開啟，必要時重啟 Clash 核心。舊的 DNS 快取與既有連線可能讓新設定看起來沒有生效。

第四輪修復：瀏覽器、連線與核心相容性

若系統代理、Global 模式、節點與 DNS 都已確認，仍然只有 Gemini 逾時，就要檢查瀏覽器自身的連線狀態。先用無痕視窗測試，排除擴充功能、Cookie、Service Worker 與舊登入狀態造成的干擾。若無痕視窗正常，逐一停用廣告攔截、隱私防護、網路切換與代理類擴充功能，不要一次全部刪除，避免無法定位原因。

部分瀏覽器會啟用獨立的安全 DNS 或 DoH。這類設定可能把 DNS 請求直接送往瀏覽器指定的服務，繞過 Clash 的 DNS 模組。若你已經使用 TUN 接管 DNS，建議先將瀏覽器的獨立安全 DNS 設為關閉或跟隨系統，再重新啟動瀏覽器。若公司、學校或家用路由器有強制 DNS 政策，還要確認本地防火牆沒有攔截 Clash 的 DNS 埠或 TUN 虛擬網卡。

針對長連線與不穩定節點的處理

Gemini 的互動請求可能持續較長時間，節點若存在丟包、頻繁重連或空閒連線被提前關閉，就可能表現為「頁面開得了，但送出訊息後逾時」。可採取以下順序處理：

1. 先換到同地區的另一個節點，優先選擇延遲波動小、連線成功率高的節點，而不是只看最低延遲。
2. 在 Clash 日誌中查看是否反覆出現 connection reset、timeout、handshake failed 或 connection refused 等訊息，並記錄發生時間。
3. 若設定檔提供 TCP 並發或連線復用選項，先使用預設值，不要為了追求速度而同時開啟多個實驗性選項。
4. 更新 mihomo 核心與用戶端到仍受支援的版本，更新後重新載入設定檔，避免舊核心讀取新格式時忽略欄位。
5. 如果只有某一種代理協定失敗，使用同一出口的另一種協定作對照；若所有協定都失敗，優先回到節點或網路路徑排查。

核心更新前，先匯出目前設定檔或複製自訂規則，並確認用戶端可回退到上一個核心版本。更新不應與大幅修改規則同時進行，否則即使問題消失，也無法判斷是核心修復還是規則變更造成的結果。

修復後驗證：用固定流程確認問題真的解決

修好之後不要只測一次首頁。建議按照固定流程完成驗證，並在每一步記下 Clash 模式、策略組、節點名稱與結果。這些資訊能幫助你下次快速判斷是節點失效，還是設定被更新後改變。

1. 重啟 Clash 核心，確認設定檔沒有錯誤，TUN 或系統代理只保留一種主要接管方式。
2. 先以 Rule 模式開啟一般 HTTPS 網站，確認一般流量可用，再觀察連線記錄是否命中預期出口。
3. 切換到 Global 模式測試 Gemini，確認節點可完成頁面載入、登入與一次簡單對話。
4. 切回 Rule 模式，重複相同操作。如果只有 Rule 失敗，查看相關請求是否被 DIRECT 或錯誤策略組接走。
5. 關閉瀏覽器後重新開啟，再測試一次，排除舊連線與 DNS 快取造成的假象。
6. 最後換回另一個節點測試。若一個節點穩定、另一個節點逾時，應將問題回報給節點服務商，而不是繼續修改本機規則。

常見問題