TUN 模式與系統代理有什麼區別:流量接管機制逐層拆解
很多人把這兩者當成「設定裡的兩個開關」,切換全憑手感。系統代理靠應用主動讀取設定去連接代理連接埠,TUN 在網路層截獲資料包,不管應用願不願意。這一層差異決定了覆蓋範圍、DNS 行為,以及踩坑時該往哪查。
兩種機制先分清:它們各自在哪一層工作
要理解區別,先得知道網路請求從應用發出到真正上網,中間經過幾層。系統代理和 TUN 模式接管的不是同一層,這是所有表現差異的根源。
系統代理工作在應用層。作業系統提供一個「代理設定」介面,瀏覽器、終端工具、部分桌面應用會讀取這個設定,把自己的網路請求主動轉發到指定的代理連接埠。這個轉發行為是應用自己實作的,作業系統只負責存這份設定、告訴想讀的人。
TUN 模式工作在網路層,更準確地說是在 IP 資料包這一級。Clash Meta(mihomo)開啟 TUN 後,會在系統裡建立一張虛擬網卡,再透過修改路由表,把預設路由指向這張虛擬網卡。此後所有走 IP 協定出去的資料包,不管來自哪個行程,都會先經過這張虛擬網卡,被核心轉交給 Clash 處理,再按規則決定直連還是走代理節點。
一句話概括:系統代理是「設定擺在那,應用自己來讀」;TUN 是「路由改了,包想走別處都繞不開」。
系統代理:應用自覺遵守的委託機制
系統代理的落地方式在不同作業系統上略有差異,但核心邏輯一致:
- Windows / macOS 圖形介面——系統提供全域代理設定項,Clash 客戶端開啟「設為系統代理」後,會把這項設定寫入系統偏好設定,主流瀏覽器和大部分現代應用預設會讀取它。
- 命令列終端——認的是
http_proxy、https_proxy這類環境變數,系統層級的代理設定對終端往往不生效,需要另外 export。 - PAC 腳本——部分客戶端用 PAC(Proxy Auto-Config)檔案動態判斷網域走不走代理,瀏覽器載入這個腳本按規則決定路徑。
這套機制的前提是「應用願意配合」。如果一個程式內部寫死了連接位址,或者根本不檢查系統代理設定(常見於一些遊戲、更新服務、背景常駐程式),系統代理對它無效,流量照樣直連出去。這也是為什麼開了系統代理,瀏覽器分流正常,某些客戶端軟體卻始終連不上代理節點——它沒在「自覺遵守」的那一批裡。
系統代理對新開啟的行程立即生效,但已經在執行中、且啟動時就快取了網路設定的程式,有時需要重新啟動該程式才能讀到新的代理設定。排查「代理開了但某個軟體不走」時,先試著重啟這個軟體,再往下查規則。
TUN 模式:網路層建虛擬網卡,全量接管
TUN 模式不依賴應用配合,它改變的是資料包離開裝置之前必經的路徑。開啟後大致發生這幾步:
- Clash Meta(mihomo)核心建立一張虛擬網路介面(常見命名如
utun、Meta),這張網卡在系統裡等同於一張真實的網路介面卡。 - 修改本機路由表,把預設路由(或指定網段)指向這張虛擬網卡,優先順序高於原有的實體網卡路由。
- 系統核心按路由表轉發資料包時,符合預設路由的流量會先送到虛擬網卡,再由 Clash 行程讀取、解析、按規則處理。
- 處理完的流量再從代理節點或直連出口發出,回包按原路徑送回發起行程,行程本身感知不到這一整套轉發過程。
因為接管發生在路由這一層,所有走 IP 協定的流量都會被截獲——不區分瀏覽器、命令列工具、系統背景服務,也不需要它們支援代理設定。這正是 TUN 模式最大的價值:處理那些「不聽話」的行程流量。
代價也很直接:虛擬網卡涉及系統底層網路堆疊,權限要求更高(Windows 上通常需要以系統管理員身分執行或授權驅動程式,macOS 上需要系統延伸功能或 root 權限的服務模式輔助),設定出錯時故障面也更廣——路由表衝突、和其他 VPN 軟體搶預設路由、防火牆攔截虛擬網卡流量,都是 TUN 模式特有的排查項目,系統代理模式基本不會遇到。
DNS 處理:兩種機制分歧最大的一環
DNS 解析該走代理還是走本機,是兩種機制表現差異最明顯的地方,也是新手最容易困惑的一環。
系統代理模式下,DNS 請求通常不經過 Clash——它只接管應用主動發起的 TCP/HTTP 連線,網域名稱解析這一步很多時候仍走本機原有的 DNS 伺服器完成,解析結果再拿去連代理。這意味著 DNS 查詢本身可能暴露給本地網路業者,而且如果本地 DNS 遭到污染,解析出的位址錯誤,連線照樣會失敗或連錯伺服器。
TUN 模式下,Clash Meta(mihomo)可以接管 DNS 請求本身,常見做法是啟用 fake-ip:核心給網域暫時分配一個假的 IP 段,應用拿著這個假 IP 去連線時,Clash 在網路層識別出這是哪個網域對應的連線,再按規則比對代理或直連,真實解析在代理端完成。這樣一來,DNS 查詢和後續連線都在 Clash 的掌控範圍內,網域污染基本不會影響到判斷結果。
| 對比項 | 系統代理 | TUN 模式 |
|---|---|---|
| 接管層級 | 應用層,需應用配合 | 網路層,基於路由表 |
| 覆蓋範圍 | 支援代理設定的應用 | 全部 IP 流量,行程無感 |
| DNS 處理 | 多數情況走本地解析 | 可用 fake-ip 全量接管 |
| 權限要求 | 一般使用者權限即可 | 需系統管理員權限或系統服務 |
| 典型故障面 | 某應用不讀取系統設定 | 路由衝突、虛擬網卡異常 |
覆蓋範圍對比:哪些流量會漏
實際使用中最常被問的問題是「為什麼開了代理,還是有些東西沒走代理」。答案往往取決於用的是哪種機制。
系統代理模式下容易漏的典型場景:
- 命令列工具(
curl、git、套件管理器)不認系統代理,只認環境變數,沒另外設定就會直連。 - 部分桌面客戶端(即時通訊、下載工具、遊戲更新器)內部走自己的網路堆疊,不檢查系統代理設定。
- 系統層級的背景服務(自動更新、遙測回報)通常不受使用者層級代理設定約束。
TUN 模式下,上述場景基本都能被接管,因為路由層不區分行程身分。但 TUN 模式也有自己的「漏」——如果規則裡把某個網段設定為直連(比如區域網段),或者虛擬網卡的路由優先順序被其他網路工具(如某些 VPN 客戶端、虛擬機器網卡)搶佔,流量同樣會繞開 Clash。這類問題的排查方向是路由表和網卡優先順序,而不是應用設定。
該用哪種:場景與切換建議
不是「哪個更好」,而是「目前需求符合哪個」。給幾條實用判斷:
- 日常以瀏覽器為主、偶爾用幾個常見工具——系統代理夠用,設定簡單,出問題時排查範圍也小,先從這個模式開始更穩妥。
- 需要覆蓋命令列工具、遊戲、背景服務等不支援代理設定的程式——上 TUN 模式,這是它存在的核心意義。
- 已經在用其他 VPN 或有虛擬網卡衝突歷史——優先排查路由表再決定是否開 TUN,避免兩套網路接管機制搶路由導致連線抖動。
- 對 DNS 污染敏感、擔心網域解析洩漏——TUN 模式搭配 fake-ip 更徹底,系統代理這條鏈路管不到 DNS 查詢本身。
兩種模式並非互斥,大多數客戶端支援隨時切換,遇到某個場景下行為異常,先確認目前用的是哪種接管機制,再對照上面的差異表定位問題,比盲目重裝或換節點效率高得多。
排查連線異常的第一步,永遠是先確認自己開的是系統代理還是 TUN——這兩種機制的故障現場完全不同,搞混了方向,後面查什麼都是白費功夫。