為什麼在終端跑 claude 會頻繁逾時？

2026 年，Claude Code（即 Anthropic 官方推出的 claude 命令列工具）已成為不少後端工程師與全端開發者日常工具鏈的一部分：你在終端輸入 claude，期望它即時呼叫 Anthropic 後端、取得模型回應，協助完成程式碼審閱、重構或測試撰寫。然而許多人第一次碰到的狀況是：瀏覽器打開 claude.ai 一切正常，甚至 Cursor 的 AI 補全也流暢；但終端裡的 claude 卻反覆顯示 connection error、SSL handshake failed，或乾脆掛起幾十秒後逾時。

直覺上，你可能先懷疑節點，切換幾個試試；或者把 Clash 改成全域模式，發現 claude 恢復了，就以為問題出在規則上，於是放棄規則模式改用全域——結果把原本不需要代理的內網 API、本機 Docker、公司服務也一起送出去，反而帶來新的麻煩。本文不走「直接開全域」的捷徑，而是從為什麼 CLI 和網頁走的不是同一條路出發，說明如何在 Clash 裡為 claude 命令列工具建立可獨立除錯的專屬分流管線，並和本站已有的 Cursor IDE 分流、AI 網站分流方案加以區隔。

CLI 行程與瀏覽器的代理差異

在解釋如何設定之前，先理解一個關鍵差異：瀏覽器通常會讀取系統代理設定（System Proxy），而 CLI 工具不一定如此。大多數命令列工具（包含 curl、git、npm）預設只讀取環境變數 HTTP_PROXY 與 HTTPS_PROXY，不會自動跟隨系統代理面板的設定。這意味著即使你在 Clash 的圖形介面開啟了系統代理，終端裡的 claude 仍可能走直連，或完全繞開 Clash 規則，導致請求到不了 Anthropic 伺服器。

這個問題有兩條解法：一是替終端設定環境變數，讓 claude 走混合埠（mixed-port）；二是啟用 TUN 模式，讓整機流量都進 Clash，包含 CLI 行程。若你採用第一條路，需要確保環境變數在每次啟動 shell 時都生效（寫入 .zshrc、.bashrc 或 .profile），且混合埠的埠號要與 Clash 設定一致。若你採用 TUN，則要注意 TUN 與系統代理並存時可能產生雙重代理，以及與其他 VPN 的路由競爭——詳見本站TUN 排查文。

確認 claude 的流量確實進入了 Clash 之後，才輪到討論規則要怎麼寫。這也是本文後半的重點。

Anthropic 連線的組成：API、CDN 與驗証端點

在 Clash 連線日誌或流量預覽中，你可能看到與 Anthropic 相關的請求分散在幾個不同的主機名下，大致可歸為三類。第一類是模型 API 端點：這是 claude 每次傳送 prompt 時最核心的請求目標，走 HTTPS，對延遲最敏感，一旦命中了慢速或不相容的節點，就會直接反映在等待時間或超時錯誤上。第二類是CDN 與靜態資源：CLI 工具在首次執行或更新時，可能需要從 CDN 下載索引、工具包或其他靜態資源；這類請求對頻寬要求較高，但對延遲容忍度相對好。第三類是帳號驗証與 OAuth：claude 在登入、token 刷新或 API 金鑰驗証時會連到驗証相關端點；這類連線通常較短暫，但若走錯節點被封鎖，整個工具會停在認證失敗而無法使用。

三類請求在網路需求上有所不同：模型 API 在意的是低延遲、穩定連線不中斷；CDN 在意的是頻寬與可快取性；驗証端點在意的是到達率而非速度。若你把三者全部塞進同一個策略組，很容易因為某一類的需求不符合節點特性而出問題。實務上初期可先共用一個策略組，待連線穩定後再視需要拆分。

為 CLI 工具單獨做策略組的理由

許多使用者的第一反應是：「直接把 anthropic.com 加進現有的 AI 策略組就好」。這在剛開始可能奏效，但隱患在於：claude.ai 的網頁版本與 Claude Code CLI 的 API 端點可能使用不同的主機名或子網域，且 CDN 的主機名往往涉及多個前綴，單靠 DOMAIN-SUFFIX,anthropic.com 可能漏掉部分請求。更重要的是，網頁 AI 分流組通常設定為 url-test 或 fallback，優先選延遲最低的節點，而自動切換節點對 CLI 長連線有時反而是反效果——模型回應過程中換節點，等於直接中斷請求。

