為什麼企業端不該沿用「消費 Gemini」同一套規則？

到了 2026 年，Gemini Enterprise 與 Agent Platform 這類產品把模型能力裝進既有 Google Cloud 帳務、IAM、稽核與網路邊界裡，流量型態自然與一般使用者開啟 gemini.google.com 或 AI Studio 大不相同。企業團隊最常遇到的不是「完全連不上」，而是主控台框架載入一半、左側導覽空白、Agent 部署精靈卡在驗證步驟，或是後端服務呼叫 Vertex／Gemini API 一律在客戶端逾時──表面看起來像產品 bug，實際卻常是出口、DNS 與規則順序疊加造成的半套連線。

若您把企業場景硬塞進與消費端共用的 AI_PROXY，很容易出現兩種副作用：第一，規則太寬，*.googleapis.com 或 DOMAIN-KEYWORD,google 類條目讓不相關流量整天在同一節點擠牙膏，除錯時難以判斷「是 Agent Platform 走錯群組」還是「其他 API 被拖慢」；第二，規則太窄，只覆蓋網頁_hostname 而漏掉後台列舉專案、啟用服務或取得憑證時偷偷蹦出的子網域，結果瀏覽器顯示已登入、但 XHR 在背景逾時。因此較穩的做法是另建 GCP_ENT_PROXY（名稱可自訂），專責承載 Google Cloud 主控台、企業主機與您日誌中反覆出現的 API 端點，並把所有相關 DOMAIN／DOMAIN-SUFFIX 放在寬鬆 GEOIP、第三方 RULE-SET 與兜底 MATCH 之前。若您尚未完成訂閱匯入，建議先閱讀 訂閱匯入教學，再回頭調整規則順序，以免策略群組名稱與訂閱內節點對不起來。

合規提醒：Clash／Mihomo 為本機網路轉送與設定管理軟體，不提供遠端節點。請在合法合規前提下使用自有或授權的服務，並遵守 Google Cloud 條款、專案配額、資料落地與所在地法規。

先把流量分車道：主控台、Agent API 與身分鏈路

企業除錯時，建議先把問題收斂到三條「車道」。第一條是人類操作的主控台與說明文件：典型主機包含 console.cloud.google.com、cloud.google.com，以及按需載入的說明與靜態資源。第二條是程式化呼叫的 Google Cloud API：視您啟用的服務而定，日誌中常見 cloudresourcemanager.googleapis.com、serviceusage.googleapis.com、iamcredentials.googleapis.com、aiplatform.googleapis.com 等；Agent Platform 與 Vertex AI 相關流量往往集中在 aiplatform 與其區域化變體，但實際子網域仍應以連線紀錄為準。第三條是身分與授權：accounts.google.com、oauth2.googleapis.com、部分情境下的 securetoken.googleapis.com 等，決定您是否能完成裝置授權、服務帳號金鑰輪替或工作站登入。

這三條車道在規則表上可以都先指向同一個 GCP_ENT_PROXY，但心智上要分得開：當您只修「主控台可開」卻忘記補 API 端點，會得到「畫面有、資料沒有」；當身分走直連而 API 走代理，有時會引發額外驗證或工作階段不一致。與本站 消費端 Gemini／AI Studio 分流專文對照時，請記得該文聚焦 generativelanguage.googleapis.com 與 aistudio.google.com 等主機；無法一對一替代企業控制平面。另可參考 AWS MCP 分流專文中「雲端主控台＋MCP／IDE」的拆分思路，將相同方法套用到 GCP 命名空間。

Agent Platform 與「總逾時」常見表象

智能體平台產品線在 UI 上往往一次拉出多個微前端與計量模組：列表頁載入、部署精靈、秘密管理、Tracing 與配額頁籤可能各自呼叫不同子網域。當出口對某段 TLS 握手不友善、或長連線被中途設備斷開時，您會在開發者工具裡看到大量請求同時 pending，最後一批一起紅字，使用者體感就像「整頁卡住」。若此時把責任全推給單一 API，通常會錯判；更實用的做法是開啟 Clash 連線列表，按時間排序，找出最早失敗或最常被重試的主機名，再往回補規則。

另一種表象是批次工具或 CI Job 穩定逾時：這類呼叫通常走 gRPC／HTTP+JSON，逾時閾值比瀏覽器短，對「節點輪替」也更敏感。當 url-test 群組在兩個實際不可用的節點間快速切換時，客戶端可能剛建立連線就被換路，形成統計意義上的「永遠連不上」。短期除錯請先在 GCP_ENT_PROXY 內手動固定單一節點，確認問題是否隨出口穩定而消失，再回到自動測速與間隔調整。整體分流哲學仍建議與 規則分流深度文一併閱讀，理解為何「命中即停」會讓順序比口號式 keyword 更重要。

