開發者為什麼需要一套穩定的 Clash 終端代理方案

對程式開發者來說，網路問題通常不是「整台電腦完全不能上網」，而是某一個工具在某一個步驟突然失敗：git clone 卡在接收物件、npm install 下載套件時出現 ETIMEDOUT，Docker 拉取映像檔時速度忽快忽慢，或 IDE 裡的擴充功能一直顯示下載失敗。瀏覽器可以正常開啟網站，並不代表終端機、Node.js、Git、Docker 和 IDE 使用了同一條網路路徑。瀏覽器可能讀取系統 Proxy 或代理擴充功能，但命令列工具常常只讀取環境變數，Docker daemon 甚至可能是獨立服務，完全不會繼承目前 Shell 的設定。

這篇文章的重點不是把所有流量無差別送進代理，而是建立一個容易觀察、容易撤銷、也方便團隊文件化的流程：先讓 Clash Verge Rev 或其他 Mihomo 用戶端正常工作，再以規則分流處理 Git、套件註冊表與容器映像站，接著補上終端機的 HTTP_PROXY、HTTPS_PROXY 和 NO_PROXY，最後才用 TUN 模式處理那些不理會系統 Proxy 的程式。這樣即使某個步驟失敗，也能判斷問題出在 DNS、代理埠、規則、憑證，還是工具自身。

開始之前，請確認代理服務的使用符合所在地法規、公司資安政策、程式碼託管平台規範與套件來源的服務條款。代理不會自動解決錯誤的帳號權限、失效的 Token、套件版本衝突或公司防火牆政策；它只負責讓允許的網路請求經過指定的連線路徑。

規則分流、系統 Proxy 與 TUN 模式如何取捨

三者解決的是不同層次的問題。規則分流決定某個網域應該交給哪個策略群組；系統 Proxy讓會讀取作業系統代理設定的應用程式連到 Clash 的本機埠；TUN則在系統網路層攔截更多不主動支援代理的連線。很多人一遇到 Git 或 Docker 逾時就直接開全域 TUN，但這會把公司內網、資料庫、印表機、VPN 和本機服務一起帶入排錯範圍，反而增加判斷難度。

方案 適合場景 優點 注意事項
規則分流＋系統 Proxy Git、IDE、一般 HTTP 工具 範圍清楚，容易查看連線紀錄 工具必須讀取系統設定或環境變數
終端機環境變數 單一 Shell、CI 測試、Node.js 工具 設定快速，不必改整台電腦路由 只對繼承該環境的行程有效
選擇式 TUN 忽略 Proxy 的應用程式或背景服務 可涵蓋較底層的 TCP、DNS 流量 可能與 VPN、虛擬網卡和公司安全軟體衝突
全域 TUN 需要快速確認是否為路由層問題 適合短時間 A/B 測試 不建議在未理解路由的情況下長期使用

建議採用「由小到大」的驗證順序：先測試 Clash 本機埠，再測試單一終端機，接著確認 Git 或套件工具，最後才處理 Docker daemon 和 TUN。每次只改一個變數，並記下測試時間、目的地、策略群組與結果，避免在同一輪同時更換節點、規則和 DNS，導致問題無法重現。

開始前要確認的 Clash 設定

開啟 Clash Verge Rev 後，先確認目前載入的是實際生效的設定檔，而不是剛下載但尚未套用的草稿。訂閱更新、設定檔合併和重新載入有時會產生多份檔案，若你修改了錯誤的副本，介面看似有設定，核心卻仍使用另一份內容。先在用戶端確認目前設定檔名稱、核心類型、代理群組和最後載入時間，再開始排錯。

  • 確認本機埠：記下 mixed-port 的實際數值，例如 7890。不要直接假設所有安裝都使用相同埠號。
  • 確認模式：排錯初期使用 Rule 模式，讓連線紀錄能清楚呈現網域命中的策略；不要一開始就用 Global 模式掩蓋規則問題。
  • 確認策略群組：選一個延遲合理、能維持長連線的群組，避免測試期間頻繁自動切換節點。
  • 確認 DNS 行為：若紀錄中出現網域解析失敗、IPv6 路徑異常或解析結果不一致，先處理 DNS，再判斷代理節點是否有問題。
  • 確認 Allow LAN：只有在其他裝置或容器需要連入本機 Clash 時才開啟，並限制在可信任的區域網路，避免把代理埠暴露到公共網路。
