一、為何會「打不開」或介面／API 異常
使用 Google Gemini 網頁時，瀏覽器會向 gemini.google.com、google.com 及其子網域發送請求，並載入帳號、分析、字型與靜態資源；若你透過 API 或 AI Studio 類工具連線，請求則多落在 googleapis.com 底下的服務主機（例如官方文件中的 Generative Language 端點，實際主機名以文件與開發者工具為準）。任一環節直連、其餘走代理，或不同請求落在不同國家／ASN 的出口，都可能出現腳本載入失敗、OAuth 流程異常，或 API 客戶端報錯。
Clash 可透過 RULE 將 DOMAIN-SUFFIX 對應到同一 proxy-group，再以節點選擇維持出口一致。先把「屬於 Google／Gemini 的流量」完整覆蓋，往往比反覆更換瀏覽器或重裝 SDK 更能對症處理連線層問題。
二、與 ChatGPT／OpenAI 專線的差異
站內另文以 ChatGPT／OpenAI 為主題，核心網域為 openai.com、chatgpt.com、api.openai.com 等，與Google 生態完全不同。若你把 OpenAI 規則複製貼上後只改策略組名稱，卻未納入 google.com、googleapis.com、gstatic.com 等後綴，Gemini 網頁與 Google API 仍可能大量直連或誤入其他策略，表現為「OpenAI 正常、Gemini 全掛」或反過來。
建議將「Google／Gemini／Vertex 等相關用途」視為獨立規則區塊，與 OpenAI 區塊並列維護。你可對照 ChatGPT／OpenAI 分流專文 的方法論（策略組、RULE 順序、DNS 一致性），但務必改用本文列出的 Google 相關後綴與實際連線所見主機名。
| 項目 | ChatGPT／OpenAI（#9 專文） | Google Gemini／Google API（本文） |
|---|---|---|
| 網頁主體 | chatgpt.com、openai.com 等 |
gemini.google.com、google.com 等 |
| API 典型主機 | api.openai.com（以官方文件為準） |
*.googleapis.com（如 Generative Language；以文件為準） |
| 常見靜態／字型 | 服務商自有 CDN 後綴（見 OpenAI 專文） | gstatic.com、googleusercontent.com 等（以 DevTools 為準） |
三、網頁端與 Google API 主機思路
瀏覽器與 gemini.google.com
一般使用者開啟 gemini.google.com 時，除了主站 HTML，還會載入帳號、同意條款、錯誤回報與前端資源。重點是讓同一工作階段內相關請求走一致的代理策略，而不是只讓首屏網址走代理、其餘子請求落在 DIRECT。
Google API 與開發者工具
若你使用官方 SDK、REST 或 gRPC 客戶端呼叫 Google API，請求主機名多在 googleapis.com 之下；程式可能不讀系統代理，導致「瀏覽器正常、API 全錯」的錯覺。此時除規則外，還需確認是否為程式設定代理環境變數，或在系統層啟用 TUN／透明代理，讓流量進入 Clash。
四、規則分流：建議納入的網域與後綴
以下示例以常見 Mihomo／Clash 規則格式撰寫，PROXY 請替換為你設定檔中的策略組名稱。Google 產品線眾多，實際主機名可能隨更新變動，請以瀏覽器「網路」面板與官方文件交叉驗證，必要時補上你在環境中觀察到的額外主機名。
若訂閱已內建「Google」或「YouTube」類規則，仍請檢查順序：較早的 GEOIP、IP-CIDR 或過寬的 MATCH 可能讓部分子請求提前結束匹配。對不確定的主機名，可短期以較精準的條目補網，長期仍建議收斂為 DOMAIN-SUFFIX，並避免過寬的 DOMAIN-KEYWORD 誤傷無關流量。
使用 fake-ip 時，請確認相關網域的 DNS 行為與 TUN／系統代理模式一致；若解析與實際連線路徑不一致，會出現「規則看似正確卻仍直連」的現象。完整說明可參考 配置說明。
五、節點選擇與策略組
將網域規則指到策略組後，實際體感仍取決於節點選擇。針對互動式網頁與長連線，建議為「AI／開發用途」單獨建立延遲較低、丟包較少的出口（例如 url-test 或 fallback），避免與大量下載或串流共用過度擁擠的線路。
地區方面，請選擇與你的帳號與服務條款情境相符、且長期穩定的區域；頻繁跨區切換節點，可能增加服務端風控關注。若必須更換節點，建議在同一策略組內切換並觀察一段時間，而不是同時在多個客戶端、多種出口之間跳轉。
| 現象 | 優先調整（網路層） |
|---|---|
| 網頁白屏或元件載入失敗 | 檢查 gstatic、googleusercontent 等是否仍直連；補齊後綴並統一策略組 |
| 僅 API／SDK 失敗 | 確認 googleapis.com 是否納入規則；程式是否走系統代理或需 TUN |
| 偶發逾時、對話中斷 | 在同一策略組內更換較穩節點；檢查 RULE 是否被前置規則覆蓋 |
部分節點對 HTTP／2、gRPC 或較長 TLS 握手的支援度不同，可能表現為「首次連線慢、其後正常」。若你已鎖定網域仍不穩，可在同一策略組內對照不同供應商，而不是只調整全域規則。
六、DNS、Fake-IP 與日誌自檢
完成規則分流後，建議依序驗證：
- 瀏覽器開發者工具「網路」：篩選失敗請求，記錄主機名是否落在未代理網域。
- 本機解析：對
gemini.google.com與實際 API 主機檢查解析結果；若使用 fake-ip，對照 Clash 日誌中的實際連線。 - 命令列：對 API 主機執行
curl -v觀察 TLS 是否完成；握手階段即失敗時，多為路徑或 SNI 問題。 - Clash 日誌：確認命中規則名稱與出站是否與預期策略組一致。
若程式不遵循系統代理，需在程式內設定代理，或於系統層啟用 TUN。這類「半代理」狀態最容易讓人以為節點選擇無效，實則是流量未進入 Clash。
七、RULE 順序與避免誤傷
規則由上而下匹配，順序錯誤會讓後段精確條目無法生效。實務上建議將「明確的服務網域」置前，將寬鬆的 GEOIP 或全域 MATCH 置後。若你同時維護 OpenAI 與 Google 兩套分流，請避免重複且矛盾的 DOMAIN-KEYWORD，並定期依實際連線更新主機名清單。
也請避免把所有境外流量塞進單一超載節點：Gemini 這類互動服務與大量下載共用出口時，容易出現佇列延遲與逾時。較穩妥的做法是依用途拆分策略組，讓網頁與 API 走較乾淨、延遲較低的線路。
八、合規提醒
請遵守 Google 服務條款、適用地區政策與帳號安全要求。本文所述為一般網路一致性設定思路，不保證特定地區或帳號型態下服務可用；若仍無法使用，請依官方支援管道排查帳號、帳單與 API 專案設定。
九、小結
面對 Google Gemini 打不開、gemini.google.com 載入異常，或 Google API 在客戶端頻繁報錯，網路層可先檢查規則分流是否覆蓋 google.com、googleapis.com、gstatic.com 等與你環境實際連線相關的後綴，並確認節點選擇與 DNS、代理模式一致。與 ChatGPT／OpenAI 專文相比，兩者網域族完全不同，應分開維護兩組規則，避免混用造成一邊正常、一邊異常。
相比只能切換少數開關的工具，Clash 生態在規則可視化、核心替換與多平台客戶端上，更利於長期維護；把 Google／Gemini 分流與策略組整理清楚後，日常多半只需微調節點選擇即可。
若你尚未安裝或希望使用更易管理的客戶端，可從本站取得安裝包並匯入訂閱，再依本文補上 Google 相關規則與策略組。