系統代理是 Clash 最基礎的接管方式，透過設定作業系統 HTTP/SOCKS5 代理參數將支援代理的應用流量轉入 Clash 處理。但系統代理存在本質局限——遊戲客戶端、命令列工具等直接建立網路連線的程式不受其控制。Clash 官方推出的 TUN 模式透過虛擬網卡在網路層接管全部系統流量，是實現真正全域透明代理的官方解決方案。
TUN 模式的工作原理
TUN（Network Tunnel）是作業系統提供的一種虛擬網路介面機制，工作在 OSI 模型的第三層（網路層）。Clash 開啟 TUN 模式後，會在系統中建立一塊名為 utun（macOS）或 Meta（Windows/Linux）的虛擬網卡，並修改系統路由表，將所有出站 IP 流量導入這塊虛擬網卡。
流量進入虛擬網卡後，Clash 在使用者空間對其進行解析，識別出目標位址，再根據規則設定決定是走代理還是直連，最後透過實際的實體網卡發出。整個過程對應用程式完全透明，應用程式無需做任何設定。
與 TAP 模式（工作在第二層，乙太網路訊框層級）相比，TUN 模式無需處理 ARP、乙太網路標頭等二層細節，效能更高，也更容易實現跨平台相容。
如何開啟 TUN 模式
開啟 TUN 模式有兩種方式。圖形化客戶端通常在設定頁面提供 TUN 開關，以 Clash for Windows 為例，需要先在「一般」設定中安裝「Service Mode」（服務模式），安裝完成後再開啟「TUN Mode」開關。服務模式的安裝需要管理員權限，目的是讓 Clash 以系統服務的身份執行，從而獲得修改路由表的權限。
另一種方式是在設定檔中直接宣告 TUN 設定：
tun:
enable: true
stack: mixed
dns-hijack:
- any:53
auto-route: true
auto-detect-interface: true三種 TUN 協定堆疊模式的選擇
Mihomo 核心提供三種 TUN 協定堆疊實作，各有優劣：
- system：直接呼叫作業系統原生的 TCP/IP 堆疊。效能最高，CPU 和記憶體開銷最小，但在少數系統設定下可能出現相容性問題。
- gvisor：使用 Google gVisor 專案中的使用者空間 TCP/IP 協定堆疊實作。與作業系統核心完全隔離，相容性最好，適合排查問題或在特殊環境下使用，但效能略低於 system 模式。
- mixed：TCP 連線使用 system 堆疊，UDP 連線使用 gVisor 堆疊。綜合了兩者的優點——TCP 效能接近原生，UDP 相容性好。這是目前最推薦的選擇，絕大多數場景下表現最佳。
DNS 劫持與防洩漏
dns-hijack: [any:53] 這個設定至關重要。它的作用是將所有發往任意 IP 位址的 53 埠 DNS 請求，都強制重新導向到 Clash 內建的 DNS 模組處理。
為什麼必須劫持 DNS？因為在 TUN 模式下，如果某些應用程式直接向 8.8.8.8:53 發送 DNS 請求（繞過系統 DNS 設定），這個請求會直接走實體網卡出去，不經過 Clash 的規則判斷。這不僅可能導致 DNS 洩漏（暴露你的真實訪問記錄），還會造成某些域名無法正確路由到代理節點。開啟 DNS 劫持後，所有 DNS 請求都由 Clash 統一處理，搭配 Fake-IP 模式可以實現最優的 DNS 防 DNS 劫持效果。
驗證與排查
開啟 TUN 模式後，可以透過以下方法驗證是否正常運作：在終端機執行 curl -I https://www.google.com，如果能收到正常的 HTTP 回應標頭，說明命令列工具的流量已經走代理了。你也可以在 Clash 的「連線」頁面即時查看所有經過 TUN 接管的連線，包括之前系統代理無法覆蓋的程式。
如果開啟後網路完全斷開，最常見的原因是 auto-detect-interface 未能正確識別出口網卡。可以手動指定：
tun:
enable: true
stack: mixed
auto-route: true
interface-name: en0 # macOS 實體網卡名稱，Windows 通常是 乙太網路 或 WLAN