為什麼「只有終端機裡的 Claude Code」特別容易逾時

2026 年圍繞生成式模型的開發者工具鏈裡，Claude Code這類在終端機互動的助理，本質上仍是透過本機行程對外發起 HTTPS 請求到 Anthropic API 與相關身分驗證／用量統計端點。當你已在瀏覽器順利開啟官方文件或帳戶頁，卻在指令列看到連線逾時、間歇性 5xx，或偶發「重試後又正常」時，常見原因並不是單一指令打錯，而是流量路徑在 Clash 規則裡被切成兩段：一段走代理、一段被送回 DIRECT（直連），導致 TLS 交握或長連線在錯誤出口上卡住。

與圖形化編輯器場景相比，終端機裡的 Node、Go 或內嵌執行緒對 HTTP(S)_PROXY 的依賴路徑更「挑脈絡」：有些實作會讀系統 Proxy，有些只讀環境變數，也有少數在程式內明確停用 Proxy。當你使用 Clash Verge Rev這類以 Mihomo（Clash.Meta）為核心的圖形用戶端時，最佳策略不是一開始就開最強的全域 TUN，而是先用規則分流把雲端 API 相關網域穩定導向可信節點，再視需要補上終端代理與開發者代理環境變數——整體可維護性會比「永遠全域」好得多。

接下來我會用可複現的順序說明：如何從 Verge Rev 的連線紀錄抓到真實網域、如何在 YAML 調整規則順序、以及 HTTPS_PROXY 該寫進哪些啟動來源。你在搜尋「Claude Code 代理」「Anthropic API 逾時」時看到的多數碎片答案，最後都會收斂到這三個旋钮：規則、系統代理模式、環境變數脈絡。

規則分流與全域 TUN：什麼時候用哪一種

先把兩件事分開：規則分流決定「這個網域走哪個策略群組」；系統代理／TUN決定「作業系統或路由表層有多少流量會進到 Clash」。在 Clash Verge Rev 中，你通常會先開啟系統代理讓一般支援系統設定的程式自動把 HTTP 連線送到本機 mixed-port；若遇到怎麼改規則都像是沒命中，或某些子行程始終繞過系統設定，再把TUN 模式當成第二階段的驗證工具，而不是預設值。

模式 優點 風險／成本 較適合的訊號
規則分流＋系統代理 精準、對本機服務影響小、易於團隊文件化 需維護網域清單與順序；不讀系統 Proxy 的程式要另補環境變數 連線紀錄已能看到請求進入 Clash，但策略欄顯示 DIRECT
全域 TUN 可覆蓋更多未支援系統代理的堆疊；利於 A／B 驗證 路由表複雜時易與其它 VPN／公司程式衝突 已確認規則正確但特定子行程仍直連外網
僅手動環境變數 對單一專案可快速試錯 易在多個終端機／CI 腳本之間漂移 你清楚知道只有某個指令需要明確 Proxy

實務上我會建議以「連線紀錄是否出現該請求」為分界：完全沒出現，優先檢查系統代理與埠號；有出現但策略錯誤，優先調規則集順序；有出現且策略正確仍偶發失敗，再往 DNS、節點品質或時間同步方向查。

小提示：在 Verge Rev 介面中，「連線」「Connections」「日誌」命名可能因版本略有差異，重點是找到可依目的地網域或行程名稱排序的即時清單；教學截圖若與你的版本不同，可直接以功能關鍵字在設定中搜尋。

開始改設定前請先對齊的三個事實

以下檢查清單能把「改了 YAML 但完全沒效果」機率降到很低：

  • 你目前生效的是哪一份設定檔？Verge Rev 可能同時存在本機草稿、訂閱合併結果與「目前啟用中」檔案；請在介面確認已載入並套用你正在編輯的那份，而不是僅存檔未切換。
  • mixed-port、HTTP、SOCKS 是否與環境變數一致：若你在 HTTPS_PROXY填了舊埠號，或在升級後 mixed-port 變更但未同步終端設定，會出現規則正確却連線仍失敗的假象。
  • 是否有第二套 VPN 或公司安全程式同時接管路由：兩層程式搶路由時，連線紀錄可能在 Clash 看起來正常，但實際封包已被改寫；排錯期建議暫時只保留單一路徑。

