Claude Code 為什麼需要另外處理終端機代理
Claude Code 是讓開發者直接在終端機裡與 AI 協作的工具。它可以讀取專案檔案、分析錯誤、提出修改建議，也能依照你的確認執行測試、搜尋程式碼與整理提交內容。對習慣使用命令列的開發者來說，這種工作流程比在瀏覽器與編輯器之間反覆切換更快；但它的連線方式也與一般網頁瀏覽器不完全相同。Claude Code 通常由終端機程序或其子程序發出 HTTPS 請求，是否能連上服務，取決於作業系統代理、Shell 環境變數、Clash 規則，以及目前實際載入的組態是否互相對得上。
當你看到 Claude Code 登入頁面開不起來、初始化長時間停住、請求偶爾逾時，或同一台電腦上的瀏覽器明明可以使用 Claude、終端機卻顯示網路錯誤，不一定代表帳號或模型服務故障。常見原因是瀏覽器使用了系統 Proxy 或擴充功能代理，但終端機沒有繼承相同設定；另一種情況則是 Clash Verge 已經啟動，然而與 Anthropic 相關的連線仍被規則送到 DIRECT，導致請求沒有經過預期出口。
本篇以 Clash Verge 為主，說明從訂閱匯入、策略選擇、系統代理，到終端機環境變數與連線紀錄驗證的完整流程。重點不是把所有流量一律丟進全域代理，而是先確認 Claude Code 的請求確實進入 Clash，再以規則分流和最小範圍的環境設定逐層排錯。請在符合所在地法規、公司資安政策與相關服務條款的前提下使用代理工具，並妥善保管帳號、API 金鑰與專案原始碼。
先理解 Claude Code 的連線路徑
在開始修改 Clash Verge 之前，建議先把「瀏覽器、桌面用戶端、終端機」視為三條可能不同的連線路徑。瀏覽器一般會讀取 macOS 或 Windows 的系統 Proxy，也可能額外使用瀏覽器擴充功能；Clash Verge 的圖形介面則負責管理訂閱、策略群組與本機監聽埠；Claude Code 由 Shell 啟動時，則可能只讀取 HTTP_PROXY、HTTPS_PROXY、ALL_PROXY 等環境變數，完全不理會系統代理設定。
實際連線目的地會隨版本、登入方式與功能改變，常見核心服務通常包括 api.anthropic.com，登入、帳戶或用量相關流程也可能觸及其他 Anthropic 網域。不要只憑網路文章預先抄一長串固定清單；比較可靠的做法是先在 Clash Verge 的連線紀錄中觀察 Claude Code 啟動、登入與送出請求時出現的目的地，再依照實際紀錄調整規則。這樣可以避免把不相關網域加入代理，也能在服務改版後更快發現新增連線。
| 檢查層級 | 要確認的內容 | 常見異常 |
|---|---|---|
| Clash Verge | 核心正在執行、組態已載入、策略群組有可用節點 | 介面開著但核心未啟動，或載入的是空白設定 |
| 系統代理 | HTTP／HTTPS Proxy 指向 Clash 的本機監聽埠 | 瀏覽器可用，終端機或其他程序不受影響 |
| Shell 環境 | 目前視窗能讀取正確的代理變數 | 只在某個終端機分頁失效，重開視窗後設定消失 |
| 規則分流 | Anthropic 相關目的地套用預期策略，而不是 DIRECT | 連線已出現在紀錄中，但仍持續逾時或握手失敗 |
第一步：在 Clash Verge 匯入訂閱並選定組態
開啟 Clash Verge 後，先進入設定檔或 Profiles 類似的頁面。將服務提供者給你的 HTTPS 訂閱連結貼入匯入欄位，完成下載後確認列表中出現新的組態。若你使用的是本機 YAML，也可以直接選取檔案匯入。訂閱連結屬於敏感資訊，不要貼到公開論壇、截圖或團隊聊天頻道；若連結本身含有識別碼，外洩後可能讓他人取得你的節點配置。
匯入完成不代表核心已經使用它。請明確點選要啟用的組態，觀察介面是否顯示已載入或正在使用。很多「規則改了卻沒效果」的問題，根源其實是修改了本機備份檔，但 Clash Verge 當下使用的是另一份訂閱檔。若設定檔支援自動更新，還要留意更新後產生的新版本是否覆蓋了手動編輯內容；把自訂規則放在可持久化的覆寫欄位，通常比直接修改訂閱原文更安全。
接著確認代理模式。排錯初期建議使用規則模式，因為你可以在連線紀錄中清楚看見每個目的地採用的策略；若規則模式下已確認請求進入 Clash，但某個終端機子程序仍然完全沒有紀錄，才考慮暫時使用全域或 TUN 模式做 A／B 測試。測試完成後，請恢復較符合日常需求的模式，避免不必要地讓公司內網、印表機、版本庫或本機開發服務經過代理。
確認 mixed-port 與系統 Proxy
Clash Verge 的 mixed-port 是同時接受 HTTP 與 SOCKS 請求的本機埠，常見預設值可能是 7890，但實際數字要以你的介面為準，不能直接照抄。若你啟用了系統 Proxy，請確認 HTTP 和 HTTPS 都指向同一個本機位址與正確埠號。部分系統會分開顯示自動代理腳本、HTTP、HTTPS 與 SOCKS；在排錯期間，最好記下每一項目前的值，避免同時開啟多套 VPN 或第二個代理客戶端造成埠位衝突。
動手設定：讓終端機讀取 Clash Verge 代理
在終端機中，先找出 Clash Verge 顯示的 mixed-port，以下以 7890 作為示例。若你的埠號不同，請替換成實際值。對 macOS、Linux 或使用類似 Bash 的環境，可以在目前工作階段暫時設定：
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 與從它啟動的子程序，適合先做一次性驗證。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"設定後，再從同一個視窗啟動 Claude Code。不要在一個視窗設定變數，卻切換到另一個沒有設定的視窗測試，否則很容易把「環境不一致」誤判成 Clash 規則問題。若你希望每次開啟終端機都套用設定，可以把相應內容放進自己的 Shell 設定檔，例如 ~/.zshrc 或 ~/.bashrc；但不建議在所有情境永久設定全域代理，因為公司內網、區域服務、套件鏡像或本機測試 API 可能不需要代理。
更穩妥的方式是為特定工作目錄建立簡短的啟動腳本，或在進入專案前手動執行代理設定。若專案同時使用 Git、Docker、Node.js 套件管理器與其他 CLI，請逐一確認它們是否會讀取相同變數。不同工具對大小寫、SOCKS 協定與憑證的支援程度不一，不能因為 curl 成功，就直接推論所有子程序都會成功。若出現代理伺服器拒絕連線，先檢查本機埠是否正在監聽；若出現 TLS 錯誤，則要查看系統時間、企業憑證、節點相容性與是否存在 HTTPS 攔截。
NO_PROXY 也值得檢查。若它包含過於寬泛的網域或萬用字元，某些請求可能被刻意排除在代理之外；如果它把整個 Anthropic 網域列入排除清單，環境變數看似正確，實際仍會直連。排錯時可先檢視目前值，再縮小到確實需要直連的本機或內網主機。不要盲目刪除所有排除項，因為本機開發服務和公司內部網域可能因此受到影響。
規則分流與 TUN：先精準驗證，再擴大範圍
對 Claude Code 而言，規則分流與終端機環境變數通常是第一階段；TUN 則是當程序不理會系統代理、也不讀取環境變數時的補充方案。你可以先把實際觀察到的 Anthropic 服務網域放在明確規則之前，指向一個可用的代理策略群組，再保留其他流量依原訂閱規則處理。規則順序非常重要：如果前面已有寬泛的直連規則，後面新增的代理規則可能永遠不會被套用。
| 方案 | 適合情境 | 優點 | 需要留意 |
|---|---|---|---|
| 規則模式＋系統 Proxy | 一般開發與日常使用 | 影響範圍較小，容易從紀錄判斷規則是否命中 | 不讀系統設定的子程序仍可能繞過 |
| 終端機環境變數 | 只想讓某個專案或工作階段使用代理 | 範圍明確，適合快速測試和回復 | 新視窗、IDE 內嵌終端或 CI 環境可能沒有繼承 |
| TUN 模式 | 程序忽略 Proxy，且需要驗證系統級攔截 | 能涵蓋更多不支援環境變數的連線 | 可能與 VPN、零信任軟體、公司路由策略衝突 |
若要使用 TUN，請先確認 Clash Verge 取得了作業系統所需權限，並了解它可能影響所有應用程式的路由。開啟後不要只看 Claude Code 是否能啟動，也要測試公司內網、Git 伺服器、localhost 與 DNS 行為。某些問題表面上是「TUN 很慢」，實際上是本機服務被錯誤送往遠端節點，或另一套 VPN 與 TUN 同時修改路由表。排錯完成後，若你只需要讓 Claude Code 走代理，回到規則模式搭配環境變數通常更容易維護。
用連線紀錄與最小測試定位問題
設定完成後，打開 Clash Verge 的連線、Connections 或日誌頁面，接著在同一個終端機啟動 Claude Code，執行一個不涉及敏感原始碼的簡單操作。觀察列表是否出現 Anthropic 相關目的地、連線是否持續建立，以及策略欄位顯示的是預期代理群組還是 DIRECT。若完全沒有紀錄，問題多半發生在終端機未使用代理、程序繞過系統設定，或 TUN 尚未成功接管；若有紀錄但策略錯誤，應回頭檢查規則順序與目前生效的組態。
可以先用低風險的命令測試本機代理埠是否可用，再比較直接連線與經過代理的差異。測試時避免把 Authorization 標頭、API 金鑰或完整帳戶資訊貼進公開指令紀錄。成功不只代表「能打開登入頁」，還要觀察串流回應是否在數分鐘內維持穩定；Claude Code 的實際工作可能包含較長的上下文傳輸、工具呼叫和多次請求，短暫成功不足以代表長工作流程沒有問題。
若登入流程卡住，先確認瀏覽器是否真的開在同一台電腦，以及遠端 SSH 工作階段是否需要把授權網址帶到本機瀏覽器。若只有大型專案分析時逾時，則應考慮節點延遲、長連線穩定性、請求大小與本機資源，而不是反覆重灌 Clash Verge。若錯誤訊息明確指出認證失敗，則應檢查帳號、登入狀態與服務方案；代理只能改善連線路徑，不能修正過期憑證、權限不足或服務端拒絕。
常見失敗原因與恢復方法
- 只開系統 Proxy，沒有設定終端機：瀏覽器正常不代表 Claude Code 會讀取系統代理。請在同一個 Shell 暫時 export 變數，再重新啟動程序。
- 把 mixed-port 當成 SOCKS 專用埠：若你使用的是 HTTP URL，確認該埠確實接受 mixed-port；若組態只開 SOCKS，則要改用對應協定與埠號。
- 規則寫在錯誤組態：訂閱更新後可能重新生成設定檔。請先確認目前啟用的檔案，再使用覆寫設定或持久化規則。
- 代理規則被前面的 DIRECT 蓋掉：Clash 通常依規則順序匹配，寬泛規則放得太前面時，後面的網域規則不會生效。
- NO_PROXY 範圍過大：檢查是否以萬用字元排除了不該排除的目的地，並只保留本機或內網真正需要直連的項目。
- 多套代理同時運作：Clash Verge、VPN、公司安全客戶端與另一個 Clash 殼可能互相搶占埠號或路由。排錯時先縮減成單一路徑。
- 把服務錯誤當成網路錯誤：API 限額、帳戶授權、模型權限與伺服器回應碼，應配合 Claude Code 的錯誤訊息分開判斷。
修改設定後，建議一次只改一個變數，並記錄「修改前、修改後、測試結果」。例如先只設定 HTTPS_PROXY，確認連線紀錄，再加入規則；之後才測試 TUN。這種逐層縮小範圍的方法雖然比一口氣開啟所有功能慢幾分鐘，卻能保留清楚的因果關係，日後換電腦、換訂閱或把設定交給團隊成員時，也比較容易重現。
建立可長期維護的 Claude Code 工作流程
完成首次連線後，不要只留下「目前能用」的狀態。建議把 Clash Verge 的核心版本、訂閱更新時間、mixed-port、模式與自訂規則整理在個人筆記中，但不要記錄訂閱完整連結或任何金鑰。每次更新訂閱後，重新查看 Claude Code 啟動時的連線紀錄，確認目的地仍由預期策略處理。若團隊使用固定開發環境，可以把代理變數名稱、啟動方式與敏感資訊處理原則寫成文件，讓成員自行填入本機值，而不是直接共享包含憑證的 Shell 設定檔。
在 IDE 內嵌終端使用 Claude Code 時，也要特別注意 IDE 可能不是由你平常的登入 Shell 啟動，因此不一定會載入 .zshrc、.bashrc 或 PowerShell 設定。可以在 IDE 終端重新檢查環境變數，並與獨立終端機做一次對照。CI、Docker 或遠端開發容器則是另一個網路命名空間，通常不會自動繼承桌面上的 Clash Verge；這些環境若要使用代理，應依組織政策在對應執行環境中配置，不能假設本機 GUI 已經涵蓋所有流量。
長時間使用時，優先選擇延遲穩定、串流不中斷的策略，而不是只看一次測試的最高速度。當你發現回應忽快忽慢，可以在不同時段比較連線紀錄與節點表現；若只有某一個策略群組失敗，切換群組後仍要確認規則沒有改變。遇到版本更新，先閱讀發行說明並保留可回復的設定副本，避免同時更新客戶端、訂閱格式與 Shell 腳本，讓問題變得難以定位。
與只在瀏覽器中使用 AI 的工具相比，Claude Code 更適合需要讀取本機專案、執行測試與持續串流回應的開發流程；但它也更依賴終端機環境是否一致。Clash Verge 提供可視化的策略切換、連線紀錄與規則分流，能讓你看見請求到底去了哪裡，而不是只靠錯誤訊息猜測。部分同類代理工具的設定介面較分散，或只適合單一平台，遇到 IDE、SSH 與不同 Shell 時往往需要另外摸索；相比之下，Clash Verge 搭配本機規則與明確的 HTTPS_PROXY，能把訂閱管理、路由觀察和終端機測試放在同一套排錯流程裡。如果你正準備為 Claude Code 建立跨平台的穩定連線環境，可以先依本文完成最小設定，再前往下載適合自己作業系統的 Clash 用戶端。