Claude Code 連線逾時，為什麼瀏覽器正常也不代表終端正常
Claude Code 在終端機裡執行，與瀏覽器開啟 Claude 網頁並不是同一條連線路徑。瀏覽器可能已經套用作業系統的系統代理，但終端程式不一定會自動沿用；即使你在 Clash 客戶端中開啟了系統代理，命令列仍可能直接連到網路，或採用另一個已經失效的代理位址。結果常見為登入頁面開得出來，Claude Code 卻在請求時等待很久，最後顯示連線逾時、連線中斷，或無法完成回應。
排查時，先把問題分成兩層：一層是終端到 Clash 本機代理埠是否通；另一層是Clash 從目前選取的策略組連到外部服務是否正常。只要其中一層有問題，Claude Code 的錯誤訊息就可能看起來相似。反覆更換節點卻不確認終端代理設定，往往只會讓症狀短暫改變，無法找出真正原因。
另一個容易忽略的差異是請求類型。Claude Code 的登入、模型請求、工作階段更新或版本檢查，實際涉及的主機可能隨版本和功能變動。不要只依照網路文章中一份固定網域清單就判斷設定完成，也不建議把所有流量長期切到全域代理。較穩妥的做法是先確認終端流量確實進入 Clash，再查看連線記錄，依實際出現的網域和規則命中結果調整路由。
檢查 Clash 的本機代理埠與目前策略
開始設定終端之前，先在 Clash Verge、Clash Verge Rev 或其他 Mihomo 客戶端確認設定檔已啟用，而且核心狀態正常。接著查看設定檔或客戶端提供的埠號資訊，確認 mixed-port 或 HTTP 代理埠目前使用哪個數字。許多設定會使用 7890，但這不是固定值；如果你曾改過設定、匯入不同設定檔，或同時執行數個代理程式，本機埠可能已經不同。
一般桌面環境可先使用本機回送位址 127.0.0.1，不要一開始就填入路由器、遠端伺服器或區域網路上的其他位址。終端與 Clash 在同一台電腦時，本機位址最容易驗證，也能避免把代理服務意外暴露給同一網路上的其他裝置。若 Clash 設定只開啟 SOCKS 埠，則要先確認 Claude Code 所用的代理變數能否使用該協定；排障初期以客戶端明確提供的 HTTP 或 mixed port 為優先，避免把協定和埠號配錯。
接著查看 Clash 的連線記錄或即時連線頁面。可以先在終端執行一次簡單的連線測試，再確認記錄中有沒有新連線、連線使用哪個規則、最後進入哪個策略組。若完全沒有新記錄，問題通常還在環境變數、埠號或終端工作階段；若看得到連線但請求失敗，才進一步檢查策略組、DNS、TLS 或出口狀態。這種分層方式比只看 Claude Code 最後顯示的錯誤文字更容易縮小範圍。
| 檢查項目 | 要確認的內容 | 常見問題 |
|---|---|---|
| Clash 核心 | 客戶端顯示核心正在執行，設定檔已啟用 | 只有介面開著，核心實際上已停止 |
| 代理位址 | 使用 127.0.0.1 與目前有效的 HTTP 或 mixed port |
照抄預設埠，但設定檔已改成其他數字 |
| 連線記錄 | 測試時能看到終端發出的連線及命中策略 | 終端沒有走代理，或規則送到不合適的出口 |
在終端設定 Claude Code 使用 Clash 代理
多數終端工具會讀取程序環境中的代理變數。以下先以 Bash、Zsh 等常見 shell 為例，將範例中的 7890 換成你在 Clash 裡實際查到的 HTTP 或 mixed port。設定後再從同一個終端工作階段啟動 Claude Code，確保子程序能繼承這些變數。
export HTTP_PROXY="http://127.0.0.1:7890"
export HTTPS_PROXY="http://127.0.0.1:7890"
export http_proxy="$HTTP_PROXY"
export https_proxy="$HTTPS_PROXY"
claude
這種設定只影響目前的終端工作階段及其後續啟動的程序，不會自動改動瀏覽器或整個作業系統的代理設定。若你之前已經開著另一個終端視窗，新增變數的視窗不會替舊視窗更新環境；請在設定完成的視窗中執行 claude。如需確認變數是否載入，可先執行 echo "$HTTPS_PROXY"，檢查輸出是否指向正確的本機位址和埠號。
使用 PowerShell 時，可在目前工作階段設定程序環境變數，再從同一個視窗啟動程式。以下同樣要按你的 Clash 埠號調整：
$env:HTTP_PROXY = "http://127.0.0.1:7890"
$env:HTTPS_PROXY = "http://127.0.0.1:7890"
claude
若每次開啟終端都需要這組設定，可以把命令加入自己使用的 shell 啟動檔，例如 Zsh 的設定檔；不過，建議先以單次工作階段測試。確認可以連線後，再決定是否要持久化。這樣能避免 Clash 關閉或埠號改變後，終端仍保留舊代理位址，造成其他命令也跟著逾時。公司網路、遠端開發環境或容器環境則要另外確認：執行 Claude Code 的程序所在位置，是否真的能連到你設定的 127.0.0.1。容器中的本機回送位址通常指向容器本身，不一定是宿主電腦。
若你使用 NO_PROXY，請只把確實需要直連的本機服務或內部網域列入排除清單。排除範圍過寬，可能讓需要代理的請求意外繞過 Clash；排除範圍過窄，則可能令本機回呼或內部服務也走代理。修改後重新啟動 Claude Code，避免舊程序繼續使用先前載入的環境變數。
確認終端流量確實命中 Clash 規則
代理變數看起來正確，不等於請求已成功經過 Clash。設定完成後，保持客戶端的連線記錄頁面開啟，再從同一終端啟動 Claude Code，執行一次你平常會用的登入或簡短請求。觀察記錄是否新增連線，以及該連線的網域、規則類型和策略組。若連線命中 DIRECT，先檢查規則順序與目前載入的設定檔；若命中代理策略組，則確認該組選到的節點可正常建立 HTTPS 連線。
不建議為了快速測試就長時間開啟全域模式。全域模式會把更多應用程式流量送往同一出口，可能影響公司內網、區域服務或其他本機工具，也不利於辨認究竟是哪一條規則造成問題。若要暫時做對照測試，請記下原先模式與策略，測試完成後恢復設定；日常使用仍以規則模式搭配明確的策略組為宜。
規則設定方面，可先沿用你信任的現有設定檔與策略組，不要在尚未看過連線記錄前就大量加入網域規則。若某個請求沒有命中預期策略，先確認連線記錄提供的實際主機名稱，再檢查規則順序。較具體的網域規則通常應放在較寬泛的匹配規則之前，否則前面的通用規則可能已經接管連線。不同版本或功能可能使用不同服務主機，請以當下的連線記錄和官方文件為依據，避免把第三方彙整清單當成永遠完整的清單。
若使用 TUN 模式，終端連線也可能由 TUN 接管，但這不代表環境變數設定毫無影響。手動 HTTP 代理與 TUN 同時作用時，流量可能經過額外的轉送路徑，讓規則命中或 DNS 行為更難判讀。排障時先固定一種方式：可以先測試明確的終端代理變數，或先確認 TUN 的連線記錄；不要同時切換多個模式、節點和 DNS 設定，否則每次測試的條件都不同。
常見逾時與登入問題的排查順序
若 Claude Code 仍然逾時，先確認錯誤發生的階段。若程式一啟動就無法連線，優先核對環境變數、埠號和 Clash 核心狀態；若能啟動但登入流程停住，查看登入期間的連線記錄，確認所需連線有沒有被錯誤規則攔截。若只有特定模型請求失敗，則要比較該次請求與成功請求所使用的策略、節點和 DNS 結果，而不是直接假設整個服務都無法連線。
- 先確認本機代理可用：確認 Clash 正在監聽指定埠，且終端設定使用同一個位址與埠號。
- 檢查變數是否被繼承：在啟動 Claude Code 的同一個終端查看
HTTP_PROXY和HTTPS_PROXY。 - 比對連線記錄：確認請求是否出現在 Clash 中、命中了哪條規則，以及使用哪個策略組。
- 逐項排除競爭設定：檢查其他 VPN、代理工具、shell 啟動檔與
NO_PROXY是否改變了路徑。 - 最後再測試 DNS 與出口：只有在代理連線已確認、策略也合理時，才調整 DNS 或更換節點做對照。
如果 Clash 記錄中完全看不到 Claude Code 的連線，先不要急著修改規則集；優先檢查程式是否在不同使用者、容器、遠端工作階段或另一個終端中執行。若記錄顯示連線已進入 Clash，但握手失敗或反覆重試，則可逐一測試另一個可用策略組，並留意系統時間是否正確、當前 DNS 設定是否能解析出合理結果。每次只更動一項設定，保留前後的連線記錄，才能知道哪個調整真正有效。
Claude Code 的終端逾時不一定是 Claude Code 本身故障，也可能是終端沒有繼承系統代理、Clash 埠號不符，或規則把請求送往不合適的路徑。相較於只提供圖形介面的代理工具，Clash 可透過終端環境變數、連線記錄與策略規則逐層檢查，較容易分辨問題是在本機代理還是外部路由；若你使用的客戶端設定入口繁瑣，或不方便查看 Mihomo 核心狀態，可以改用介面更完整的 Clash V.CORE 管理日常設定，並前往下載頁查看可用版本。