TUN 模式與「系統代理」到底差在哪？
在 Clash 系家族（含以 Mihomo 為核心的現代用戶端）中，系統代理多半透過作業系統或執行環境提供的 HTTP／HTTPS 代理變數，讓「願意遵守系統代理設定」的應用程式把流量交給本機代理埠。這種做法設定快、侵入性低，卻有兩個結構性限制：第一，許多桌面程式、遊戲啟動器、或背景服務根本不讀系統代理；第二，部分流量在更底層發起，或先走自有 DNS 解析鏈路，導致你在規則裡寫得再漂亮，實際連線仍可能從旁邊溜走。
TUN 模式則改從網路堆疊較底層介入：核心會建立一個虛擬網路介面（常見稱為 tun／utun），並透過路由規則把符合條件的 IP 封包導向該介面，再由 Clash 依 rules 與 proxy-groups 做分流。用白話說，它更接近「在系統眼裡多了一張網卡」，而不是「請瀏覽器記得用 7890 埠」。因此，對於不遵守代理環境變數的軟體，TUN 往往才是讓行為與預期對齊的關鍵手段。
不過也要務實看待：TUN 不是魔法。若某程式以硬編碼方式綁定介面、使用 raw socket、或具備獨立 VPN 通道，仍可能出現例外情況。本文目標是幫你建立「可驗證」的啟用流程：知道該開哪些選項、該看哪些日誌、以及遇到斷網時如何回退，而不是把 TUN 當成百分之百無漏的口號。
為什麼會「漏流」？先釐清三條常見路徑
使用者口中的漏流，通常不是單一原因，而是解析、路由、與應用程式行為三者疊加。第一條路徑是 DNS：若客戶端沒有把 DNS 查詢納入與 TCP／UDP 相同的決策邏輯，你可能看到「網域解析已發生在某個上游」，接著實際連線卻走了另一條路，規則看起來像沒命中。第二條路徑是路由：系統預設路由、策略路由、或企業 VPN 分開隧道（split tunnel）可能讓部分子網不經過 TUN。第三條路徑則是應用程式本身忽略代理、或自行指定網路介面。
在只開系統代理的情境下，上述問題會更明顯，因為代理只影響「願意配合的那一段」。切換到 TUN 之後，核心有機會在更接近封包入口的地方攔截，但仍需搭配合理的 DNS 模式、以及避免與其他虛擬網卡／防火牆規則互相打架。接下來我們會把「啟用 TUN」拆成可檢查清單，方便你逐步對照。
若你正在同時調整規則集與 DNS，建議先閱讀本站的使用說明與文件，把 fake-ip、redir-host 等關鍵字放在同一張心智圖上，否則很容易出現「規則顯示命中，但體感仍不對」的錯覺。
TUN 在作業系統裡實際做了什麼？
觀念上，TUN 介面負責承載第三層（IP）封包。Clash 在啟用 TUN 後，會與系統協調一組位址與路由：哪些目的位址應送到虛擬介面、哪些保留本機或區網直連。核心收到封包後，再還原成連線資訊，依規則決定走哪個出站，最後把封包送回真實網路路徑。
不同用戶端會在圖形介面用不同名稱呈現同一概念，例如「TUN 模式」「虛擬網卡」「Meta Tunnel」。底層仍圍繞兩件事：介面是否成功建立，以及路由是否按預期覆蓋目標流量。若介面建立失敗，多半與權限、驅動、或其他 VPN 佔用有關；若介面存在但流量沒進來，則要往路由優先級與例外清單追查。
在 Mihomo 路線上，進階使用者還會看到與堆疊實作相關的選項（例如 system、gVisor、mixed 等概念性分類，實際可用值依核心版本與平台而異）。選型的取捨通常是效能與相容性：越貼近系統原生路徑，理論延遲越低，但對特定環境的依賴也越高；使用者空間實作則可能在奇異企業網路或舊版系統上較穩，但 CPU 開銷不同。實務上建議以「預設可連線」為第一優先，再依延遲與 CPU 佔用微調。
啟用前的檢查清單：權限、衝突與備援出口
在 Windows 與部分 Linux 環境，TUN 往往需要系統管理員或等效權限，因為修改路由屬於高權限操作。macOS 則可能出現隱私或防火牆提示，需要你在「系統設定」中允許對應程式。若你同時安裝了公司 VPN、其他廣義「加速器」、或虛擬機橋接網路，請預留心理準備：兩套方案同時改路由時，常見症狀是「能 ping 不能上網」「只有瀏覽器正常」等半套狀態。
建議在第一次開啟 TUN 前，先記錄你原本的閘道與 DNS，並確認用戶端提供一鍵關閉 TUN或緊急恢復路徑。多數圖形介面會在關閉時嘗試還原路由；若遇到異常斷線導致路由殘留，重新啟動用戶端或暫時停用虛擬介面，通常比盲目重開機更有效率。
另外，請確認你的設定檔本身沒有互相矛盾的 rules 順序：TUN 只負責把流量送進核心，若最後仍被 MATCH 到錯誤策略組，表象會像「TUN 沒用」。這也是為什麼進階使用者會習慣搭配即時連線日誌，觀察實際命中的規則與出站名稱。
設定檔中的 tun 區塊：你至少需要知道哪些鍵？
不同核心版本欄位名稱可能略有差異，但整體骨架相似：開關、堆疊、位址／遮罩、是否自動路由、以及與 DNS 劫持、fake-ip 相關的選項。下列範例僅示意結構，實際鍵名請以你所用的核心與用戶端文件為準；註解一律使用英文，方便你複製到專案範本時比對。
tun:
enable: true
stack: system
auto-route: true
strict-route: false
dns-hijack:
- any:53auto-route 這類選項的語意，是請核心協助寫入系統路由，讓流量自然進入 TUN。若你手動維護企業內網靜態路由，請特別留意是否與自動路由衝突。strict-route 則偏向更積極地收斂路徑，對某些環境可減少繞路，卻也可能在複雜網路下需要額外例外。調整時請採小步驗證，每次只改一個參數，並保留可回滾的備份檔。
若你使用訂閱產生的一鍵設定，tun 區塊可能被模板覆寫；此時應改用用戶端支援的覆寫檔或片段合併功能，把 TUN 相關段落與訂閱內容分離，避免每次更新訂閱就把手動調校沖掉。關於規則模組化，也可延伸閱讀本站另一篇以 rule-providers 為主題的教學，讓「路由入口」與「分流資料」各司其職。
DNS、劫持與 fake-ip：TUN 成敗的另一半戰場
只開 TUN 而不處理 DNS，就像只修好水管的進水閥卻沒檢查水表：連線可能仍依舊走意外解析結果。多數進階設定會討論是否讓 Clash 承擔本機 DNS 入口、或使用 fake-ip 模式降低部分應用的額外查詢成本。這些選項沒有絕對正解，必須與你的規則集、區域直連需求、以及是否使用 DoH／DoT 一併考量。
實務排查順序可以記成四句話：先看解析是否進核心、再看規則命中哪條、三看出站是否如預期、最後才懷疑平台特例。當你觀察到某些網站永遠直連，請同時檢查該網域在規則集中的位置，以及 DNS 回傳的位址型態；fake-ip 環境下，應用程式看到的 IP 可能與真實伺服器不同，這是設計使然，不是「壞掉」。
若你在行動裝置上使用支援 TUN 的用戶端，還要留意系統省電策略與背景網路限制；這類問題常被誤判成「TUN 不穩」，其實是作業系統在休眠時收回介面或中斷背景連線。將應用程式列入電池最佳化排除名單，往往比反覆重裝有效。
Windows、macOS 與 Linux 的實務差異
Windows 使用者最常遇到的是權限與其他網路軟體互斥：若系統已存在多張虛擬網卡，路由表的優先順序可能讓你以為 TUN 已開，實際封包卻仍走舊介面。此時可用內建或第三方工具檢視路由表，對照用戶端日誌中是否有「add route」類訊息。macOS 則要注意系統完整性保護與防火牆彈窗，首次啟用時建議完整允許，避免半開狀態。
Linux 桌面環境差異更大：NetworkManager、systemd-resolved、與手動 iptables／nft 規則都可能與 TUN 互動。若你同時使用容器或虛擬機橋接，請確認哪些介面應排除在自動路由之外。對一般使用者而言，選擇已打包好的圖形用戶端，讓它處理平台細節，通常比自行拼湊命令列來得穩定。
無論平台為何，都建議保留一份最小可連線設定：只含必要節點、簡單規則、以及保守 DNS。當進階選項導致斷網時，先切回最小設定確認基底沒問題，再逐步加回 hijack、strict-route 等選項，可節省大量猜測時間。
常見症狀與排查方向
症狀一：一開 TUN 全網斷線
優先檢查是否與其他 VPN 同時運行、路由是否形成迴環、以及出站節點本身是否可用。暫時關閉 TUN 後若立刻恢復，表示問題集中在路由或 DNS 劫持段落；可嘗試關閉 strict-route、暫停 dns-hijack 其中一項做二分法。
症狀二：瀏覽器正常，特定程式仍直連
先確認該程式是否支援代理以外的路徑，並在連線日誌中搜尋對應程序名稱或目的位址。若完全沒有日誌，代表流量未進核心；若日誌顯示命中 DIRECT，則回到規則順序與 GEOIP 類條件是否過寬。
症狀三：延遲變高或 CPU 佔用上升
嘗試調整 TUN 堆疊選型、減少大型規則集、或關閉不必要的除錯日誌級別。硬體較弱的裝置上，過度複雜的規則與頻繁 DNS 查詢會疊加成可感知卡頓。
安全與合規：把 TUN 放在正確的使用情境
TUN 能放大代理核心的能力，也代表系統網路行為更依賴你載入的設定檔與節點來源。請只使用可信來源的訂閱與規則集，並定期更新用戶端；避免在不明 Wi-Fi 環境下長期開啟來路不明的「一鍵腳本」。若你任職企業對終端網路有明確政策，請先確認是否允許自行修改路由，避免誤觸資安規範。
開源社群的價值在於透明：你可以在官方儲存庫查閱授權條款、變更紀錄與問題討論。一般使用者的安裝包取得與版本對照，仍建議以本站整理的入口為主，將「下載用戶端」與「閱讀原始碼」分開看待，較不容易在發布頁眾多檔名中迷路。完整平台列表與更新說明可參考用戶端下載頁。
總結：用 TUN 把「能進核心」變成預設，而不是例外
相較於僅依賴系統代理，TUN 模式的核心價值在於把更多類型的流量納入同一套規則與策略組，從而顯著降低「以為有開代理、其實某程式從旁直連」的落差。它不是萬靈丹，但在正確搭配 DNS、路由與規則順序的前提下，往往是進階使用者告別漏流煩惱的起點。
若你希望在一條穩定路徑內完成安裝、更新與進階開關調校，選擇介面清楚、能安全合併自訂片段、並提供可讀日誌的用戶端，通常比四處拼湊過時教學更省時間。相比其他同類工具，Clash 生態在規則表達與核心演進上持續整合社群需求，長期維護成本相對可預期。