小提示：測試時可在 Clash 的連線列表搜尋 github、registry、npm 或實際錯誤訊息中的主機名稱。比起只看「成功／失敗」，請同時確認請求是否進入 Clash、最後使用哪個策略，以及是否在連線建立後很快斷開。

設定終端機環境變數，讓 Git 與套件工具讀到代理

許多命令列程式會讀取標準的代理環境變數。若 Clash 的 mixed port 是 7890，可以先在目前 Shell 暫時設定，完成測試後再決定是否寫入啟動檔。使用 http:// 作為本機代理前綴並不代表遠端連線不安全；它只是表示終端機到本機 Clash 的控制通道，真正前往遠端主機的 HTTPS 通常仍由工具建立。

export HTTP_PROXY=http://127.0.0.1:7890
export HTTPS_PROXY=http://127.0.0.1:7890
export ALL_PROXY=http://127.0.0.1:7890
export NO_PROXY=localhost,127.0.0.1,::1,.local

Windows PowerShell 可使用下列形式：

$env:HTTP_PROXY="http://127.0.0.1:7890"
$env:HTTPS_PROXY="http://127.0.0.1:7890"
$env:ALL_PROXY="http://127.0.0.1:7890"
$env:NO_PROXY="localhost,127.0.0.1,::1,.local"

設定完成後，不要直接重試原本的大型操作，先用輕量請求確認環境是否生效：

curl -I https://github.com
git ls-remote https://github.com/example/project.git
npm config get proxy
npm config get https-proxy

Git除了環境變數，也可能有自己的設定。若全域設定曾經寫入另一個已失效的埠號，工具可能表現得像是完全不理會目前的環境變數，因此應檢查：

git config --global --get http.proxy
git config --global --get https.proxy
git config --list --show-origin

團隊共用電腦或 CI 環境不建議把含有帳號密碼的代理 URL 直接寫進 Git 設定或 Shell 記錄。若代理需要驗證，請使用作業系統的秘密管理工具、CI Secret 或短期 Token，並在工作結束後清除歷史設定。NO_PROXY 也要保持精準：本機服務、公司內網和內部套件註冊表通常應該直連，但不要把過大的網域後綴加入其中，否則可能讓原本需要代理的請求被悄悄繞過。

IDE、npm 與 Docker 的分層設定方式

IDE 與內嵌終端機

IDE 通常同時包含兩個網路層：編輯器本身負責下載擴充功能、同步帳號和查詢語言伺服器；內嵌終端則依賴啟動它的 Shell 環境。你在外部終端機設定了 HTTPS_PROXY，不代表已開啟的 IDE 會立即取得新變數。最穩妥的做法是先完全關閉 IDE，再從已設定環境變數的終端機啟動，或在 IDE 的網路設定中明確填入 Clash 本機埠。

若只有擴充功能下載失敗，先檢查 IDE 的 Proxy 模式是否為自動偵測、系統設定或明確手動設定，並查看輸出面板中的實際錯誤主機。若只有內嵌終端失敗，則檢查它使用的是哪個 Shell、是否載入 .zshrc、.bashrc 或 PowerShell Profile。不要同時在 IDE、Shell 和作業系統填入互相矛盾的 Proxy，否則關閉其中一層後，另一層可能仍指向不存在的埠號。

npm、pnpm 與套件註冊表

Node.js 生態的下載來源不一定只有一個。除了預設的 npm registry，專案還可能在 .npmrc 指定公司私有註冊表、Git 依賴或二進位檔下載網址。若 npm install 失敗，請先分辨是解析套件名稱失敗、TLS 憑證失敗、權限遭拒，還是下載內容逾時。可查看目前生效設定：

npm config get registry
npm config get proxy
npm config get https-proxy
npm ping

對公開註冊表的規則可以走適合的代理群組，但公司私有 registry、內部 Git 和內網套件通常應放入 NO_PROXY 或 Clash 的直連規則。若公司使用自簽憑證，不要為了繞過錯誤而關閉 TLS 驗證；應向管理者取得正確的 CA 憑證並依公司文件安裝。

