Claude Code 連不上時，先分清是代理沒接上，還是服務端沒有回應
Clash 已經啟動、瀏覽器也能正常開啟網站，不代表 Claude Code 一定會經過同一條代理路徑。瀏覽器可能使用系統代理或擴充功能；終端機裡的 Claude Code 則是另一個程序，是否使用代理通常取決於它啟動時取得的環境變數、作業系統代理設定，以及 Clash 是否正在監聽相應連接埠。這幾處只要有一處不一致，就可能出現登入卡住、請求逾時、串流中斷，或一直重試卻沒有明確錯誤訊息。
排查時最重要的是先把問題分層：第一，終端機程序有沒有把請求送到本機 Clash；第二，Clash 是否把相關網域交給預期的代理策略，而不是 DIRECT（直連）；第三，所選節點能否穩定連到 Anthropic 服務。假如請求已經抵達服務端，仍可能遇到帳戶授權、服務狀態、區域可用性或限流等問題。只反覆切換「規則」與「全域」模式，未必能辨認是哪一層出了錯。
本文以 Clash Verge Rev、其他支援 Mihomo 的桌面用戶端，以及一般 Bash、Zsh、PowerShell 終端為例說明。不同版本的選單名稱和預設連接埠可能不同，請以自己的用戶端設定為準；如果是公司或學校管理的裝置，也請遵守組織網路政策。排錯期間先一次只改一個項目，並記錄原設定，這樣才能知道哪一步真的有效。
先確認 Clash 狀態：代理埠、模式與節點是否正常
不要先改 Claude Code 的設定，先確認 Clash 本身確實能提供本機 HTTP／HTTPS 代理。開啟用戶端設定頁，找到 mixed-port、HTTP 代理埠或類似欄位，記下實際埠號。常見範例是 7890，但它不是固定值；如果你目前設定的是其他埠號，後續測試也必須使用該值。若用戶端只提供分開的 HTTP 與 SOCKS 連接埠，應依用途選擇正確類型，不能把 SOCKS 埠直接當成 HTTP 代理埠。
接著查看 Clash 的連線列表或即時日誌。選擇一個你平常確認可用的節點，確認策略群組目前確實選中該節點，再用用戶端提供的測試功能檢查延遲。延遲測試成功只能表示測試目標有回應，不等同 Claude Code 的完整請求已經可用；不過，如果一般節點測試也失敗，應先處理訂閱更新、節點狀態或網路連線，而不是急著修改 Claude Code 的環境變數。
- 確認核心正在執行：用戶端介面看起來已開啟，不一定代表代理核心已成功啟動。檢查是否有核心錯誤、連接埠占用提示，或其他 VPN／代理程式正在使用相同連接埠。
- 核對代理模式：規則模式下，請求會依規則選擇策略；全域模式通常會將更多連線送往目前選中的代理。先保留規則模式作為基準，稍後再用短時間全域模式做對照。
- 查明實際監聽埠：設定檔更新或切換設定後，埠號可能改變。以 Clash 介面當下顯示的值為準，不要只沿用很久以前抄下來的設定。
- 暫停其他網路接管工具測試：公司 VPN、其他代理用戶端或安全軟體可能改寫路由。若政策允許，可先逐一停用其他工具做短暫對照；不要同時關閉多項設定，否則很難確認影響來源。
確認埠號後，可從終端測試本機代理是否接受連線。以下把 7890 當作示例；若你的 HTTP／mixed-port 不同，請替換成自己的值。這個測試只驗證代理入口與指定網址的連通狀況，不能代替 Claude Code 登入或 API 請求的測試。
curl -I -x http://127.0.0.1:7890 https://api.anthropic.com如果出現連線被拒絕或無法連上 127.0.0.1，先檢查 Clash 是否執行、代理埠是否正確，以及該埠提供的是 HTTP 還是 SOCKS 服務。若得到 HTTP 回應，即使狀態碼不是成功，也表示請求至少到達了某個 HTTP 端點；接下來還要用 Clash 連線紀錄確認它走了哪條策略。不要把單一狀態碼當成帳戶或 Claude Code 一定正常的證明。
讓終端機使用 Clash：設定 Claude Code 可讀取的代理環境
不少命令列工具不會自動沿用桌面環境的系統代理。最直接的測試方式，是在啟動 Claude Code 的同一個終端機視窗設定 HTTP_PROXY 與 HTTPS_PROXY，並指向 Clash 的 HTTP／mixed-port。請把連接埠換成前一步確認的實際值，再從該視窗啟動程式：
export HTTP_PROXY=http://127.0.0.1:7890
export HTTPS_PROXY=http://127.0.0.1:7890
claude在 PowerShell 中可用以下形式設定目前視窗的環境變數，並從同一視窗執行命令：
$env:HTTP_PROXY = "http://127.0.0.1:7890"
$env:HTTPS_PROXY = "http://127.0.0.1:7890"
claude這些設定一般只對目前終端機程序及其子程序生效，關閉視窗後便不一定保留。這很適合做一次性的排錯：如果同一個視窗裡設定代理後能連線，問題很可能在先前啟動 Claude Code 的環境沒有代理資訊，而不一定是 Clash 規則本身。確認結果後，再決定是否要把設定寫入登入 Shell 設定檔、PowerShell 設定檔，或只在需要時手動設定。
若你是從 VS Code、JetBrains 或其他 IDE 的內嵌終端啟動 Claude Code，請特別注意 IDE 是否在設定環境變數之前就已開啟。桌面環境後來新增的變數，不一定會自動傳回已經執行中的 IDE；可以完全退出並重新開啟 IDE，再從新終端測試。使用 WSL、SSH、容器或遠端開發環境時，127.0.0.1 指的是執行 Claude Code 的那個環境本身，不必然是 Windows、macOS 或主機上的 Clash。這種情況應先確認兩端網路邊界與可達位址，不要假設本機迴圈位址會跨越虛擬機或容器。
若設定變數後仍無法判斷是否生效，可以在同一終端檢視目前變數內容。檢查時只查看代理位址與埠號，避免把含帳密的代理網址、授權資料或訂閱連結貼到公開討論區。也要留意 NO_PROXY／no_proxy：若其中有過寬的網域或萬用字元規則，可能讓原本預期走代理的請求被排除。除非你清楚知道這些例外的用途，先不要隨意加入 Anthropic 相關網域。
最後，部分工具或執行環境對環境變數大小寫、HTTP 代理與 SOCKS 代理的支援方式可能不同。如果在同一環境中設定 HTTPS_PROXY 後仍看不到預期連線，可先核對 Claude Code 版本與官方文件所列的代理支援方式，再測試大小寫變體；不要同時改變代理協定、埠號與規則，否則即使連線恢復，也無法知道真正原因。
檢查 Clash 分流：從連線紀錄確認規則是否命中
環境變數的工作是把請求送進本機代理；Clash 規則的工作則是決定請求進來後要走哪個策略。兩者不能互相取代。Claude Code 的主要服務請求常會涉及 api.anthropic.com，但登入、帳戶頁面或其他功能可能使用不同服務或網域。實際連線會隨版本、功能與登入狀態變動，因此比起照抄一份固定網域清單，更可靠的做法是重現問題時查看 Clash 的連線列表，記錄目的網域、命中規則與策略結果。
在 Claude Code 啟動或發出請求的同時，打開 Clash 的連線紀錄，搜尋 anthropic 或目前顯示的相關主機名稱。逐項確認下列資訊：
- 完全沒有相關連線：可能是 Claude Code 沒有使用該 Clash 入口、環境變數沒有傳入程序、請求尚未發出，或連線被其他網路層攔截。先重新確認終端視窗、代理埠與程序啟動方式。
- 看得到連線，但策略為 DIRECT：代表請求有進入 Clash，問題較可能在規則順序、匹配範圍或目前載入的設定檔。檢查實際命中的規則，確認相關網域是否被較早的直連規則涵蓋。
- 命中代理策略，但節點連線失敗：嘗試在同一策略群組切換至另一個已測試的節點，再重現請求。如果其他服務也不穩，先檢查節點；如果只有 Anthropic 相關請求失敗，則再比較不同節點對該目的地的連線結果。
- 顯示代理節點且連線成功，Claude Code 仍報錯：問題可能已不在基本路由層。記下錯誤時間、目的網域與 HTTP 狀態，再確認授權、帳戶狀態、服務狀況或工具版本。
若確認是規則命中順序造成直連，可在自己維護且確實生效的設定中，將精確的網域規則放在可能提前匹配的廣泛規則之前，並指向已設定好的代理策略群組。規則名稱要與設定中的策略群組名稱完全一致；不要直接複製範例名稱後就假設可以使用。訂閱可能在更新時覆寫遠端設定，修改前請先確認用戶端是否支援覆寫或合併檔，並保留備份。
rules:
- DOMAIN,api.anthropic.com,你的代理策略群組
- MATCH,你的預設策略群組上面的 YAML 只是說明規則放置與命名關係的示意，不能直接保證適用於每份訂閱。若問題出現在登入流程，請以連線紀錄實際顯示的主機為準，再查核該服務所需的網域及政策，不要為了「全包」而把大量不相關網域一律送代理。改完後重新載入設定，確認 Clash 顯示的生效設定確實包含變更，再重新啟動 Claude Code，避免拿舊連線紀錄判斷新規則。
如果規則模式下無法辨認是不是路由攔截，可在符合網路政策的前提下，短暫切換全域模式進行對照，然後立即切回原模式。全域模式能協助判斷規則分流是否是變數，但不代表應長期使用；它會影響更多程式與連線，可能改變本機服務、公司資源或其他網站的出口路徑。每次測試只改模式、不改其他條件，並在連線列表中確認同一目的網域的策略變化。
用最小測試隔離本機、節點與服務端問題
完成前面的檢查後，可以依序做幾個對照，避免把某一層的失敗誤判為另一層。每次只改一個因素，並記下測試時間、終端環境、Clash 模式、所用節點和錯誤訊息。請勿在紀錄中保留 API 金鑰、登入權杖、完整授權標頭或其他敏感資料。
- 確認本機代理入口：使用先前的
curl測試，確認指定的 HTTP／mixed-port 可接受連線。若本機連線被拒絕，回到 Clash 執行狀態與埠號檢查。 - 確認請求有進入 Clash：在同一終端設定代理環境變數，重新啟動 Claude Code 並重現問題。觀察連線列表是否出現相應目的網域；沒有紀錄時，先排查環境傳遞或執行環境邊界。
- 確認命中策略正確：查看規則模式下的匹配結果。若顯示 DIRECT，檢查規則順序與實際載入的設定；若顯示代理節點，記錄該策略及節點狀態。
- 比較另一個節點：保持其他設定不變，只切換到另一個可信且可用的節點，再重試。若只在特定節點失敗，較像出口或節點路徑問題；若所有節點都呈現相同錯誤，應繼續檢查本機環境及服務狀態。
- 比較不同終端環境：在一般本機終端與 IDE、WSL 或 SSH 終端分別測試。若只有其中一種環境失敗，通常要查該環境的代理變數繼承、容器網路或遠端出口設定。
- 查看服務端與帳戶訊號：如果連線已透過代理完成，仍出現明確的授權拒絕、帳戶限制或服務錯誤，依錯誤內容檢查登入狀態、帳戶可用性與官方服務狀態。網路代理無法修正帳戶資格或服務端拒絕。
錯誤表現可以提供方向，但不是單獨的定論。長時間沒有回應或逾時，常值得先檢查代理路徑與節點；名稱解析失敗時，要看 DNS 與執行環境；TLS 握手錯誤則可能涉及節點、網路設備、系統時間或憑證環境。若收到 HTTP 狀態碼，也要區分網路已抵達伺服器與請求獲得授權是兩回事。保留錯誤原文中的非敏感部分，通常比只描述「不能用」更有助於定位。
測試時也可比較不經 Claude Code 的一般 HTTPS 連線與 Claude Code 本身，但不要用包含憑證或使用者資料的請求做公開測試。某個 API 網域可建立連線，並不等於完整登入、模型請求或串流工作流程都會成功；它只能協助縮小範圍。若問題只在長時間串流中發生，除了規則是否命中，也應留意節點穩定性、連線中斷與本機網路切換。
完成對照後，請還原排錯時暫時改動的全域模式、節點與環境設定，只保留已驗證必要的調整。若錯誤持續存在，整理 Claude Code 版本、作業系統、執行環境、Clash 模式、匿名化後的目的網域、命中策略及錯誤時間，再向適當的工具或服務支援管道詢問。分享診斷資料前，先遮蔽 IP、帳戶識別資訊、訂閱連結與任何權杖。
常見問題
瀏覽器能上網，為什麼 Claude Code 還是連不上？
瀏覽器和終端機程序可能使用不同代理設定。瀏覽器能走系統代理，不代表 Claude Code 也會讀取同一設定；先在啟動 Claude Code 的終端視窗設定代理環境變數，再查看 Clash 連線紀錄是否出現相關請求。
我需要直接開啟 TUN 模式嗎？
不一定。若 Claude Code 能使用本機 HTTP／mixed-port，先用環境變數配合規則分流通常較容易定位問題。只有在確認程式沒有使用代理入口、而且你了解 TUN 對其他網路流量的影響時，才把 TUN 當成測試選項；也要留意它可能與 VPN 或公司網路工具衝突。
連線紀錄顯示 DIRECT，代表節點壞了嗎？
不代表。DIRECT 表示這筆連線依目前規則直連，通常應先檢查規則匹配與順序；只有連線被送往代理策略後仍無法完成，才進一步檢查節點或出口。請以連線紀錄中的目的網域和實際命中規則為準。
設定環境變數後仍逾時，下一步該做什麼？
確認變數設定與 Claude Code 啟動在同一個終端視窗，代理埠和協定也與 Clash 設定相符。接著觀察連線是否進入 Clash、命中哪個策略，再只切換一個節點做對照。若路由正常仍有錯誤，檢查登入授權、帳戶狀態及服務端回應。
有些臨時代理方案只接管瀏覽器，或要求每個終端工具各自設定，切換視窗後就容易漏掉；單純開啟全域代理雖然省事，卻可能讓不相關的程式也改走同一出口。Clash 的優勢是能把「終端是否接上代理」與「網域如何分流」分開檢查，再透過連線紀錄觀察實際結果。若你希望在 Windows、macOS 等平台使用圖形化介面管理節點與規則，可先確認適合自己的用戶端版本，再從下載頁取得相關資訊。