Clash 三種模式差異
Git clone 卡住、npm 或 pip 安裝逾時，Docker 映像檔也拉不下來？本篇從工程師日常開發流程出發，帶你設定 Clash TUN 模式，讓終端機工具依規則連線，不必每次都手動調整代理。內容涵蓋 Git、npm、pip 與 Docker 的測試方式，並整理 macOS、Windows 常見權限與連…
為什麼 Git 與套件工具需要 TUN
終端機程式不一定會遵循作業系統的系統代理設定。瀏覽器能開啟網站，不代表 git、npm 或 Docker 也會使用同一條代理路徑。它們可能各自讀取環境變數、工具專屬設定，或直接建立網路連線；遇到 GitHub 逾時、套件下載卡住、映像檔拉取失敗時，問題未必是節點本身無法連線。
Clash 或 mihomo 的 TUN 模式會建立虛擬網路介面，並透過路由接管符合條件的 IP 流量，再交給內核依目前的規則模式、全域模式或直連模式處理。這和只設定 HTTP 系統代理不同：應用程式即使沒有明確讀取代理環境變數，也可能經由作業系統路由進入 TUN。實際接管範圍仍受作業系統、權限、路由設定、排除清單與網路堆疊影響。
因此，TUN 不是「所有程式必定代理」的保證，也不是一種分流模式。是否走代理，還要看連線有沒有進入內核、規則命中什麼策略，以及該策略目前選用的出口。建議先保留規則模式，再只為開發相關網域加上代理規則，避免把公司內網、套件鏡像或區域網路服務一併送到遠端節點。
| 情境 | 系統代理 | TUN 的用途 |
|---|---|---|
| 瀏覽器開啟 GitHub 正常，Git 命令逾時 | Git 可能未讀取系統代理設定。 | 接管符合路由條件的終端機連線。 |
npm install 下載失敗 | npm 可能使用自己的代理設定或環境變數。 | 讓未明確設定代理的網路請求也有機會進入內核。 |
| Docker 拉取映像檔失敗 | Docker CLI 與背景 daemon 的代理路徑可能不同。 | 可能協助處理主機上的 daemon 流量，但仍須檢查 daemon 所在環境及路由。 |
| 指定網域要走代理、其餘保持原路 | 工具的代理設定可能需要逐一維護。 | 由內核規則統一決定已接管連線的出口。 |
啟用前先檢查客戶端與設定
先確認目前使用的是 Clash Verge、Clash Verge Rev，還是其他整合 mihomo 的客戶端，並在「關於」或核心資訊頁記下客戶端與核心版本。各版本的選單名稱可能不同；TUN 通常位於「設定」中的「TUN 模式」或「虛擬網路介面」項目。若使用的是不同客戶端，請以該版本介面提供的設定為準，不要照抄其他平台的服務管理步驟。
- 備份設定：匯出目前設定，或複製客戶端資料目錄。若設定來自訂閱，確認客戶端是否支援覆寫或合併設定；直接修改訂閱產生的檔案，更新時可能被覆蓋。
- 確認權限：Windows 通常需要安裝或啟動 TUN 服務；macOS 可能會要求授權系統網路延伸或管理權限；Linux 則可能需要管理員權限或相應的網路能力。只使用客戶端正式提供的授權流程。
- 檢查埠與其他 VPN：若同時運作其他 VPN、虛擬機或容器網路，可能發生路由優先順序衝突。先記下原本的網路狀態，不要同時開啟多個會改寫預設路由的工具。
- 確認策略名稱：開啟代理頁面，確認設定中有可用的代理策略組，並記下名稱及目前選取的節點。以下範例使用「開發代理」作為策略名稱，實際設定時必須換成自己的名稱。
若要用設定檔檢查 TUN，可參考以下 mihomo 片段。它不是完整設定檔，也不能不加檢查地直接覆蓋訂閱；proxies、proxy-groups、DNS 與規則都要和現有設定配合。不同核心版本及客戶端可能對設定欄位提供不同的介面或預設值。
mixed-port: 7890
mode: rule
tun:
enable: true
stack: mixed
auto-route: true
auto-detect-interface: true
strict-route: true
rules:
- DOMAIN-SUFFIX,github.com,開發代理
- DOMAIN-SUFFIX,githubusercontent.com,開發代理
- DOMAIN-SUFFIX,npmjs.org,開發代理
- DOMAIN-SUFFIX,npmjs.com,開發代理
- MATCH,現有預設策略範例中的策略名稱必須存在於目前的 proxy-groups 或節點設定中；現有預設策略 也必須換成實際存在的策略。若訂閱已經定義 rules，不要只把上面幾行貼到檔案最後就假設規則會自動合併。規則由上而下比對，應把開發網域放在可能先行匹配的廣泛規則之前，並將一般兜底規則保留在後面。
依作業系統啟用 TUN
Windows：先確認服務與虛擬介面
在 Clash Verge 或 Clash Verge Rev 中開啟「設定」，尋找 TUN 開關；部分版本會先要求安裝服務或以系統管理員權限執行。依提示完成授權後啟用 TUN，等待客戶端顯示服務正常或虛擬介面已建立，再測試連線。若開關無法保持啟用，先查看客戶端日誌中的權限錯誤、服務啟動失敗或介面建立錯誤，不要反覆重裝網路驅動程式。
Windows 的系統代理與 TUN 是兩個不同入口。停用系統代理不一定代表 TUN 已停止；反過來，系統代理顯示已開啟，也不能證明命令列程式有使用它。測試時一次只切換一項，並在客戶端連線記錄中確認目標連線是否出現，以及命中的規則與策略名稱。
macOS 與 Linux：留意授權和路由
macOS 上啟用 TUN 時，依系統提示授權網路延伸或相關服務；若系統拒絕授權，請到系統設定中的隱私權與安全性區域查看是否有待確認項目。升級客戶端或作業系統後，授權可能需要重新確認。不要為了排查而刪除不認識的系統設定檔或網路擴充項目。
Linux 上的介面與權限取決於發行版、桌面環境及客戶端封裝。確認目前帳號是否有建立 TUN 介面所需權限，並檢查是否已有其他 VPN 或網路管理程式修改路由。使用容器、虛擬機或遠端桌面時，請分清 TUN 運作於主機、虛擬機還是容器內；主機啟用 TUN，不表示每個隔離的網路命名空間都會自動沿用相同路由。
為 Git、npm 與 Docker 設定可驗證的分流
先用最小範圍測試，再擴大規則。GitHub 常見流量涉及 github.com，下載原始碼、發佈檔案或使用 Git LFS 時也可能連到其他網域。npm 常見登錄服務使用 registry.npmjs.org，但自訂 registry、企業鏡像或私有套件服務會使用不同網域。Docker Registry 的認證、清單與映像層下載也可能分別連到不同主機；實際目的地取決於映像來源與服務配置。
| 工具 | 先做的測試 | 需要留意 |
|---|---|---|
| Git | git ls-remote https://github.com/git/git.git HEAD | HTTPS 與 SSH 是不同連線方式；SSH 常用 TCP 22，不會因為 HTTPS 測試成功就代表 SSH 也正常。 |
| npm | npm ping --registry=https://registry.npmjs.org/ | 檢查目前的 registry；企業或專案設定可能指定不同來源。 |
| Docker | docker pull hello-world | Docker CLI 通常會向 daemon 發出請求；daemon 可能運行於不同主機、虛擬機或 WSL 環境。 |
若 Git 使用 HTTPS，可以先確認客戶端日誌是否記錄 github.com 的連線，以及最終策略是不是預期的代理組。若 Git 遠端網址使用 [email protected]:...，則為 SSH 連線。可以先使用 HTTPS 遠端做對照，或為 SSH 明確設定支援的代理方式；單靠 TUN 的網域規則不一定能在所有情況下識別尚未解析網域的連線。
npm 測試時先查明目前 registry 和代理設定，不要為了讓一次安裝成功就永久改成陌生鏡像。可使用 npm config get registry 查看 registry，使用 npm config get proxy 及 npm config get https-proxy 檢查 npm 層級的設定。這些設定可能來自專案、使用者設定檔或環境變數；若它們仍指向失效的代理埠，即使 TUN 已啟用也可能造成錯誤。確認狀況前，先記下原值再變更。
Docker 特別需要確認 daemon 的位置。若 Docker Desktop 在本機使用虛擬化環境，或 Docker CLI 連到遠端 daemon，主機上的 TUN 不一定能接管 daemon 所在環境的流量。先用 docker context ls 查看目前 context，並確認 Docker Desktop 的代理設定或 daemon 執行環境。不要把設定 Docker CLI 的環境變數，誤當成已設定 Docker daemon 的映像下載代理。
規則只加入實際需要的網域
先從客戶端連線記錄或工具輸出找出失敗的主機名稱，再新增對應規則。不要把整個雲端服務網域或所有 TCP 流量一概送往代理；範圍過大的規則可能令登入、內網套件庫或公司開發服務繞遠路。若服務使用多個 CDN 或短效下載網址，某次測試成功後也應再檢查完整安裝流程涉及的主機，而非只以首頁能否開啟作判斷。
若新增網域規則後仍失敗，請依序檢查：規則是否排在廣泛規則之前、策略組是否選中可用節點、連線是否出現在客戶端記錄中，以及 DNS 解析是否得到預期結果。對 Docker 等使用多個服務端點的工具，逐一確認認證服務與映像層下載的連線，比猜測並添加大量網域更有效。
確認代理生效並排查常見失敗
啟用後不要只看 TUN 開關。先用瀏覽器開啟目標服務，再執行一項終端機測試，並同步查看客戶端的連線或日誌頁面。對照時間、目標網域、命中規則與策略組選擇，才能確認終端機流量是否確實進入內核。若工具回報連線成功，但客戶端沒有對應記錄，也可能是請求走了另一條網路、使用快取，或由另一個代理設定處理。
- 先檢查環境變數：查看
HTTP_PROXY、HTTPS_PROXY和ALL_PROXY是否仍指向舊埠或失效主機。Windows PowerShell 可執行Get-ChildItem Env:*proxy*；macOS 或 Linux 可執行env | grep -i proxy。不要公開輸出中可能包含帳號或權杖的代理網址。 - 檢查 Git 的獨立設定：使用
git config --show-origin --get-regexp 'http\..*proxy|https\..*proxy|remote\..*\.url'查看相關來源。若結果顯示某個設定檔強制指定代理，請確認它是否仍有效；分享輸出前遮蔽網址中的認證資訊。 - 確認 DNS 與規則：相同網域可能因本機快取、DNS 配置或解析結果不同而命中不同規則。清除快取前先確認客戶端是否提供相應功能；不要直接修改系統 DNS 作為第一步。
- 分辨逾時與拒絕連線：
connection timed out、connection refused、TLS 憑證錯誤和 HTTP 401/403 的排查方向不同。保留錯誤類型、目標主機及時間，不要把所有失敗都歸因於節點速度。 - 逐項建立對照：暫時停用 TUN、恢復系統代理原狀，或更換一個節點時，每次只改一項。測試完成後恢復原設定，避免遺留全域代理或錯誤環境變數。
若客戶端日誌顯示連線已命中代理策略，但連線仍失敗，可再檢查節點狀態、目標服務回應及 DNS。若完全沒有連線記錄，優先檢查 TUN 權限、路由、工具執行環境及 Docker daemon 位置。若只有 SSH 或特定容器失敗，應針對該協定或網路命名空間測試，不要立即改動其他已正常的規則。
常見問題
已設定 HTTP_PROXY，還需要啟用 TUN 嗎？
不一定。若 Git、npm 等工具都能正確使用明確代理設定，且沒有其他需要接管的應用程式，未必需要 TUN。TUN 適合處理不支援或未讀取代理設定的流量；啟用前仍應檢查路由、權限與規則，避免兩套代理設定互相衝突。
開啟 TUN 後，所有流量都會經過代理節點嗎？
不會。TUN 是流量接管方式，流量進入內核後仍依模式和規則決定出口；有些連線可能被排除、未經虛擬介面，或命中 DIRECT。請以客戶端連線記錄、命中規則和實際策略為準。
TUN 正常，但 Docker pull 仍然逾時，該檢查什麼？
先確認目前 Docker context、daemon 所在環境，以及 Docker Desktop 或 daemon 的代理設定。再從日誌找出認證與映像層下載實際使用的主機，檢查這些連線是否進入內核及命中預期策略。只測試 Docker CLI 的代理變數，不能證明背景 daemon 的網路也已設定完成。
GitHub 的網域規則有效，為什麼 SSH Git 仍連不上？
SSH 通常透過 TCP 22，與 HTTPS Git 使用的連線方式不同；連線也可能在 DNS 或路由階段無法提供網域資訊給規則判斷。先確認遠端網址格式與客戶端記錄，再考慮明確設定 SSH 代理或改用 HTTPS 做對照測試。不要只因為瀏覽器和 HTTPS Git 正常，就推定 SSH 路徑也相同。