因此，建議至少建立一個專屬於 claude CLI 的策略組（本文範例命名為 CLAUDE_CLI），初期設為 select 類型，讓你手動固定一個穩定節點進行測試；待行為確認後，再決定是否改為自動策略。若你的工作流程中同時用到 Cursor、Claude Code 與其他 AI API，各自對應不同策略組，讓除錯時「縮小變因」容易得多——你可以只切換 CLAUDE_CLI 的出口，不影響 Cursor 或其他服務。

怎麼找到實際的主機名？以連線日誌為準

和 Cursor 分流一樣，本文不列一張「Anthropic 域名大全」清單，原因同樣是：清單會過期，而日誌不會說謊。Anthropic 的服務架構會隨產品迭代調整，CDN 供應商也可能切換；你複製別人的規則清單，可能在一次版本更新後就失效，卻看不出原因。

正確的流程是：在 Clash 的連線預覽（Connection Log）或 API 日誌中，於觸發問題的當下觀察每一條連線的主機名。具體步驟如下：先把 CLAUDE_CLI 策略組的節點換成一個你確定可用的出口，暫時不加任何 claude 相關規則，讓所有流量先落到 MATCH 預設出口；然後在終端執行一個簡單的 claude 指令（例如 claude --version 或一個短 prompt）；最後在連線日誌裡觀察這幾秒內出現了哪些主機名，逐一記錄下來。接著把這些主機名或後綴加進 CLAUDE_CLI 的規則，驗証指令是否能穩定執行。

這個「一次只加一條、每次都確認」的方式雖然比直接貼一大段規則慢，但能讓你清楚知道每條規則的作用，也讓未來維護時更容易找到失效規則並修正。若你習慣批次加入，至少要確保規則加入後在 Clash 連線日誌中能看到命中（hit）記錄，而不是讓流量悄悄落進 MATCH 而你不知道。

規則順序：CLI 專用規則要靠前

Clash 的規則是自頂向下匹配，第一條命中即套用對應的策略組。若你有一條寬鬆的 GEOIP,US,PROXY 或 MATCH,PROXY 在靠前位置，而 Anthropic 相關規則在它們之後，結果就是 CLI 請求永遠走「泛用出口」，而不是你精心配置的 CLAUDE_CLI。

建議的規則排列優先順序：第一區塊放內網與保留位址（GEOIP,PRIVATE,DIRECT、IP-CIDR,192.168.0.0/16,DIRECT 等）；第二區塊放需要直連的特定業務（公司內網、本機服務）；第三區塊放應用層細分規則，依序是 claude CLI 相關、其他 AI API、開發工具（Docker、npm、pip 等）；第四區塊才是地區分流（GEOIP,CN,DIRECT 等）；最後是 MATCH 兜底。

若你同時用到本站Docker 映像倉庫分流和Cursor IDE 分流，可以把這些「開發工具」規則集中在同一區塊，彼此之間再依主機名或後綴特異性決定先後——越具體的規則越靠前，越寬鬆的規則越靠後。

DNS 與 Fake-IP：為何「解析正確」仍可能連不上

claude CLI 使用 HTTPS 連接 Anthropic API。若你的 Clash 啟用了 Fake-IP 模式，DNS 解析結果可能是一個虛假 IP，再由 Clash 在建立連線時進行真正的名稱解析與路由決策。這在大多數情況下透明且正確運作，但有幾個場景需要注意：

第一，若 claude 在連線前先進行了 getaddrinfo（例如使用某些版本的 SDK 或依賴 Go 的 net.Dial），而 DNS 解析的結果是 Fake-IP 範圍內的位址，Clash 必須能正確接管這條連線。若 TUN 模式未啟用而你僅靠環境變數代理，Fake-IP 的特殊 IP 範圍可能讓 SDK 在 connect() 時困惑，因為它試圖直連一個 Fake 位址而不是真實伺服器。解法是確保 claude 流量的 TCP 連線都通過 Clash 的 HTTP/SOCKS5 代理埠，而非繞過。

