Claude Code 與 Clash Verge 終端設定

先理解 Claude Code 的連線路徑：終端機不等於瀏覽器

使用 Claude Code 時，最容易誤判的一點是：「瀏覽器可以開網站，所以終端機也應該可以登入。」實際上，兩者可能完全沒有使用同一條網路路徑。瀏覽器通常會讀取系統代理或瀏覽器自身的代理設定；終端機啟動的 Node.js、Python、Git 或 Claude Code 子程序，則可能依照環境變數、應用程式設定，甚至作業系統的網路層來決定是否經過代理。

Clash Verge負責的是本機代理服務，而不是自動替每一個程式完成設定。當你在 Verge 中啟用系統代理後，常見的 HTTP 與 HTTPS 應用程式可以透過系統代理連線；但某些終端機工具不會讀取系統代理，或只接受明確設定的 HTTP_PROXY、HTTPS_PROXY 與 ALL_PROXY。因此，Claude Code 顯示登入失敗、請求逾時或無法取得授權頁面時，應先分辨是Clash 沒有接到流量，還是終端機根本沒有把流量交給 Clash。

另外，Claude Code 的一次操作可能不只發出一個請求。登入流程可能涉及瀏覽器授權、帳戶或工作區狀態確認、API 請求，以及長時間保持的串流連線。只讓某一個網站直連、卻讓其他必要請求走到不同出口，便可能出現「登入頁能開，但終端機仍然失敗」的情況。這也是為什麼本篇不只介紹如何點選 Clash Verge 的開關，也會說明代理模式、TUN、連線紀錄與分流規則之間的關係。

先確認代理服務，再確認 Claude Code 不要一開始就反覆登出帳戶或刪除設定。先在 Clash Verge 確認本機代理埠與運行狀態，再用終端機測試代理是否真的可用；只有當一般 HTTPS 請求能經過預期出口，才值得進一步排查 Claude Code 的登入或權限問題。

安裝 Clash Verge 與匯入訂閱：先讓核心穩定運作

請從可信的專案發布頁或本站下載頁取得與作業系統相符的 Clash Verge 或 Clash Verge Rev 安裝檔。Windows 使用者通常會接觸到安裝程式或可攜版本；macOS 使用者則要注意系統安全性提示與網路擴充功能權限。不同發行版的畫面名稱可能略有差異，但核心流程大致相同：安裝應用程式、啟動 Mihomo 或相容核心、匯入設定，最後才開啟代理模式。

首次啟動後，進入「訂閱」或「Profiles」頁面，貼上服務商提供的訂閱 URL。若服務商同時提供名稱、更新週期或轉換參數，先保留預設值；不要在還沒確認基本連線前，一次加入多個轉換器、遠端規則集或自訂腳本。匯入完成後，切換到該設定檔並等待節點列表出現。若頁面顯示成功但節點數量為零，可能是訂閱已過期、連結需要授權、回傳內容不是有效 YAML，或請求本身尚未通過網路環境。

接著進入「設定」或「General」區域，確認 Mixed Port、HTTP 代理埠與 SOCKS 代理埠。Mixed Port 可以同時接收常見的 HTTP 與 SOCKS 請求，對初學者較方便；如果你的版本只顯示分開的埠號，也要記下兩者差異。後續在終端機設定環境變數時，必須使用實際顯示的埠號，而不是直接照抄網路文章中的數字。常見的本機位址是 127.0.0.1，但仍應以 Clash Verge 畫面為準。

檢查項目	應看到的狀態	異常時的優先處理
設定檔	已成功匯入，且目前套用中的設定檔正確	重新檢查訂閱 URL、有效期限與回傳格式
核心狀態	Mihomo 或所選核心正在執行	查看核心日誌，確認沒有 YAML 語法錯誤
代理埠	Mixed、HTTP 或 SOCKS 埠已監聽	避免被其他程式占用，必要時更換埠號
節點列表	能看到節點或策略組，並可完成延遲測試	先測試單一節點，不要立即使用複雜自動組

不要公開訂閱連結 訂閱 URL 通常包含帳戶識別資訊或存取令牌。不要把它貼到公開討論區、截圖中或提交到 Git 儲存庫；若連結意外外洩，應立即到服務商後台重新產生或撤銷。

代理模式與終端機設定：從最容易驗證的方法開始

Clash Verge 常見的規則模式、全域模式與直連模式，解決的是「流量應該交給哪一條路」；它們不一定能解決「流量是否真的到達 Clash」的問題。規則模式適合日常使用，會依設定檔中的規則判斷某個網域走代理、直連或拒絕；全域模式則把大部分流量交給選定的代理組，適合用來做短時間的診斷對照；直連模式通常用於確認問題是否確實與代理有關。

