前言：先判斷問題出在哪裡
Gemini 透過 Clash 無法打開、一直轉圈、顯示連線逾時，並不一定代表你的 Google 帳號或瀏覽器發生故障。實際上，Gemini 的請求通常會經過登入服務、對話介面、靜態資源、API 與安全驗證等多個網域，只要其中一部分沒有經過正確的代理節點，頁面就可能載入不完整，甚至在登入後立即斷線。
另一個常見原因是「代理看起來已經開啟，但 Gemini 流量其實沒有走代理」。例如瀏覽器使用了系統代理以外的 DNS、Clash 規則將 gemini.google.com 分配到 DIRECT，或 TUN 模式沒有成功接管應用程式流量。本文會依照由簡到難的順序，帶你檢查代理狀態、分流規則、DNS 與節點品質，最後再判斷是否需要更換供應商。
排查目標
確認 Clash 確實接管 Gemini 流量；讓相關網域使用同一個穩定節點；避免 DNS 洩漏、規則誤判與節點頻繁切換造成的連線問題。
1確認 Clash 代理真的生效
開始修改 YAML 之前，先不要急著新增大量規則。許多「Gemini 無法使用」的案例，根本原因只是 Clash 沒有啟動、系統代理沒有打開，或目前使用的配置檔案並不是你以為的那一份。排查時應先把問題縮小到「客戶端」或「網路路徑」其中一側。
檢查客戶端與模式
- 打開 Clash Verge、Clash Verge Rev 或 Mihomo 客戶端，確認核心狀態顯示為正在運行。
- 確認目前已經載入正確的訂閱配置，而不是空白配置、過期配置或測試檔案。
- 在「模式」中優先選擇「規則」模式。全域模式可用於短暫測試，但不建議長期使用，因為所有應用程式流量都會經過代理。
- 開啟系統代理；若使用的是不遵循系統代理的應用程式，再考慮啟用 TUN 模式。
- 清除 Gemini 頁面後重新整理，並觀察 Clash 的連線記錄中是否出現相關網域。
小撇步
可以先在瀏覽器開啟 https://www.google.com 與 https://gemini.google.com，再回到 Clash 的「連線」頁面查看請求。如果完全沒有 Gemini 相關記錄，問題通常不在節點速度，而在代理接管或瀏覽器網路設定。
用最小測試確認節點
選擇一個延遲較低且位置穩定的節點，暫時不要使用「自動選擇」「負載均衡」或會不斷切換 IP 的策略組。Gemini 的登入與驗證流程對連線一致性較敏感，同一個頁面載入期間若 IP 在不同地區之間跳動，可能被要求重新驗證，甚至直接顯示服務不可用。
2補齊 Gemini 網域與分流規則
Gemini 不只使用單一網域。若配置檔案只代理 gemini.google.com，但 Google 登入、靜態資源或 API 請求被分配到直連，常見結果就是首頁能打開，對話卻無法送出；或者頁面外觀正常，但模型列表、檔案上傳與歷史記錄載入失敗。
你可以在現有規則的前方加入一組明確的 Gemini 規則。PROXY 是示意名稱，實際使用時請換成配置檔案中已存在的穩定策略組名稱，例如 Google 或 Gemini。
規則的順序非常重要。Clash 會從上到下匹配，先匹配到的規則會立即生效。如果在這些規則前方存在 GEOIP,CN,DIRECT、寬泛的 DOMAIN-SUFFIX,google.com,DIRECT，或其他自訂規則，Gemini 可能仍然被錯誤地導向直連。因此，請將 Gemini 相關規則放在寬泛規則之前。
注意
不要直接把上述內容貼到任何配置檔案的任意位置。YAML 對縮排非常敏感，請確認它位於 rules: 區塊內，並使用半形逗號與空格。修改前最好先備份原始配置。
檢查規則是否命中
重新載入配置後，開啟 Clash 的連線記錄，依次搜尋 gemini、googleapis、accounts.google.com。每個網域旁邊都應顯示同一個代理策略或同一個節點。若某個請求顯示 DIRECT，先記下該網域，再將它加入規則，而不是盲目切換其他客戶端。
3處理 DNS 解析與 TUN 模式問題
DNS 是 Gemini 連線問題中最容易被忽略的一環。即使瀏覽器的 HTTP 請求經過代理，如果網域解析仍使用本地網路提供的 DNS，可能出現解析失敗、返回不適合的 IP，或解析結果與代理節點所在區域不一致。這種情況在頁面偶爾能打開、重新整理又逾時時尤其常見。
建議的 DNS 檢查方向
- 在 Clash 的 DNS 設定中啟用內置 DNS，避免完全依賴作業系統的本地 DNS。
- 使用可信任的 DoH 或 DoT 服務，並確認配置格式與目前使用的 Mihomo 核心相容。
- 如果開啟了 fake-ip，確認
fake-ip-filter沒有把 Gemini 或 Google 相關網域排除。 - 修改 DNS 後重新啟動 Clash，並清除瀏覽器 DNS 快取，避免舊解析結果繼續生效。
- 不要同時讓多個 VPN、瀏覽器代理外掛與 Clash 接管 DNS，否則容易產生端口衝突與解析路徑混亂。
什麼時候需要 TUN 模式？
一般瀏覽器通常會遵循系統代理，因此只要系統代理正確，未必需要 TUN。但若你使用的是獨立應用程式、桌面版 WebView、特殊瀏覽器，或發現 Clash 連線記錄沒有完整反映 Gemini 請求，就可以測試 TUN 模式。TUN 會建立虛擬網路介面，接管較底層的 TCP、UDP 流量。
- 在 Clash 設定中確認使用 Mihomo 內核，然後開啟 TUN 模式。
- 依照提示授予虛擬網卡或系統權限；Windows 可能需要管理員權限。
- 關閉其他代理軟體與瀏覽器代理外掛，避免多重接管。
- 重新啟動 Clash 與瀏覽器，再測試 Gemini 登入、發送訊息及載入歷史對話。
- 若開啟 TUN 後反而無法上網，先關閉 TUN，檢查虛擬網卡、DNS 與防火牆設定。
4排除瀏覽器、登入與快取干擾
當 Clash 的規則與 DNS 都看似正常，Gemini 仍然打不開時，下一步應檢查瀏覽器環境。瀏覽器可能保留了先前直連時建立的 Cookie、錯誤的服務工作者快取，或透過外掛修改請求。這些因素會讓你誤以為是節點故障。
- 使用無痕視窗測試 Gemini。若無痕模式正常，通常表示 Cookie、快取或擴充功能造成干擾。
- 暫時停用代理切換、廣告攔截、隱私防護與 User-Agent 修改等外掛。
- 只清除
gemini.google.com、accounts.google.com與 Google 相關站點的 Cookie，不必一開始就刪除整個瀏覽器資料。 - 確認系統日期、時間與時區正確。時間偏差過大可能導致登入憑證或安全驗證失效。
- 退出 Google 帳號後重新登入，測試時盡量保持同一個節點與同一個地區，不要在多個節點之間快速切換。
快速判斷方法
如果無痕視窗可以使用，而普通視窗不行，優先處理瀏覽器資料；如果所有瀏覽器都逾時，則應回到 Clash 規則、DNS 或節點品質繼續排查。
此外，帳號地區、Google 服務政策與 Gemini 本身的可用性也可能影響結果。代理工具只能改變網路路徑，不能保證所有帳號都具備相同的功能權限。若頁面能正常載入但模型功能顯示不可用，應先查看帳號提示，而不是反覆修改代理規則。
5判斷是否需要更換節點或供應商
當規則命中、DNS 沒有洩漏、TUN 與系統代理也運作正常，但 Gemini 仍然出現 ERR_CONNECTION_TIMED_OUT、登入循環或回應中斷，就很可能是節點本身的問題。常見原因包括出口 IP 被過度共用、節點頻寬不足、國際線路在尖峰時段擁塞，或供應商的 Google 相關路由品質不佳。
你可以使用同一個配置中的不同節點進行對照測試，每個節點至少觀察幾分鐘，並測試相同的操作：開啟首頁、登入帳號、送出簡短訊息、重新整理頁面。建議記錄以下結果：
- 可連線但速度慢： 可能是節點頻寬或出口距離問題，優先選擇延遲較低、晚間表現穩定的線路。
- 首頁能開但無法送出訊息： 檢查 API 網域是否被分流到直連，或節點是否阻斷長連線。
- 頻繁要求驗證： 可能是出口 IP 信譽不佳，或自動策略組不斷切換地區。
- 只有某一地區完全失敗： 不要只看延遲數字，改用其他地區節點測試實際 Gemini 請求。
- 所有節點都失敗： 回到規則與 DNS 檢查，並確認訂閱沒有過期或核心版本不相容。
不要只追求最低延遲
節點測速結果只反映到測速伺服器的延遲，不等於 Gemini 的實際使用品質。穩定的出口 IP、較少的斷線與一致的地理位置，通常比低幾十毫秒的數字更重要。
最後的配置檢查清單
- Clash 核心正在運行，且載入的是最新配置。
- 系統代理或 TUN 模式已正確啟用，沒有其他代理程式搶占流量。
gemini.google.com、Google 登入與 API 相關網域都命中代理規則。- DNS 使用一致的解析方案，沒有被本地 DNS 或瀏覽器單獨接管。
- 瀏覽器快取、Cookie 與擴充功能已排除，系統時間也正確。
- 已使用至少兩個節點進行實際對照，而不只是查看延遲測試結果。
依照以上順序排查，通常可以明確判斷問題屬於設定、瀏覽器、帳號還是供應商線路。完成修改後，記得重新載入配置並重新啟動 Clash，不要在多個選項同時變更，否則很難知道是哪一項設定真正發揮作用。