Claude Code 一直連不上？Clash 代理設定這樣查

為什麼 Claude Code 會一直逾時或無法登入

Claude Code 在終端機裡出現「連線逾時」「登入沒有反應」或「API request failed」，不一定代表 Anthropic 服務本身故障。對使用 Clash 的人來說，真正的問題通常發生在流量沒有按照預期進入代理：有些網域走了代理節點，有些網域卻被規則送去直連；也可能是終端機使用的代理環境變數，與 Clash 的系統代理或 TUN 模式互相衝突。瀏覽器可以正常開啟網站，並不表示 Claude Code 一定會走同一條網路路徑。

Claude Code 的連線流程不是只有一個 API 網域。首次使用時，可能包含登入授權、瀏覽器回呼、帳戶狀態確認、模型請求、版本檢查，以及套件或更新相關的下載連線。這些連線在時間上很接近，使用者只看到終端機停住，卻很難立即知道究竟是 OAuth 授權失敗、API 請求被阻擋，還是某個背景網域沒有命中正確規則。因此排查時不要只搜尋一個「Claude 網域」並直接加入代理，而是要觀察實際連線紀錄。

另一個常見誤區是把「節點延遲低」直接等同於「Claude Code 一定穩定」。延遲測試通常只反映探針主機的往返時間，不能完整代表 TLS 握手、長連線、串流回應與實際 API 請求的品質。某個節點可能測速只有一百毫秒，但連續傳輸時頻繁重置連線；另一個節點延遲略高，卻能穩定完成較長的模型回應。本文的重點，是先確認代理路徑、規則命中與 DNS，再處理節點選擇。

先分段判斷：登入、API 與更新鏈不能混查

Claude Code 無法正常使用時，第一步不是立刻更換整份訂閱或大幅改寫規則，而是把故障拆成幾個階段。若程式在登入指令後開啟瀏覽器，但授權完成後終端機沒有回應，較可能是回呼流程、授權狀態確認或本機端口被攔截。若已經完成登入，執行指令時才出現 timeout、ECONNRESET 或串流中斷，則應優先查看 API 路徑與節點穩定性。若只有更新、安裝或版本檢查失敗，則要另外檢查套件來源、GitHub 或 CDN 相關連線。

建議每次只測試一個階段，並記下測試時間、使用中的策略組、節點名稱與日誌中的網域。這份簡單紀錄非常重要，因為你切換節點後若突然恢復，很容易誤以為「規則已修好」，其實可能只是新節點暫時避開了壅塞。當問題再次出現時，沒有紀錄就只能重新猜測，最後變成不斷匯入新配置的循環。

檢查 Clash 模式：規則、全域與 TUN 的差異

如果你使用 Clash Verge、Clash Verge Rev、Mihomo 或其他 Mihomo 客戶端，請先確認目前的代理模式。Rule 模式會按照規則檔案決定直連或代理，適合日常使用，但前提是 Claude Code 實際連線的網域已被可靠規則覆蓋。Global 模式會把大部分流量集中送往選定的代理組，適合用來做短時間的對照測試。若 Global 模式下 Claude Code 立刻恢復，而 Rule 模式下仍逾時，通常表示節點本身不是唯一問題，規則或 DNS 路徑更值得深入檢查。

Direct 模式只能用於確認「代理是否造成問題」或測試本來就允許直連的服務，不應被當成長期解法。若所在地網路對相關服務的連線不穩定，Direct 測試失敗是預期結果；它的價值在於提供比較基準，而不是證明 Clash 沒有作用。做測試時，請一次只切換一個變數，例如先保持同一節點，只從 Rule 切到 Global，再觀察終端輸出與連線日誌。

TUN 模式則是另一層接管方式。它可以處理不遵守系統代理的應用程式，但同時會引入路由表、虛擬網卡、DNS 劫持與權限等因素。若你已經設定終端的 HTTPS_PROXY，又開啟 TUN，某些連線可能被代理兩次；若 NO_PROXY 包含本不應排除的網域，也可能讓 Claude Code 繞過 Clash。排查期間建議先選定一種主要路徑：要嘛使用系統代理與終端代理，要嘛使用 TUN 接管，等問題定位後再恢復複合配置。

