#TUN 模式與系統代理有什麼區別:流量接管層級、相容性差異與選擇建議

系統代理的運作機制:應用層的自覺配合

系統代理本質上是作業系統提供的一組環境變數或登錄檔項目,記錄著「HTTP 流量該發到哪個位址和埠」。Clash 系列客戶端開啟系統代理後,會把這組設定指向自己監聽的 port(HTTP)或 socks-port(SOCKS5),瀏覽器、大多數帶網路設定的應用在發起請求前會讀取這些值,主動把連線建到 Clash 監聽的埠上,再由 Clash 按規則分流。

這套機制的關鍵字是「自覺」。它依賴應用主動讀取代理設定並遵守,一旦某個程式不讀取系統代理(比如舊版本的 Java 程式、部分遊戲客戶端、命令列工具預設忽略環境變數),它的流量就會直接走實體網卡出網,完全繞開 Clash 的規則判斷。這不是 Clash 的問題,而是系統代理這種接管方式本身的邊界——它只能管住「願意配合」的進程。

TUN 模式的運作機制:網路層的虛擬網卡

TUN 模式的思路完全不同,它不在應用層做說服工作,而是直接在作業系統的網路層掛一張虛擬網路介面(virtual network interface)。啟用後,Clash Meta(mihomo 核心)會建立一張名為 utun(macOS)、Meta 或類似命名(Windows/Linux)的虛擬網卡,並透過修改系統路由表,把預設路由或部分子網的流量指向這張虛擬網卡。

此後,作業系統層面看到的不是「某個應用要不要用代理」,而是「這個資料包該走哪張網卡出去」——這是核心路由層的決策,和應用是否感知代理無關。資料包進入虛擬網卡後,由 mihomo 核心在使用者態解析、還原成 TCP/UDP 連線,再按代理規則處理轉發。因為決策點下沉到了網路層,幾乎所有進程產生的流量都會被這張虛擬網卡截獲,不存在「某個程式不聽話」的問題。

# config.yaml 中開啟 TUN 模式的基礎欄位
tun:
  enable: true
  stack: system   # 可選 system / gvisor / mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

其中 stack 決定虛擬網卡的實現方式:system 使用系統原生 TUN/TAP 驅動,效能較好但對系統版本有一定要求;gvisor 是使用者態網路堆疊,相容性更好但吞吐略低;mixed 是較新核心提供的折中方案。auto-route 負責自動寫入路由表,關閉後需要手動設定路由,建議非進階使用者保持開啟。

兩者的覆蓋範圍與相容性差異

覆蓋範圍上,系統代理只能管住主動讀取代理設定的進程,典型是瀏覽器、大多數桌面應用的網路請求;而系統級服務、部分背景進程、命令列工具、遊戲客戶端的網路模組往往不讀取系統代理,流量會直接繞過。TUN 模式因為運作在路由層,理論上能接管所有基於 IP 協定堆疊的流量,包括那些「不認代理」的進程。

但覆蓋範圍廣不等於沒有相容性代價,以下幾類場景需要留意:

• 虛擬機與容器網路:如果虛擬機使用 NAT 或橋接網路,其流量路徑可能與主機的 TUN 路由表產生衝突,導致虛擬機斷網或走錯路徑,通常需要在 route-exclude-address 中把虛擬機子網排除。
• 本地區域網路存取:開啟 TUN 後存取區域網路內的印表機、NAS、路由器管理頁面時,如果沒有正確設定直連規則或本地網段例外,流量可能被誤判成需要代理轉發,造成存取失敗。
• VPN 軟體疊加使用:兩套虛擬網卡同時爭奪預設路由,容易出現互相覆蓋、斷線的情況,一般不建議同時開啟系統級 VPN 和 Clash 的 TUN 模式。
• 需要管理員/系統權限:建立虛擬網卡、修改路由表都屬於系統級操作,TUN 模式在 Windows 上需要管理員權限執行,在 macOS/Linux 上通常需要 sudo 或對應的權限授予流程,這一點和系統代理「點個開關就好」不同。

相對地,系統代理不涉及路由表和虛擬網卡,基本不會和虛擬機、其他 VPN 衝突,權限要求也低,這是它在相容性上的優勢——問題只出在覆蓋不全。

