為什麼 Claude Code 會一直連線逾時

如果你在終端機執行 Claude Code 時，指令長時間沒有回應，最後顯示 connection timeout、request timed out、socket hang up 或 TLS handshake failed，問題不一定出在模型服務本身。這類現象更常見的原因是：終端機沒有使用 Clash、Clash 規則把 Anthropic 相關連線判定為 DIRECT、目前節點無法穩定建立長連線，或者系統中同時存在多套代理而互相覆蓋。

Claude Code 與一般瀏覽器使用情境不同。你在瀏覽器中開啟其他網站正常，只能證明瀏覽器的流量可用，不能代表終端機裡的 Node.js、原生 HTTPS 用戶端或 Claude Code 子程序也會自動繼承同一套代理。尤其是在 Windows PowerShell、macOS Terminal、Linux Shell、VS Code 內建終端之間切換時，每個工作階段讀取環境變數的時間點都可能不同。

Claude Code 的請求通常會連到 Anthropic API 相關主機，例如 api.anthropic.com，登入、授權、更新或遙測流程也可能涉及其他網域。實際網域會隨版本、登入方式與功能調整而變化，因此不建議只憑網路文章複製一份很長的固定清單。更可靠的方式是先在 Clash 的連線紀錄中觀察逾時當下出現的目的地，再根據實際紀錄補充規則。

排錯時可以把問題拆成三層：第一層是請求有沒有進入 Clash；第二層是進入後是否命中正確的代理策略；第三層是節點、TLS、HTTP/2 或長連線品質是否足以支援 Claude Code。依這個順序檢查，比一開始就反覆更換設定檔或節點更容易找出真正原因。

先確認 Clash 與終端機的基本狀態

開始修改 YAML 以前，先在 Clash Verge Rev、Clash Verge 或其他 Mihomo 用戶端中確認目前使用的設定檔確實已載入。很多人修改的是下載到本機的原始檔，但用戶端實際使用的是訂閱合併後的配置；這時即使檔案內容正確，核心也不會讀到你的修改。

檢查項目 應確認的內容 常見錯誤
核心狀態 Mihomo／Clash.Meta 核心正在執行，且沒有反覆重啟 介面開著，但核心啟動失敗或埠號被其他程式佔用
代理埠 記下目前生效的 mixed-port 或 HTTP／SOCKS 埠 環境變數仍指向舊埠號，導致請求送到不存在的服務
模式 暫時使用 Rule 模式，方便從連線紀錄確認命中規則 一直使用 Global 模式，無法判斷究竟是規則還是節點造成問題
策略群組 Anthropic 相關規則指向可用的代理群組，而非失效節點 策略群組名稱存在，但目前選中的節點已離線
連線紀錄 能看到 Claude Code 執行時產生的目的地主機與策略 完全沒有紀錄，表示終端機可能沒有經過 Clash

接著在終端機檢查代理環境。Linux 與 macOS 可以使用 env | grep -i proxy，PowerShell 則可使用 Get-ChildItem Env: | Where-Object Name -Match 'PROXY'。重點不是一定要設定所有變數，而是確認它們沒有互相矛盾。例如 HTTPS_PROXY 指向 7890，但 Clash 實際的 mixed-port 已改成 7897；或者 NO_PROXY 包含過大的網域範圍，讓請求直接繞過代理。

如果你在 Clash 中看不到任何 Claude Code 請求，先不要急著改分流規則。這個訊號通常代表問題發生在「終端機到 Clash」之間。你可以先確認系統 Proxy 是否已啟用，再於目前這個終端機視窗內暫時設定正確的代理位址，然後重新啟動 Claude Code。只在另一個視窗設定變數，並不會自動影響已經開啟的 Shell 或 IDE 終端。

小提示：排錯期間盡量只保留一套主要代理。若同時開啟 VPN、Clash Verge Rev、系統代理工具與 IDE 代理擴充功能，請求可能分別走不同出口，最後看到的逾時訊息會很難對應到真正的網路路徑。

修正 Anthropic 分流規則與規則順序

