為什麼 Gemini 在 Clash 下會打不開、逾時或載入很慢

如果你在瀏覽器中開啟 Gemini 時看到空白頁、長時間轉圈、訊息送不出去，或是頁面偶爾可以載入但對話請求經常逾時，問題不一定出在 Gemini 帳號本身。當流量經過 Clash 時，瀏覽器與 Gemini 服務之間多了一層節點選擇、規則分流、DNS 解析與 TLS 連線。只要其中一層判斷不一致，就可能出現「首頁能開、對話不能用」或「手機正常、電腦異常」這類看似沒有規律的結果。

Gemini 的網頁版通常不只連線到一個主機。載入頁面時，瀏覽器可能同時請求 Google 登入、靜態資源、API、分析服務與串流回應相關的網域；實際使用時還會建立較長時間的 HTTPS 或串流連線。若主要頁面走代理，但某個登入或 API 網域被規則判定為 DIRECT，畫面仍可能顯示出來，然而送出提示詞後就卡在等待回應。反過來，若所有 Google 流量都被丟到一個延遲很高或晚間壅塞的節點，則會表現為頁面載入緩慢、圖片缺失與回應中斷。

因此，排查時不要一開始就反覆重新整理或直接重灌 Clash。比較有效的順序是：先確認節點本身，再觀察 Clash 連線紀錄，接著檢查規則與 DNS，最後才處理 TUN、瀏覽器快取或更複雜的核心設定。每次只改一個變數，才能知道哪一個調整真正解決問題。

第一步：先確認節點、模式與 Clash 基本狀態

最常見的根因其實是節點品質不適合 Gemini。許多節點測試只反映短時間的 ICMP 延遲，並不能代表它能穩定處理 Google 網頁應用所需的 HTTPS、HTTP/2 或長連線。你可能看到延遲測試只有幾十毫秒，但實際打開 Gemini 時仍然會在登入、傳送訊息或串流輸出階段中斷。

  1. 確認 Clash 核心正在運作：在 Clash Verge Rev 或其他相容用戶端中，查看核心狀態、混合埠是否正常監聽，以及目前使用的設定檔是否確實載入。不要只修改下載資料夾裡的 YAML 複本，因為介面實際使用的可能是合併後設定。
  2. 暫時切換到另一個節點：優先選擇延遲穩定、封包遺失較少且能處理長連線的節點。不要只比較單次延遲，連續觀察數分鐘，並在 Gemini 中完成一次登入、開啟對話與送出訊息。
  3. 確認代理模式：規則模式適合日常分流，但測試期間可以短暫切換到 Global 或全域代理，作為 A/B 對照。如果全域代理立即恢復正常，通常代表原本的規則、DNS 或某個網域命中錯誤，而不是 Gemini 完全不可用。
  4. 暫停其他代理軟體：VPN、瀏覽器代理擴充功能、另一套 Clash 客戶端或公司零信任程式，可能與 Clash 同時接管流量。排查時先保留單一路徑，避免流量在兩個代理之間繞行。

完成以上測試後，請記下結果。例如「節點 A 在規則模式逾時、全域模式正常；節點 B 兩種模式都逾時」。這種紀錄比單純說「Gemini 不能用」更有價值：前者指向規則問題，後者則可能是節點品質、地區限制、DNS 或上游服務狀態。

小提示：測試時不要同時開啟多個 Gemini 分頁，也不要連續快速重新整理。Google 服務可能暫時保留失敗的登入或串流連線，讓你誤以為新節點仍然無效。

第二步：從連線紀錄找出被錯誤分流的網域

如果切換節點後問題仍然存在，下一步應該查看 Clash 的連線紀錄，而不是猜測應該加入哪些規則。不同版本的 Clash Verge Rev 可能把功能稱為「連線」「Connections」或「日誌」，但核心目標相同：在你開啟 Gemini、登入帳號及送出訊息的同一時間，觀察哪些目的地被建立連線，以及它們最後套用了哪個策略。

先清空或重新整理連線列表，再依序執行三個動作：開啟 gemini.google.com、重新整理頁面、送出一段簡短訊息。接著在紀錄中搜尋 google、gemini、googleapis 或相關的 API 字串。重點不是死記一份永遠不變的網域清單，而是確認「實際出現的目的地是否全部走到預期的代理群組」。Google 服務會更新資源與子網域，僅憑網路文章中的固定清單，可能漏掉你目前版本實際使用的主機。

