Claude Code 終端連線卡關？用 Clash 設定代理與分流

先分清終端機代理與 Clash 流量入口

Claude Code 在終端機中連線失敗，不一定是訂閱或代理節點故障。瀏覽器能開啟網站，也不代表終端機使用了相同的代理設定：瀏覽器可能讀取作業系統代理，而命令列程式通常會依自己的設定或目前 Shell 中的環境變數連線。若終端機沒有代理設定，即使 Clash 已開啟系統代理，Claude Code 仍可能直接連線，或因所在網路無法存取服務而逾時。

排查時可把流程拆成幾段：Claude Code 發出 HTTPS 請求 → 終端機將請求交給本機代理連接埠，或由 TUN 接收流量 → Clash 核心套用規則並選擇出站 → 代理節點連線至服務端。問題可能出在任何一段。先確認請求是否進入核心，再檢查命中的規則與出站，比反覆更換訂閱或一次切換多項設定更容易定位。

Claude Code
  → 終端機代理環境變數，或 TUN 虛擬網卡
  → Clash / mihomo 核心
  → 規則與代理群組
  → 代理節點或 DIRECT
  → Claude Code 服務

瀏覽器正常、Claude Code 失敗：優先檢查終端機是否有代理環境變數，以及請求有沒有出現在 Clash 的連線記錄。
瀏覽器與終端機都失敗：先確認設定檔已啟用、代理群組有選到可用節點，並檢查目前網路是否能連上代理伺服器。
連線記錄有請求但仍逾時：查看目標網域、命中規則、最終出站及錯誤訊息；這通常表示請求已進入核心，但後續連線仍可能失敗。
連線記錄完全沒有相關請求：檢查環境變數、代理埠號與 TUN 狀態。若終端機沒有將請求送進 Clash，調整代理群組通常不會生效。

確認設定檔、節點與本機代理連接埠

開始設定 Claude Code 前，先確認 Clash 用戶端載入的是預期設定檔。前往「設定檔 / Profiles」確認設定檔已啟用，再到「代理 / Proxies」查看代理群組是否有可選節點。設定檔匯入成功，只代表用戶端取得了設定內容，不等於設定檔已啟用，也不代表群組內的節點目前可連線。

接著查看用戶端的混合連接埠或 HTTP 代理連接埠。下文以 127.0.0.1:7890 為範例；這不是所有用戶端的固定預設值，請以目前設定為準。使用供終端機連線的本機 HTTP 代理時，優先採用用戶端明確標示為 HTTP 或混合代理的埠，不要把只供 SOCKS 使用的埠當成 HTTP 代理埠。

檢查位置	應確認的內容	結果代表什麼
設定檔	目前設定檔已啟用，且代理群組與節點存在	確認核心載入了預期的規則與節點來源
代理群組	群組選到可用節點，而非 `DIRECT` 或失效成員	確認規則命中代理群組後的實際出站
監聽連接埠	記下 HTTP 或混合代理埠號及監聽位址	確認環境變數指向正確的本機入口
連線記錄	搜尋服務相關網域，查看規則、策略與錯誤	判斷請求是否進入核心，以及後續由哪個出站處理
DNS 與日誌	查看解析失敗、連線逾時、TLS 或代理交握錯誤	協助區分名稱解析、線路與應用程式設定問題

在 macOS 或 Linux 的終端機中，可先使用以下命令測試本機代理埠是否能建立 TCP 連線。將 7890 換成用戶端顯示的實際值：

nc -vz 127.0.0.1 7890

接著用明確指定代理的 HTTPS 請求測試代理入口與遠端連線：

curl --proxy http://127.0.0.1:7890 \
  --connect-timeout 10 --max-time 25 \
  -sS -o /dev/null -w 'HTTP %{http_code}\n' \
  https://api.anthropic.com/

此命令只用來觀察能否經過指定代理建立 HTTPS 請求，不是 Claude Code 的登入或帳號測試。服務端可能回傳錯誤狀態碼；只要命令有收到 HTTP 回應，就與 DNS 失敗、連線逾時或 TLS 交握失敗不同。若命令報告無法連線至 127.0.0.1，先檢查埠號、用戶端是否正在執行，以及該埠是否提供 HTTP 代理。

在終端機設定臨時代理

先使用目前 Shell 工作階段內的環境變數測試，不要一開始就寫入全域啟動檔。以下範例為常見的 HTTP 代理用法，請把埠號替換成 Clash 實際監聽的 HTTP 或混合埠。環境變數的名稱需使用大寫；HTTPS_PROXY 指出 HTTPS 請求應使用的代理位址，值的協定部分仍是本機 HTTP 代理。

macOS 與 Linux：zsh、bash

在目前終端機視窗執行：

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

claude