Docker CLI 與 Docker daemon

Docker 是最容易誤判的一層。你在終端機 export 代理變數，只會影響目前的 Docker CLI；實際執行 docker pull 時，下載映像檔的通常是 Docker daemon。因此 CLI 能連到本機 Docker socket，不代表 daemon 能連到 Docker Hub 或其他 registry。若只有 docker build 裡的 RUN npm install 失敗，還要區分建置容器的代理變數與 daemon 拉取基礎映像檔的代理設定。

建議依序驗證：先執行 docker version 確認 Client 與 Server 狀態，再執行 docker pull 測試 registry，最後才處理 Dockerfile 內的建置網路。企業環境可使用 Docker daemon 的服務設定或官方支援的 registry mirror，但應由管理者統一維護，不要把個人代理埠硬編碼進團隊映像檔。若需要在建置階段使用 Proxy，也應透過受控的 BuildKit secret 或 CI 變數傳入，避免把代理資訊寫入映像檔層或公開日誌。

TUN 模式的啟用時機與常見排錯順序

當 Clash 連線列表完全看不到 Docker、某個 IDE 背景程序或其他工具的請求時，才適合把 TUN 當作下一個驗證工具。啟用前先關閉其他可能建立虛擬網卡的 VPN、零信任客戶端或流量攔截軟體，並保留目前規則檔的備份。TUN 啟用後，先測試一個外部 HTTPS 網站，再測試 Git registry，最後測試 Docker；如果所有內網服務都突然無法連線，應立即檢查路由排除和 DNS，而不是繼續更換節點。

TUN 常見的問題包括權限不足、虛擬網卡未建立、系統安全軟體阻擋、DNS 劫持模式與公司 VPN 衝突，以及 IPv6 流量未依預期處理。不同作業系統和 Clash 客戶端的選項名稱可能不同，因此不要照搬其他版本的截圖；應以目前介面是否顯示 TUN 已啟用、系統是否出現對應網卡、連線列表是否出現預期目的地為準。

完成測試後，請做一次「關閉 TUN、保留系統 Proxy」的回歸測試，再做一次「清除環境變數」的回歸測試。這兩輪能幫你確認實際依賴的是規則、Shell 環境，還是 TUN 接管。若只有 TUN 開啟時成功，代表某個程式不支援代理環境變數；若只在環境變數存在時成功，則應把設定寫入該工具或服務的正式部署配置，而不是永久依賴全域 TUN。

把一次成功調整成可重複的開發工作流

當問題解決後，建議把結果整理成一份不含機密資訊的團隊檢查表。內容至少包括 Clash 本機埠、規則群組名稱、需要代理的公開網域類型、應直連的內部網域、各工具的代理設定位置，以及如何恢復預設值。不要只記錄「開啟 TUN 後就正常」，因為換到公司 VPN、CI Runner、遠端 SSH 主機或 Docker Desktop 後，流量路徑可能完全不同。

  1. 先確認 Clash 核心正在執行，且目前策略群組能正常建立連線。
  2. 使用連線列表確認 Git、套件 registry 或容器 registry 的實際目的地。
  3. 在單一終端機設定代理變數，測試 curl、git ls-remote 和套件管理器。
  4. 檢查 IDE 本身與內嵌終端是否使用相同的代理路徑。
  5. 將 Docker CLI、daemon 和建置容器分開測試，避免混為一談。
  6. 只有在請求未進入 Clash 或工具明確忽略 Proxy 時，才啟用 TUN。
  7. 記錄成功設定並清理過期的全域 Proxy、錯誤的 Git 設定與不必要的 NO_PROXY。

與只提供單一全域開關的簡易代理工具相比，這種做法雖然多了規則、環境變數和服務層的檢查，但能清楚處理「瀏覽器正常、Git 失敗」或「Docker CLI 正常、daemon 逾時」這類開發現場最常見的差異。Clash 的規則分流、連線紀錄、策略群組與可選的 TUN 模式，讓你可以先用低干擾方式定位問題，再按需要擴大接管範圍；如果你正在尋找一個能同時配合終端機、IDE 與容器工作流的跨平台工具，這套方法會比反覆切換全域開關更容易維護。

立即免費下載 Clash，開啟流暢上網新體驗 →