Claude Code 在中國怎麼連線？Clash 代理設定攻略

為什麼 Claude Code 會出現登入失敗與連線逾時

Claude Code 是在終端機中執行的 AI 程式設計工具。它與一般瀏覽器開啟網頁的情況不同：一次登入或對話，可能同時涉及帳號驗證、授權回呼、模型 API、版本檢查、文件資源與套件下載。當其中任何一段連線沒有經過可用的代理出口，終端機通常不會清楚告訴你是哪個網域失敗，而是顯示登入卡住、ETIMEDOUT、fetch failed、socket hang up，或長時間沒有新輸出。

對中國大陸地區的使用者而言，最容易誤判的一點是：「瀏覽器能打開某個頁面」不等於「Claude Code 一定能完成 API 請求」。瀏覽器可能使用了系統代理、瀏覽器擴充功能或單獨設定的代理；終端機則可能繼承另一組環境變數，甚至完全不理會桌面客戶端的系統代理。反過來，若你啟用了 Clash 的 TUN 模式，終端流量可能被透明接管，但 DNS、路由模式或規則組合不正確時，仍然會出現只有 CLI 失敗的情況。

因此，排查 Claude Code 不應只盯著一個 API 網域，也不應一遇到逾時就反覆更換節點。比較可靠的方式，是先把問題拆成三條鏈：第一條是登入與授權鏈，第二條是模型請求鏈，第三條是安裝、更新與文件鏈。每條鏈都要在 Clash 連線日誌中確認實際命中的主機、規則與策略組，這樣才能知道是代理沒有啟用、網域沒有覆蓋，還是節點本身不穩定。

ℹ 先記住三個原則：不要把瀏覽器可用當作終端可用；不要只為單一 API 主機寫規則；不要在未確認日誌前同時修改 DNS、TUN、環境變數與節點。

Claude Code 需要哪些連線：登入、API 與更新資源

Claude Code 的實際網路行為會隨版本、登入方式、作業系統與官方服務調整，因此文章中的網域清單只能作為排查起點，不能視為永遠不變的固定白名單。你應該以當下版本的官方說明、終端錯誤訊息與 Clash 日誌交叉確認。特別是授權流程可能從終端跳轉至瀏覽器，再由本機回呼將結果交還給 CLI；如果瀏覽器走代理，而本機回呼被防火牆或其他安全軟體攔截，登入仍然可能失敗。

登入階段通常比單純的模型請求更複雜。終端可能先連到產品或帳號服務，再取得授權頁面，最後等待瀏覽器完成驗證。此時請注意三個位置：瀏覽器是否使用與 Clash 相同的代理、終端是否能連到授權服務、本機回呼埠是否被其他程式佔用。若畫面已經顯示授權完成，但 Claude Code 仍停在等待狀態，問題未必在節點，也可能是回呼沒有回到正確的本機程序。

若你以環境變數指定代理，請確認變數格式與目前 CLI 所使用的執行環境一致。Linux、macOS 的 shell、Windows PowerShell 與 Windows 命令提示字元，載入環境變數的方式並不完全相同。常見錯誤包括只設定了 HTTP_PROXY、大小寫變數沒有同時處理、代理埠號寫錯，或在設定檔中留下過期的遠端代理。若 Clash 使用 mixed port，應以客戶端當下顯示的監聽地址與埠號為準，而不是直接套用網路文章中的預設值。

模型 API、套件與更新鏈

登入成功後，Claude Code 還要建立模型請求。這部分可能與登入使用不同的主機或不同的服務層，不能因為授權頁面成功就推斷 API 一定正常。若終端可以登入但輸入提示後逾時，請先打開 Clash 的連線紀錄，觀察發送提示的時間點是否出現新的連線；若完全沒有紀錄，代表流量可能沒有經過 Clash，或 CLI 使用了另一個網路堆疊。若有紀錄但顯示拒絕、握手失敗或反覆重試，才進一步檢查策略組與節點品質。

安裝與更新又是另一條路徑。使用 npm、套件管理器或官方安裝腳本時，可能會連到套件註冊表、版本資訊服務、程式碼託管平台及其 CDN。這些連線與模型 API 沒有必然重疊。若你只把 Anthropic 相關網域送入代理，卻讓套件註冊表直連，便可能出現「Claude Code 已經能對話，但更新或重新安裝失敗」的情況。比較穩妥的做法，是在安裝和執行兩個階段各自記錄日誌，再決定是否需要為套件來源建立獨立策略組。

Clash 分流設計：先分類，再決定策略組

對初次使用 Clash 的人來說，最容易犯的錯是把所有相關流量放進一條非常寬的規則，例如將整個大型網域後綴全部送往同一節點。這種做法短期可能看似有效，卻容易把不需要代理的資源、公司內部服務或本地開發站點一起帶走，也會讓日後的故障很難定位。更好的方法是先建立「用途分類」，再讓同類流量命中相同的策略意圖。