第一次設定 Claude Code 時，建議先使用規則模式搭配一個能正常連線的節點。如果終端機仍然逾時，再暫時切換全域模式測試。若全域模式可以使用而規則模式失敗，問題多半落在網域沒有命中預期規則、策略組選錯，或某些請求被誤判為直連。反過來，如果全域模式也完全沒有反應，則應回到本機代理埠、終端機環境變數、TUN 權限與防火牆方向檢查。

在 macOS、Linux 或支援類 Unix shell 的終端機中，可以先用目前 Clash Verge 顯示的 Mixed Port 設定代理環境變數。以下只是格式範例，請把 7890 替換成你的實際埠號：

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:7890

# 確認目前 shell 已讀取變數
env | grep -i proxy

如果你使用 Windows PowerShell，可以在目前工作階段設定相同概念的環境變數：

$env:HTTP_PROXY="http://127.0.0.1:7890"
$env:HTTPS_PROXY="http://127.0.0.1:7890"
$env:ALL_PROXY="socks5://127.0.0.1:7890"

Get-ChildItem Env: | Where-Object Name -match "PROXY"

設定完成後，不要直接把失敗結果歸咎於 Claude Code。先用簡單的 HTTPS 請求測試，並觀察 Clash Verge 的「連線」或「Connections」頁面是否出現新紀錄。測試指令可以使用你所在環境允許存取的公開 HTTPS 網址；重點不是一定要得到某個固定頁面，而是確認請求能完成、連線紀錄中的主機名稱與出口策略符合預期。若終端機測試成功，但 Claude Code 仍失敗，才進一步檢查應用程式自己的代理支援、登入流程或帳戶權限。

需要特別留意的是，部分程式只讀取大寫環境變數，部分程式則會優先採用小寫變數；若同一個 shell 曾設定過不同代理，可能產生互相覆蓋的結果。排查時可先清除不需要的設定，再只保留一組代理變數。若公司網路或安全軟體要求保留特定直連網域，也不要把整個網域清單無條件套進 NO_PROXY，因為過寬的例外可能讓關鍵請求繞過 Clash。

用連線紀錄驗證，不要只看「系統代理已開啟」 先執行一個簡單請求，再到 Clash Verge 的連線頁面搜尋對應主機。若完全沒有紀錄，代表終端機沒有經過 Clash；若有紀錄但顯示 DIRECT，則是分流規則的問題；若顯示代理節點卻仍逾時，才需要比較節點品質、DNS 與 TLS 狀態。

TUN 與分流規則：什麼時候該開，如何避免越改越亂

TUN 模式會在作業系統層建立虛擬網路介面，讓原本不理解 HTTP 或 SOCKS 代理的程式，也有機會被導入 Clash 核心處理。這對不讀取環境變數的終端機工具、桌面應用程式或子程序特別有用。不過 TUN 不是「一開就全部正常」的萬用開關：它需要額外的系統權限，可能與其他 VPN、企業安全軟體、虛擬機網路或防毒程式衝突，也可能因 DNS 設定不一致而產生看似隨機的逾時。

建議先用一般系統代理與環境變數完成測試，只有在確認 Claude Code 或其子程序不願意讀取代理設定時，再啟用 TUN。開啟後請留意 Clash Verge 是否要求管理員權限、是否成功建立網路介面，以及系統是否同時存在其他 VPN 連線。測試時最好一次只保留一個網路攔截工具，否則即使連線成功，也很難判斷到底是哪一層在處理封包。

分流規則方面，不建議一開始就從網路文章複製一大段不明來源的規則集。Claude Code 的實際請求主機可能隨版本、登入方式、區域、帳戶類型與後端服務調整；比起猜測固定網域，應先在連線紀錄中觀察真實主機，再建立最小規則。你可以把與 Claude 相關的請求交給一個獨立策略組，並讓其他一般流量維持原有規則，這樣日後測試不同節點時比較容易看出結果。

rules:
  # 先以實際連線紀錄確認網域，再加入精確規則
  - DOMAIN,example-authority.invalid,Claude-Code
  - DOMAIN-SUFFIX,example-service.invalid,Claude-Code
  - MATCH,DIRECT

上面的網域只是格式示意，不能直接當成 Claude Code 的正式網域清單。實際設定時，請以 Clash Verge 的連線紀錄、官方文件與你的登入流程為依據。規則排序也很重要：精確的 DOMAIN 規則應放在較寬的 DOMAIN-SUFFIX、GEOIP 或 MATCH 規則之前，否則前面的寬規則可能已經把流量送往另一個策略組。修改後重新載入設定檔，再重現同一個失敗操作，避免一次改動太多欄位而失去對照基準。

