Clash TUN 模式原理詳解:虛擬網卡如何接管全局流量與開啟方法

NT-02.1系統代理為什麼「管不全」

Clash 預設的運作方式是系統代理(System Proxy):客戶端在系統網路設定裡寫入 HTTP/HTTPS 代理位址,作業系統把這個位址通知給應用程式,應用程式再決定是否遵循。這個「遵循」是關鍵——系統代理本質上只是一份建議,不是強制轉發。絕大多數圖形介面瀏覽器、常見通訊軟體會讀取系統代理設定並照做,但命令列工具(`curl`、`git`、`ping`)、部分遊戲、老舊客戶端,以及一些 Android/iOS 應用往往會繞過系統代理設定,直接用系統底層網路介面發送封包。

這就帶來一個常見現象:瀏覽器裡代理測速正常,能連上目標網站,但終端機裡 `curl` 同一個位址卻直接逾時;或者某個應用在設定裡勾選了「使用系統代理」,實際抓封包卻發現流量根本沒有經過代理埠。這不是設定錯誤,而是系統代理機制本身的覆蓋範圍有限——它只能覆蓋「願意讀取並遵循」這條設定的行程。

TUN 模式解決的正是這個覆蓋範圍問題。它不再依賴應用程式「自願」讀取代理設定,而是在作業系統網路堆疊更底層的位置建立一張虛擬網卡,把系統路由表指向這張虛擬網卡,從而讓幾乎所有出站流量都無法繞開。

NT-02.2虛擬網卡如何接管流量

TUN(Tunnel,隧道裝置)是作業系統提供的一種虛擬網路介面類型,和實體網卡、Wi-Fi 網卡一樣會出現在系統的網路介面清單裡,擁有自己的 IP 位址,但它背後沒有真實的實體連線,收發的封包會直接交給建立它的使用者態程式處理。Clash Meta(mihomo 核心)開啟 TUN 模式後,會在系統裡建立這樣一張虛擬網卡,並調整系統路由表,把預設路由或指定網段的流量導向這張虛擬網卡。

此後,應用程式發出的 IP 封包,不管它是否「知道」有代理這回事,都會先經過系統路由判斷,被送到 TUN 虛擬網卡。mihomo 核心在使用者態讀取這些原始封包,還原出目標位址與協定資訊,依規則集比對對應的策略群組,再透過真實網路介面轉發給選中的節點。回傳封包按原路返回,再由 TUN 網卡交還給發出請求的行程。整個過程對應用程式而言是透明的——它以為自己在直接與目標伺服器通訊,實際上每一個封包都經過了核心的規則判定。

這也解釋了為什麼 TUN 模式常被稱作「全局透明代理」:它運作在網路層,而系統代理運作在應用層協定(HTTP/SOCKS)之上,層級更低意味著覆蓋面更廣,但也意味著排查問題時思路要切換——不再是看「這個應用有沒有代理選項」,而是看「這台裝置的流量有沒有被正確路由」。

NT-02.3開啟前要理清的三個設定項

TUN 模式不是一個開關就搞定,設定檔裡通常涉及以下幾項,理解含義能省下後續大量排查時間。

1. enable:TUN 功能總開關,布林值。只有開啟這一項,虛擬網卡才會被建立。
2. stack:選擇使用者態網路堆疊的實作方式,常見取值有 system、gvisor、mixed。不同核心版本支援的可選值不同,一般優先用官方文件推薦的預設值,遇到相容性問題再切換比較。
3. dns-hijack:是否在 TUN 層劫持 DNS 查詢請求,通常寫作監聽位址加埠號(如 any:53)。這一項和下文的 DNS 處理直接相關,設定不當會導致網域名稱解析異常或分流規則失效。

此外,TUN 模式下的分流判斷仍然依賴規則集,和系統代理模式共用同一份 rules 設定,差別只在「流量怎麼被送進核心」,而不是「核心怎麼分流」。也就是說,開啟 TUN 不會讓原有規則失效,但可能暴露出規則裡此前沒被系統代理模式覆蓋到的流量。

NT-02.4各平台開啟步驟

不同客戶端的介面入口不同,但底層都是呼叫 mihomo 核心的 TUN 參數,思路一致。

Windows