第二，某些 Anthropic 端點可能使用 SNI（Server Name Indication），若你的規則是基於 DOMAIN-SUFFIX，Clash 在 TLS 握手前就已決策，通常沒有問題；但若混用了 IP-CIDR 規則，要留意 CNAME 解析鏈是否因 Fake-IP 截斷而影響命中。若你不確定，可先只用 DOMAIN-SUFFIX 規則，避免 IP 規則帶來的複雜度。

若你想深入了解 Fake-IP 的機制，可參考本站文件頁的 DNS 說明；在 Claude Code CLI 場景，建議先用最簡單的設定（純 DOMAIN-SUFFIX 規則 + 手動指定出口）確認可行，再逐步引入自動化策略。

設定檔示意：獨立策略組與靠前規則（概念範例）

下列為概念示意，策略組名稱、節點與網域請以你的訂閱與連線日誌為準；合併進正式設定檔前請先備份。範例中的域名僅為佔位符，請替換成你環境中實際觀察到的主機名。

proxy-groups:
  # Claude Code CLI dedicated group — use 'select' first for stable testing
  - name: CLAUDE_CLI
    type: select
    proxies:
      - YOUR_STABLE_PROXY_NODE
      - DIRECT

  # Anthropic CDN / asset download (can reuse CLAUDE_CLI or separate if needed)
  - name: ANTHROPIC_CDN
    type: select
    proxies:
      - YOUR_STABLE_PROXY_NODE
      - DIRECT

rules:
  # --- Internal / private networks first ---
  - IP-CIDR,192.168.0.0/16,DIRECT
  - IP-CIDR,10.0.0.0/8,DIRECT
  - GEOIP,PRIVATE,DIRECT

  # --- Claude Code CLI: API and auth endpoints (replace with log-observed hostnames) ---
  - DOMAIN-SUFFIX,anthropic.com,CLAUDE_CLI
  - DOMAIN-SUFFIX,claude.ai,CLAUDE_CLI

  # --- Anthropic CDN / static assets ---
  - DOMAIN-SUFFIX,anthropicusercontent.com,ANTHROPIC_CDN
  # Add any other CDN suffixes observed in your logs

  # --- Regional direct ---
  - GEOIP,CN,DIRECT

  # --- Fallback ---
  - MATCH,YOUR_DEFAULT_PROXY_GROUP

幾點補充說明：anthropic.com 作為後綴規則已能涵蓋大多數 API 子域名，但若你在日誌中看到其他頂域（例如某 CDN 前綴不含 anthropic 字樣），請逐一補充。ANTHROPIC_CDN 策略組在實際使用中可能合併回 CLAUDE_CLI，取決於你是否希望對兩類流量使用不同節點。初期建議先拆開，確認後再視需要合併，以降低除錯時的混淆。

環境變數設定：讓 claude 走 Clash 混合埠

如前所述，CLI 工具通常不讀系統代理。以下為常見 shell 的環境變數設定方式，請將 7890 替換為你 Clash 實際設定的混合埠號（mixed-port）：

# Add to ~/.zshrc or ~/.bashrc
# Replace 7890 with your actual Clash mixed-port value
export HTTP_PROXY="http://127.0.0.1:7890"
export HTTPS_PROXY="http://127.0.0.1:7890"
export NO_PROXY="localhost,127.0.0.1,::1,192.168.0.0/16,10.0.0.0/8"

設定後執行 source ~/.zshrc（或重新開啟終端），再用 curl -v https://api.anthropic.com 確認連線是否通過 Clash。若 curl 的輸出中出現 * Uses proxy env variable HTTPS_PROXY，表示環境變數已生效。接著在 Clash 連線日誌中確認這條連線命中了 CLAUDE_CLI 策略組，而非 MATCH 預設出口。

需要特別注意 NO_PROXY 的設定：若遺漏了內網位址段，所有內網請求（包含本機 Docker API、localhost 服務）也會嘗試走代理，可能導致意外的連線失敗或迴圈。建議至少把 localhost、127.0.0.1 與你常用的內網段都列入 NO_PROXY。若你的工作同時涉及 WSL2 環境，可對照本站WSL2 接 Windows Clash 混合埠一文的環境變數設定段落，確保子系統與主機的代理設定互不干擾。

驗証流程：按步驟確認、不一次猜到底

完成設定後，建議按以下順序驗証，每一步都確認再進行下一步，避免多個變因疊加導致難以定位問題。