現象	較可能的層級	建議順序
連線頁完全沒有 Claude 相關紀錄	終端機沒有使用代理，或程序被其他設定攔截	檢查環境變數、TUN 與子程序繼承狀態
紀錄出現但全部顯示 DIRECT	規則未命中或排序太後	先用全域模式對照，再調整精確規則
已經走代理但 TLS 或讀取逾時	節點品質、DNS、長連線或安全軟體	換單一穩定節點，檢查 DNS 與長連線表現
瀏覽器登入成功，終端機仍失敗	應用程式代理設定或登入回呼未對接	確認終端機變數、回呼流程與 Claude Code 版本

登入失敗與請求逾時的排查順序

當 Claude Code 回報登入失敗時，先區分「授權頁面無法開啟」與「授權完成後終端機沒有收到結果」。前者偏向瀏覽器、代理或 DNS 路徑問題；後者可能與本機回呼埠、防火牆、終端機權限或應用程式狀態有關。不要因為頁面能在瀏覽器開啟，就直接判定整個登入鏈路沒有問題。

出現請求逾時時，記下發生時間、當時使用的策略組、節點名稱與 Clash Verge 連線紀錄。若每次都在同一個主機逾時，優先檢查該主機的規則與 DNS；若同一主機換節點後立即恢復，則應比較節點品質，而不是盲目增加規則。若短請求正常、長時間串流在一段時間後中斷，則要考慮出口節點的長連線穩定度、閒置逾時與本機安全軟體檢查。

還有一種常見情況是「設定檔能更新，但 Claude Code 不能使用」。這代表 Clash Verge 至少可以存取訂閱服務，但不代表 Claude Code 所需的每個服務都能通過同一條路徑。訂閱更新可能只是短時間 HTTPS 下載；AI 編程工具則可能需要不同主機、不同連線時間與更長的回應串流。排查時應把兩種請求分開記錄，避免用訂閱成功來替代應用程式成功的判斷。

確認 Clash Verge 核心正在運作，設定檔已套用，且節點或策略組可以正常測試。
確認代理埠沒有被其他程式占用，並在終端機檢查環境變數是否指向相同的本機位址與埠號。
使用簡單 HTTPS 請求，觀察 Clash Verge 是否產生連線紀錄。
暫時切換全域模式，重現同一個 Claude Code 操作，以分辨規則問題或基礎連線問題。
若一般代理無法接管程序，再測試 TUN；同時關閉其他 VPN 或網路攔截軟體。
最後才修改分流規則、更新核心或重新登入，並且每次只改一個變因。

不要把 401、403 與逾時混為一談 401 或 403 通常代表伺服器已收到請求並回覆了身分、授權或政策結果；逾時則可能連 HTTP 層都尚未取得答案。前者應檢查帳戶、訂閱、組織政策與登入狀態，後者才優先檢查代理路徑、節點、DNS 與 TUN。

寫在最後

把 Claude Code 與 Clash Verge 搭配使用時，真正重要的不是盲目開啟最多功能，而是建立一條可以觀察、可以重現、也可以撤回的排查流程。先讓核心與訂閱穩定，再確認代理埠；接著讓終端機明確使用代理，最後才用 TUN 與精細規則處理不支援一般代理的程序。每完成一個步驟，就用連線紀錄確認流量是否真的按照預期通過，這比反覆更換節點或複製整份規則更有效。

相較於只提供瀏覽器按鈕的代理工具，部分競品在終端機環境變數、TUN 權限、連線紀錄與規則命中結果上顯示得不夠清楚；遇到「瀏覽器可以、CLI 不行」時，使用者往往只能重新安裝或猜測設定。Clash Verge 的優勢在於把設定檔、策略組、模式切換、連線明細與核心日誌集中在同一個介面，既能用簡單模式快速驗證，也能在需要時深入檢查 Mihomo 的分流行為。對剛開始接觸代理的 Claude Code 使用者而言，這種可視化的排查路徑通常比功能表面更重要。

如果你已確認自己的帳戶與服務狀態正常，接下來只要選擇可信的訂閱來源、準備一個穩定節點，依照本文順序完成代理測試即可。先從基本模式開始，等 Claude Code 能穩定登入與完成請求後，再按需要加入 TUN 或更精確的分流規則，日後升級客戶端或核心時也更容易保留可用的設定。

→ 立即免費下載 Clash，取得 Clash Verge 與其他客戶端的下載入口，開始設定你的 Claude Code 終端機代理環境。