情境資訊 · Clash 技術部落格

ChatGPT、Gemini、Claude 怎麼用 Clash 分流？

ChatGPT、Gemini 和 Claude 的網頁、登入與模型介面可能使用不同網域。給每個服務綁定穩定策略，並從實際連線記錄補規則，能減少登入和長回覆時的出口漂移。

閱讀正文回到部落格
  • ChatGPT
  • Gemini
  • Claude
本文目錄
發布日期
更新時間
預計閱讀
約 6 分鐘

ChatGPT、Gemini、Claude 要分流，先把網頁、登入和 API 分開

ChatGPT、Gemini 和 Claude 的首頁能開啟，只能證明前端頁面的一部分請求成功。帳號登入會跳到認證網域，傳送訊息會存取模型介面，上傳檔案還會使用對象儲存或內容網域；其中一條直連、被拒絕或換了出口，使用者看到的往往只是轉圈。

先把失敗動作寫清楚：頁面白屏、登入循環、訊息發不出去、串流回答中斷、檔案停在上傳中，分別對應不同請求。把它們統稱為「AI 打不開」，只能得到一份越來越長卻無法驗證的網域表。

症狀先對應到請求階段

看到的現象先觀察什麼不應先做什麼
頁面白屏或缺少樣式指令碼、靜態資源和 DNS反覆更換帳號
登入後又回到登入頁認證跳轉、Cookie 與出口地區只補模型 API 規則
訊息一直轉圈或中途斷開模型介面、串流連線與節點切換只測試首頁
檔案上傳停住上傳網域、對象儲存和請求體大小把所有 CDN 都加入代理

登入期間先固定出口，不讓自動測速組換地區

認證請求和登入後的第一批介面請求如果來自不同出口，可能觸發重新驗證或讓會話失效。檢查時建立一個手動策略群組，固定一條可用節點，讓帳號頁、主站和介面在一次登入過程中使用同一出口。

這不是說三個服務必須永久共用一個節點。問題確認後可以按 ChatGPT、Gemini、Claude 分組；但每個服務自己的認證和資料請求仍應保持地區一致。帳號不可用、服務未對所在地區開放或產品側限流，也不會因為多寫幾條 Clash 規則而消失。

網域從實際會話裡找，不從舊清單裡整包複製

清空連線記錄後，只完成一個動作，例如登入 Claude、在 Gemini 傳送一條短訊息，或從 ChatGPT 上傳一個小檔案。記錄失敗前後出現的主機名、命中規則和出站，才知道遺漏發生在哪一層。

從明確的產品入口開始記錄：ChatGPT 使用 chatgpt.com，OpenAI API 使用 api.openai.com；Gemini 網頁使用 gemini.google.com，Gemini API 常見入口是 generativelanguage.googleapis.com。

Claude 網頁使用 claude.ai，Anthropic API 使用 api.anthropic.com。登入跳轉、靜態資源和上傳位址仍要從自己的連線記錄補齊。

新規則放在寬泛的 GEOIP、規則集和 MATCH 之前。Google 登入網域還會被 Gmail、YouTube 等服務共用，不要為了 Gemini 直接把 accounts.google.com 之類的寬網域永久綁進 AI 組。

連線記錄確認認證請求走錯出口時，再把當次出現的主機加入 AI 組並重新驗證。

下面不是可直接貼上的完整設定。先在目前訂閱的代理群組清單裡找一個確實存在的組名，用它替換每一處 YOUR_EXISTING_GROUP；否則設定檢查一定會報 group not found。三個 AI 組建好以後，再加入規則。

先把現有組名替換正確，再建立三個 AI 策略群組
# 必须先把 YOUR_EXISTING_GROUP 替换成当前配置里真实存在的组名
proxy-groups:
  - name: AI-OPENAI
    type: select
    proxies:
      - YOUR_EXISTING_GROUP
      - DIRECT
  - name: AI-GOOGLE
    type: select
    proxies:
      - YOUR_EXISTING_GROUP
      - DIRECT
  - name: AI-CLAUDE
    type: select
    proxies:
      - YOUR_EXISTING_GROUP
      - DIRECT

