為什麼開了代理，Git 和遊戲還是「不走」？
許多人在瀏覽器裡已能順利翻牆或加速，但一回到終端機執行 git clone、npm install，或是啟動某款線上遊戲用戶端，就好像完全沒開代理一樣。這通常不是 Clash「壞掉」，而是流量根本沒有經過代理那條路。
常見的「系統代理」做法，本質上是告訴會主動讀取系統 Proxy 設定的程式：請把 HTTP／HTTPS 請求轉到本機的代理埠。Chrome、Edge 這類瀏覽器多半會跟隨；但不少桌面程式、遊戲引擎、以及 Git／npm 這類工具，預設不會去讀作業系統裡那組 Proxy，而是直接對外建立連線。於是你會看到兩個世界：瀏覽器很快，終端機與遊戲卻依然卡在外網或公司防火牆的另一側。
TUN 模式想解決的，正是「程式不聽話」這件事。它透過在系統裡建立一張虛擬網卡（TUN／TAP 類型介面），搭配路由表或策略路由，讓符合條件的 IP 封包先被交給 Clash，再由 Clash 依你的 YAML 規則決定要直連、走哪個策略群組、或送到哪一個節點。如此一來，只要封包有進到那條管線，就不依賴程式是否支援 HTTP 代理了。
TUN 和「系統代理」差在哪裡？用哪一種比較好？
用一句話區分：系統代理是「應用層自願報到」，而 TUN 更接近「網路層統一收發」。系統代理通常只涵蓋瀏覽器能理解的 HTTP／HTTPS 流量走法；若程式使用自訂協定、純 TCP／UDP、或自己實作了 DNS 解析流程，就可能完全繞過。
TUN 則是在封包尚未離開本機路由決策前就被攔下來，因此對 Git（SSH 與 HTTPS）、npm／pnpm／yarn 的下載、Docker 映像拉取、以及多數遊戲用戶端的 UDP／TCP 連線，都能在同一套規則下處理。缺點是：權限要求更高（常見為管理員或安裝網路延伸）、與本機其他 VPN／虛擬網卡軟體更容易衝突，設定錯誤時也比較容易出現「全網斷線」或「流量迴圈」。
實務上常見做法是：日常瀏覽以系統代理為主，需要命令列或遊戲時再開 TUN；或反過來，長期開 TUN，再把區網、本機服務、公司內網網段寫成規則最前段的直連。沒有絕對正解，只有你的裝置上誰與誰相容、以及你能接受的除錯成本。
技術觀念：虛擬網卡、路由、DNS 與規則的協作
當你在圖形用戶端按下「TUN」或「虛擬網卡模式」時，背後通常會發生幾件事：建立一張虛擬介面、為它指定一個閘道或路由規則、由核心把符合條件的封包轉給 Clash 使用者空間程式處理。不同作業系統與不同用戶端實作細節不同，但「接管路由決策」這個目標是一致的。
另一個常被忽略、卻會直接影響 Git 與遊戲體驗的環節是 DNS。若規則使用 fake-ip 這類機制，本機程式拿到的可能是「假的」IP，實際連線仍由 Clash 還原域名並分流。多數情況下這能讓規則更精準；但若你同時跑了其他 DNS 攔截工具，或遊戲用戶端強制使用自己的 DNS，就可能出現「解析得到、連線卻異常」的現象。遇到這類問題時，建議先釐清：DNS 是誰在回答、規則是依域名還是依 IP 命中。
若你使用 Clash Meta（Mihomo）核心，還可能看到與 sniffer（嗅探）相關的選項，用於在 TLS／QUIC 等情境下還原域名，讓規則有機會在「只知道 IP」時仍按域名分流。這對某些遊戲與大型網站流量有幫助，但也會增加 CPU 與延遲開銷，建議在確實遇到「全變成最後一條 MATCH」時再逐步開啟並觀察。
Windows 與 macOS：啟用前你應該知道的事
在 Windows 上，TUN 幾乎一定牽涉到驅動程式與使用者帳戶控制（UAC）授權。第一次啟用時，請從可信來源安裝用戶端，並允許網路介面建立。若你同時使用公司 VPN，兩邊可能爭奪預設路由，這時需要更謹慎的例外規則，把內網網段留在直連。若你不確定圖形介面各開關意義，可先對照本站 Clash Verge Rev Windows 教學 裡關於系統代理與 TUN 的章節，再回來調整自己的 YAML。
在 macOS 上，部分用戶端會以「網路延伸（Network Extension）」或類似機制實作 TUN。你可能需要在「隱私權與安全性」裡允許系統延伸，並在首次啟用時輸入密碼。Apple 平台對沙箱與簽章要求較嚴格，若你混用多款代理或抓包工具，請預留時間做「只開一種」的對照測試，較容易定位衝突來源。
讓 Git、npm 這類工具穩定走代理的實務做法
當 TUN 正常運作時，理論上終端機程式會像一般應用一樣走系統路由，因此 git、npm、curl 等命令不必再手動堆滿 HTTP_PROXY 環境變數。這能顯著降低「只在某一個終端機分頁生效」的混亂。
不過仍有幾個實務細節值得記住。第一，SSH 連線與 HTTPS 連線走的是不同堆疊；若你使用 [email protected]:... 這種 SSH URL，規則要能涵蓋對應埠與目標 IP／域名。第二，npm 可能會讀取自己的 proxy 設定檔；若你過去為了救火曾寫入全域設定，建議用 npm config list 檢查是否還有殘留，避免「變數一套、TUN 一套」互相打架。第三，公司內部的 Registry 鏡像通常應直連，請在規則前段加上域名或 IP 段，避免無謂繞路。
若你暫時不想開 TUN，但仍希望終端機走代理，也可以保留「環境變數／Git 的 http.proxy」當備援方案；只是維護成本會比較高。長期來看，讓路由與規則集中在 Clash，通常比每個工具各自設定來得一致。若你正在從舊版用戶端遷移，也可參考 Clash Meta 升級指南，把訂閱與 DNS 段落一併整理乾淨，TUN 會更好調。
遊戲用戶端與 UDP：為什麼 TUN 常常是第一選擇
許多線上遊戲依賴 UDP 傳輸語音、對戰同步或反作弊心跳。傳統 HTTP 代理埠通常無法完整承載這類流量型態；即使能連上登入伺服器，也可能在進房後頻繁斷線或語音異常。TUN 在「把整張網卡流量交給 Clash 決策」這件事上，通常比單純系統代理更完整，因為它不必假設「所有程式都會乖乖講 HTTP」。
另一方面，遊戲反作弊與部分啟動器會偵測虛擬網卡或注入環境，可能與 TUN 共存性不佳。若你遇到啟動即閃退、或提示網路環境異常，請先查官方文件是否允許與 VPN／虛擬網卡並存，並避免同時開啟多款會改路由的軟體。對一般玩家而言，能開不代表合規，請務必尊重遊戲服務條款與當地法律。
設定檔裡通常會看到什麼？（概念層級）
完整 YAML 會因核心版本與用戶端而異，本文刻意不複製一大段可能造成誤用的設定，而是提醒幾個關鍵欄位方向：與 tun 區塊相關的啟用開關、堆疊選項（例如 gVisor 與系統堆疊的取捨）、以及是否自動設定路由。另一邊，dns 區塊的 enhanced-mode、上游 DNS 選擇、是否開啟 fake-ip，會直接影響「程式看到的 IP」與規則命中方式。
規則面向上，請確認最後仍有合理的 MATCH 落點，並把區網、本機、Multicast 等保留位址放在前段直連。當你懷疑流量沒進 Clash 時，可以用用戶端內建的連線紀錄或儀表板觀察：若完全沒有命中紀錄，問題多半在路由或權限；若有命中但連線失敗，才往節點相容性（例如 UDP 被機場關閉）追查。
常見問題與排除方向
- 一開 TUN 全網斷線：優先檢查是否與其他 VPN 爭奪預設路由，或規則把關鍵 DNS 也導去無法連線的節點。
- 只有瀏覽器正常、終端機不行：若未開 TUN，多半是程式未讀系統代理；開啟 TUN 後仍不行，則檢查是否走了直連規則或本機 DNS 繞過。
- 遊戲延遲變高：可能是堆疊模式與 sniffer 帶來的額外成本，或節點對 UDP 支援不佳；請用控制變因方式一次只改一個選項。
- 特定網站 SSL 錯誤：與中間人憑證、公司防火牆、或 DNS 污染皆可能有關，請勿為了「讓規則命中」而關閉必要的安全驗證。
想更系統性理解規則與 DNS 的關係，可搭配閱讀本站整理的 Clash 說明與教學文件，把「分流邏輯」與「TUN 管線」放在同一張心智圖上思考。
結語：把 TUN 當成「交通樞紐」，而不是萬靈丹
TUN 模式的本質，是把更多類型的流量納入同一套路由與規則體系，讓 Git、npm、遊戲用戶端這類不會主動跟隨系統代理的程式，也能在可控的前提下走你指定的出口。它帶來自由度的同時，也要求使用者更理解 DNS、路由與安全邊界。
相較於到處複製環境變數或為每個工具各寫一份代理設定，活躍維護的 Clash 生態在規則表達能力、核心更新節奏與圖形用戶端整合上，通常更適合長期使用。若你準備在 Windows 或 macOS 上把 TUN 真正用進日常工作流，建議從本站下載頁取得可信的安裝來源，先以小步驗證方式開啟，再逐步加上遊戲與命令列場景；整體體驗會比四處搜尋來路不明的舊版鏡像踏實許多。→ 立即免費下載 Clash，開啟流暢上網新體驗