授權與帳號：用於登入、換票、帳戶狀態與授權回呼相關的服務，重點是穩定完成 HTTPS 與重新導向。
模型請求：用於 Claude Code 對話、工具呼叫與長連線回應，重點是節點穩定、延遲可接受，以及不要頻繁切換出口。
安裝與更新：用於 npm、程式碼託管平台、套件 tarball 與版本檢查，重點是下載完整與連線可重試。
本地與內網：包括 localhost、127.0.0.1、公司網域、區域網路設備與開發服務，通常應保持直連。

如果你使用訂閱規則，先確認目前配置採用的是哪一套規則順序。Clash 通常按照規則由上而下比對，較早出現的寬規則可能在精確網域之前攔截流量。例如前面存在一條把大量流量送往直連的規則，後方即使補上 Claude 相關網域，也不一定有機會被命中。修改前建議備份配置，並使用清楚的策略組名稱，例如 CLAUDE-CODE、AI-DEV 或 REMOTE-API，避免與訂閱自動生成的組名混淆。

節點選擇方面，不要只看 Clash 介面顯示的延遲。延遲測試通常只代表探針網址的往返時間，不能完全代表長時間 HTTPS 回應、串流輸出或大檔案下載的品質。Claude Code 的互動可能持續較久，因此一條短測速很快、但連線容易重置的節點，實際體驗未必比延遲稍高但長連線穩定的節點好。可以先用 select 手動固定節點完成測試，確認穩定後再考慮 url-test 或 fallback。

合規提醒：請在所在地法律、服務條款、雇主或學校網路政策允許的範圍內使用代理與 AI 服務。訂閱連結、存取令牌、API Key 與登入資訊都屬於敏感資料，不要貼到公開討論區、截圖或除錯日誌中。

動手設定：在 Clash 中完成 Claude Code 代理流程

以下流程適用於 Clash Verge、Clash Verge Rev、Mihomo Party 或其他使用 Mihomo 核心的客戶端。不同版本的按鈕名稱可能略有差異，但核心思路相同：先確認核心正在執行，再確認本機代理入口，最後用日誌驗證 Claude Code 的實際流量。若你的客戶端仍使用較舊核心，部分 TUN、DNS 或規則欄位可能不相容，請先確認核心版本與配置格式。

確認配置檔已啟用。在 Profiles 或設定檔頁面選取正在使用的訂閱，確認核心狀態為執行中。不要只在磁碟中修改一份 YAML，卻忘記客戶端實際載入的是另一份檔案。若有「配置檔解析失敗」提示，先修復 YAML 縮排與欄位格式，再進行連線測試。
確認代理入口。在設定頁查看 HTTP、SOCKS 或 mixed port 的監聽地址。若終端與 Clash 位於同一台電腦，通常可使用本機地址；若 CLI 在容器、虛擬機或遠端開發環境中執行，127.0.0.1 可能只指向該環境本身，不能直接連到宿主機的 Clash。
先採用規則模式。將模式設定為 Rule，避免一開始就使用 Global 或 Direct。Rule 模式可以讓你在連線日誌中看到每個主機命中了哪一條規則與哪個策略組，便於區分「沒有代理」和「代理節點不可用」。
建立專用策略組。可以先建立一個手動選擇的 CLAUDE-CODE 組，加入兩至三個已知穩定節點。測試期間先不要使用大量自動切換，否則登入過程中出口改變，可能觸發重新驗證或讓長連線中斷。
補上實際規則。先把你在登入、安裝與對話時從日誌看到的官方服務網域分別整理，再以精確網域或可信後綴加入規則。不要把猜測中的陌生網域全部放進寬泛規則，也不要直接複製來源不明的巨大規則集。
設定終端環境。若你不使用 TUN，便要讓 Claude Code 使用 Clash 的 HTTP 或 SOCKS 代理。設定完成後重新開啟終端，避免目前 shell 還保留舊環境。若同時啟用了 TUN 和代理變數，先用其中一種方式完成基準測試，再逐步加入另一種，避免重複代理。
分階段驗證。先測試一般 HTTPS 連線，再測試登入，最後輸入一個簡短提示。每一步都記錄時間、策略組、節點與錯誤內容。若第二步失敗，先不要跳到第三步；這樣才能知道故障發生在授權鏈、模型鏈還是終端環境。

在 YAML 中新增規則時，縮排與規則順序都很重要。示意結構可以如下，但其中的網域、策略組名稱與欄位必須依你的實際配置調整：

rules:
  - DOMAIN-SUFFIX,example-auth-domain,CLAUDE-CODE
  - DOMAIN-SUFFIX,example-api-domain,CLAUDE-CODE
  - DOMAIN-SUFFIX,example-package-domain,CLAUDE-CODE
  - DOMAIN,localhost,DIRECT
  - IP-CIDR,127.0.0.0/8,DIRECT,no-resolve

上面的 example-* 只是佔位示意，不能直接當作 Claude Code 的完整網域清單。正式使用前，請以官方文件和 Clash 日誌確認真實主機。若規則命中正確但仍然逾時，切換到另一個穩定節點再測一次；若所有節點都失敗，應回頭檢查 DNS、TLS、系統時間與服務本身，而不是無限增加規則。

