系統代理接管不了的流量,TUN 能接管
先說清楚一個常被混用的概念區分:系統代理(System Proxy)和 TUN 模式解決的是同一個問題的兩種不同層面。系統代理的原理是修改作業系統或瀏覽器讀取的代理設定項——像 Windows 的「網路和 Internet」設定裡那個 HTTP/HTTPS 代理位址,或是環境變數 HTTP_PROXY/HTTPS_PROXY。軟體如果遵守這套約定、主動去讀代理設定,流量就會被轉發到 Clash 監聽的埠;但如果軟體不讀、或者用的是自己寫死的連線方式(常見於部分遊戲客戶端、命令列工具、某些 UWP 應用、系統更新服務),系統代理就管不到它。
TUN 模式換了一種思路:它不再「勸說」軟體走代理,而是在作業系統網路堆疊裡建立一張虛擬網卡(Virtual Network Adapter),然後把系統預設路由指向這張虛擬網卡。這樣一來,所有出站流量——不管是瀏覽器、背景服務、還是不認識代理設定的程式——都會先經過這張虛擬網卡,再由 Clash(或 Clash Meta / mihomo 核心)在使用者態讀取、解析、依規則分流。這就是常說的「全局流量接管」:接管的對象是整台裝置的網路層,而不是某個應用程式的應用層設定。
需要澄清一個常見誤解:TUN 模式不是「更強力的系統代理」,而是完全不同的實作路徑。系統代理停留在應用層協定(HTTP/HTTPS CONNECT),TUN 工作在網路層(IP 封包),因此它能處理任意基於 TCP/UDP 的流量,包括遊戲、VoIP、DNS 查詢本身。這也是為什麼部分情境——比如需要代理 UDP 流量、需要統一處理裝置上所有程式——只有 TUN 模式能做到。
虛擬網卡怎麼「劫持」流量:三個關鍵環節
理解 TUN 模式的運作流程,有助於排查後續可能遇到的問題。整個過程可以拆成三個環節:
- 建立虛擬網卡:客戶端呼叫系統底層介面(Windows 上常用 Wintun 驅動,macOS 上是 utun 介面)建立一張名為類似
Clash、utun的虛擬網路介面卡,並為其分配一個私有 IP 段。 - 調整路由表:客戶端把系統的預設路由或部分路由規則改為指向這張虛擬網卡,同時保留到 Clash 本身行程、到本機閘道的直連路由,避免流量繞圈子。
- 使用者態轉發與分流:作業系統把封包送進虛擬網卡後,Clash 核心在使用者態讀取這些 IP 封包,還原成具體的 TCP/UDP 連線,再依設定檔裡的規則(網域比對、IP 段比對、GeoIP 等)決定走直連、走某個代理節點,還是直接拒絕。
這也解釋了為什麼 TUN 模式需要更高的系統權限——修改路由表和建立虛擬網卡在 Windows 上需要系統管理員權限,在 macOS 上需要 sudo 或系統延伸功能授權。這不是軟體「越權」,而是虛擬網卡這項技術本身對作業系統底層資源的必要存取。
開啟 TUN 模式前,先確認裝置上沒有同時執行其他會建立虛擬網卡的軟體(如另一個代理工具、某些 VPN 客戶端)。兩套虛擬網卡同時搶路由表,大概率導致斷網或流量繞不出去,建議先完全退出衝突軟體再開啟 TUN。
Windows 上開啟 TUN 模式的完整步驟
不同 Windows 客戶端的介面配置略有差異,但核心開關和順序是一致的,以下按通用流程說明:
- 確認客戶端核心是 Clash Meta 或 mihomo(部分舊版 Clash Premium 核心不支援 TUN,升級客戶端或切換核心即可)。
- 打開客戶端主介面,找到「代理設定」或「網路」面板,定位到 TUN 模式 開關,首次開啟時系統通常會彈出安裝 Wintun 驅動的提示,點擊允許。
- 若客戶端提供「服務模式」(Service Mode)選項,建議一併安裝。服務模式讓 TUN 相關操作以 Windows 服務身份長期駐留背景執行,好處是不需要每次都以系統管理員身份重新啟動客戶端才能開啟 TUN,也能避免使用者登出後 TUN 網卡異常。
- 打開 TUN 開關後,客戶端會提示以系統管理員權限重新啟動,確認即可,首次啟動可能有 1~2 秒的短暫路由切換感知。
- 切換到「代理模式」面板,確認目前處於規則模式(Rule)而不是全局直連,這樣 TUN 接管的流量才會依訂閱裡的分流規則處理,而不是一股腦全部走代理或全部直連。
控制台 → 網路和共用中心 → 變更介面卡設定
應能看到一張名為 Clash / Mihomo 的虛擬網卡,狀態為「已連線」
如果開啟後網路介面卡清單裡沒有出現對應的虛擬網卡,大概率是 Wintun 驅動安裝失敗或被安全軟體攔截,可以嘗試以系統管理員身份手動重新啟動客戶端一次,或暫時關閉第三方安全軟體的驅動攔截功能後重試。
macOS 上開啟 TUN 模式:系統延伸功能授權是關鍵
macOS 從系統層面對建立網路延伸功能有更嚴格的審核流程,因此在 macOS 上開啟 TUN 模式通常會多一步「系統延伸功能核准」的環節:
- 在客戶端設定中開啟 TUN 模式開關,首次開啟系統會彈出「系統延伸功能被封鎖」的提示。
- 前往「系統設定 → 隱私權與安全性」,找到底部提示允許該客戶端對應的系統延伸功能,點擊允許。
- 部分 macOS 版本需要重新啟動電腦才能讓系統延伸功能生效,重啟後重新打開客戶端。
- 再次打開 TUN 開關,客戶端會要求系統管理員密碼用於建立 utun 虛擬介面和修改路由表,輸入密碼確認。
- 開啟成功後,可以在終端機執行
ifconfig或networksetup -listallnetworkservices查看是否出現utun系列介面。
ifconfig | grep utun
# 正常應能看到類似輸出
utun5: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1500
macOS 上如果反覆出現系統延伸功能被拒絕,先檢查「系統設定 → 隱私權與安全性 → 安全性」裡是否開啟了「僅允許來自 App Store 的應用程式」,部分安全策略會連帶攔截合法的網路延伸功能授權請求,需要暫時放寬後再重試一次。
驗證 TUN 是否真的生效:別只看開關狀態
開關變成「開」並不等於流量真的按預期接管了,這裡提供兩個可靠的驗證方法。第一個是看 DNS 解析是否被劫持——TUN 模式下,DNS 查詢本身也應該經過 Clash 核心處理,這樣才能讓基於網域的規則正確命中:
nslookup example.com
# 關注回傳結果裡的應答伺服器位址
# 如果顯示的是 Clash 核心在設定裡設置的 DNS 監聽位址(如 198.18.0.2 等 fake-ip 段)
# 說明 DNS 查詢已經被 TUN 接管,而不是直接打到系統原生 DNS
第二個方法是直接在客戶端的連線面板或流量面板裡觀察,開啟 TUN 後應該能看到不經過瀏覽器代理設定的軟體(比如系統內建的天氣應用、某些命令列工具)的連線記錄也出現在清單裡。如果打開一個明確不支援系統代理設定的程式,依然完全無法連上網路或流量沒有出現在面板裡,說明 TUN 沒有真正接管成功,需要回頭檢查路由表是否被其他軟體搶占,或者服務模式是否正常運作。
另外要注意 fake-ip 模式下部分內網存取、區域網路裝置發現類功能可能受影響,如果同時需要正常存取區域網路裝置,建議在設定檔裡為區域網路 IP 段單獨設定直連規則,或使用 fake-ip-filter 排除相應網域與位址段,避免內網存取被錯誤代理。
開啟 TUN 後常見的幾個問題
- 開啟後立刻斷網:多數是路由表衝突,先關閉其他可能建立虛擬網卡的軟體,重新啟動客戶端後重新開啟。
- 部分應用程式無法存取,回報證書錯誤:如果客戶端同時開啟了 MitM(中間人抓包)相關功能,需要額外安裝並信任 Clash 產生的根證書,和 TUN 模式本身無關,可以先在設定裡關閉 MitM 相關選項排查。
- Windows 上每次重新啟動電腦都要重新以系統管理員權限打開一次:說明服務模式沒有正確安裝,回到設定面板重新安裝一次服務元件。
- 區域網路內其他裝置無法互相發現:檢查規則清單中區域網路位址段(如 192.168.0.0/16、10.0.0.0/8)是否設定為直連,必要時手動補充規則。
總的來說,TUN 模式解決的是系統代理天生的覆蓋盲區問題,原理上依賴虛擬網卡與路由表調整,設定上比開啟系統代理多了驅動安裝與權限授權兩步。理解了這三個環節——建立網卡、調整路由、使用者態分流——遇到具體錯誤時,基本都能對應到某一步排查,而不是盲目重裝客戶端。