觀察結果 較可能的原因 建議處理方式
Gemini 相關請求顯示 DIRECT 規則順序太後、被 GEOIP 或其他規則提前匹配 把明確的 Google AI 網域規則放到廣泛直連規則之前
只有登入網域逾時 帳號驗證相關請求與 Gemini 主頁使用了不同策略 觀察登入、驗證與靜態資源的實際目的地，避免只代理單一主網域
連線列表完全沒有相關請求 瀏覽器沒有使用系統代理，或流量被另一個程式接管 檢查系統 Proxy、瀏覽器設定，必要時以 TUN 做對照測試
所有請求都走代理但仍不斷重試 節點封鎖、DNS 污染、TLS 相容性或長連線品質不佳 更換節點並檢查 DNS，之後再測試 TUN 或核心設定

若你需要在 YAML 中補充規則，應使用自己連線紀錄中確認過的網域，並把規則放在較寬泛的規則集之前。概念上可以是以下形式，實際策略名稱請替換成你設定檔中的群組名稱：

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

這段範例的重點是「明確規則要先於 MATCH」，而不是要求所有 Google 網域都使用同一種策略。某些服務可能包含不需要代理的本地內容，過度寬泛的規則會增加延遲，甚至影響其他 Google 服務。因此，調整後要回到連線列表確認每條規則是否真的命中，不要只看 YAML 表面上是否寫得完整。

第三步：處理 DNS 解析、IPv6 與 TLS 連線問題

當規則看起來正確、請求也確實進入 Clash，但 Gemini 仍然反覆逾時，DNS 是下一個需要檢查的層面。DNS 負責把網域名稱解析成 IP 位址；如果系統先使用了不穩定或遭到改寫的 DNS，Clash 可能拿到不可達的位址，接著就會出現瀏覽器卡住、偶爾成功或不同網路環境結果完全相反的情況。

先確認 Clash 的 DNS 功能是否啟用，以及設定檔是否同時混用了系統 DNS、遠端 DNS 和不同的 fake-ip 或 redir-host 模式。排錯期間不要一次套用多個網路教學的 DNS 片段，因為重複的 nameserver、fallback、nameserver-policy 可能讓實際解析路徑變得難以判斷。可以先選擇一組穩定、可信且符合所在地網路政策的 DNS，重新啟動核心後再測試；若使用 fake-ip，則觀察 Gemini 相關網域是否出現異常的解析或被加入 fake-ip 過濾清單。

IPv6 也可能造成「有時很快、有時完全超時」。部分網路會優先回傳 AAAA 記錄，但 IPv6 路由實際上並不完整，瀏覽器便會先嘗試一條不可用的路徑，再等待超時後退回 IPv4。你可以在排錯期間暫時關閉 Clash 的 IPv6 或系統 IPv6 進行對照；如果停用後明顯改善，再針對路由器、網路供應商與節點是否支援 IPv6 做更精確的修正，而不是永久關閉所有 IPv6。

此外，瀏覽器顯示的「安全連線失敗」不一定表示憑證真的有問題。錯誤的系統時間、攔截 HTTPS 的安全軟體、公司網路的 TLS 檢查，以及節點對 HTTP/2 或串流連線支援不佳，都可能讓 TLS 握手在表面上看起來像憑證錯誤。請先確認作業系統日期與時區正確，暫停不必要的 HTTPS 掃描功能，並用另一個節點或另一個網路進行交叉測試。

第四步：確認系統 Proxy，不足時再啟用 TUN

許多使用者以為只要 Clash 顯示「已啟動」，所有程式就會自動走代理，實際上並非如此。系統 Proxy 主要影響遵循作業系統代理設定的瀏覽器與應用程式；某些獨立瀏覽器、沙盒環境、安全軟體或自訂網路堆疊可能忽略它。若 Clash 的連線列表在你操作 Gemini 時完全沒有任何新請求，首先要檢查系統 Proxy 是否開啟，以及 HTTP、HTTPS 和 SOCKS 代理埠是否填寫正確。

在 Windows 或 macOS 上，請先用同一個瀏覽器測試系統 Proxy，再確認瀏覽器沒有單獨設定「不使用代理」或例外清單。若你同時設定了瀏覽器擴充功能代理與系統 Proxy，先停用其中一個。代理埠也不要照抄其他教學，因為不同設定檔的 mixed-port 可能是 7890、7897 或其他數值，應以 Clash 目前顯示的埠位為準。

