Clash TUN 模式是什麼:虛擬網卡接管全域流量的原理與開啟步驟

DOC-01

系統代理模式的覆蓋邊界

多數使用者第一次接觸 Clash 時,使用的是系統代理模式。這種模式的運作方式是:客戶端啟動一個本機 HTTP/SOCKS5 連接埠,作業系統或瀏覽器把該連接埠寫入代理設定,應用程式發起請求時讀取這份設定,把流量轉發到本機連接埠,再由 Clash 處理。這條路徑依賴兩個前提——應用程式支援讀取系統代理設定,應用程式使用的協定在代理支援範圍內。

問題恰好出在這兩個前提上。部分命令列工具、部分遊戲客戶端、部分內建了自訂網路堆疊的應用程式,不會讀取系統代理設定,或者只支援 HTTP 協定、不支援 UDP。這些流量會繞開 Clash,直接走實體網卡出站。結果是:瀏覽器分流正常,但某個客戶端始終連線失敗,或者始終走的是本機真實 IP,這類問題的根源大多在這裡。

系統代理模式的覆蓋盲區可以歸納為三類:不遵循系統代理設定的行程、依賴 UDP 且代理協定不支援轉發的場景、以及在應用層之下發起連線的系統服務或驅動程式。TUN 模式正是為了填補這三類盲區而存在。

DOC-02

TUN 模式的運作原理

TUN 是一種虛擬網路裝置,運作於作業系統核心網路堆疊的介面層。Clash Meta(核心 mihomo)開啟 TUN 模式後,會在系統裡建立一塊虛擬網卡,並透過修改系統路由表,把預設路由或指定網段的流量導向這塊虛擬網卡。此時,流量的攔截點從應用層的代理設定,下移到了網路層的路由規則。

這個差異決定了覆蓋範圍的不同。系統代理模式是「應用程式主動配合才能被代理」,TUN 模式是「只要走系統路由就會被截獲」。不管發起連線的是瀏覽器、命令列工具還是某個背景服務,只要它的資料封包經過系統網路堆疊,就會被路由到虛擬網卡,交給 Clash 核心按規則處理——直連、走代理、還是拒絕,判定邏輯與一般代理模式完全一致,只是流量入口變了。

具體流程大致如下:

1. Clash 核心建立虛擬網卡(如 Meta 或 utun 裝置),分配虛擬 IP 段。
2. 核心在系統路由表中插入規則,把需要接管的流量指向該虛擬網卡。
3. 應用程式發出的資料封包經過系統路由判斷,進入虛擬網卡而非實體網卡。
4. Clash 核心在使用者態讀取虛擬網卡的資料,還原出原始的 TCP/UDP 連線請求。
5. 依規則清單判定該連線走直連還是某個代理節點,再由對應出口轉發出去。

這套機制要求客戶端具備建立虛擬網卡與修改路由表的系統權限,這也是為什麼 TUN 模式在各平台都需要額外授權,而不是像系統代理模式那樣點個開關就能用。

DOC-03

兩種模式的關鍵差異對照

把系統代理模式和 TUN 模式放在同一張表裡比較,更容易判斷該在什麼場景下用哪一種。

簡單結論:如果只是讓瀏覽器分流,系統代理模式已經足夠,設定也更簡單。如果目標是讓全部本機流量(包括不配合代理設定的行程)都納入規則管控,TUN 模式是必要選項。

DOC-04

依平台開啟步驟

各平台底層虛擬網卡實作不同,授權方式也不同,以下按平台分別說明。

Windows

Windows 上的 TUN 實作依賴 Wintun 驅動程式,主流客戶端(如 Clash Verge Rev、Clash for Windows 系桌面客戶端)安裝包內已經整合該驅動程式,首次開啟時通常會觸發系統的驅動安裝確認或 UAC 提權彈窗,需要以系統管理員身分執行客戶端,並允許該驅動安裝請求,否則虛擬網卡無法建立。

1. 關閉系統代理模式(避免兩種模式的路由規則互相干擾)。
2. 以系統管理員身分重新啟動客戶端。
3. 在設定中找到 TUN 模式開關並開啟,確認驅動安裝提示後點擊允許。
4. 開啟「網路連線」面板,確認出現一塊名為 Meta 或類似標識的虛擬網卡,狀態為已連線。
5. 用瀏覽器造訪 IP 查詢頁面,核對出口 IP 是否變為代理節點所在地區。

macOS

macOS 使用系統自帶的 utun 介面族,客戶端建立虛擬網卡本身不需要額外驅動程式,但需要輔助程序權限。桌面客戶端(如 Clash Verge Rev、ClashX 系)首次開啟 TUN 時會請求安裝一個特權輔助工具,系統會彈出密碼輸入框,輸入目前使用者密碼完成授權。

1. 在設定中開啟 TUN 模式開關。
2. 系統彈出授權提示時,輸入 macOS 登入密碼確認。
3. 如果客戶端提示需要安裝或更新輔助服務,依提示完成一次性安裝。
4. 用系統的「網路」設定面板查看是否新增一個虛擬介面。

