2026 Claude Code 終端總逾時？用 Clash 分流 Anthropic API 與依賴網域

現象：Claude Code 在終端反覆逾時，瀏覽器卻像沒事

許多使用者是在桌面安裝了 Claude Code（或類似的 Anthropic／Claude CLI 工作流程）後，才第一次認真面對「為什麼同一台電腦上，Safari／Chrome 能開 claude.ai，終端指令卻卡住、Handshake 很慢或乾脆報 ETIMEDOUT」這類問題。若您也正在搜尋 Claude Code、Anthropic API 與 終端代理怎麼接在一起，可先建立一個關鍵認知：只有「對瀏覽器生效」的系統代理，不等於對所有行程生效。Clash／Mihomo 真正解的是「如何把出口決策規則化」，但前提是請求要能進核心；否則再漂亮的 分流規則都只會對「已進來的流量」有效。

2026 年圍繞 AI 程式助理的工作流密度更高，許多人會同步使用 Cursor 這類編輯器整合，以及本篇聚焦的終端 Claude 工具鏈。坊間速成教學常把問題簡化成「設定好 API Key 就行」，但若您身處對海外 API 線路敏感的網路環境，實際上需要處理的往往是多段主機：除了 api.anthropic.com 這類公開 API，登入／用量追蹤、分析與 CDN 資產也可能散落在不同後綴下。本篇以 Clash 語意的「策略群組＋規則置前＋可觀測日誌」來講終端視角的分流，並與站內泛用 ChatGPT／Claude 規則專文並讀時，把注意力放在CLI 如何把流量送進代理核心即可。

合規提醒：Clash 為本機網路轉送與設定管理軟體，不提供節點。請於合法授權與所在地法規範圍內使用網路與各家 API／產品條款相容的組態；本文僅講設定與網域策略，不涉及規避服務條款。

先有路徑、才有規則：終端與編輯器差在哪裡？

在問題定位上，建議把所有症狀先拆成兩條問句：(1) 這條 TCP／TLS 連線有經過 Mihomo 核心嗎？ (2) 若有，規則把該請求送去了哪個 proxy-groups？ 對 Claude Code 而言，常見的流量包括：呼叫 Anthropic API 的程式化請求、與 Claude 控制台或帳號體驗相關的網域名稱（例如 claude.ai）、以及可能隨產品更新而增減的統計／快取節點。您不需要背死清單，但要在腦中準備一桶「可依日誌補洞的 Anthropic／Claude 後綴」，並把這一桶放在獨立的策略決策之下。

對照 僅瀏覽器走代理 時，Electron 類編輯器與終端對「系統代理」的敏感度常常不同。「只勾了瀏覽器延伸套件」的情境下，Claude Code 可能完全不知道本機連接埠上跑著 Mihomo；相對地，開啟 TUN 模式 可把系統層路由更完整地導進核心（仍要注意略過區域網域與分割通道需求）。換句話說：TUN 不是萬靈丹，但在「確認終端沒繼承代理」的情境下，多半是除錯時最省事的一條對照途徑。

五步收斂：從確認進核心到補規則

以下流程假設您已能跑起基本的訂閱與規則骨架；若尚無節點或群組，請先依照 訂閱匯入指南 完成底層，再回到此處把 Anthropic／Claude 相關名稱掛載到靠前的位置。

  1. 在 Clash／Mihomo 儀錶板確認目前模式為 rule，並紀錄本機開放給程式使用的連接埠（常見為 mixed-port 對應的 HTTP／SOCKS 位址）。開啟一個終端對照：這個 Shell 沒設定任何 Proxy 環境變數時，Claude Code 的連線在日誌中是否完全沒出現——若是，問題多半在未進核心。
  2. 二選一或並用：若要系統級導流，評估開啟 TUN／系統 proxy 並把「略過區域／內網」寫清楚；若要最小影響面，對您執行 Claude Code 的那段 Shell export HTTPS_PROXY=http://127.0.0.1:埠（或 SOCKS 對應寫法），必要時細調 NO_PROXY 放行本機組建與內網 Git，請勿把 127.0.0.1、公司 VPN 區段誤塞进代理而造成次級逾時。
  3. 新建名稱明確的策略群組，例如 CLAUDE_AI：外層 select 便於您在 UI 內鎖特定節點，子層可加 url-test 自動挑線；對長連線與 HTTPS API 請避免過度頻繁切換出口，可把 interval 適度拉大並觀察 tolerance。
  4. 於 rules: 頂區（早于 GEOIP、早于巨大 RULE-SET、早于寬鬆 MATCH）插入 Anthropic／Claude 網域示例：DOMAIN-SUFFIX,anthropic.com、DOMAIN-SUFFIX,claude.ai；若控制台或文件站使用獨立子域，請以日誌中實際出現的字串補強。對整體「國內外骨架」仍可參考 規則分流詳解，並記得細則永遠在寬則之上。
  5. 重跑 Claude Code；在連線日誌對照請求的策略與規則名稱；若規則顯示正確但仍覺得不穩定，將排查轉往 DNS：enhanced-mode: fake-ip 情境下，請核對 fake-ip-filter、是否與 nameserver-policy 假設不一致，並暫時關閉瀏覽器安全 DNS／DoH 做受控對照——這類問題常表現為「規則看對、體驗仍怪」。若您不熟圖形化操作，可走 Clash Verge Rev 對照群組開關與日誌。

小貼士：用 curl -v 加上 --proxy 對同一 API 做一次手動對照（先直連後走代理），能極快判斷是「規則沒命中」還是「出口品質問題」。對 Claude Code，優先對準日誌中反覆逾時的那一兩個主機名。

