情境資訊 · Clash 技術部落格

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

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

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

想把不同 AI 服務分開管理，重點不是收集越長越好的網域清單，而是知道帳號驗證、模型請求與上傳各自去了哪裡。共用的登入網域也可能被其他產品使用。依實際工作階段補充規則，並為各服務保留穩定出口，避免一次修改連帶改變其他存取。

網頁、登入、模型與上傳分別有哪些請求？

為 ChatGPT、Gemini 或 Claude 設定規則時，分別完成登入、傳送訊息與上傳檔案，記錄對應網域與出口。首頁能開啟只證明部分網頁請求成功；同一服務的其他請求可能走了不同策略。已有失敗時，依下表從具體動作定位。

失敗動作對應的請求

看到的現象觀察重點容易走錯的方向
頁面白屏或缺少樣式指令碼、靜態資源和 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 用戶端沒有連線記錄時，檢查該處理程式的代理設定。每次只調整失敗動作涉及的設定。

參考資料