常見故障：從日誌與終端逐層定位

先確認瀏覽器完成授權後，終端是否仍在等待本機回呼。檢查本機防火牆、端點安全軟體與是否有其他 CLI 程式佔用回呼埠。接著查看 Clash 日誌，確認授權相關連線是否命中預期策略。若瀏覽器使用系統代理，而終端使用另一個代理埠，兩者就可能看到完全不同的結果。可以先關閉多餘的代理環境變數，使用單一代理方式重新登入，以降低變數。

可以登入，但輸入提示後 API 逾時

這種情況通常要觀察提示送出瞬間的連線紀錄。如果沒有新紀錄，代表 CLI 沒有經過你正在查看的 Clash 實例；如果有紀錄但命中 Direct，便是規則或規則順序問題；如果命中代理但多次重試，則要比較不同節點的握手、首字節時間與連線重置情況。長時間沒有輸出也可能與串流回應、終端代理相容性或公司網路攔截有關，不能只用一次 ping 結果判斷。

啟用 TUN 後反而更不穩定

TUN 會改變系統路由與 DNS 行為。若同時保留舊 VPN、系統 PAC、第三方加速器或另一個 Clash 客戶端，容易形成多重接管。建議先關閉其他網路工具，以最小配置啟用 TUN，確認一般網頁、終端 HTTPS 與 Claude Code 分別可用，再逐一恢復其他功能。若使用 fake-ip，還要留意本地開發域名、公司內網與需要真實 IP 的服務是否被錯誤解析；必要時將內網網域與保留地址加入直連或 fake-ip 過濾。

安裝或更新失敗

安裝問題要獨立處理。確認套件管理器目前使用的 registry，查看是否存在使用者級代理設定，例如 npm 的 proxy、https-proxy 或 registry 配置。這些設定可能與 Clash 系統代理不同，甚至指向已失效的地址。清理過期設定後，再使用 Clash 日誌觀察註冊表、下載 CDN 與版本服務的連線。若只有某個套件來源失敗，先確認來源本身是否暫時不可用，不要把所有問題都歸因於 Claude Code 或 Clash。

若你在公司、學校或受管理的裝置上使用終端，還要考慮 TLS 憑證、網路安全閘道與代理認證。部分企業代理要求安裝自有根憑證，單純把流量轉到 Clash 並不能解決憑證驗證問題；也不要為了繞過錯誤而長期關閉 TLS 驗證。安全的排查順序是確認系統時間、根憑證、代理認證、DNS 與規則，再檢查節點，而不是以降低安全性換取短暫可用。

與只提供系統代理開關的簡易 VPN 相比，Clash Verge Rev、Mihomo Party 等客戶端能讓你看到規則命中、連線日誌、策略組與 DNS 行為，對 Claude Code 這類終端工具更容易定位問題；但若客戶端操作過於複雜，或舊版 Clash for Windows 缺少對應的 Mihomo 功能，也可能讓 TUN、規則覆寫與核心更新變得繁瑣。Clash V.CORE 的優勢在於把穩定的核心能力、可讀的分流思路與多平台使用場景整理在一起，方便你針對登入、API 與套件鏈逐步驗證；如果你希望用較少的猜測完成 Claude Code 的代理環境配置，可以前往下載頁取得 Clash V.CORE，從清楚的配置與日誌檢查開始建立可靠的終端工作流。

完成設定後的長期維護清單

Claude Code 可以正常使用後，不代表配置永遠不需要維護。官方服務可能增加新的授權端點，CLI 更新也可能改變登入流程或套件來源。建議每次升級前先備份 Clash 配置與終端代理設定，升級後重新觀察一次登入、短提示與長回應三個場景。若規則來自訂閱，確認本地覆寫不會在更新訂閱時被覆蓋；若規則由自己維護，則應保留變更日期與測試結果，避免幾個月後忘記某條規則為何存在。

保留一個已知可用的手動策略組，方便自動選擇異常時快速回退。
將登入、模型 API、套件更新與本地開發服務分開記錄，不要全部混在同一條寬規則中。
定期檢查終端的代理環境變數，避免舊埠號、舊訂閱或停用客戶端殘留。
更新核心或切換 TUN 前先備份，並在變更後逐項驗證，不要一次修改多個網路層。
任何 API Key、OAuth Token、訂閱 URL 與錯誤日誌，都要先遮蔽敏感欄位再分享。

// 編輯推薦

Clash V.CORE — 為 Claude Code 打造清楚的代理分流

從登入授權到模型 API，再到套件更新與 DNS 排查，用可觀察的規則與日誌建立穩定的終端工作環境。

支援 Claude Code 終端代理排查
清楚查看規則命中與連線日誌
可分離登入、API 與更新流量
支援多平台 Clash 使用場景
方便備份與維護本地配置

取得 Clash V.CORE →