1. 確認使用的客戶端核心為 Clash Meta / mihomo(部分基於舊版 Clash 核心的客戶端不支援 TUN)。
2. 在客戶端設定裡找到「TUN 模式」或「Tun Mode」開關,首次開啟通常會彈出系統管理員權限申請,需允許。
3. 若客戶端以非系統管理員身分啟動導致開關無效,需以「以系統管理員身分執行」重新啟動客戶端。
4. 開啟後可在系統「網路連線」清單裡看到新增的虛擬網卡裝置,名稱通常包含 Mihomo 或 Meta 字樣。

macOS

1. 在客戶端設定裡開啟 TUN 模式,系統會彈出「網路擴充功能」或「系統延伸功能」授權提示。
2. 前往「系統設定 → 隱私權與安全性」或「系統設定 → 網路 → VPN 與過濾器」,手動允許該延伸功能。macOS 版本不同,彈出視窗的位置略有差異。
3. 授權完成後重新開啟 TUN 開關;若客戶端安裝時已處理過網路延伸功能權限,這一步通常可以跳過。

Android

1. Android 上 TUN 模式對應系統的 VPN 服務介面,開啟時會彈出「連線要求」式的系統授權對話框,點選允許即可。
2. 授權後狀態列會常駐一個 VPN 圖示,這是系統層級的提示,不代表異常。
3. 若同時安裝了其他 VPN 類應用,注意系統通常只允許一個 VPN 服務處於啟用狀態,兩者會互相取代。

Linux

1. 建立 TUN 裝置需要 CAP_NET_ADMIN 權限,圖形介面客戶端通常需要以 sudo 或授權方式啟動核心行程。
2. 以命令列執行 mihomo 核心時,若未加權限直接啟動,日誌會回報建立 TUN 裝置失敗,需檢查啟動方式。
3. 部分發行版預設啟用了防火牆(如 ufw、firewalld),需確認沒有額外規則擋住虛擬網卡的轉發。

NT-02.5開啟後常見問題排查

TUN 模式引入了新的路由層,以下幾類問題出現頻率較高。

• 開啟後完全無法上網:多數是路由表被完全接管,而規則裡存在設定錯誤或核心行程異常退出,導致虛擬網卡「佔了路由卻沒轉發」。可先關閉 TUN 恢復系統代理驗證基礎連線,再單獨排查 TUN 設定區塊。
• 部分網段無法連上區域網路裝置:TUN 模式預設接管全部路由後,存取區域網路內的印表機、NAS 等裝置可能受影響。需要在規則裡為區域網路網段(如 192.168.0.0/16、10.0.0.0/8)設定直連(DIRECT)策略,排除在代理路由之外。
• 與其他 VPN 軟體衝突:同一台裝置上如果還執行著企業 VPN 或其他基於虛擬網卡的工具,兩者可能爭搶預設路由,表現為間歇性斷線或路由跳變,建議同一時間只保留一個虛擬網卡類工具處於啟用狀態。
• DNS 解析異常:未同步設定 dns-hijack 和 fake-ip 時,網域名稱解析可能仍走本機原有 DNS,導致按網域比對的分流規則不生效,表現為「能上網但分流不對」。

NT-02.6什麼情況適合用 TUN,什麼情況不必

TUN 模式不是「越全局越好」的選項,是否開啟取決於實際需求。

• 需要讓命令列工具、開發環境、遊戲客戶端等非瀏覽器程式走代理時,TUN 是目前最可靠的方式。
• 日常僅使用瀏覽器和常見通訊軟體,且這些軟體都能正確讀取系統代理時,繼續用系統代理模式更省心,出問題時排查起來也更快。
• 在企業辦公網路、已有 VPN 客戶端常駐的裝置上,謹慎開啟 TUN,先確認不會與既有網路策略衝突。
• 行動裝置對電量與穩定性有一定顧慮時,可先在桌面端驗證規則集是否設定妥當,再決定是否在手機上長期開啟。

總體而言,TUN 模式解決的是「覆蓋面」問題,系統代理解決的是「夠用就好」的日常場景。理解兩者在網路堆疊層級上的差異,遇到「某個應用沒走代理」的問題時,就能快速判斷該切到哪種模式,而不是反覆重啟客戶端試錯。