只有在系統 Proxy 已正確啟用、規則也確認無誤，但 Gemini 相關流量仍然不會出現在 Clash 連線列表時，才考慮使用 TUN 模式。TUN 會在更低的網路層接管流量，能涵蓋部分不遵循系統代理的連線，因此適合用來確認「是不是有程式繞過了系統 Proxy」。不過 TUN 也會改變系統路由，可能與公司 VPN、遊戲加速器、Docker 網路、虛擬機或防毒軟體衝突。

  • 啟用 TUN 前，先記下原本的系統 Proxy、DNS 與 VPN 狀態，方便恢復。
  • 只開啟必要的自動路由或嚴格路由選項，不要同時套用多份不明的網路接管設定。
  • 啟用後重新開啟瀏覽器，清除卡住的分頁連線，再觀察 Clash 連線列表。
  • 如果 TUN 讓 Gemini 正常，但區域網路、公司內網或其他應用程式失效，應建立例外規則，而不是長期忽略衝突。

第五步：清理瀏覽器狀態並用可重複的方式驗證

當你已經更換節點、修正規則與 DNS，瀏覽器仍可能保留舊的 Service Worker、Cookie、DNS 快取或失敗的登入狀態。這時不要立刻刪除整個瀏覽器資料，可以先使用無痕視窗開啟 Gemini，登入後測試一個簡短對話。如果無痕視窗正常，而一般視窗異常，問題多半在 Cookie、擴充功能或快取，而不是 Clash 核心。

接著可依序停用廣告攔截器、隱私保護擴充功能與瀏覽器代理工具，再測試是否恢復。某些擴充功能會阻擋 Google 的跨網域請求或串流事件，表面上就像節點不穩。若仍然異常，再針對 Gemini 網站清除單一網站的 Cookie 與儲存資料，避免不必要地登出所有網站。

建議用以下矩陣完成最後驗證，每次只改一項條件：

測試組合 需要記錄的結果 可判斷的方向
節點 A＋規則模式 首頁、登入、送出訊息是否成功 建立基準結果
節點 A＋全域模式 是否只在全域模式恢復 判斷規則或 DNS 是否有問題
節點 B＋規則模式 長連線與串流是否穩定 判斷節點品質與路由相容性
節點 B＋TUN 連線是否出現在 Clash 列表 判斷瀏覽器或系統是否繞過代理

如果所有節點、所有模式都失敗，但其他 Google 服務也同時異常，應查看 Google 服務狀態、所在地網路與帳號安全通知，不要繼續盲目增加規則。若只有某個帳號失敗，則可用另一個符合服務條款的帳號或瀏覽器設定進行對照；請勿反覆嘗試可疑的登入方式，也不要在不可信的第三方頁面輸入 Google 密碼或驗證碼。

容易讓問題更嚴重的做法

第一種常見錯誤是把所有 Google 網域一律送到同一個節點，卻沒有考慮節點負載與服務類型。這種做法短期內可能讓 Gemini 打得開，但也可能讓搜尋、雲端硬碟、同步服務與本地化內容全部繞遠路，造成整體網路變慢。第二種錯誤是把規則放在廣泛的直連規則後面；Clash 依序匹配規則，前面的 GEOIP、RULE-SET 或 MATCH 可能已經決定了策略，後面新增的 Gemini 規則根本不會被執行。

第三種錯誤是同時修改 DNS、TUN、核心版本、瀏覽器和節點，最後即使恢復正常，也不知道真正原因。比較可靠的做法是先備份目前設定，記錄核心版本與節點名稱，然後按照「節點 → 連線紀錄 → 規則 → DNS → TUN → 瀏覽器」的順序逐項測試。若使用遠端訂閱，還要注意訂閱更新可能覆蓋本地修改；可以使用覆寫或腳本功能，但必須確認設定檔重新更新後規則仍然存在。

另外，Gemini 的可用性也可能受到帳號所在地、服務條款、企業管理政策或暫時性的服務故障影響。Clash 只能改善一般網路路由與連線穩定性，不能保證所有帳號、所有地區或所有節點都能使用每項功能。請在合法合規及遵守 Google 服務條款的前提下進行設定，並把帳號安全放在優先位置。

相較於只提供單一全域開關、遇到長連線就容易卡住的簡單代理工具，Clash 能讓你從連線紀錄確認 Gemini 實際命中的網域，再用規則分流、節點切換與 TUN 對照逐層定位問題；即使需要處理 DNS 或瀏覽器繞過代理，也能保留清楚的測試路徑。如果你想把這套排查流程延伸到 Windows、macOS 或其他裝置，使用 Clash 會比反覆重啟一個無法觀察流量的工具更容易維護。

立即免費下載 Clash，開啟流暢上網新體驗 →