如果已經開啟 Claude Code，設定環境變數不會追溯變更已啟動程序的環境。請先結束該程序，再從設定好變數的同一個終端機重新執行 claude。不同版本或執行環境對代理變數的支援可能不同；如果明確指定變數後仍無請求進入 Clash，請依照實際執行方式檢查 Claude Code 的代理支援與啟動環境。

測試完成後，可以在該 Shell 中移除變數，再比較不經明確代理設定時的結果：

unset HTTP_PROXY HTTPS_PROXY ALL_PROXY
claude

NO_PROXY 可用來列出應略過代理的本機或內部目標，但不宜在排查時隨意加入寬泛網域。若目標網域意外落入略過清單，請求就可能繞過本機代理。可用 env | grep -i proxy 檢查目前工作階段中的代理變數；分享輸出前，仍要確認其中沒有內部主機名稱或其他敏感資訊。

Windows PowerShell

在 PowerShell 中，環境變數使用 $env: 語法設定。請在同一個視窗中執行 Claude Code：

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

claude

確認環境變數是否設定成功，可輸入 $env:HTTPS_PROXY。測試後可在目前視窗清除設定：

Remove-Item Env:HTTP_PROXY -ErrorAction SilentlyContinue
Remove-Item Env:HTTPS_PROXY -ErrorAction SilentlyContinue
Remove-Item Env:ALL_PROXY -ErrorAction SilentlyContinue

這些命令只影響目前 PowerShell 程序及其後續啟動的子程序，不會替其他終端機視窗設定代理。若使用 VS Code 整合終端機、IDE 內建工作階段、遠端 SSH 或容器，還要確認 Claude Code 是在哪個環境中啟動；本機桌面系統的代理設定不一定會自動傳入遠端主機或容器。

用規則分流，並從錯誤定位問題

讓終端機請求經過本機代理，只完成了「流量進入 Clash」這一步。核心仍會依目前模式、規則順序與代理群組選擇出站。規則模式下，請檢查服務相關網域是否命中預期的代理群組；若較早的規則已命中 DIRECT、其他群組或 REJECT，後面的規則就不會再處理同一請求。

可以先在 Clash 的連線頁搜尋連線記錄中出現的網域，並核對以下欄位：請求的程序或目標、命中的規則、代理策略、最終出站及連線錯誤。不同用戶端顯示欄位的方式可能不同；如果只看見群組名稱，需再展開代理群組，確認其成員目前選到哪個節點。測速成功只能表示特定測試目標在當下可達，不能保證 Claude Code 所需的所有網域、登入流程或 API 請求都能通過。

現象或訊息	先檢查	下一步
連線逾時	環境變數、代理埠、節點連線狀態及連線記錄	先用 curl 明確指定代理測試，再逐段查看逾時發生位置
名稱解析失敗	連線記錄中的 DNS 錯誤、DNS 設定及代理路徑	區分本機解析與核心處理方式，不要只依瀏覽器結果判斷
TLS 或握手錯誤	系統時間、代理連線、TLS 錯誤文字及是否有中間代理	先排除錯誤埠號與網路攔截，不要關閉 TLS 驗證作為常規修復
登入或授權失敗	帳號狀態、登入流程、服務端提示與目前地區可用性	確認網路請求已成功送出後，再處理帳號或服務資格問題
瀏覽器可用但 CLI 不通	終端機環境變數、啟動 Claude Code 的程序及代理記錄	在同一終端機明確設定代理後重新啟動程式

DNS 問題尤其容易被誤判。使用 HTTP 代理時，應用程式與代理之間會先建立連線；目標網域由哪一端解析，會受代理協定、核心設定及應用程式連線方式影響。若 Clash 記錄顯示名稱解析錯誤，應檢查核心 DNS 設定與相關日誌；如果記錄顯示請求已使用代理節點並開始連線，則應再確認節點能否連接目標服務。不要因某次本機 nslookup 成功，就推定代理端解析也一定成功。

若目前使用規則模式，可暫時確認相關請求是否被預期規則接手；如需短暫切換模式比較，測試後要還原原設定，且以新的請求驗證，避免把已建立的連線當成切換後結果。也不要為了排錯直接刪除整份訂閱、覆寫核心設定或關閉所有安全檢查。一次只調整一項，記錄改動前後的連線記錄與錯誤訊息，較容易找出真正的故障點。

如果使用 TUN，終端機流量也可能由虛擬網卡接收，但 TUN 與 Shell 代理變數是不同的流量入口。初次排查時先選一種方式驗證：使用環境變數時確認其指向本機代理埠；使用 TUN 時確認核心日誌與連線頁有收到請求，並留意其他 VPN、路由與 DNS 設定是否互相影響。兩種方式同時啟用不一定會更穩定，反而可能令流量路徑難以判讀。