為什麼終端機常常「不理會」系統代理？
許多使用者在瀏覽器裡已經能順利開啟 GitHub、npm registry，可是一回到終端機執行 git clone、npm install 或 curl https://...，連線卻逾時或直接被重置。最常見的原因並不是「網路完全不通」，而是指令列程式根本沒有走你以為已經開好的那條代理路徑。
在 Windows 與 macOS 上，透過 Clash 客戶端開啟的「系統代理」，多半是把 HTTP／HTTPS 代理位址寫入系統設定，或通知支援系統 Proxy API 的應用程式。這對 Chrome、Edge、Safari 等瀏覽器通常有效；但許多終端機程式有下列特性：
- 預設不讀取系統代理：除非另外指定，否則會直接對目標 IP／網域發起連線。
- 只看環境變數：例如
HTTP_PROXY、HTTPS_PROXY、ALL_PROXY；若 shell 沒繼承到這些變數，就不會走代理。 - 自行解析 DNS：在未走代理通道的情況下，DNS 查詢可能仍經由本機預設 DNS，與代理規則不一致時會出現「解析得到 IP，但連線行為不如預期」的現象。
- 不同子指令行為不同：例如 Git 對 HTTP／SSH 傳輸、npm 對 registry 與 tarball 的下載路徑，各自有不同的設定入口。
也因此，僅依賴「開系統代理」往往無法一次性解決所有終端機情境；要讓指令列工具穩定且一致地走代理，要麼為每個工具單獨設定代理與 DNS，要麼在更底層用 TUN 模式統一接管流量。接下來我們先澄清 TUN 與傳統代理埠的差異，再落到 git、npm、curl 的實務設定。
TUN 模式是什麼？與「監聽一個本機埠」哪裡不同？
一般所謂的「開代理」，多半是在本機開一個 127.0.0.1:7890 之類的 SOCKS5 或 HTTP 代理埠，應用程式必須主動把流量送進這個埠，中介軟體才能依規則轉發到節點。這種模式仰賴應用程式支援：瀏覽器可以設 PAC；但有些程式完全不支援 SOCKS，或只在特定 API 才會讀取代理設定。
TUN（網路隧道）模式則從另一個角度解決問題：由 Clash（或 Mihomo 核心）在作業系統內建立一個虛擬網路介面，並配合路由表（routing table），把符合條件的 IP 封包導向這張虛擬網卡。對大部分應用程式來說，這條路徑像是「一般對外連線」，因此在許多情境下無需在每個程式裡重複設定代理，終端機裡執行的二進位檔也能被納入同一套路由與規則引擎。
可以這樣對照理解：
- 本機代理埠：應用程式要「懂得」把連線交給
127.0.0.1；適合瀏覽器、部分支援良好的 CLI。 - TUN 模式：作業系統依路由把封包交給 Clash；對應用程式較「透明」，較能涵蓋未正確繼承環境變數的工具。
需要管理員／驅動授權是正常的：啟用虛擬網卡會改變系統路由，Windows 可能出現防火牆提示，macOS 會要求輸入密碼授權_helper；若一律拒絕，TUN 無法正常建立。
TUN、系統代理與 Mixed Port 要如何搭配？
多數現代 Clash 客戶端（例如 Clash Verge Rev）會同時提供：
- 系統代理（System Proxy）：快速讓瀏覽器等支援系統設定的程式走本機埠。
- Mixed Port（HTTP + SOCKS 同一埠）：方便把
HTTP_PROXY與ALL_PROXY指到同一個位址。 - TUN 模式：補上「不吃系統代理」的程式與分散的 DNS 行為。
實務上常見的穩定組合是：平常開著規則分流與 DNS；需要終端機全面遵循分流時啟用 TUN，並保留 Mixed Port 給明確支援代理環境變數的工具（或除錯時手動指定）。若僅開系統代理而不開 TUN，又未為每個 CLI 設定環境變數，就很容易出現「瀏覽器沒問題、終端機頻繁逾時」的分裂體驗。
啟用 TUN：從設定檔到客戶端按鈕
具體按鈕名稱依客戶端而異，但後端通常會在設定檔反映為 tun 相關區塊。以下是一段典型的 Mihomo／Clash Meta 風格骨架（實際鍵名請以你所用的核心版本文件為準）：
tun:
enable: true
stack: system
auto-route: true
auto-detect-interface: true
# dns-hijack may be needed on some setups (check core docs)各平台值得留意：
- macOS：首次啟用常需同意系統延伸功能或輸入密碼；若同時使用其他 VPN，路由可能互相覆寫，需只保留一個「會改預設路由」的服務或調整優先順序。
- Windows：部分環境需允許 Clash 通過防火牆；公司網域策略若鎖定網卡或路由，TUN 可能被擋下。
- Linux：可能需要額外套件或權限（例如
CAP_NET_ADMIN）；桌面發行版與伺服器環境差異大，建議查所用 GUI 客戶端的說明。
不要在不明狀況下同開多款全能 VPN：多個程式同時寫入預設路由，容易造成分流規則失效、區網無法存取，或 DNS 形成閉環。
git、npm、curl：在 TUN 模式下仍建議了解的細節
即使 TUN 已在大多數情境下透明轉發，下列工具的額外設定仍有價值：一方面可作為除錯手段，另一方面在暫時關閉 TUN、改用手動代理時可直接沿用。
Git：HTTP／HTTPS 與 SSH 是分開的兩條路
許多開發者使用 https://github.com/... 形式的遠端網址，此時 Git 走的是 HTTPS 堆疊，會受系統或 Git 自身代理設定影響；若改用 [email protected]:... 的 SSH URL，則連線由 SSH 客戶端負責，HTTP 代理設定不一定會生效，需要為 SSH 設定 ProxyCommand 或改用 HTTPS。
在啟用 TUN、且規則允許連線 GitHub 的前提下，通常 HTTPS clone／pull 會一併被接管；若你仍想明確指定 Git 的 HTTP 代理（例如在沒有 TUN 的環境），可使用：
# Git uses HTTP proxy for HTTPS remotes
git config --global http.proxy http://127.0.0.1:7890
git config --global https.proxy http://127.0.0.1:7890取消時將對應設定改為空值或刪除該鍵即可。
npm／pnpm／Yarn：registry、 tarball 與 corporate 網路
套件管理器會向 registry 發起大量 HTTPS 請求；在嚴格網路環境下，常見問題是解析到了中國大陸鏡像或公司快取，與你預期的代理路徑不一致。啟用 TUN 後，請確認規則中對 registry 網域的走向是否符合預期。
另外仍可備援設定（埠號請換成你的 Mixed Port）：
npm config set proxy http://127.0.0.1:7890
npm config set https-proxy http://127.0.0.1:7890若使用私有 registry 或內網 Verdaccio，記得在 Clash 規則中讓內網位址直連，避免被誤送到境外節點。
curl：透明代理與手動 --proxy
curl 會優先讀取環境變數；在未設定時通常直接連線。啟用 TUN 後，可用下列指令快速確認出口 IP 是否已經過代理節點（範例服務請換成你信任的測試站）：
curl -fsSL https://ifconfig.me/ip若關閉 TUN 改用手動代理，可使用：
curl -x socks5h://127.0.0.1:7891 https://example.com/其中 socks5h 代表把網域名稱解析也交給代理端處理，在規避特定 DNS 污染情境時特別有用。
DNS、fake-ip 與「以為走了代理其實沒有」
TUN 能接管 IP 封包路由，但若 DNS 仍在應用程式或系統層被套用到錯誤的伺服器，仍可能出現解析結果與規則預期不符的情況。多在 Mihomo 核心會見到 dns 區塊與 enhanced-mode（例如 fake-ip）相關選項；設計目標是讓連線決策與規則引擎一致。
實務建議：
- 先確認 Clash 日誌中該網域命中哪條規則，而不是只看瀏覽器是否能開啟頁面。
- 調整 DNS 後清除本機 DNS 快取再測（各 OS 指令不同）。
- 避免同一時間在多個地方設定互相矛盾的 DNS（系統、路由器、第三方加速器）。
除錯時暫時提高 log-level：在設定檔將 log-level 調為 debug，觀察連線與 DNS 相關日誌，排查完畢後務必改回 info 或 warning 以免日誌量過大。
常見問題
開 TUN 後區網印表機或 NAS 連不上？
多半是路由被改寫後，區網流量也被錯誤導向代理。請在規則最前面保留對 192.168.0.0/16、10.0.0.0/8 等私人位址的 DIRECT 規則，並檢查是否有過於寬鬆的 MATCH 將所有流量送進代理。
為什麼 SSH git 仍然卡住？
SSH 連線不走 Git 的 http.proxy；需在 ~/.ssh/config 為特定主機設定 ProxyCommand，或改用 HTTPS 遠端並確保 HTTPS 走代理／TUN。
效能會不會變差？
TUN 會多一層封包處理，但在現代硬體上通常遠小於跨國延遲本身；若感覺明顯變慢，優先檢查節點品質、規則是否讓「該直連的網站」誤走代理，以及 DNS 是否繞路。
為什麼仍推薦使用持續維護的 Clash 客戶端？
市面上也有不少「一鍵全域代理」類工具，但常見短板包括：規則粒度不足（僅能全域代理而無法細緻分流）、核心停更後無法跟上新式協定與 TUN 堆疊、或介面難以除錯導致 DNS／路由問題無法追蹤。相對而言，基於Mihomo／Meta 核心並持續更新的 Clash 客戶端，通常具備完整的規則引擎、Rule Provider、現代協定與視覺化連線面板；你已為終端機問題苦惱時，這種「既能開 TUN、又能看清楚每一條連線命中規則」的能力，往往正是省去盲目試錯的關鍵。
若你希望同一套分流規則同時涵蓋瀏覽器與 git、npm、curl，又不想在每個 shell 裡輪流匯出環境變數，搭配TUN 模式與清楚的 DNS 設定會是比較省心的一條路；本站提供各平台 Clash 客戶端下載，可依裝置直接取得最新版本：