較新版本的 macOS 對系統擴充功能和網路擴充功能的權限收緊較多,如果授權彈窗沒有出現或點擊後無回應,可以在「系統設定 - 隱私權與安全性」裡檢查是否有被阻擋的背景元件,手動允許後重新啟動客戶端再試。

Android

Android 上的 TUN 模式透過系統的 VPNService 介面實作,這是系統開放給應用程式做全域代理的標準方式,不需要 root 權限。開啟方式與授權一個一般 VPN 應用程式類似。

1. 在客戶端(如 Clash Meta for Android)裡開啟 TUN 或「虛擬網卡」開關。
2. 系統彈出「連線請求」對話框,提示該應用程式將建立一個 VPN 連線,點擊確定。
3. 狀態列出現 VPN 圖示,表示虛擬網卡已生效。
4. 如果需要排除某些本機應用程式不走代理,可在應用程式的個別代理設定中單獨取消勾選。

需要注意的是,系統層面同一時間只能有一個 VPNService 生效,如果裝置上還安裝並開啟了其他 VPN 類應用程式,兩者會互相搶占,需要先關閉另一個。

iOS

iOS 上的等效機制是 NetworkExtension 框架下的個人 VPN 設定,客戶端在首次開啟對應模式時會請求安裝一個 VPN 設定描述檔,需要在系統提示中確認信任。

1. 在客戶端設定中開啟全域流量接管相關開關。
2. 系統彈出「允許新增 VPN 設定」提示,輸入裝置密碼或使用面容確認。
3. 在「設定 - VPN」中確認該設定狀態為已連線。

Linux

Linux 上建立 TUN 裝置依賴核心自帶的 tun 模組,通常無需單獨安裝驅動程式,但客戶端程序需要 CAP_NET_ADMIN 能力或以 root 權限執行才能建立介面和修改路由表。

# 以 root 權限執行客戶端,或為二進位檔案單獨授予網路管理能力
sudo setcap cap_net_admin,cap_net_raw=eip /path/to/clash-core

授予能力後即可用一般使用者身分執行客戶端並開啟 TUN 模式,不必每次都用 sudo 啟動整個程式,這樣能減少不必要的權限暴露。

DOC-05

常見衝突與排查思路

TUN 模式涉及虛擬網卡與路由表改寫,出問題時的表現往往是「能連上但沒有效果」或「直接連不上網」,而不是清晰的報錯。以下是幾類高頻情況。

與其他 VPN 或虛擬網卡工具衝突

如果裝置上同時運行著企業 VPN 客戶端、某些安全軟體自帶的網路過濾驅動程式,或另一款代理工具的 TUN 元件,多個虛擬網卡會爭奪路由優先權。表現通常是開啟 TUN 後網路時斷時續,或者部分流量繞過了預期路徑。處理辦法是先關閉其他虛擬網路元件,只保留一個在運行,確認 Clash 的 TUN 單獨運作正常後,再考慮是否需要兩者共存以及如何調整路由優先權。

DNS 解析異常

開啟 TUN 模式後,如果網域名稱解析仍走系統原有 DNS 而不經過 Clash 核心,可能導致網域名稱被劫持到錯誤位址,或者規則裡按網域名稱比對的項目失效。這種情況通常需要在設定裡同時開啟 DNS 接管相關設定,讓核心統一處理解析請求,而不是讓流量層面接管了、解析層面卻還在用系統預設 DNS。

虛擬網卡建立失敗

Windows 上常見原因是驅動程式未正確安裝或權限不足;macOS 上常見原因是特權輔助工具被系統安全策略攔截;Linux 上常見原因是權限能力未正確設定。排查順序建議是:先確認客戶端是否以足夠權限執行,再檢查系統日誌或客戶端日誌裡是否有明確的驅動或權限報錯,最後確認沒有其他程式占用了同名的虛擬網路介面。

部分應用程式仍未被接管

少數應用程式會繞過系統路由表,自行指定網路介面傳送資料,這類情況在 TUN 模式下也無法覆蓋,屬於應用程式本身的實作方式所致,不是設定錯誤。如果確認某個應用程式始終不受任何模式管控,可以在該應用程式自身的網路設定裡檢查是否有獨立的代理或直連選項。

DOC-06

該不該常開 TUN 模式

TUN 模式的覆蓋面更完整,但也意味著系統層面多了一層路由改寫,遇到問題時排查鏈路更長。日常只用瀏覽器上網、對分流精細度要求不高的場景,系統代理模式已經能滿足需求,設定簡單、衝突機率低。需要覆蓋遊戲客戶端、命令列工具、背景服務等不配合系統代理設定的場景時,TUN 模式是更穩妥的選擇。

兩者並不互斥,大多數客戶端支援隨時切換,可以依當前使用場景靈活啟停,不必固定選擇一種模式長期使用。