第一步，確認 claude 的流量有進入 Clash：在 Clash 連線日誌開啟的情況下，執行 curl -v https://api.anthropic.com，確認 Clash 日誌出現對應的連線記錄。若沒有，代表環境變數未生效或 CLI 未讀取代理設定，需要先解決這一層。

第二步，確認連線命中了 CLAUDE_CLI 策略組：在 Clash 連線日誌中，該連線應顯示策略組為 CLAUDE_CLI 而非 MATCH 或其他規則。若顯示 MATCH，表示你的 Anthropic 相關規則沒有在 MATCH 之前命中，需要檢查規則順序。

第三步，執行一個簡單的 claude CLI 指令（例如 claude --version 或 claude "Hello"），確認回應時間在合理範圍內。若逾時，可嘗試切換 CLAUDE_CLI 策略組的節點，逐一測試。

第四步，確認 CDN 相關的主機名（若你在日誌中觀察到）也命中了預期的策略組。若 CDN 主機名落入了 DIRECT 但實際連不上，需要把它們也加進對應策略組。

第五步，若你同時使用 Cursor 或其他 AI 工具，確認它們的連線仍命中各自的策略組，沒有被 CLAUDE_CLI 的規則意外攔截（例如若 Cursor 也使用了 Anthropic 後端，DOMAIN-SUFFIX,anthropic.com 就會同時命中兩者，請確認這是否符合你的預期）。

對照表：常見現象與優先處理方向

下列整理常見問題，方便快速縮小排查範圍。

與 Cursor IDE 分流的關係：互補而非重疊

你可能已在使用本站的Cursor IDE 分流方案，且 Cursor 內部也使用了 Anthropic 或 Claude 模型。這裡有個值得注意的地方：Cursor 作為桌面應用，其流量走的是 Electron 行程，而 Claude Code CLI 走的是終端的 claude 行程。兩者在 Clash 的連線日誌中會以不同的 Process Name（若你啟用了 Process 規則）或不同的連線來源出現。

若你希望「Cursor 用節點 A，claude CLI 用節點 B」，可以分別建立 CURSOR_APP 與 CLAUDE_CLI 兩個策略組，並利用 PROCESS-NAME 規則（例如 PROCESS-NAME,claude,CLAUDE_CLI）讓行程名稱決定路由。需要注意的是，PROCESS-NAME 規則目前在 Linux 上需要 TUN 模式才能生效，在 macOS 系統代理模式下也可支援；Windows 上的行為依 Clash 實作版本而異。若你不打算用 Process 規則，改用更精確的主機名規則（確保兩個策略組的主機名範圍不重疊）也能達到相同效果。

整體架構上，Claude Code CLI 分流、Cursor IDE 分流、Gemini 分流、網頁 AI 分流，以及Docker 映像分流，共同構成開發者日常工具鏈的分層路由策略。各自對應不同的行程、連線型態與延遲需求，互相補充而不重疊，是維護靈活且可除錯的 Clash 設定的核心思路。

合規與使用條款提醒

透過代理或節點使用 Anthropic 的 API 與 Claude Code 時，仍須遵守 Anthropic 的服務條款、API 使用政策，以及所在地的相關法規。本文僅從網路工程角度說明 Clash 規則與流量路徑的協同思路，不構成任何法律建議；讀者請自行確認相關合約與適用規範。

結語：CLI 工具值得一條屬於自己的分流管線

Claude Code 代表的是一類新型開發工具：它不是網頁、不是 IDE 插件，而是直接在終端行程裡消費 AI API。這類工具對連線穩定性的要求更高，因為一次 prompt 往往是分鐘級的長請求，而不是秒級的網頁載入。把它和「ChatGPT 網頁分流」或「Cursor IDE 分流」混在同一條管線，往往是逾時問題難以定位的根源。

透過為 claude CLI 建立獨立的 CLAUDE_CLI 策略組、正確設定環境變數讓流量進入 Clash、並以連線日誌驅動規則補充，你可以把「終端 AI 工具連線不穩」從玄學現象，收斂成可逐步驗証的工程問題。若你還沒有一個整合好的 Clash 設定環境，可先從本站用戶端下載頁取得適合你平台的版本，再依本文思路建立 CLI 分流管線。

→ 立即免費下載 Clash，為 Claude Code 等 CLI AI 工具建立穩定的分流管線