一、先對齊現象：白屏、驗證迴圈與半載入常是「多條路徑」同時出問題
在瀏覽器開啟 Google AI 相關頁面時，表面症狀可能都是「轉圈」，但底層往往同時涉及帳號工作階段、前端套件、背景 API 與靜態資源。當其中一條請求被地區直連規則截走、另一條卻走代理，就很容易出現工作階段不一致：例如登入看似成功，但對話介面永遠載不出來；或反覆被要求驗證，因為風控看到的出口位址與你實際瀏覽器發起的 API 位址不一致。
因此請避免一開始就只靠「換節點」或「開全局」。較可靠的做法是：先在「僅開啟首頁」與「進入實際對話畫面」兩種情境下各收集一次連線紀錄，確認各自命中的規則與 DNS 行為，再決定要不要把登入類流量與 gemini.google.com 應用流量放在同一策略脈絡。若你尚未匯入訂閱或策略名稱不確定，建議先完成《Clash 訂閱連結怎麼用？機場設定檔案一鍵匯入完整教程》，避免在錯誤的群組名稱上反覆試錯。
二、為什麼 Google 系 AI 前端特別吃「同一出口＋一致 DNS」
Google 登入與 OAuth 流程通常會跨多個 google.com 子網域與帳號相關主機；而 Gemini 網頁本體與其背景請求，又可能落在 gemini.google.com、generativelanguage.googleapis.com 或其他 API 命名空間。再加上前端常從 gstatic.com 等位置載入腳本與字型，任何一條被錯誤直連或解析到不理想的路徑，都會讓你體感成「整站壞掉」。
撰寫 Clash 分流時，請以你環境中實際出現的主機名稱為準，而不是只抄一份過期懶人包。Google 會依區域、產品與實驗旗標調整邊緣與 API；最穩的方式仍是在你電腦上，於「登入」「開啟對話」「上傳附件」等動作下各收集一次日誌，再把重複出現的後綴整理成 DOMAIN-SUFFIX。
三、用開發者工具對齊：哪一些是登入、哪一些是應用與 CDN
在撰寫規則前，建議開啟瀏覽器開發者工具的網路面板，觀察失敗請求的狀態碼與主機名稱。若你看到大量腳本或樣式表來自 gstatic.com 類網域卻顯示逾時，而 API 請求又落在另一組主機，就很適合回到 Clash 連線清單逐條對照策略。
同時請留意瀏覽器擴充套件：廣告攔截、隱私保護或腳本管理工具，有時會阻擋特定追蹤網域，卻意外破壞 Google 產品的前置載入流程。若你只在安裝某套件後才出現異常，應先用無痕視窗或乾淨設定檔交叉驗證，再歸因到 Gemini 代理設定。
四、為什麼「只開系統代理」有時會漏掉 Google 相關流量
許多人習慣只啟用系統 HTTP／HTTPS 代理，但瀏覽器、外掛程式或背景程序仍可能以不同方式發起連線。若症狀主要發生在桌面瀏覽器，實務上常會建議你驗證 TUN 模式是否能讓相關流量一致進核心，因為它能在網路層統一接管符合條件的封包。
啟用 TUN 會涉及路由與系統權限，請先閱讀《Clash TUN 模式開啟方法》再操作，並在開啟後回到連線清單確認瀏覽器程序相關連線是否出現在核心中。若你同時使用 WSL2 或容器環境，也可對照《WSL2 共用本機 Clash 代理》理解哪些流量預設不會跟著主系統代理走。
五、建議排查順序（先證明流量有進核心，再談節點品質）
下列順序刻意把「換節點」放在中後段：先確認 Google／Gemini 相關連線有經過 Clash，且規則命中符合預期，再談線路品質與風控表現。
- 確認 Clash 正在執行，並依場景選擇系統代理或TUN；若問題主要出在瀏覽器，優先驗證 TUN。
- 在登入與開啟
gemini.google.com時，於連線日誌檢查是否出現預期的 Google 子網域，以及策略是否為你以為的代理群組，而非被過寬的DIRECT規則提前截走。 - 進入對話與上傳附件後，再次檢視日誌：API 與靜態資源是否仍維持同一策略脈絡，避免「登入走代理、腳本直連」的分裂狀態。
- 檢查 DNS 模式（是否
fake-ip）、以及 Google 相關後綴是否在fake-ip-filter或nameserver-policy中有合理設定，避免解析與連線決策互相打架。 - 在規則已正確命中的前提下，再挑選掉包低、重連少的節點；若上游對長連線或 QUIC 不友善，體感仍可能異常，此時才需要回到節點型態層面處理。
若出現埠號占用、訂閱無法拉取等通用錯誤，請併讀《Clash 常見報錯解決方案》；本文聚焦 Google AI 訪問場景下的網域對齊。
六、網域怎麼收集：以日誌為準，不要只抄清單
Google 產品線會隨時間調整邊緣與 API 命名，第三方整理可作起點，但最可靠的方式仍是在你自己的環境收集主機名稱。在 Clash 用戶端的連線清單中依關鍵字篩選 google、gemini、gstatic 等，並在開發者工具網路面板比對完整主機名稱，通常比單純猜測更有效。
將觀察到的名稱依後綴分組後，優先使用 DOMAIN-SUFFIX 對齊整棵子網域樹，比過寬的 DOMAIN-KEYWORD 更不易誤傷其他服務。若你看到資源來自第三方公有雲邊緣，請只加入「該次失敗時間點實際命中」的後綴，避免把超大後綴一刀切進代理。
七、實務上常見的 Google／Gemini 網域方向（以實測為準）
下列為多數環境下登入、載入前端與呼叫模型 API 時常見的典型後綴家族；實際是否全部需要、以及是否應走同一策略群組，請以你的連線日誌為準：
google.com：搜尋、帳號、產品導流與多數登入流程的骨干。accounts.google.com：帳號與 OAuth 相關流程的高頻主機。gemini.google.com：Gemini 網頁應用本體與多數使用者直接輸入的網址。gstatic.com：靜態腳本、字型與分段資源常見承載位置。googleusercontent.com：部分內嵌資源或使用者內容相關路徑可能出現。googleapis.com／google.dev：API、開發者文件與部分服務後端請求可能落在此家族。- 重點：實際對話與附件上傳可能觸發額外子網域；請在日誌中確認「失敗當下」的完整主機名稱，不要假設只補一條就足夠。
當登入成功但對話區永遠空白時，優先懷疑 API 或應用子網域仍直連；當頁面骨架出現但按鈕無法點擊時，優先核對腳本與字型是否完整載入，並檢查是否有擴充套件或公司網路中斷特定路徑。
八、DNS 與 fake-ip：別讓解析鏈放大「一直驗證」的感受
在 fake-ip 模式下，Clash 會先回傳虛擬位址再在連線階段決策出口。若 DNS 與規則配合不當，可能出現「解析看起來成功、實際 TLS 對錯出口」或反覆重試。Google 服務在載入頁面時會平行請求大量子網域，任一條解析被汙染或指向不理想的路徑，體感就會像整站故障。
實務上可以分兩步：第一，確認你的 DNS 上游對海外網域可信且可達；第二，對反覆出問題的後綴在用戶端支援的欄位中設定較穩定的解析策略（例如指定 DoH），並在調整後用連線日誌比對命中是否與預期一致。若改 DNS 後載入明顯推進，代表瓶頸有相當比例在解析鏈路，而非單純節點速度。
九、分流設計檢查清單（請以你的日誌為準）
下表整理撰寫 Gemini 代理規則時的檢查角度；欄位中的後綴會隨營運調整，務必以實測主機名稱為準。
| 類型 | 常見主機名稱方向 | 設定提示 |
|---|---|---|
| 帳號與 OAuth | accounts.google.com 等 | 與應用流量同一策略脈絡，避免登入走代理、API 直連造成風控異常。 |
| Gemini 網頁應用 | gemini.google.com | 使用者最常輸入的入口；需與相關 API 一併驗證。 |
| 靜態資源 | gstatic.com 等 | 半載入或白屏時優先核對腳本是否誤直連或被攔截。 |
| API 與後端 | googleapis.com 等 | 對話與附件可能觸發；請以日誌補齊實際子網域。 |
| 開發者與文件 | google.dev 等 | 若你同時使用 AI Studio 類工具，請另外收集一次日誌。 |
十、分流規則範例（請替換為你的策略群組名稱）
下列 YAML 片段示範「把 Google／Gemini 相關後綴明確指向代理群組」的寫法；請將 PROXY 替換為實際策略群組名稱，並維持規則順序：更具體的條目應放在過寬的 MATCH 與地區直連清單之前。若你希望「登入」與「高頻下載型靜態資源」分流到不同群組，可定義 PROXY_LOGIN 與 PROXY_APP，再依日誌微調。
# Example only — replace PROXY with your policy group name; extend from your logs
rules:
- DOMAIN-SUFFIX,google.com,PROXY
- DOMAIN-SUFFIX,googleapis.com,PROXY
- DOMAIN-SUFFIX,gstatic.com,PROXY
- DOMAIN-SUFFIX,googleusercontent.com,PROXY多數情況下仍以 DOMAIN-SUFFIX 為主。若日誌中出現與上述家族不同的協作或上傳專用子網域，請逐條補上；不確定時寧可先記錄完整主機名稱，再查後綴歸屬。請勿直接複製其他 AI 服務專文的規則，例如 Anthropic 或 OpenAI 的網域集合與 Google 系完全不同。
十一、圖形用戶端中如何少踩坑
在 Clash Verge Rev 等用戶端中，建議開啟即時連線清單，篩選 gemini 或 google 關鍵字，逐條確認策略。若某條顯示 DIRECT，請回到規則表檢查是否有地理分流、廣告攔截或「繞過區域網」類規則前置命中。
若桌面端基礎設定尚未完成，可先依《Clash Verge Rev 完整設定教學》跑通訂閱與模式，再回到本文補 Google AI 專用規則，可節省大量試錯時間。
十二、小結：把「打不開」變成可驗證的規則問題
2026 年造訪 Google Gemini 與相關 Google AI 網頁時，若遇到驗證迴圈、白屏或資源半載入，可依序確認：瀏覽器流量是否進核心、DNS 與 fake-ip 是否一致、gemini.google.com 與 Google 帳號／CDN／API 子網域是否各自命中預期出口，以及擴充套件與公司網路是否攔截特定路徑。當連線日誌能清楚對應主機名稱與策略，你就不需盲目全局代理或反覆更換節點卻無法改善體驗。
當你希望把觀測、規則與核心更新集中在同一套成熟用戶端時，官方維護方案通常能降低手寫 YAML 的低階錯誤；相較其他同類工具，Clash 在規則透明度與日誌對照上往往更一致。→ 立即免費下載 Clash，開啟流暢上網新體驗