規則順序：為什麼補了 DOMAIN 仍像沒生效？

在 mode: rule 下，rules: 由頂端向下比對，命中即停。因此 Gemini Enterprise 相關規則要嘛出現在會提前結束比對的寬鬆集合之前，要嘛乾脆改寫訂閱合併方式，把自訂區段插入到第三方 RULE-SET 載入結果的前面。實務上最常見的錯誤，是您在檔案末尾追加了幾行 DOMAIN,console.cloud.google.com，但訂閱商注入的巨大 RULE-SET 早在更早的插入點就把流量送往 DIRECT 或另一個不符預期的群組──結果您怎麼改「底部」都不動。

第二個常被忽略的點是國內／海外分流的總開關：某些 GEOIP 規則會把「看起來像境外的 Google IP」硬導向直連或相反方向，與您期望的企業出口不一致。若您使用 TUN 模式，還要分開檢查「流量有沒有進核心」與「進核心後由哪條規則命中」，否則容易在錯層除錯。簡言之：先把「誰先結束比賽」搞清楚，再談節點品質。

可照抄的規則清單骨架（務必再用日誌補齊）

以下條目為教學用骨架，請視環境增刪；優先使用精準 DOMAIN 或範圍可控的 DOMAIN-SUFFIX，避免一條過大的 googleapis.com 規則讓全家桶 API 跟著搬家。

  • DOMAIN,console.cloud.google.com,GCP_ENT_PROXY
  • DOMAIN,cloud.google.com,GCP_ENT_PROXY
  • DOMAIN-SUFFIX,aiplatform.googleapis.com,GCP_ENT_PROXY
  • DOMAIN-SUFFIX,cloudresourcemanager.googleapis.com,GCP_ENT_PROXY
  • DOMAIN-SUFFIX,serviceusage.googleapis.com,GCP_ENT_PROXY
  • DOMAIN-SUFFIX,iamcredentials.googleapis.com,GCP_ENT_PROXY
  • 身分鏈路（可選與 API 同群組）：DOMAIN-SUFFIX,accounts.google.com,GCP_ENT_PROXY、DOMAIN-SUFFIX,oauth2.googleapis.com,GCP_ENT_PROXY

若您的組織啟用 BeyondCorp 類方案或自架零信任閘道，還可能在日誌中看到額外的企業網域或單一登入主機；那類名稱不屬於 Google 公網文件保證範圍，但仍應以實際連線為準補規則。請勿從論壇複製巨型「谷歌全家桶」清單而不經審核。

YAML 骨架：插入點與命名

下列片段示範策略群組與規則的相對位置。請將遠端訂閱中的真實節點名稱替換進 proxies 列表，勿未審核即用于生產環境：

YAMLproxy-groups:
  - name: "GCP_ENT_PROXY"
    type: select
    proxies:
      - "GCP_ENT_AUTO"
      - "Hand-Picked-Stable-Node"
      - DIRECT
  - name: "GCP_ENT_AUTO"
    type: url-test
    proxies:
      # Inject real proxy names from your subscription
    url: "https://www.gstatic.com/generate_204"
    interval: 300

rules:
  - DOMAIN-SUFFIX,lan,DIRECT
  - DOMAIN-SUFFIX,local,DIRECT
  # Google Cloud console / enterprise APIs (must sit BEFORE broad RULE-SET / MATCH)
  - DOMAIN,console.cloud.google.com,GCP_ENT_PROXY
  - DOMAIN,cloud.google.com,GCP_ENT_PROXY
  - DOMAIN-SUFFIX,aiplatform.googleapis.com,GCP_ENT_PROXY
  - DOMAIN-SUFFIX,cloudresourcemanager.googleapis.com,GCP_ENT_PROXY
  - DOMAIN-SUFFIX,serviceusage.googleapis.com,GCP_ENT_PROXY
  - DOMAIN-SUFFIX,accounts.google.com,GCP_ENT_PROXY
  - DOMAIN-SUFFIX,oauth2.googleapis.com,GCP_ENT_PROXY
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

重點仍是：任何會提早結束比對的外掛規則集若放在上述片段之前，您新增的 GCP 條目可能永遠輪不到。若遇此情況，請改在訂閱合併工具的「自訂規則區」插入，或暫時停用可疑片段做對照測試。

DNS、fake-ip 與瀏覽器安全 DNS

