先理解 Claude Code 的連線鏈路:終端機、授權與模型請求不是同一件事
Claude Code是以終端機為主要操作介面的程式輔助工具。它與一般只在瀏覽器開啟聊天頁面的使用方式不同:你會在專案目錄執行指令,工具再依序處理登入、工作區權限、模型請求、工具呼叫與結果串流。只要其中一段沒有走到穩定的代理出口,就可能出現登入頁打不開、驗證完成後回到終端機仍未授權、指令執行到一半停止,或長時間沒有新文字輸出的情況。
因此,設定Clash Verge時不要只測試瀏覽器能否開啟某個網站。瀏覽器正常,並不代表終端機啟動的 Node.js 或其他執行程序一定使用相同代理;有些 Shell、IDE 內建終端機與系統服務也可能讀取不同的環境變數。比較穩妥的做法是把問題拆成三層:第一層是 Clash Verge 本身已啟動並有可用節點,第二層是終端機程序能取得代理設定,第三層是 Claude Code 實際連線的主機被正確分流。
啟動前也要確認版本來源與帳號狀態。不要把第三方封裝的命令列工具、來路不明的啟動腳本與官方客戶端混為一談;不同發行方式可能使用不同的登入流程、設定檔位置與更新機制。安裝完成後,可以先執行版本查詢指令確認命令已被 Shell 找到,再進入一個不含重要秘密的測試專案。API 金鑰、OAuth token、SSH 私鑰與環境檔都不應貼到公開問題或除錯紀錄中。
Clash Verge 安裝與匯入訂閱:先建立乾淨的基礎環境
Clash Verge 的實際介面會隨版本與核心分支略有差異,但基本流程大致相同:從可信來源取得安裝檔,完成安裝後啟動程式,選擇使用的核心,接著在訂閱或設定檔頁面加入服務商提供的訂閱網址。訂閱網址通常是一條以 https:// 開頭、帶有授權參數的連結,請使用複製貼上,不要手動重打,也不要把它公開貼在截圖、Issue 或聊天群組裡。
匯入完成後,先觀察設定檔是否成功解析。正常情況下應該能看到代理節點、代理群組與規則模式;如果頁面只顯示空白、更新失敗或 YAML 解析錯誤,這還不是 Claude Code 的問題。常見原因包括訂閱已過期、服務商限制請求來源、網址被瀏覽器截斷、系統時間不正確,或回應內容其實是登入頁 HTML 而不是設定檔。此時可在瀏覽器或 Clash Verge 的更新紀錄查看 HTTP 狀態,但不要把完整訂閱網址分享出去。
選擇節點時,延遲數字只能當作初步參考。測速通常只反映某個測試網址的 TCP 或 HTTP 回應時間,無法代表 Claude Code 長時間串流的穩定度。建議先選一個延遲合理、最近使用沒有頻繁斷線的節點,再執行一次完整登入與短指令;若短請求正常、長任務卻中斷,應比較封包穩定性、出口品質與讀取逾時,而不是只追求最低毫秒數。
| 檢查位置 | 應看到的結果 | 異常時的優先處理 |
|---|---|---|
| Clash Verge 核心狀態 | 核心已啟動,沒有反覆崩潰或重啟 | 檢查核心版本、設定檔格式與權限 |
| 訂閱更新 | 節點與策略組成功載入 | 確認網址、有效期、系統時間與回應內容 |
| 代理模式 | 目前模式符合你的分流需求 | 先用 Rule 模式,避免全域代理掩蓋規則問題 |
| 連線紀錄 | 測試請求能命中預期策略組 | 搜尋實際 host,依紀錄補規則,不要猜網域 |
讓終端機真正使用代理:環境變數、規則分流與連線紀錄
Clash Verge 開啟「系統代理」後,瀏覽器通常可以直接受益,但終端機程序是否跟隨,仍取決於作業系統、Shell 與程式本身。對 Claude Code 這類命令列工具,建議先確認目前 Shell 是否看得到代理環境變數。HTTP 與 HTTPS 通常會使用 HTTP_PROXY、HTTPS_PROXY 或小寫變體;部分工具也會讀取 ALL_PROXY。不同作業系統與 Shell 的設定語法不完全相同,請依你的本機監聽埠調整,以下只是測試方向:
export HTTP_PROXY=http://127.0.0.1:7890
export HTTPS_PROXY=http://127.0.0.1:7890
export ALL_PROXY=socks5://127.0.0.1:7891
curl -I https://example.com
Windows PowerShell 可使用對應的環境變數語法,亦可在 Clash Verge 的設定中確認 HTTP 與 SOCKS5 監聽埠。重點不是盲目複製某一組數字,而是確定端口與目前版本的「通用端口」欄位一致。若你在一個終端機視窗設定了變數,另一個已經開啟的 IDE 終端機不一定會同步;修改後請重新開啟終端機,必要時重啟 IDE 或 Claude Code。
分流方面,優先使用Rule 模式,並讓 Claude Code 的實際請求依網域命中代理策略。不同版本、登入方式、地區與功能可能涉及不同主機,不能把一份網路流傳的網域清單視為永久標準。最可靠的方法是開啟 Clash Verge 的連線紀錄,先執行登入或一個短指令,再查看新出現的 host、命中的規則與使用的策略組。若某個主機一直落到 DIRECT,而該主機在你的網路環境中無法穩定連線,才針對它補上精確的 DOMAIN 或合理的 DOMAIN-SUFFIX 規則。
rules:
- DOMAIN,example-auth.invalid,Claude-Code
- DOMAIN-SUFFIX,example-api.invalid,Claude-Code
- MATCH,DIRECT
上面的網域只是格式示例,不是 Claude Code 的固定官方網域,請勿原樣加入正式設定。策略組名稱也必須與你的設定檔實際存在的名稱完全一致。若規則寫在 MATCH 之後,永遠不會被執行;若前面已有更寬的 GEOIP、IP-CIDR 或其他後綴規則,也可能在到達你的新規則之前就被攔截。修改後重新載入設定,清除不必要的舊連線,再用連線紀錄確認順序。
| 現象 | 較可能的原因 | 建議排查順序 |
|---|---|---|
| 瀏覽器正常,終端機逾時 | Shell 沒有使用代理或端口不一致 | 查看環境變數,重開終端機,再測試 curl |
| 登入頁無法開啟 | 授權主機漏規則、DNS 異常或節點不可用 | 查看連線紀錄中的實際 host 與錯誤類型 |
| 登入成功但指令沒有回應 | API 或串流連線走了不同出口 | 重現短指令,按時間排序比對多個主機 |
| 執行一段時間後中斷 | 節點抖動、讀取逾時或長連線不穩 | 換穩定節點對照,不要只看測速延遲 |
| 立即出現 401、403 或配額訊息 | 帳號、授權、區域或服務端政策 | 先確認帳號狀態,不要把所有 HTTP 錯誤歸咎於代理 |
常見故障排除:從錯誤類型判斷,而不是反覆更換節點
如果終端機顯示 connection refused,通常代表本機代理端口沒有服務、端口填錯,或 Clash Verge 核心尚未啟動;這類錯誤不需要先換節點。若是 connection timed out 或 dial tcp timeout,才比較接近路由、DNS、出口品質或遠端防火牆問題。若看到 TLS、憑證或握手錯誤,應檢查系統時間、企業網路的 HTTPS 檢查、防毒軟體與自訂憑證,不要只增加更多分流規則。
若 Claude Code 能登入,但模型輸出在長任務中停止,先用短指令與較小專案重現,再把時間點對照 Clash Verge 的連線紀錄。短請求成功代表基本解析與握手可能沒有問題,接下來要觀察的是長連線是否被節點重置、讀取逾時是否過短,以及代理服務是否對串流連線有限制。此時固定使用一個穩定節點做對照,比同時更改核心、DNS、規則與終端機變數更容易定位。
也要留意終端機目前所在的專案目錄。Claude Code 可能需要讀取本機檔案、執行 Git 或呼叫其他開發工具;如果你只看到網路相關錯誤,實際原因也可能是檔案權限、Shell 路徑、公司裝置政策或子程序沒有繼承環境變數。排查時請把「代理連線」「帳號授權」「本機專案權限」分開驗證,並以最小化測試逐項恢復設定。
相較於只在瀏覽器設定代理的工具,某些桌面代理客戶端對終端機、TUN、系統 DNS 或規則紀錄的呈現較不完整,遇到 Claude Code 這種需要長連線與多主機協作的工作流時,使用者往往只能反覆切換全域模式;部分簡化版客戶端也缺少清楚的策略組、連線日誌與設定檔管理。Clash Verge 的優勢在於能集中管理訂閱、節點、Rule 分流與請求紀錄,方便把「終端機沒有連線」拆成可驗證的步驟,而不是靠猜測網域或盲目換線。若你想把這套 Claude Code 終端機代理流程與其他客戶端安裝、規則設定一起整理,接下來就可以從 ClashNote 的下載與使用指南開始,選擇適合自己系統的 Clash 客戶端。