動手排查：用一輪最小測試找出故障層

下面這套流程適合在 Clash Verge Rev 或其他 Mihomo 圖形客戶端中操作。每一步完成後都要記錄結果，不要同時修改模式、DNS、規則與節點，否則即使問題暫時消失，也無法知道真正有效的是哪一項。

1. 確認核心正在運行。在客戶端中查看 Mihomo 核心狀態，確認設定檔已成功載入，並記下 mixed-port、HTTP 代理端口或 SOCKS 端口。若核心日誌已出現 YAML 解析錯誤、端口被佔用或 DNS 啟動失敗，先處理這些基礎問題。
2. 暫時切換到 Global。選擇一個平時較穩定的節點，先不要使用複雜的 url-test 或 fallback 組。用最簡單的路徑執行一次 Claude Code 登入或模型請求，觀察是否仍然逾時。
3. 查看連線日誌。在 Claude Code 執行測試的同時，開啟 Clash 的 Connections 或 Logs，記下出現的主機名、連接埠、進程名稱與命中的規則。若完全沒有對應連線，可能是終端沒有使用 Clash，或請求在本機程序內就已失敗。
4. 切回 Rule 並比較。保持同一個節點，只切換回 Rule。若 Global 成功、Rule 失敗，搜尋日誌中的主機名，檢查它是否命中直連、拒絕、錯誤策略組或不預期的代理組。
5. 檢查 DNS 結果。如果日誌中顯示的 IP 位址反覆變動、連線被送往明顯不合理的地區，或 fake-ip 與本機解析結果不一致，請檢查 DNS 模式、fake-ip-filter、嗅探設定與系統 DNS 是否互相衝突。
6. 最後才測試節點組。確認規則能命中後，再把固定節點換回 url-test 或 fallback。若自動組再次出現逾時，問題多半與探針地址、節點池品質、切換頻率或某些節點不支援穩定長連線有關。

在命令列測試時，請避免把完整的認證資訊、Token 或訂閱 URL 貼到公開討論區。若需要提供錯誤訊息，可以先遮蔽帳戶名稱、授權碼、請求標頭與本機路徑。連線日誌本身也可能包含敏感網域或識別資訊，分享前應先檢查內容。

規則分流與 DNS：最容易被忽略的兩個環節

規則編寫的重點不是堆出大量關鍵字，而是讓同一個使用情境涉及的主機，穩定命中同一個策略意圖。若登入授權、API 請求與必要的控制平面被拆到不同策略組，某一條連線就可能因節點地區、憑證驗證或會話狀態不一致而失敗。與其一開始加入大量寬泛的 DOMAIN-SUFFIX，不如先從連線日誌建立最小清單，再觀察哪些主機在成功與失敗時有所不同。

同時要留意規則順序。自訂規則若放在過於寬泛的規則之後，實際上可能永遠不會被執行；而一條過早出現的 GEOIP、GEOSITE 或 MATCH，也可能把本應進入代理組的流量提前截走。編輯後請使用客戶端提供的規則測試功能，或直接觀察 Connections 中的 rule 欄位，不要只看 YAML 是否能成功保存。

DNS 問題則常被誤認為節點故障。當域名解析到被污染、不可達或地理位置不合適的位址時，即使代理本身正常，TLS 也可能在連線早期失敗。fake-ip 模式能改善部分解析污染情境，但若把本機服務、登入回呼或某些必要域名錯誤放入 fake-ip-filter，可能導致應用程式拿到與預期不符的結果。調整 DNS 前應先備份原設定，一次只改一項，並在成功後保留變更紀錄。

# 僅作為排查方向，請依你的系統與客戶端調整
curl -I --proxy http://127.0.0.1:7890 https://example.com