第一步：用連線紀錄定位「是哪個網域在直連」

打開 Clash Verge Rev 的即時連線檢視，在另一個終端機視窗重現一次會失敗的 Claude Code 操作（例如會觸發遠端模型推理或帳戶驗證的子命令）。當錯誤訊息出現或長時間無回應時，立刻在連線清單以關鍵字過濾：

  • anthropic、claude、api 等字首；實際子網域會隨產品更新而增減，以你在列表中重複看到的為準。
  • 若條目顯示 DIRECT，但它明顯屬於需要穩定對外頻寬與低遞延的雲端服務，應把該後綴加入下一節的精確規則，並放在較大條的「直連／國內」集合之前。
  • 若列表中完全沒有相關條目，代表請求未進入 Clash：回到系統代理是否開啟、或該行程是否略過本機 Proxy。

這個方法比從社群帖子抄一份「完整網域表」可靠，因為你的訂閱規則集、DNS 模式與地區網路條件都可能與他人不同；以自己的連線紀錄為真實來源，之後團隊內再共享 YAML 片段會更穩。

第二步：把 Anthropic API 相關後綴接到正確的策略群組

下方片段僅為結構示意，請將 PROXY-GROUP-YOU-USE替換為你設定檔內實際存在的策略群組名稱（常見如 🚀 節點選擇）；並將整段放在會把大型 CDN、雲端供應商或「大陸直連」一次吃掉的規則集之前，避免永遠匹配不到。

# Example — replace PROXY-GROUP-YOU-USE; keep above broad DIRECT / CN rule-sets
DOMAIN-SUFFIX,anthropic.com,PROXY-GROUP-YOU-USE
DOMAIN-SUFFIX,claude.ai,PROXY-GROUP-YOU-USE
# Add more DOMAIN-SUFFIX lines observed in your Verge Rev connection list

若你使用上游維護的 RULE-SET，請特別留意其中是否含有把通用雲端後綴整包導向直連或地區分流的路徑；開發者 API 類服務最常卡在這種「過於粗糙的集合」。解法通常是上移精確 DOMAIN-SUFFIX，而非盲目整包取消訂閱。

搭配 fake-ip 或細緻 DNS 政策時，若見到解析結果異常或被導向意外區域，也要同步檢查 nameserver 分流是否把特定網域送進易被污染的解析路徑；否則表面規則正確，TLS 仍可能在錯誤 IP 上擺動。

合規提醒：請在遵守所在地法規以及你與 Anthropic／所用服務供應方合約前提下使用本文設定方式；下列內容僅描述常見網路排錯流程，不包含任何規避監管或濫用 API 的意圖。

第三步：HTTPS_PROXY／ALL_PROXY 應該寫在哪

「環境變數寫在哪」本質上是在問：哪一個行程啟動了執行 Claude Code 的那個 shell？不同啟動來源讀取的設定檔不一樣，以下列出常見情境與建議：

  • macOS／Linux 的互動式 zsh／bash：將 export HTTPS_PROXY=http://127.0.0.1:<mixed-port> 與 export HTTP_PROXY=... 寫在實際會被載入的 ~/.zshrc、~/.bashrc 或拆分檔並以 source 引入；若你使用終端機多工器，確認每個 pane 都是在修改後重新開啟的工作階段。
  • IDE 內建終端：有些整合式終端繼承 GUI 程式的環境而非登入 shell；可在 IDE 的終端機設定中增加啟動前指令，或在外層以 wrapper 腳本先 export 再啟動子行程。
  • Windows PowerShell／cmd：可用目前工作階段的 $env:HTTPS_PROXY="http://127.0.0.1:埠"做快速驗證，確認無誤後再考慮寫入使用者或系統層環境變數；注意服務帳戶與一般使用者隔離。
  • 排程與背景服務：launchd、systemd user unit、或工作排程器裡的指令，預設不一定載入互動式 shell 設定檔；請在單元檔內顯式宣告 Environment= 或在腳本最上方 export。

