為什麼 Claude Code 特別容易「終端機逾時」？
Claude Code 這類工具會把編修檔案、執行指令與呼叫後端 API綁在同一個終端機會話裡。對使用者來說，卡住的表象多半是進度停在某個百分比、認證視窗開不出來，或直接看到連線逾時字樣；對網路路徑來說，卻常常是某個程式並未走代理、或走了代理但規則把特定子網域留在直連，導致同一台電腦上「瀏覽器正常、CLI 不正常」的分裂現象。Anthropic 雲端服務的路由也可能隨產品調整而新增 CDN、認證或計費相關主機名稱；仰賴一份過時的靜態域名表，很容易留下漏網之魚。
把問題收斂成可操作的檢查清單會更有效：第一，確認終端機行程對外的 TCP 連線是否真的進入 Clash（而不是只在瀏覽器測試成功）；第二，確認連線日誌裡的主機名稱是否命中預期的策略組；第三，確認DNS 解析結果與規則匹配所用視圖一致，而不是「規則寫對、解析卻走在另一條路」。接下來各節會依這個順序展開。
系統代理足以嗎？何時一定要上 TUN
許多桌面環境在使用者勾選「系統代理」後，會把 HTTP／HTTPS 代理設定寫進作業系統；對 Safari、Chrome、Edge 這類預設尊重系統設定的程式通常有效。然而終端機裡的 Node、Python、Go 或獨立二進位常見的行為是：預設不使用代理，除非您在 shell 設定檔中匯出 HTTPS_PROXY、HTTP_PROXY、ALL_PROXY，或該工具本身提供獨立的網路設定。這也是為什麼只看「瀏覽器能上 Claude」並不足以判斷 Claude Code CLI 會成功。
TUN 模式透過虛擬網卡與路由表在較底層接管系統對外流量，讓未主動支援代理的程式也能進入同一套路由決策；對於不易確認究竟哪個子行程在連線的情境，TUN 通常比逐一為每種語言鏈結設定環境變數更省事。若您使用圖形客戶端，可先閱讀 Clash Verge Rev TUN 模式完整教學，釐清與防火牆、其他 VPN、以及 macOS／Windows 權限提示相關的注意事項；再在規則模式下搭配日誌驗證命中是否正確。
實務建議：先用規則模式加上連線日誌確認域名走向；確認無誤後再長開 TUN，並避免與另一套全隧道 VPN爭搶路由而不自知。
與「Claude 網頁／API」分流文如何分工？
本站已有以通用 Claude / Anthropic 存取為主的 Claude 網頁與 API 分流與 DNS，該篇偏重瀏覽器與 SDK 並存的域名辨識與規則骨架。本篇把焦距收窄到命令列／終端機：為何同一組Anthropic端點在瀏覽器可走代理、在 CLI 卻逾時，以及如何優先用 TUN 與環境變數統一路徑。若您同時在意編輯器、GitHub、npm registry 等開發鏈路，亦可疊加閱讀 Cursor／GitHub／npm 分流優化，把「套件下載」與「模型 API」拆成兩條可觀測的策略組。
1先用連線日誌鎖定 Anthropic／Claude 主機名稱
實務排查請一律以您客戶端日誌為準：在開啟 Claude Code 並復現逾時的同時，於 Clash／Mihomo 介面檢視連線紀錄，搜尋 anthropic、claude、api. 等關鍵片段，記下完整Host／SNI。您可能會看到服務於互動式編修工作階段的閘道、服務於金鑰呼叫計費的 API 主機，以及登入／授權流程使用的獨立域名；這三類不一定要共用同一個 CDN，規則上也不應假設「同一個頂級網域就足夠」——子網域遺漏仍然是 CLI 逾時最常見的原因之一。
下列名稱僅供對照起手方向，並非承諾永遠完整：anthropic.com、api.anthropic.com、claude.ai。若日誌出現新的資源網域或地區性入口，請把它視為必須追加規則的信號，而不是偶發噪音。
2分流規則：把日誌裡看到的域名接到對的策略組
規則的本質是把觀測到的現象對應到固定的出口決策。請將下方 YAML 視為結構範例：把 PROXY 換成您設定檔中實際存在的策略組名稱，並自行插入在日誌中新發現的主機；註解維持英文以符合設定檔慣例。
# Example only — replace PROXY with your policy group; extend from connection logs
rules:
- DOMAIN-SUFFIX,anthropic.com,PROXY
- DOMAIN-SUFFIX,claude.ai,PROXY
# Observed API gateway:
# - DOMAIN,api.anthropic.com,PROXY
- MATCH,PROXY
若您使用 Meta／Mihomo，可把較長的清單搬到 rule-providers；無論如何，請優先確認規則順序：較具体的域名應該排在過寬的規則之前，避免較早的 GEOIP 或地區規則先把流量吃掉。MATCH 最後一跳請依您的日常使用習慣決定走向代理或直連，並確保與除錯時的假設一致，以免排查過程自相矛盾。
3DNS 與 FakeIP：別讓 CLI「看得到域名、卻對錯 IP」
FakeIP 搭配 TUN 時非常強大，但若 fake-ip-filter、上游 DNS、以及規則所用解析視圖彼此不一致，典型症狀就是瀏覽器看似正常，終端機工具卻握手時間拉長或直接逾時；也可能是反向，視您的程式是否自行快取 DNS、或使用不同的解析器。對 Anthropic API 這種對連線可靠性敏感的工作負載，建議把 DNS 視為規則的一部分：先收斂解析鏈路，再談換節點。
若要補齊背景概念，可對照 Meta 核心 DNS 防洩漏終極指南 中的 FakeIP、DoH、DoT 與 fallback 設計；再回到本篇把與 Claude／Anthropic 相關的域名逐一對齊。路由器透明代理與本機 Clash並存時，也要留意是否出現雙重 DNS 劫持卻不知道優先順序為何的情況。
提醒：在公司網域或自行部署的HTTPS 檢查環境下，TUN 與憑證信任議題會與一般家用情境不同；若您懷疑企業中介憑證導致 TLS 失敗，請先與網路管理單位確認，而非僅調整規則。
4環境變數代理：與 TUN 並用的細節
即便開啟 TUN，仍可能有工具透過明確綁定介面或使用自有網路堆疊而繞過預期路由；亦有開發者在同一台機器上為 Docker、虛擬機器維護獨立的網路命名空間。若您暫時無法使用 TUN（例如與特定軟體衝突），可在 shell 設定檔（如 ~/.zshrc）為需要呼叫 Anthropic API 的工作階段單獨匯出代理環境變數，並確保連接埠與 Clash 的 mixed-port 或 HTTP／SOCKS 監聽設定相符。
使用環境變數時請記得：過度寬鬆的全域 ALL_PROXY可能讓區網資源或公司內部網址也被送去代理，反而製造另一種逾時；可搭配細緻的規則或在特定子 shell 才開啟代理。這種「分段啟用」雖然稍微麻煩，卻能把問題限制在可觀察範圍內。
5驗收順序：從規則命中到最小復現
- 啟用 Clash，確認為規則模式（或您熟悉的對應模式），並開啟 TUN（或已正確設定環境變數）。
- 重新操作 Claude Code 直至出現逾時，再回到連線日誌核對該時間段命中策略組是否符合預期。
- 使用
curl -v對日誌裡尚未確認的主機做最小 HTTPS 請求，觀察 TLS 握手是否在同一策略組下完成。 - 若規則命中正確但仍逾時，再輪換延遲較低且 UDP／QUIC 相容良好的節點池；若換節點無效，回到 DNS 區段暫時簡化 fallback 鏈做對照。
常見問題（簡答）
為什麼瀏覽器能用 Claude，終端機裡 Claude Code 卻一直逾時？瀏覽器多半遵循系統代理；許多 CLI 預設不走代理，除非設定環境變數或由 TUN 在底層接管。Anthropic API 域名怎麼列才算完整？請以連線日誌為準，靜態表只能當起手式。規則看似正確為何仍間歇失敗？多半是 DNS／FakeIP、規則順序或 MATCH 前一條誤判，其次才是節點品質。
開源資訊與安裝包取得方式
Clash 生態的核心與多數圖形介面為開源專案；若要檢視授權或原始碼，GitHub 仍是合適來源。日常安裝或更新客戶端建議優先使用 本站 Clash 下載頁，並搭配 設定說明文件 理解模式差異；將「取得安裝包」與「閱讀開源倉庫」分開，可避免誤以為必須依賴不明來源的程式組態檔。
結語
把 Claude Code 的CLI 逾時問題放回終端機是否真的經過 Clash這個原點，往往比反覆重試指令更有效：TUN能把「哪些程式在外連」這件事變得透明；接著再用連線日誌校準 Anthropic 相關域名的分流規則與策略組命名；最後才把 DNS／FakeIP 收斂到與規則一致的視圖。相較於只調整瀏覽器或只複製別人的規則集卻不去對照自己的日誌，這套順序能把間歇性逾時逐步縮小到具體的可修正項目。
有些代理工具偏重簡化場景，對細緻規則與日誌對照支援較弱，較難在同一介面裡同時處理瀏覽器與終端機的多段連線差異。Clash 搭配 Meta／Mihomo 核心時，規則表達與圖形客戶端生態較容易長期維護「可看見的策略」：命中哪條規則、走哪個策略組、對應哪個域名，都能在紀錄裡對齊。
若您希望把這套終端機代理流程落到日常桌面環境，不妨免費下載 Clash，依本文順序開啟 TUN、核對 Anthropic／Claude 域名規則，並同步檢視 DNS 區段；完成後再回到 Claude Code 復現同一操作，通常就能明顯區分「路徑問題」與「純線路品質問題」。