效能開銷與穩定性對比

系統代理的轉發路徑比較短:應用直連 Clash 監聽的埠,Clash 判斷規則後轉發到目標伺服器,中間只經過一次使用者態代理邏輯,開銷主要來自規則比對和加解密,對大多數頻寬場景影響很小。

TUN 模式多了一道「網路層截獲 + 協定還原」的工序:資料包先進虛擬網卡,核心網路堆疊處理後交給 mihomo 使用者態程式解析成完整的 TCP/UDP 連線,再走一遍代理規則和轉發邏輯。這個過程比系統代理多了一次核心態與使用者態之間的資料拷貝,理論上會帶來輕微的延遲和 CPU 佔用增加,具體幅度和 stack 的選擇有關——system 堆疊通常比 gvisor 更接近系統代理的效能水準。對一般網頁瀏覽、影片觀看等場景,這點差異基本感知不到;但在大量小包、高並發連線的場景(比如某些下載工具、區塊鏈節點同步),差異會更明顯一些。

穩定性方面,系統代理出問題通常表現為「某個應用沒走代理」,影響範圍局限、易定位;TUN 模式出問題則可能表現為路由表異常導致的大範圍斷網,恢復手段是關閉 TUN 或重啟網路服務,排查成本相對更高,這也是為什麼多數客戶端把 TUN 模式放在「進階設定」裡,而不是預設開啟。

命令列工具、遊戲與 UWP 應用場景下怎麼選

不同應用類型對代理設定的支援程度差異很大,以下是幾類典型場景的建議。

命令列工具(curl、git、套件管理器等)

大多數命令列工具預設不讀取系統代理,而是依賴明確設定的環境變數,例如:

export http_proxy="http://127.0.0.1:7890"
export https_proxy="http://127.0.0.1:7890"

如果嫌逐個設定環境變數繁瑣,或者工具本身連環境變數都不認(部分 Go/Rust 編譯的靜態工具),開啟 TUN 模式是更省心的做法——不需要為每個工具單獨設定,虛擬網卡會統一接管。

遊戲客戶端

不少遊戲的啟動器和遊戲本體是分離的兩個進程,且大量使用 UDP 傳輸(尤其是對戰類遊戲的即時同步資料),系統代理對 UDP 的支援有限,往往只能代理到啟動器登入環節,進入對局後的流量仍然走實體網卡。如果需要讓遊戲對局流量也按規則分流(比如接入某個專線節點降低延遲),TUN 模式基本是唯一可靠的路徑,因為它在網路層統一接管 TCP 和 UDP。需要注意提前在規則裡為遊戲加速節點單獨分組,避免遊戲流量被影片、下載等大流量規則組搶佔頻寬。

UWP 應用(Windows 市集應用)

Windows 平台的 UWP 應用執行在獨立的網路隔離容器(Network Isolation)裡,預設情況下既不讀取系統代理,也不在 TUN 模式的常規路由捕獲範圍內,這是 Windows 系統設計導致的沙盒隔離,不是 Clash 客戶端的疏漏。要讓 UWP 應用(例如部分市集版本的瀏覽器、聊天工具)也走代理,通常需要額外執行 CheckNetIsolation.exe 相關命令為該應用放行網路隔離,或者在客戶端裡找到「允許存取 UWP 應用回送/網路」一類的開關,這一步系統代理和 TUN 模式都需要單獨處理,不存在哪種模式天然相容。

該怎麼選:一個簡單的判斷思路

如果日常使用集中在瀏覽器和一般桌面應用,系統代理已經能覆蓋絕大部分場景,設定簡單、出問題好排查,是更省心的預設選項。如果遇到以下任意一種情況,再考慮切換到 TUN 模式:命令列工具頻繁需要代理卻不想逐個設定環境變數;遊戲、語音通話等 UDP 流量需要走規則分流;某個進程明確不讀取系統代理導致規則形同虛設。切換前建議先確認自己的虛擬機、其他 VPN 軟體是否會和虛擬網卡產生路由衝突,並檢查客戶端裡的區域網路直連規則是否已經正確設定,避免開啟後出現內網裝置存取異常的情況。