啟用 enhanced-mode: fake-ip 時，規則匹配與應用程式實際解析路徑可能出現落差。企業場景下更棘手的是：瀏覽器或系統層級的安全 DNS／DoH 可能繞過 Clash 的 DNS 元件，導致「規則顯示命中代理、但應用程式解析到另一組 IP」。當 Agent Platform 主控台出現零星 502、連線重設或長時間白屏，請同步檢查 fake-ip-filter、嗅探設定與是否有多張網卡／VPN 疊床架屋。

處理原則與其他雲端 API 分流文相同：把 DNS 決策與規則設計放在同一個心智模型裡。必要時在受控環境暫時關閉瀏覽器 DoH 做 A／B 測試，並避免同時開啟多個互相改寫路由的虛擬網卡而不自知。

驗證流程（建議照順序執行）

  1. 確認客戶端為 Rule 模式，且系統代理或 TUN 已在該作業系統正確授權。
  2. 清空舊連線紀錄後，開啟 Google Cloud 主控台並進入與 Gemini Enterprise／Agent Platform 相關的專案頁面，觀察是否仍有長時間 pending 的 XHR。
  3. 在連線列表中篩選 google 或 googleapis 關鍵字，確認命中策略為 GCP_ENT_PROXY，而非被其他規則提前帶走。
  4. 以最小權限的服務帳號或本機 ADC 呼叫其中一個管理型 API（例如列出已啟用服務），對照日誌是否仍逾時。
  5. 在 GCP_ENT_PROXY 內改為單一手選節點，排除 url-test 誤判或出口輪替干擾。
  6. 若症狀僅發生在特定子網域，將該主機名補進規則表更前段並重載設定；必要時暫停可疑第三方規則集確認插入點。

常見踩坑

  • 過大的 googleapis.com 規則：涵蓋面太廣，除錯與風險同步放大。
  • 只配主控台、忘記管理平面 API：畫面骨架能開，資料與部署流程全失敗。
  • 以為 MATCH 會智慧理解 Agent Platform：MATCH 只是兜底命中。
  • 忽略第三方規則集插入點：在檔案末尾新增的條目可能永遠輪不到。
  • 把問題誤判成訂閱全壞：實為 DNS、登入出口分裂或 IAM；先對照日誌再換節點。

安全提醒：請勿使用來路不明的「一鍵雲端規則」；惡意集合可能把敏感 API 導向不可信出口。訂閱連結與服務帳號金鑰應視為憑證，勿公開分享。

常見問題（精簡版）

可以把整個 googleapis.com 一次塞進同一條 DOMAIN-SUFFIX 嗎？ 不建議，理由是同後綴涵蓋過多非 GCP 服務；請依日誌收斂子網域。

與消費端 Gemini／AI Studio 規則能否共用？ 主機集合只有部分重疊；企業控制平面應獨立群組維護以免互相干擾。

OAuth 與 API 一定要同一出口嗎？ 不必，但短期讓二者固定同一節點有助於排除身分問題。

仍逾時怎麼辦？ 若網路層已排除，請回到專案配額、組織政策、VPC SC 與客戶端錯誤碼；Clash 只解決「出口與規則」這一層。

結語

Gemini Enterprise 與 Agent Platform 讓「模型」長進既有雲端治理邊界，但也把Google Cloud 控制平面、IAM 與推理 API綁在同一套企業體驗裡。Clash 能提供的價值，並非取代雲端安全控制，而是把這些主機變成可排序、可觀測、可回滾的規則：當您把置前 DOMAIN／DOMAIN-SUFFIX 與獨立 GCP_ENT_PROXY 對齊實際日誌，再用固定節點做對照測試，多數「總逾時」會從黑箱變成可測量的網路問題。後續若還要打磨 CLI、CI 或 IDE 外掛，亦可搭配 教學文件把基礎模式先站穩。

相較於零散腳本或只改系統代理卻缺乏觀測面的工具，在同一套規則語意下維護桌面與開發環境，長期維運成本通常更低；不過市面不少方案要嘛介面步驟瑣碎、缺少繁體說明與一致的前後導航，要嘛在遇到長連線與多訂閱來源時難以還原「到底是誰先命中了規則」。Clash 官網 針對這類企業雲端主控台＋API 分流情境整理了可複用的骨架與驗證順序，並與站內多篇 AI、雲端與開發者工具分流專文互相銜接，讓您不必在工作與除錯之間反覆試誤。若您正在找一款能把規則、訂閱與觀測串在同一條鏈路上的用戶端，不妨 免費下載 Clash 官網，依本文步驟幾分鐘內就能完成對照測試。