YAML 骨架示例（請以您環境日誌補洞）

片段僅示意語意：遠端規則集 URL、節點本名與埠號務必換成您的真值，勿複製陌生人的「一包到底」規則庫進生產環境。名稱可自調，一致性比背誦術語更重要。

YAMLproxy-groups:
  - name: "CLAUDE_AI"
    type: select
    proxies:
      - "CLAUDE_AUTO"
      - "HAND_PICK"
      - DIRECT
  - name: "CLAUDE_AUTO"
    type: url-test
    proxies:
      # Insert real proxies from subscription
    url: "https://www.gstatic.com/generate_204"
    interval: 300
    tolerance: 40

rules:
  - DOMAIN-SUFFIX,lan,DIRECT
  - DOMAIN-SUFFIX,local,DIRECT
  # Keep Anthropic stack BEFORE broad GEOIP / MATCH blocks
  - DOMAIN-SUFFIX,anthropic.com,CLAUDE_AI
  - DOMAIN-SUFFIX,claude.ai,CLAUDE_AI
  # Extend with domains seen in Mihomo logs (e.g. console or CDN hosts)
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

若您訂閱注入順序複雜、或上游模板把規則集插得很早，可能出現「您手寫規則其實在檔案中落得很後面」這種視覺誤區；應以核心實際載入後的順序為準，而不是只看備份 YAML 視覺上的位置。許多短文會說「把規則貼在最上面」，但在實務上等價於插在會提早結束比對的那一條寬規則之前，並非字面第一段註解之後就一定能命中。

為什麼測速正常，Claude Code 仍像在「載入中空轉」？

url-test 對單一路徑統計的好壞不保證對 Anthropic API 在每個區域端點都同樣友善。模型串流或使用 HTTP／2、gRPC wrapper 的情境，對連線數、長連線中斷、節點 IP 評價更敏感；若自動群組在您工作階段中頻繁換出口，伺服器側可能對「短時間內多次變換出口」這類行為額外加嚴。另一個速成文較少提到的細節是：tolerance 太小會讓節點「分分鐘自動換線」，前端看起來就像連串重試與假性逾時。

遇到「終端卡住但日誌看似有代理」時，先把變因收斂成三件事：(1) 暫停在 CLAUDE_AI 內手動鎖單一節點；(2) 為了對照而暫停 Sniffer／特殊規則集；(3) 對照問題是否只在某些機房或某家供應商的節點上發生。多數人一輪對照就能把「自動挑線誤判」與「單一路線確實有問題」分開來看。

延伸問答（對照 Structured Data）

瀏覽器開網頁正常，不代表 Claude Code 沒問題。瀏覽器與終端對 PAC、環境變數、Sandbox 的反應路徑並不相同；只靠「這台電腦有開代理」而沒對齊行程，CLI 仍可能維持直連。務實的切入點仍是二選一的「進核心」：全域 TUN，或對執行 Claude Code 的 Shell 設定 HTTPS_PROXY。

一定要用 TUN 嗎？不一定要。對日常開發，若您能接受對單一終端機分頁輸入代理環境變數，影響範圍通常比全域 TUN 更小；但每次開新視窗都要記得載入設定，對依賴腳本的人來說也容易被遺漏。許多現成設定選擇一次開 TUN 以求省事，但需要您事先規劃好略過區段與公司 VPN 並存的優先級。

規則明明寫了，連線紀錄卻仍是 DIRECT，多半可往「順序」「被規則集提前遮蔽」「請求根本沒進核心」三件事收斂。請務必以紀錄裡的策略與規則命中來源為準，而不是憑 YAML 視覺位置臆測；若只是把他人整包 RULE-SET 貼上卻插在個人細則之前，也常會發生這類假性「規則無效」。若已確認命中代理群組仍逾時，就不宜再無限堆疊規則，應改檢節點品質、DNS／fake-ip 與長連線行為。

安全提醒：請勿將訂閱連結或含 API Token 的全量組態檔張貼在公開討論區。第三方現成規則包若未經您親自稽核來源與順序，可能把流量導向不明出口或在語意上過於寬鬆。

結語

對 Claude Code 這類高度依賴 Anthropic API 的流程而言，終端端的網路問題很少只靠「打一個總開關」就消失，多半要像拼圖一樣同時對齊請求是否真的進 Mihomo／Clash、Anthropic／Claude 相關後綴是否插在寬規則之前，以及 DNS / fake-ip 是否與假設一致。當您把這些網域收斂到獨立的 CLAUDE_AI，再依連線紀錄補齊零星漏網之主機名稱，原本「像在賭運氣」的逾時，通常會逐一收斂成可解釋的線路或解析問題；坊間只看域名列表、卻不提載入順序與終端進核心前置的速成文，往往就是在這個轉換點讓讀者卡關。

市面上一鍵懶人包若缺乏可追溯的規則載入順序與連線紀錄觀念，往往在訂閱合併、Sniffer 或規則集規模變大時就不好除錯；相對地，本站建議在同一套 Mihomo／Clash 規則語意底下維護訂閱、策略群組與圖形化面板，並把可查連線紀錄當成日常習慣，對長期在終端使用 Claude Code、同時又開著 Cursor 的工程師會省大量往返試錯。ClashSource 把主流桌面平台版本與文件整理在同一入口，少用時間在論壇拼湊互不相容的小抄。如果您也希望讓終端代理與細緻分流規則長期待在可回溯的工作流程裡，依本文對齊 Anthropic／Claude 鏈路後，不妨先 免費下載 ClashSource：完成底層訂閱與規則骨架後，再在策略群組拉出專門承載 Claude Code 的出口桶即可。