實務上我會同時設定 HTTPS_PROXY 與 ALL_PROXY（若你的工具鏈讀後者），並以 NO_PROXY保留 127.0.0.1,localhost,::1與公司內網網段，避免把內部 Git、套件倉庫誤送進海外節點。

瀏覽 Clash／Mihomo 各桌面用戶端下載聚合

第四步：用 curl 與實際 CLI 做最短驗證迴圈

改完規則與環境變數後，建議依序做兩次測試：

  1. 使用 curl -v 並透過 --proxy 明確指定 http://127.0.0.1:<mixed-port> 對公開可及的 HTTPS 端點做探測，先確認本機代理鏈路與憑證鏈正常。
  2. 撤除 --proxy，在「與平常相同」的 shell 環境下重跑；若此次失敗而前一步成功，代表問題在於程式未走代理或規則未命中，而不是單一節點瞬斷。
  3. 最後再執行實際會呼叫 Anthropic API 的 Claude Code 指令，邊看 Verge Rev 連線清單是否出現預期策略名稱；若名稱正確但延遲仍高，再切換節點或檢查 UDP／HTTP2 相容性。

這個迴圈能把問題從「感覺網路不穩」收窄成可描述的分支：代理鏈故障、規則漏網、環境脈絡錯誤，或純粹遠端限流。

第五步：訂閱品質與節點型態如何放大「逾時感」

即使規則與環境變數都正確，以下因素仍會讓 CLI 體感像「常常逾時」：

  • 長連線與多輪工具呼叫：助理型 CLI 可能在單次使用者操作背後觸發多段請求；若節點對長連線或特定 TLS 指紋不友善，錯誤會以逾時而非立即斷線呈現。
  • IPv6 與雙棧路由：部分網路會讓 AAAA 記錄走不同出口；若你僅在 IPv4 規則看到正常，仍值得在核心設定中暫時觀察 IPv6 行為。
  • 時間不同步：系統時鐘偏差會讓憑證驗證看起來像偶發網路問題；尤其在虛擬機與多系統開機切換後應先校時。

仍未解時可再對照的快速清單

  • 連線紀錄完全沒有相關網域：優先檢查系統代理開關、mixed-port 是否被其它程式佔用、以及該 CLI 是否內建忽略系統 Proxy。
  • 規則已寫卻仍 DIRECT：檢查是否被更前面的 rule-set 匹配；必要時把觀察到的子網域再上移數行。
  • 同一 Wi‑Fi 下他人正常只有你異常：檢查本機是否啟用公司 SSL 解密、或安裝了會注入憑證的安全代理。
  • 只有在特定節點出問題：先更換協定相容的後端，再談規則；避免把節點故障誤判成設定錯誤。

為什麼開發者場景下，Clash 生態比封閉加速器更好收斂

坊間不少「一鍵加速」產品把應用程式清單寫死在自家二進位檔裡，當雲端供應商新增子網域或調整 CDN 時，使用者只能被動等待更新；對需要頻繁呼叫 Anthropic API、同時還要連公司內網與套件倉庫的開發者代理場景而言，這種黑箱往往放大利空。Clash搭配 Clash Verge Rev與 Mihomo核心，讓你能用同一套可版控的 YAML，在「看得到連線紀錄」的前提下迭代規則分流，並以 HTTPS_PROXY精準補強終端脈絡——當下一個模型供應商或區域路由變更來臨時，你多半是改幾行設定就能跟上，而不是重裝一整套不明工具。

相較把網路行為全部押在全域 TUN或單一系統旋钮，強調規則與環境變數並用的作法，對需要長時間開著代理寫程式的人通常更省力：對外 API 走穩定出口，內網與本地測試站維持直連，問題發生時也更容易用連線紀錄還原真實路徑。Clash Verge Rev提供的圖形化觀察介面只是把這件事變得可視——底層仍是你能理解、可團隊共享的規則與環境變數實測流程。

立即免費下載 Clash，為終端機與 API 建立可複製的代理設定 →