瀏覽器開 claude.ai 正常，為什麼 Claude Code CLI 仍逾時？

瀏覽器多半吃系統 Proxy 或自有通道；終端與編碼代理整合行程常用環境變數或透明接管以外的路徑，規則命中與 DNS 解析鏈不一定相同。請以 CLI 重現流程中的核心日誌為準補規則，不要假設網頁可用的網域清單足以涵蓋終端。

能不能直接複製站內 Claude 網頁／API 專文的規則到 CLI？

可作為起手參照，但 Claude Code／Anthropic CLI 仍以終端日誌為準：行程是否進核心、訂閱更新後規則區塊是否被插入到錯誤位置，都會讓「複製貼上」看似正確卻仍逾時。請獨立維護終端視角清單並用日誌擴充。

為什麼一直換節點還是 handshake 很慢？

若規則早一步把部分請求送去直連或不相容出口，或 DNS 與實際連線終點不一致，外觀會像節點品質問題。請先把出站鎖定為單一可信策略組，並對照日誌確認同一串請求是否落在同一出口。

📖 教學 2026 年 5 月 6 日 ⏱ 約 20 分鐘閱讀

Claude Code CLI 總逾時？2026 用 Clash 鎖網域分流與 DNS（分步實測）

如果你已經裝好 Clash（或 Clash Verge Rev／Mihomo 核心），瀏覽器開 Claude大致順，換到終端或編輯器整合跑 Claude Code CLI（官方命令列／編碼代理工具鏈，亦常與 Anthropic CLI、後端直連 api.anthropic.com 並存）卻出現請求逾時、TLS 握手卡住、或偶發中斷後長時間無回應——多半不是「抽到爛節點」這麼簡單，而是終端行程沒走同一套代理決策，再疊網域分流順序與DNS 分裂，症狀會統一成難以判讀的逾時。本站〈Claude 網頁與 Anthropic API〉偏瀏覽器與後端情境；本篇刻意對齊開發命令列 × 分流：先證明流量真的進核心，再以連線紀錄對桶補規則、最後收斂Clash DNS。Clash 基礎教學入口若你要先把訂閱、模式與系統 Proxy 對齊，建議並行翻閱。

先把「逾時」拆成可追查訊號

終端與編碼代理工具回報的錯誤往往只有ETIMEDOUT、ECONNRESET或泛用的「request timeout」，使用者很容易把它直接等同於「機場節點品質差」。實務上更值得先把現象分類：第一類是請求根本沒進 Clash 核心（直連撞上區域過濾，或走了不相容的路由）；第二類是多段 HTTP／TLS 中只有一段失手，例如呼叫模型前仍可連到統計或設定檔主機，但真正對api.anthropic.com的長連線被更早的規則送去錯的出口；第三類是解析結果與規則決策不一致，常見於fake-ip與系統級 DoH、路由器強制 DNS、企業過濾並存時——握手看起來「很慢」，其實是在錯誤的位址上反覆重試。

接下來的流程只圍繞一件事：把模糊的逾時，變成你可以在日誌唸出來的主機名稱序列。這才是「網域分流」真正能發揮作用的起點，而不是在論壇複製一大段與你環境無關的 YAML。

本篇與站內 Claude「網頁／API」專文差在哪？

2026 用 Clash 存取 Claude 網頁與 API：Anthropic 網域分流規則與 DNS 實測步驟把瀏覽器頁面、Console、官方 HTTP API放在一起談，對網域集合與規則順序是非常好的基底；但Claude Code CLI這種終端工具會再多出兩個現實課題：①編輯器外掛或node／npm鏈安裝的子行程是否自動繼承你的HTTPS_PROXY；②長時間互動與串流式回覆對連線穩定性與同一出站一致性更敏感——你若只要能在網頁講一句話，偶發分流落差可能被忽略；在 CLI 裡會被放大成「每次都快逾時」。

也和本站Gemini CLI 總連線逾時？2026 年用 Clash 鎖終端請求網域與 DNS（分步實測）採同一套終端稽核方法：差別只在目標關鍵詞與 Anthropic 網域樹，請不要把 Google OAuth 那一套主機表硬搬過來；關鍵字搜尋時請鎖定Claude Code CLI、Anthropic CLI與api.anthropic.com等組合，較容易對上你的日誌語境。

前置：證明「這個終端請求確實經過 Clash 核心」

最划算的第一步，永遠是先確認誰在替你決定出站。許多教學會叫你在 shell 裡設定export https_proxy=http://127.0.0.1:7890之類變數；但若你的mixed-port根本不是 7890，或你只開規則模式＋瀏覽器 Proxy卻沒有TUN／透明接管，Chrome 仍可上網、終端裡的Claude Code CLI卻會直連到外面撞牆。WSL2、Docker Desktop、遠端 SSH 開發還會再多一層命名空間：宿主看似已代理，子環境的/etc/resolv.conf與路由表仍可能把你送回意料之外的 DNS。

