TUN 模式和系統代理有什麼區別:兩種流量接管機制的運作原理對比

兩種機制的本質區別

Clash 用戶端提供兩種讓流量走代理的方式:系統代理(System Proxy)和 TUN 模式。很多人把它們當成「哪個更好用」的二選一開關,但實際上兩者運作在完全不同的層級,解決的是不同的問題。理解這個層級差異,才能明白為什麼某些應用換了代理設定也不生效,而某些命令列工具怎麼設都連不上。

系統代理是作業系統提供的一套設定介面,本質上只是往系統或瀏覽器寫入一條「HTTP/HTTPS 代理伺服器位址」的紀錄。它運作在應用層:哪個程式願意讀取這條設定、願意按這個位址轉發請求,流量才會經過代理;不讀取這條設定的程式,流量照常走原本的網路路徑,和代理毫無關係。

TUN 模式則完全不同。它由用戶端在系統裡建立一塊虛擬網路卡(Virtual Network Interface),並透過修改系統路由表,把裝置上大部分甚至全部的出站流量都先送到這塊虛擬網路卡,再交給 Clash 核心處理。這個過程發生在網路層,不依賴任何應用主動配合——只要資料封包要出網,就會經過虛擬網路卡,不管上層是什麼程式、用了什麼協定。

系統代理的運作路徑與限制

系統代理的實現路徑可以拆成三步:用戶端啟動 HTTP/SOCKS 混合連接埠(Clash 裡預設的 mixed-port 常見值是 7890)、用戶端把這個連接埠寫入系統或瀏覽器的代理設定項、應用發起網路請求時查詢該設定並把請求轉發到這個連接埠。整條鏈路的關鍵在第三步——轉發這一步是「應用主動配合」完成的,不是系統強制的。

大多數圖形介面瀏覽器和常見桌面應用都會規範地讀取系統代理設定,所以系統代理模式覆蓋日常網頁瀏覽、聊天工具、大部分桌面軟體已經足夠。但它有幾個明確的短板:

• 不遵循系統代理設定的程式不受影響,常見於部分命令列工具、部分遊戲用戶端,以及一些用自訂網路庫直連的應用。
• 只覆蓋 HTTP/HTTPS 及部分 SOCKS 流量,不處理以 UDP 為主的協定(比如某些依賴 UDP 的遊戲或視訊通話場景),除非程式本身支援走 SOCKS5 UDP 轉發。
• 依賴 PAC 或系統層設定項,不同作業系統實現細節不一致,macOS、Windows、Linux 桌面環境各有各的代理設定入口,行為略有差異。

TUN 模式如何在網路層接管流量

TUN 全稱 Tunnel 虛擬網路裝置,它是作業系統核心提供的一種網路介面類型,行為上和一塊真實網路卡幾乎一樣——有自己的 IP 位址,能被路由表引用,能被防火牆規則比對。差別在於它不連接實體硬體,收發的資料封包由使用者態程式(這裡就是 Clash / Clash Meta 核心)讀取和處理。

開啟 TUN 模式後,用戶端會做三件事:建立虛擬網路卡並分配一個內部 IP、把系統預設路由或部分路由指向這塊虛擬網路卡、在核心內部接管從這塊網路卡流入的資料封包並按代理規則轉發。因為路由層面已經把流量導向虛擬網路卡,任何走系統網路堆疊發出請求的程式都逃不掉這一層攔截,不管它是否知道「代理」這個概念。這也是為什麼 TUN 模式常被稱為全域流量接管。

一個直觀的設定片段能說明這個層級差異,以下是 Clash Meta(mihomo)設定裡 TUN 相關的常見欄位:

tun:
  enable: true
  stack: system
  dns-hijack:
    - any:53
  auto-route: true
  auto-detect-interface: true

auto-route 負責自動寫入路由表項目,dns-hijack 負責把 DNS 查詢也一併劫持到核心裡處理,避免流量走了代理但 DNS 解析仍暴露真實出口的情況。這兩項配合起來,才是「全域接管」名副其實的原因——系統代理模式做不到劫持 DNS 查詢,這也是兩者在隱私層面的一個實際差異。

為什麼命令列工具和遊戲經常必須用 TUN

命令列工具(比如某些套件管理器、版本控制工具、自訂腳本)往往不讀取系統代理設定,而是要求使用者手動傳入 --proxy 參數或設定 HTTP_PROXY/HTTPS_PROXY 環境變數才會生效。如果工具本身沒有實現這類參數,系統代理設定對它就是不可見的,唯一能讓它連網走代理的方式就是 TUN——因為 TUN 攔截的是路由層的資料封包,工具是否「願意」配合代理完全不重要。

遊戲用戶端的情況類似,但原因更複雜一些:

1. 不少遊戲的網路模組直接呼叫底層 socket 介面發起連線,完全繞開系統或瀏覽器的代理設定項。
2. 遊戲對戰、語音、部分資源下載大量使用 UDP,而系統代理預設覆蓋的 HTTP/HTTPS 場景對 UDP 支援有限。
3. 部分遊戲用戶端會做反作弊或網路環境偵測,直接屏蔽已知的系統代理連接埠特徵,但對虛擬網路卡這種系統層網路介面不做特殊處理。

這三點疊加,導致「開了系統代理但遊戲還是直連」的現象很常見,而切到 TUN 模式後流量立刻被正確接管。這也是為什麼很多用戶端把 TUN 模式單獨列出來,並在教學裡特別強調遊戲、命令列場景優先用 TUN。

效能與穩定性差異要提前預知

TUN 模式覆蓋面更廣,但代價是多了一層使用者態與核心態之間的資料拷貝和處理,理論上會比系統代理多一點延遲和 CPU 占用,尤其在流量較大的場景(比如大型檔案下載、4K 影片)更容易感知到差異。系統代理因為鏈路更短,通常在輕量場景下表現更輕巧。實際使用中這個差異對多數人不明顯,但如果裝置效能有限或對延遲極度敏感(比如競技類遊戲),值得先做個人對比測試再決定長期用哪種模式。

另外,TUN 模式因為修改了系統路由表,在少數情況下可能與其他 VPN 軟體、虛擬機器網路、企業內網用戶端產生路由衝突,表現為開啟後完全無法連網或只能存取部分位址。遇到這種情況,先確認是否同時執行了其他會修改路由表的網路工具,關閉其中一個通常能定位問題。系統代理因為不改路由表,基本不會有這類衝突,相容性更穩定。

該怎麼選:兩種模式的適用場景

不需要糾結「哪個更好」,兩者本來就是為不同場景設計的,可以按下面的思路選:

• 日常瀏覽網頁、用主流聊天工具和桌面應用,系統代理已經夠用,鏈路短、資源占用低。
• 用命令列工具、SDK、套件管理器需要連網但工具本身不認系統代理設定,直接開 TUN,不用逐個工具找參數設定代理。
• 玩需要走代理的遊戲,或者遊戲走 UDP 較多導致系統代理下延遲異常,優先試 TUN。
• 懷疑某個應用繞過了代理設定在直連,可以先用系統代理模式配合封包擷取工具確認,再決定是否切到 TUN 徹底堵住這個缺口。

大多數用戶端(比如 Clash Verge Rev、FlClash、Clash Nyanpasu)在設定裡都把系統代理和 TUN 模式做成獨立開關,兩者甚至可以同時開啟,互不衝突,只是同時開啟時實際生效的接管層級以 TUN 為主。剛安裝完用戶端建議先用預設的系統代理模式驗證節點和規則是否正常,再根據具體應用的連網情況決定是否需要額外打開 TUN。