確認請求已進入 Clash 後，下一步是查看目的地與策略。若連線紀錄顯示 api.anthropic.com 或其他 Claude 相關主機被套用 DIRECT，就表示目前規則沒有把它導向代理群組。這時應在自訂規則或覆寫規則中加入精準的網域條目，並放在可能匹配到直連的廣泛規則之前。

常見的配置思路如下，但群組名稱必須換成你設定檔中實際存在的名稱：

rules:
  - DOMAIN-SUFFIX,anthropic.com,Claude
  - DOMAIN,api.anthropic.com,Claude
  - MATCH,DIRECT

上面的例子使用 DOMAIN-SUFFIX 覆蓋 Anthropic 子網域，也用單獨的 DOMAIN 突出 API 主機。實際使用時，請先確認你的策略群組真的叫作 Claude；如果設定檔只有「Proxy」「AI」「手動選擇」等名稱，直接複製這段會造成規則載入失敗或群組不存在。

規則順序尤其重要。若在自訂規則之前已經有一條將某類網域送往 DIRECT 的規則，後面的 Anthropic 條目可能永遠不會被執行。修改後必須重新載入配置，並在連線紀錄中確認同一目的地的策略欄位已經改變。不要只看 YAML 編輯器中的文字顏色，也不要把「配置檔成功載入」誤認為「規則一定命中」。

如果你使用的是訂閱配置，更新訂閱後手動加入的規則可能被覆蓋。較穩妥的做法是使用客戶端提供的覆寫功能、外部控制器或明確的本地規則檔，並保留一份備份。每次訂閱更新後重新觀察 Claude Code 的連線紀錄，確認自訂規則仍然存在。

動手設定：讓 Claude Code 使用 Clash 代理

這一節用最小變更的方法測試終端機代理，不要求你立即啟用 TUN。假設 Clash 的本機 HTTP／混合代理埠是 7890，請依你的實際埠號替換。命令只對目前的終端機工作階段有效，適合先做 A／B 對照。

macOS 與 Linux

export HTTP_PROXY=http://127.0.0.1:7890
export HTTPS_PROXY=http://127.0.0.1:7890
export ALL_PROXY=socks5://127.0.0.1:7890

設定後不要沿用已經啟動的 Claude Code 程序，請先退出，再在同一個終端機視窗重新執行。若你使用 zsh、bash 或 fish，永久設定的位置不同；建議先使用目前工作階段驗證成功，再決定是否寫入 Shell 啟動檔。永久寫入前也要留意公司網路、SSH 連線與其他不應走代理的內部服務。

Windows PowerShell

$env:HTTP_PROXY="http://127.0.0.1:7890"
$env:HTTPS_PROXY="http://127.0.0.1:7890"
$env:ALL_PROXY="socks5://127.0.0.1:7890"

PowerShell 設定的變數不一定會影響透過其他啟動器、圖形化 IDE 或服務管理器啟動的程序。如果 Claude Code 是從 VS Code 內建終端執行，請在該終端內直接檢查變數；如果是由桌面捷徑、npm script 或自動化工具啟動，還要確認父程序是否把變數傳遞下去。

接下來使用簡單的 HTTPS 請求測試本機代理是否有回應。測試的重點是本機埠可用、請求能進入 Clash，而不是用未授權的方式呼叫 API。你可以在 Clash 連線紀錄中觀察測試期間是否出現新條目，再執行 Claude Code 做第二次對照。如果系統代理測試成功但 Claude Code 仍然沒有紀錄，代表該工具可能使用自己的網路層、清除了環境變數，或由另一個子程序負責真正的請求。

也要檢查 NO_PROXY。它原本是為了讓 localhost、內部網域或公司服務繞過代理，但錯誤設定可能把 Anthropic 網域一併排除。排錯時可以暫時清除目前工作階段的 NO_PROXY，測試完成後再依公司內網需求恢復，不建議在不了解後果的情況下永久刪除所有例外。

判斷是節點品質、TLS 還是超時參數

若連線紀錄已顯示正確命中代理，但 Claude Code 依然逾時，問題可能已經從分流層進入節點品質或協定相容性層。AI 程式開發工具常會使用較長的請求、串流回應或多次 API 呼叫；某些節點能開啟一般網頁，卻在長連線期間頻繁斷開，因此「瀏覽器能用」並不能完全排除節點問題。