在 Windows 若使用圖形客戶端，建議先對照Windows 11 下 Clash Verge Rev 首次安裝釐清「系統代理 vs TUN」覆蓋範圍；在 macOS／Linux 則可延伸Clash TUN 模式深度解析，理解為什麼有些行程不吃傳統 HTTP 代理。若你同時開著第二套 VPN／Tailscale 類虛擬介面，請一併閱讀Tailscale 與 Clash 並存：路由與 DNS 分步核對，避免 OAuth 或長連線在本該走低延遲路徑時被競態路由拖住。

💡 小提示「代理群組是否存在、名稱是否與規則完全一致」仍是硬門檻。若你對proxy-groups不熟，可先讀Clash 代理群組（proxy-groups）完全指南，再回到本文補終端視角的DOMAIN規則，避免規則寫滿卻指向INVALID或空集群。

Claude Code／Anthropic CLI：日誌上常見的主機類型（教學用起手清單）

下列分類是教學上合理的分桶草稿，不是 Anthropic 的永久承諾——產品改版、CDN、統計或開關平台換子網域時，你仍要以當下這版 CLI與當次連線紀錄擴充。把它們看成協助你搜尋「Claude Code CLI 逾時」「Anthropic CLI」「api.anthropic.com」時對得上的詞彙，而不是論壇咒語：

模型與官方 HTTP API：api.anthropic.com是多數 SDK、後端與 CLI 類工具呼叫 Messages 等端點時最常見的主機；長連線與串流若卡在這裡，日誌會非常直白。
產品網頁與工作階段：claude.ai、www.claude.ai及相關前端資源子網域。若你的流程仍會開啟瀏覽器視窗完成某些確認步驟，請不要把終端與瀏覽器視為同一條連線鏈。
開發者主控台與文件：console.anthropic.com、docs.anthropic.com等。只看對話頁而漏掉主控台後綴時，體感的「後台轉圈」其實就是另一類主機。
品牌根網域：anthropic.com底下可能承載政策、招聘或導流頁；是否要與 API 走同一策略組，取決於你想不想把「所有 anthropic.com 樹」統一出站。
統計／開關／可觀測性（依版本與環境浮動）：有些組建會對statsig類或其他第三方主機送出事件；這類名稱不該硬背，但一旦在你的日誌裡反覆出現且被錯誤規則命中，就值得獨立加成規則或確認是否需要走同一出站。
Amazon Bedrock 路線：若你實際呼叫的是 Bedrock 上的 Claude，連線會落在 AWS 主機樹，與本篇聚焦的anthropic.com體系不是同一套規則；請另依日誌拆分，勿假設貼上 Anthropic 區塊即可涵蓋。

對終端開發而言，真正棘手的是「前半段像正常、進入長推理後突然全面卡住」：這往往代表連線鏈上仍有背景請求在換發憑證、刷新設定或上報事件，其中某一類主機被 GEOIP 或寬鬆關鍵字規則提前送去錯的出口；表面上却是主指令逾時。這也是為什麼本文堅持先收集完整時間線的日誌再改設定檔。

YAML 起手式範例：把容易被誤射的出口對齊到同一組

下面示意如何在規則前段接上你的proxy-group名稱（請替換為檔案中真實存在的標籤）；重點仍是順序與不要過早上 MATCH：CLAUDE-CODE-OUT僅為占位符號。

# Example only — extend from your client logs after upgrades
rules:
  - DOMAIN-SUFFIX,claude.ai,CLAUDE-CODE-OUT
  - DOMAIN-SUFFIX,anthropic.com,CLAUDE-CODE-OUT
  - DOMAIN-SUFFIX,api.anthropic.com,CLAUDE-CODE-OUT
  - DOMAIN-SUFFIX,console.anthropic.com,CLAUDE-CODE-OUT
  - DOMAIN-SUFFIX,docs.anthropic.com,CLAUDE-CODE-OUT
  - MATCH,Main

DOMAIN-SUFFIX,anthropic.com能把多數*.anthropic.com收進同一策略組，但也會把與本次 CLI 無關的子網域一併帶走；若你想維持精簡規則，請在日誌挑實際 TLS SNI／HTTP Host能對上的最細條件改寫。若嗅探結果與 SNI 對不起來（少數企業環境會發生），延伸閱讀Clash Meta 嗅探與分流例外會比「一次關掉整包 sniff」更可控。

合規提醒本文協助你從連通性與路由器設計角度理解終端工具問題，不涉及規避身分驗證、違反服務區域規定或任何形式的濫用。請遵守適用地區法律、組織資安規範與 Anthropic／相關產品條款。

Clash DNS 與 fake-ip：為什麼 CLI「對 DNS 特別敏感」？