上面的測試只能確認本機代理端口能否建立基本 HTTPS 請求，不能直接證明 Claude Code 的完整授權或模型串流一定可用。它的用途是先排除「Clash 根本沒有監聽」「端口寫錯」或「代理服務完全不可用」等低層問題。若基本測試成功而 Claude Code 仍失敗，就應把焦點移回實際連線日誌、規則命中與終端自己的代理設定。

節點品質、TLS 與終端環境變數

Claude Code 的模型回應通常比普通網頁更容易暴露節點品質。網頁只要完成幾個短請求就能顯示內容，但 CLI 可能維持較長的 HTTPS 連線並持續接收串流資料。節點若存在高丟包、頻繁重連、共享出口過載或對長連線不友善，表面上可能只顯示「請求逾時」。因此測試節點時，至少要連續執行數次不同長度的請求，而不是只看一次延遲數字。

TLS 錯誤也不一定代表 Clash 憑證配置錯誤。系統時間偏差、過舊的根憑證、企業端點防護攔截 HTTPS、錯誤的 SNI 或中間代理重新簽發憑證，都可能造成握手失敗。若瀏覽器正常、終端失敗，請比較兩者是否使用相同的代理路徑，以及終端使用的 Node.js、系統憑證庫或執行環境是否不同。不要為了「先讓它通」而長期關閉 TLS 驗證，這會把認證風險轉化為更難察覺的安全問題。

環境變數方面，macOS 與 Linux 常見的是 HTTP_PROXY、HTTPS_PROXY、ALL_PROXY 和 NO_PROXY；Windows PowerShell 則可能同時受到使用者環境變數、系統環境變數與客戶端設定影響。修改後要重新開啟終端機，因為已經啟動的 shell 或編輯器終端可能仍保留舊值。若你在 IDE 內執行 Claude Code，也要檢查 IDE 的整合終端是否繼承了與外部終端不同的設定。

常見問題

瀏覽器可以開啟 Claude，為什麼 Claude Code 還是逾時？

瀏覽器可能使用系統代理、瀏覽器外掛或自己的 DNS，而 Claude Code 可能只讀取終端環境變數，甚至完全不使用系統代理。請在 Claude Code 執行時同步查看 Clash Connections，確認是否真的出現對應連線；若沒有，先處理終端代理路徑，而不是繼續更換節點。

切到 Global 就正常，是否代表規則一定寫錯？

這是很強的線索，但不代表每一條規則都錯。它通常說明 Global 使用的策略組與 Rule 模式的命中結果不同，可能是網域漏列、規則順序不對、DNS 結果不同，或某條寬泛規則提前攔截。比較同一次請求在兩種模式下的主機名與命中規則，才能找到具體差異。

開啟 TUN 後反而更不穩，應該關掉嗎？

排障階段可以暫時關閉 TUN，改用單一的系統代理或終端代理做基準測試。若關閉後恢復，應檢查虛擬網卡路由、DNS 劫持、權限與其他 VPN 是否同時接管，而不是直接認定 TUN 本身不能使用。定位完成後，再逐項恢復 TUN 相關功能。

應該優先換節點，還是先改規則？

若 Global 模式下固定節點能穩定完成請求，而 Rule 模式失敗，先修規則；若所有模式都在同一類請求中逾時，再比較節點、TLS、DNS 與服務狀態。盲目換節點可能暫時掩蓋問題，卻無法處理下一次規則更新或節點自動切換後的故障。

Claude Code 的代理排障，和只追求「哪個節點最快」的簡單測速不同；某些輕量 VPN 或僅支援瀏覽器代理的工具，往往不會清楚呈現終端規則命中、DNS 路徑與長連線狀態，設定出了問題也只能反覆重連。Clash V.CORE 則能把規則模式、策略組、TUN、DNS 與連線日誌集中在同一套工作流中，方便你按照本文的順序逐層確認；如果你希望少一點猜測、穩定處理 Claude Code 的登入與 API 連線，可以前往下載 Clash V.CORE，從單一節點與最小規則開始建立自己的可靠配置。