現象 較可能的方向 建議驗證方式
完全沒有 Clash 連線紀錄 終端機未使用代理或程序繞過環境變數 檢查同一 Shell 的變數，並暫時啟用系統 Proxy 或 TUN 做對照
紀錄顯示 DIRECT 規則未命中或規則順序錯誤 提高精準網域規則優先順序，重新載入配置
命中代理但立即 TLS 失敗 節點出口、TLS 握手或中間網路設備不相容 切換另一個可靠節點，並比較同一目的地的連線結果
開始回應後中途斷線 長連線、HTTP/2 或節點穩定性不足 使用不同協定或節點做長時間對照，不要只測一次首頁
只有某個 IDE 終端逾時 IDE 使用獨立環境或覆蓋了 Proxy 設定 比較系統終端與 IDE 終端的環境變數及連線紀錄

如果更換節點後問題立即消失，通常不必先大幅改動 Clash 全域配置。保留原本的規則，將測試結果記錄下來，再檢查失敗節點是否存在高延遲、頻繁重置或出口地區不適合的情況。不要因為一次成功就認定節點永久穩定；可以在不同時段重試，特別是你實際使用 Claude Code 最頻繁的工作時間。

TUN 模式可以作為第二階段驗證。當你確定規則正確，但 Claude Code 或某個子程序始終不讀取系統 Proxy 時，TUN 能協助判斷「程序是否繞過代理」這個假設。不過 TUN 會改變更多系統流量，可能與公司 VPN、Docker、虛擬機器、區域網路服務或零信任軟體衝突，因此建議先在可回復的情況下短時間測試，完成比較後再決定是否長期啟用。

一套可重複的修復流程與注意事項

當你需要在多台電腦或團隊環境中重現修復結果時，最好把排錯流程固定成幾個可記錄的步驟，而不是只留下「換節點後好了」這種無法追溯的結論。

  1. 記錄原始錯誤：保留 Claude Code 顯示的錯誤類型、發生時間、使用的網路環境與 Clash 版本。錯誤發生的時間有助於在連線紀錄中找到相同請求。
  2. 確認實際配置：記下目前啟用的設定檔、核心版本、mixed-port、代理模式與策略群組。不要只修改訂閱原始檔後就直接下結論。
  3. 確認請求入口：在清空或修正環境變數後重啟終端機，觀察 Claude Code 執行時是否真的出現在 Clash 連線清單。
  4. 修正最小規則：先加入必要的 Anthropic 網域規則，放在廣泛 DIRECT 規則之前，避免一次匯入大量來路不明的規則集。
  5. 執行節點 A／B 測試：使用兩個不同節點，在相同 Shell、相同配置與相近時間測試，分辨規則問題與節點問題。
  6. 最後才考慮 TUN：只有在程序明確繞過系統代理時，才用 TUN 做範圍更大的驗證，並記錄啟用前後的差異。

修復後建議把有效設定保存在版本控制或安全的團隊文件中，但不要把訂閱連結、Token、API Key 或帶有個人識別資訊的連線紀錄直接提交到 Git。分享錯誤訊息時，可以保留錯誤類型與目的地網域，遮蔽授權標頭、完整 URL、帳號名稱與內部 IP。

另外，請不要為了消除逾時而無限制提高所有請求的 timeout。較長的 timeout 只能讓錯誤更晚出現，無法修復 DIRECT、錯誤埠號或失效節點。先確定流量路徑正確，再依實際網路品質調整重試與逾時行為，通常更容易得到穩定結果。

相較於只依賴瀏覽器擴充功能或必須逐個程式手動填寫代理的工具，Clash 在這個場景的優勢是能把規則命中、策略群組、節點切換與連線紀錄放在同一個可觀察的控制面；當 Claude Code、IDE 終端與其他開發工具出現不同表現時，你可以用同一套分流邏輯逐項對照，而不必猜測每個程式背後的代理狀態。如果你正在尋找一個能以規則模式逐步排錯、又能在必要時用 TUN 擴大涵蓋範圍的方案，Clash 會讓整個修復流程更容易重現。

立即免費下載 Clash，開啟流暢上網新體驗 →