rules:
  - DOMAIN-SUFFIX,chatgpt.com,AI-OPENAI
  - DOMAIN,api.openai.com,AI-OPENAI
  - DOMAIN,gemini.google.com,AI-GOOGLE
  - DOMAIN,generativelanguage.googleapis.com,AI-GOOGLE
  - DOMAIN,api.anthropic.com,AI-CLAUDE
  - DOMAIN-SUFFIX,anthropic.com,AI-CLAUDE
  - DOMAIN-SUFFIX,claude.ai,AI-CLAUDE
  - GEOIP,CN,DIRECT
  - MATCH,YOUR_EXISTING_GROUP

這組規則真正生效的證據

  • 設定檢查透過，沒有 group not found
  • ChatGPT、Gemini、Claude 的測試請求分別命中自己的策略群組
  • 登入跳轉和傳送訊息期間出口沒有變化
  • 未加入規則的 Google 服務沒有被意外帶進 AI-GOOGLE

網頁正常而 CLI 超時，多半不是同一條代理入口

瀏覽器通常讀取 Windows 或 macOS 的系統代理，Python SDK、命令列工具、IDE 外掛程式和容器未必這樣做。先看失敗請求有沒有出現在 Clash 的連線頁面；完全沒有記錄，說明請求還沒有進入規則引擎。

命令列工具可以臨時設定 HTTP_PROXY、HTTPS_PROXY 和 NO_PROXY，桌面開發環境也可按應用說明填寫代理。確實有多個不遵循系統代理的處理程式時再考慮 TUN。若連線已經出現在記錄裡，就不要繼續折騰環境變數，而應檢查它命中的規則、策略群組和節點。

同一服務偶爾白屏，先統一 DNS 入口

瀏覽器安全 DNS、系統 DNS 和 Clash DNS 同時工作時，同一服務可能在不同程式裡得到不同位址。檢查階段可暫時關閉瀏覽器獨立 DoH，讓網域查詢和連線都從 Clash 經過，再看白屏或資源載入失敗是否仍然出現。

解析成功而 TLS 握手或連線繼續超時，問題才回到節點品質和規則。不要因為一次 DNS 失敗就更換十個城市，也不要在沒有觀察結果時同時改 Fake-IP、嗅探和上游 DNS。

長回覆和上傳更怕出口變化，而不是測速數字多幾毫秒

AI 對話會維持較長的串流連線。自動組過於頻繁地重新選擇節點，可能讓首頁始終很快，回答卻在中間斷開。測試時用一條固定節點完成長回覆、重新產生和檔案上傳，再比較自動組是否真的帶來改善。

上傳失敗還要區分請求是否已經傳送。進度從 0% 不動，先看上傳位址是否命中；傳到一半回傳明確 HTTP 狀態，則查看大小限制、檔案類型和服務回應。Clash 只能改變網路路徑，無法繞過產品本身的限制。

最後分別測試登入、長回覆、上傳和 API

比開啟首頁更有意義的測試

  1. 重新登入

    確認認證跳轉結束後不會回到登入頁，出口地區沒有變化。

  2. 傳送一段長對話

    觀察首字時間、串流輸出和結束狀態，不只看能否出現第一句話。

  3. 上傳一個小檔案

    核對上傳網域、進度和最終處理結果。

  4. 呼叫一次 API

    記錄主機、HTTP 狀態碼和用戶端是否使用了正確代理入口。

某一項失敗時，只回到對應階段處理。登入穩定、對話中斷，就保留認證規則不動；瀏覽器正常、API 用戶端沒有連線記錄，就處理處理程式代理。文章的規則不應比問題本身擴張得更快。

參考資料