瀏覽器可以把複雜的快取與內建 DNS 行為藏在使用者介面之後；許多node、go或編輯器整合啟動的子行程則相對「耿直」，往往直接信任作業系統回覆的位址結果。當你同時開著系統級 DoH、路由器強制轉發與fake-ip時，只要Claude Code CLI那條解析鏈沒對齊，症狀就會統一成握手很慢或無限重試。Clash DNS區塊中的enhanced-mode、nameserver／fallback與是否對anthropic.com給予nameserver-policy級別特殊處理，目標應是減少解析分裂，而不是在同一台電腦上維護三套彼此覆寫的答案。

若你在 Linux 桌面遇到systemd-resolved與核心「搶答」爭議，請對照Linux Clash systemd-resolved 除錯；WSL2讀者可延伸WSL2、Windows Clash專題，先把「誰的 resolv.conf 才是真的」釐清，否則會花大量時間猜疑 API Key，其實只是 Nameserver 指錯。

分步實測：建議順序（可列印 checklist）

請避免同一輪調整同步動到「規則＋DNS＋訂閱＋VPN＋路由器」——這樣永遠無法知道哪一刀有效。建議依序：

固定重現情境：同一終端視窗、同一 shell 設定檔、同一個專案資料夾與同一種金鑰／登入方式；先跑一次最小對話或最小指令，把錯誤全文備份。
先查核心日誌：確認是否出現api.anthropic.com與其他 Anthropic 相關命中；若完全沒有封包影子，優先回到TUN／系統代理／環境變數，而不是再加十條規則。
檢查順序與訂閱覆寫：許多規則集習慣把GEOIP,CN,DIRECT或國內直連區塊放得很前面；一旦某段 Anthropic 流量被送去不相容出口，外觀就像「CLI 特別容易逾時」。需要分拆訂閱與手寫覆寫時，可參考Clash 自訂規則教學。
收斂 DNS：測試期暫停會搶答的加速器型 DNS、廣告封鎖工具的 DoH 模式或 VPN 內建 DNS，只保留一條你能對照 log 的路徑，再復測全流程。
鎖節點做對照：先固定策略組與單一出口家族，確認同一串請求是否落在同一國別／同一ASN視角；頻繁換節點會讓你誤以為規則無效。
交叉網路：在家用 Wi‑Fi 與手機熱點各測一次；若只差其中一環，偏向路由器劫持或電信側策略，並非 Clash 規則本身。

若你懷疑是 Windows「程式沒繼承 Proxy」而非規則，亦可交叉閱讀Windows 11 系統代理與環形隔離理解系統開了≠每個行程都跟進核心的落差；此現象在 IDE 啟動的子行程上尤其常見。

除錯心態：別把「換節點」當唯一旋鈕

當問題被草率歸類成「API 國外慢」時，許多人會開始瘋狂切換東京／新加坡／美西，結果Claude Code CLI逾時紀錄仍在原處。對生成式推理這類長連線來說，路由一致性往往比絕對延遲數字更重要：授權或控制面在一條路徑、資料面跳到另一條路徑時，速率限制與會話視角會像在打架，終端只看到 timeout。請先把出站策略組鎖在你願意長期信任的配置上，再用日誌驗證是否真有改善。

常見問題

我已加了api.anthropic.com，為什麼 CLI 仍逾時？

請依序確認：①該行程是否真的經過核心；②是否有其他 Anthropic 子網域或第三方統計主機在規則更前面被誤判；③DNS 是否與實際握手終點一致。只做其中一項檢查通常會漏。

我該強制設定HTTPS_PROXY，還是依賴 TUN？

兩種都能成立：HTTPS_PROXY適合鎖定單一 shell；缺點是容易打到錯埠或打到殘留的小寫http_proxy。TUN覆蓋面大，但要處理與其他 VPN 的路由競爭。對日常開發而言，先選「能在日誌看到對應主機命中」的那種，再長期優化會比較省時間。

規則用關鍵字會不會比較省事？

DOMAIN-KEYWORD,anthropic看似浪漫，長期常把不相關流量一起送走，除錯與審計成本反而更高。請堅持以日誌擴張精準條目，而不是盲補關鍵字。

相較之下，部分傳統代理方案不是只能整機隧道，就得要你手動為每個工具鏈維護環境變數；一旦編輯器整合與終端子行程分岔，就很難長期維持一致。Claude Code CLI與Anthropic CLI這類 2026 年主流的編碼代理工具又特別依賴穩定的長連線與一致的出站視角——只要規則順序或 DNS 鏈其中一段沒對齊，外觀就全是連線錯。Clash生態能把訂閱、路由、DNS與視覺化日誌收斂到同一決策環，對照命中路徑通常比在零散 shell 環境裡試誤更可預期；若你希望用能看清楚命中順序、並貼齊 Meta／Mihomo 核心演進方向的客戶端整理CLI 逾時問題，不妨自本站下載區取得對應平台版本並依本文順序演練。→ 免費取得 Clash 安裝檔，親自驗證終端對 Anthropic API 的出站路徑。