Git clone 偶爾逾時、npm 套件下載停在一半，或 Docker pull 一直重試，常見原因是命令列程式沒有遵循桌面用戶端設定的系統代理。Windows、macOS 與 Linux 的系統代理主要服務會主動讀取代理設定的應用程式；不少終端工具、背景服務與容器引擎則使用自己的網路堆疊，甚至完全忽略系統代理。
Clash 用戶端中的 TUN 模式會建立虛擬網路介面，並透過路由將符合條件的 IP 流量交給核心處理。這讓不支援 HTTP 或 SOCKS 代理的程式，也有機會依 Clash 規則分流。但 TUN 不會自動修正 DNS、憑證、容器內部網路或目標服務端的限速問題；要讓開發工具穩定連線，仍須確認核心、路由、規則與測試方式。
TUN 與終端機代理有什麼不同
系統代理通常會提供 HTTP、HTTPS 或 SOCKS 監聽連接埠，例如常見的 127.0.0.1:7890，但實際位址和連接埠應以用戶端目前設定為準。程式必須支援並讀取這些設定，才會把連線送到代理。終端機中的 git、npm 或 Docker daemon 可能由不同程序執行，各自有獨立的代理設定，因此「瀏覽器可以開啟網站」不能證明命令列也走同一路徑。
TUN 的接管位置更接近作業系統網路層。流量進入虛擬介面後，核心再依 DNS、IP 與規則選擇代理或直連。這通常比逐一為每個工具設定代理更方便，但也表示 TUN 權限、路由表和 DNS 行為都會影響整台裝置。使用 TUN 並不等於所有流量都必定代理：規則可以選擇 DIRECT，而未被虛擬介面接管的流量也不會經過核心。
| 方式 | 適用情況 | 常見限制 |
|---|---|---|
| 系統代理 | 瀏覽器與會讀取系統代理的桌面程式 | 未讀取系統設定的命令列程式可能直連 |
| 環境變數或工具代理設定 | 只需讓 Git、npm 等指定工具使用代理 | 各工具設定方式不同，背景服務未必繼承終端機變數 |
| TUN | 需要接管多種未設定代理的應用程式流量 | 需要系統權限，並須檢查路由、DNS、區域網路與容器流量 |
若只有單一工具出問題，先用該工具的代理設定通常較容易限制影響範圍；如果多種工具都無法遵循系統代理，且希望共用同一套分流規則，再考慮啟用 TUN。兩種方式也可以分工使用，但要避免同一程序同時被環境變數代理與 TUN 重複轉送，否則可能形成迴圈或連線失敗。
按作業系統啟用 TUN 並驗證接管
先確認目前使用的核心支援 TUN。許多仍在維護的桌面用戶端使用 mihomo 核心，但舊版核心或用戶端不一定有相同功能。介面上看到 TUN 開關也不代表服務已成功啟動；應查看用戶端狀態或核心記錄，確認虛擬介面建立、路由設定與 DNS 接管沒有錯誤。
Windows
- 在 Clash Verge、Clash Verge Rev 或其他目前使用的用戶端設定中，找到 TUN 或服務模式選項。選單位置會隨版本不同而變動，請以安裝版本的介面為準。
- 依用戶端提示授予管理員權限或安裝所需服務，再啟用 TUN。若系統安全提示來自不明程式，請先確認應用程式來源，不要直接批准。
- 查看核心記錄，確認虛擬介面建立成功，且沒有權限不足、路由衝突或 DNS 監聽錯誤。若原本另有 VPN，先完全中斷後再測試。
- 開啟新的 PowerShell 視窗，執行
curl.exe -I https://registry.npmjs.org/。再查看用戶端連線記錄，確認該連線是否出現以及命中的規則與策略。
Windows 也可用 Get-NetRoute 檢查路由，但不建議在不了解介面用途時手動刪除路由。若 TUN 關閉後仍無法上網，先確認用戶端服務已停止，再查看是否有殘留的 VPN、虛擬網卡或系統代理設定。
macOS 與 Linux
macOS 用戶端啟用 TUN 時，可能需要核准系統延伸功能、網路延伸或管理員授權；不同 macOS 版本與用戶端的提示不完全相同。依畫面完成授權後，重新啟動用戶端並確認核心記錄。若使用 Apple Silicon 或 Intel 的不同版本套件，請確認安裝檔與處理器架構相符。
Linux 桌面環境通常需要核心建立 TUN 裝置並調整路由的權限。可先確認系統有 /dev/net/tun，並依用戶端文件設定服務權限。不要為了快速啟動而將整個應用程式長期以 root 執行；應使用受支援的服務或權限配置。啟用後檢查預設路由、DNS 解析與區域網路存取，避免把 SSH 管理連線或內部套件伺服器意外送入代理。
各平台的圖形介面不同，操作順序可以概括為：先停用其他接管工具，再啟動核心服務，授權虛擬介面，最後查看路由與連線記錄。若啟用後所有網路都中斷，先關閉 TUN 並恢復原本的系統網路，不要同時修改 DNS、MTU 和規則，否則難以判斷是哪個變更造成問題。
為 Git、npm 與 Docker 設定分流
啟用 TUN 後，先用明確的網域規則指定開發服務，再確認策略群組名稱與現有設定完全一致。以下是規則片段，不是可單獨使用的完整設定；PROXY 必須是現有設定中的策略群組名稱。規則應放在較寬泛的網域規則及最後的 MATCH 之前，並透過用戶端提供的覆寫或合併方式加入，避免訂閱更新時被覆蓋。
rules:
- DOMAIN-SUFFIX,github.com,PROXY
- DOMAIN-SUFFIX,githubusercontent.com,PROXY
- DOMAIN-SUFFIX,githubassets.com,PROXY
- DOMAIN-SUFFIX,npmjs.org,PROXY
- DOMAIN-SUFFIX,docker.io,PROXY
- DOMAIN,auth.docker.io,PROXY
- DOMAIN-SUFFIX,cloudflare.docker.com,PROXYGitHub、npm Registry 與 Docker Hub 可能會使用不同網域、CDN、重新導向或企業自訂鏡像。上述清單只涵蓋常見目標，不是完整的網域清單；若 Git clone 正常但大型 release 檔案逾時，請從核心連線記錄找出實際請求的主機，再補上精確規則。Docker pull 也可能連到映像檔儲存服務，單獨代理 docker.io 不保證所有資料傳輸都已涵蓋。
- Git：先確認 Git 命令出現在核心連線記錄中，再查看其命中規則。若採用 SSH remote，目標通常是 SSH 連線，不一定等同於 HTTPS 的 Git 流量；可先確認 SSH 連接埠與核心是否支援對應轉送。
- npm：使用
npm config get registry查看目前 Registry。公司或專案若使用內部 Registry，不應直接把它改成公開服務；依網域規則選擇代理或直連。 - Docker：Docker CLI 通常會向 Docker daemon 發出請求，而 daemon 可能是獨立服務，不會繼承目前終端機的環境變數。TUN 可協助接管 daemon 的網路流量，但仍要確認其執行環境、容器網路與規則命中。
要區分「沒有接管」和「代理出口不可用」，可在同一個終端機、同一網路下重複執行相同請求，並同時查看核心連線記錄。若記錄完全沒有該連線，優先檢查 TUN、程式是否在另一個網路命名空間內執行，以及 DNS 是否解析到預期目標；若記錄顯示已命中代理但仍逾時，則改測其他節點或檢查目標服務狀態。
DNS、環境變數與容器網路的邊界
TUN 接管 IP 流量，不代表 DNS 一定會依預期處理。若程式在核心收到網域連線前，就透過作業系統或其他 DNS 服務取得位址，核心可能只看到 IP，無法按網域規則分流。應在用戶端記錄中檢查 DNS 請求與後續連線是否對應；若使用 fake-ip，確認 mihomo 的 DNS 功能與 TUN DNS 攔截設定相互配合，且不要重複新增互相衝突的頂層 dns: 區段。
只想讓特定命令使用本機 HTTP 代理時，可以透過環境變數作為另一種測試方式。以下的連接埠僅為範例，請替換成用戶端實際監聽的 HTTP 連接埠：
export HTTP_PROXY=http://127.0.0.1:7890
export HTTPS_PROXY=http://127.0.0.1:7890
export NO_PROXY=localhost,127.0.0.1,.internal.example這些變數只會影響從該 Shell 啟動、且支援代理環境變數的程序，不會自動套用到已在背景執行的 Docker daemon 或其他服務。完成對照測試後，可在目前 Shell 執行 unset HTTP_PROXY HTTPS_PROXY NO_PROXY 清除變數；若已寫入 Shell 設定檔，則還要移除對應內容並重新開啟終端機。不要把含有帳密的代理 URL 寫進共用專案檔或公開日誌。
Docker 有不同的網路層級：Docker daemon 負責取得映像檔，容器內的程式則經由容器網路對外連線。宿主機上的 TUN 不一定會以相同方式處理每一種 bridge、虛擬網路或遠端 Docker context。先分開測試 docker pull 與容器內的連線；若只有容器內失敗，檢查容器 DNS、網路模式與公司防火牆，而不是只調整宿主機上的代理環境變數。
依症狀排查 TUN 與終端連線
| 症狀 | 優先檢查 | 處理方向 |
|---|---|---|
| 瀏覽器正常，終端機逾時 | 核心連線記錄、TUN 狀態、程序執行環境 | 確認終端連線是否進入核心；若沒有，檢查路由或服務權限 |
| 連線有命中規則但仍失敗 | 策略群組、節點狀態、目標服務錯誤 | 手動選擇已知可用節點，對同一網址重測 |
| Git 可用，npm 或 Docker 失敗 | Registry、重新導向網域、daemon 執行身分 | 從記錄找出實際目標網域，逐一核對分流 |
| TUN 開啟後內網或 SSH 中斷 | 內網網段、直連規則、路由優先順序 | 為確認過的內部網段設定直連，避免猜測或放寬整個路由 |
| TUN 關閉後仍無法上網 | 殘留服務、系統代理、DNS 與虛擬介面 | 停止用戶端服務，恢復原本代理與網路設定後重測 |
建議按照固定順序排查：先確認核心正在執行且 TUN 狀態正常；再對單一 HTTPS 網址執行 curl -I，同時觀察連線記錄；接著確認規則命中與策略群組；最後才比較節點、DNS 或本地網路。每次只改一項，修改後重試相同命令，並記錄時間和結果。這比同時切換模式、改 DNS、增加規則及重裝用戶端更容易定位問題。
如果需要比較系統代理與 TUN，可在保留原設定記錄的前提下，先停止 TUN，再明確為單一工具設定代理進行測試。測試結束後恢復原狀，確認系統代理、路由與 Shell 變數沒有互相覆蓋。需要查看用戶端選擇與設定入口時，可前往用戶端比較；新手設定流程可參考設定教程。
常見問題
開啟 TUN 後，Git 還需要設定 HTTP_PROXY 嗎？
通常不必，但取決於核心是否實際接管 Git 所在程序的流量。先查看連線記錄；如果 Git 已進入核心且規則命中，移除重複的代理環境變數可避免多重轉送。若 Git 使用 SSH remote，也要另外確認 SSH 流量的處理方式。
為什麼瀏覽器能上網，npm 卻顯示逾時？
瀏覽器可能遵循系統代理，而 npm 使用不同的 Registry、DNS 或代理設定。先執行 npm config get registry，並在核心連線記錄中確認實際請求的網域與命中策略；不要只因瀏覽器可用，就判定 TUN 已接管所有工具。
Docker pull 失敗，是否代表 TUN 沒有生效？
不一定。Docker daemon 通常是獨立背景服務，且映像檔可能透過多個 Registry 或 CDN 網域下載。確認 daemon 的連線是否出現在核心記錄，再檢查實際目標網域；若問題發生在容器內，還要分開檢查容器 DNS 與網路設定。
可以一直使用全域模式解決開發工具連線嗎？
全域模式可作為短時間的交叉測試，確認是否與規則分流有關，但會讓原本應直連的內網與服務也可能經過代理。測試後建議恢復規則模式，針對實際失敗的網域補充規則，並保留已驗證的直連路徑。