兩種流量接管方式的本質區別
Clash 客戶端(以及 mihomo 核心)提供兩種截然不同的流量接管方式:系統代理與 TUN 模式。二者常被當作「效果差不多的兩個開關」,但它們在作業系統層面的運作原理完全不同,這個差異直接決定了哪些流量會被代理、哪些會被漏過。
系統代理的做法是修改作業系統或瀏覽器的代理設定項,告知支援代理協定的應用程式「請把 HTTP/HTTPS 請求發到這個位址和連接埠」。這是一種應用層的約定,依賴每個程式自己去讀取並遵守這個設定。Windows 的「網路和 Internet 設定」、macOS 的「網路偏好設定」、Linux 桌面環境的代理選項,本質上都是在寫入一份可被查詢的設定,程式讀取後自行決定是否使用。
TUN 模式則完全不同,它在作業系統核心層面建立一張虛擬網路介面(virtual network interface),讓系統認為多了一張網卡。隨後 Clash 透過路由表規則或防火牆規則,把裝置上幾乎所有出站流量都導向這張虛擬網卡,再由 mihomo 核心在使用者態解析這些原始 IP 資料封包,還原成具體的連線請求後按規則轉發。這種方式作用在網路層,不依賴應用程式是否「配合」,是一種更底層的流量劫持機制。
系統代理為什麼會漏流量
系統代理的核心侷限在於它是「自願遵守」機制,而不是強制接管。這帶來幾類實際會踩到的漏流量場景。
不讀取系統代理設定的程式
大量命令列工具、背景服務和部分桌面程式不會主動查詢系統代理設定,而是直接建立 TCP 連線。常見例子包括 curl、git、ssh、部分套件管理器(如未明確設定代理的 pip、npm)、以及不少 Electron 應用程式之外的原生客戶端。這些程式發出的請求會直接繞過 Clash,走本機預設網路路徑。
UDP 流量普遍不受系統代理約束
系統代理設定本質上是為 HTTP/HTTPS 這類基於 TCP 的請求設計的,作業系統層面並沒有統一的「UDP 系統代理」概念。這意味著依賴 UDP 的應用程式——包括大量網路遊戲的即時同步流量、基於 QUIC(HTTP/3)的網頁請求、部分視訊通話軟體、DNS 查詢本身——在系統代理模式下往往完全不經過 Clash。如果代理節點本身支援 UDP 轉發(如 Shadowsocks、Trojan 部分實作),這部分能力在系統代理模式下也用不上。
遊戲客戶端的特殊性
遊戲對網路延遲極為敏感,多數遊戲引擎會直接呼叫底層 socket 介面建立連線,既不查詢系統代理,也很少支援應用層代理協定。想要讓遊戲流量走代理,幾乎必須依賴網路層的接管方式,系統代理在這類場景裡基本無效。
系統代理模式下「部分網站能存取、部分連不上」的現象,很多時候不是節點或規則問題,而是該程式本身沒有遵循系統代理設定,或使用了系統代理管不到的 UDP 通道。排查前先確認問題程式的網路實作方式,能省下不少反覆調節點的時間。
TUN 模式如何做到全域接管
TUN 模式的接管範圍明顯更廣,原理上涵蓋了系統代理遺漏的絕大多數場景,原因在於它工作在網路層而非應用層。
- 不依賴程式配合。虛擬網卡加路由表的組合,讓所有發往公網的資料封包預設經過這張虛擬介面,無論發起連線的程式是否「知道」存在代理,這一點對命令列工具和不支援代理設定的程式尤其重要。
- 原生支援 UDP。mihomo 核心在處理 TUN 流量時會解析 UDP 資料封包並按規則轉發,只要選中的代理節點本身支援 UDP over 對應協定,遊戲、語音通話、QUIC 請求都能被正常代理,不再是系統代理模式下的盲區。
- 對本機所有網路介面生效。虛擬機器、容器、部分開發環境產生的流量,只要最終經過系統預設路由,也會被 TUN 網卡截獲,涵蓋面比逐個應用程式設定代理更徹底。
需要指出的是,TUN 模式並非「零設定萬能開關」。它依賴作業系統層面的權限——在 Windows 上需要以系統管理員權限執行以建立虛擬網卡並修改路由表,在 macOS 和 Linux 上通常需要安裝核心擴充功能或使用特定網路擴充框架,並授予相應權限。部分客戶端(如 Clash Verge Rev、FlClash)在設定中提供了「服務模式」或「TUN 模式」開關,開啟前一般會有權限授權提示,這是正常流程而非異常錯誤。
兩種模式的實際差異對照
| 對比維度 | 系統代理 | TUN 模式 |
|---|---|---|
| 工作層級 | 應用層(需程式主動讀取設定) | 網路層(虛擬網卡 + 路由表) |
| 命令列工具涵蓋 | 取決於工具是否讀取代理環境變數 | 預設全部涵蓋 |
| UDP / 遊戲流量 | 普遍不支援 | 支援(取決於節點協定能力) |
| 所需權限 | 一般使用者權限即可 | 需系統管理員/root 權限或系統網路擴充授權 |
| 開啟成本 | 低,開關即用 | 較高,涉及首次權限設定 |
| 與本機網路工具的相容性 | 基本無衝突 | 可能與部分虛擬機器網路、VPN 客戶端產生路由衝突 |
如何選擇:場景導向的判斷標準
沒有絕對更優的一方,選擇應該基於實際使用場景。以下是幾種典型判斷路徑。
只是日常網頁瀏覽、辦公軟體存取外部服務
系統代理已經足夠。瀏覽器和絕大多數辦公類客戶端都會遵循系統代理設定,不需要引入 TUN 模式帶來的額外權限設定和潛在路由衝突風險。這也是多數客戶端預設給出的初始模式。
需要在終端機裡使用 git、curl、套件管理器等工具
優先考慮 TUN 模式,或者為這些工具單獨設定代理環境變數(如設定 HTTP_PROXY/HTTPS_PROXY 環境變數指向 Clash 的混合連接埠)。後者更輕量,但需要逐個工具設定,不如 TUN 模式一次性解決。
玩需要連接海外伺服器的網路遊戲
基本只能依賴 TUN 模式。遊戲流量以 UDP 為主且不讀取系統代理設定,系統代理模式下幾乎不會對遊戲連線產生任何效果,這也是社群裡「開了代理遊戲還是連不上」的常見原因之一。
公司電腦或對系統權限變更有顧慮的環境
建議使用系統代理。TUN 模式需要較高的系統權限並會修改路由表,在受管控的辦公裝置上開啟前應確認是否符合所在單位的裝置使用規範。
主流客戶端(Clash Verge Rev、FlClash、Clash Plus 等)都支援在設定介面裡直接切換系統代理與 TUN 模式,不需要手動改動設定檔欄位。首次開啟 TUN 模式時按提示完成一次性的權限授權即可,後續切換只是一個開關操作。
關於混合使用的幾點說明
部分使用者會同時開啟系統代理和 TUN 模式,理論上不衝突,但實際意義有限——一旦 TUN 模式生效,幾乎所有流量已經被路由表導向虛擬網卡,系統代理設定基本不會再被觸發,同時開啟更多是心理上的「雙重保險」,不帶來額外涵蓋範圍。
另外需要注意,TUN 模式與某些 VPN 客戶端、虛擬機器桌面軟體的網路介面卡可能存在路由表爭搶的情況,如果發現開啟 TUN 模式後虛擬機器網路異常或另一個 VPN 連線失效,通常是路由優先級衝突,可以在設定中調整 TUN 的路由躍點數(metric)或暫時關閉衝突的一方定位問題,而不必懷疑 Clash 本身出錯。
無論選擇哪種模式,策略群組、代理節點與分流規則的設定邏輯是共通的——TUN 模式只是改變了「流量怎麼被送到 Clash 手上」,之後走規則判斷、選節點、轉發出去的處理鏈路和系統代理模式完全一致。理解這一點後,兩種模式之間的切換只是接管方式的選擇,不涉及重新學習一套規則體系。