什麼是 TUN？和系統代理差在哪裡
在 Clash 生態裡，多數使用者最先接觸的是系統代理（System Proxy）：把瀏覽器與「願意讀取系統 Proxy 設定」的應用程式導向本機的 HTTP 或 SOCKS 連接埠。這條路徑成熟、功耗低、也不一定要額外驅動，但它不會自動讓所有程式都遵從。遊戲用戶端、部分啟動器、語音／視訊模組、模擬器、以及不少命令列工具，常會繞過系統 Proxy，直接往作業系統的預設路由與網卡送封包。
TUN 模式則是在系統層建立一個虛擬網路介面（常稱 tun／utun），並透過路由表或等效機制，把符合條件的 IP 流量（含許多情境下的 UDP）交給 Clash 核心處理。用白話說：它不是「請 App 自己去連 Proxy」，而是「讓封包在離開電腦前先經過規則引擎」。因此在需要更接近全域接管、或UDP／非標準連線必須分流時，TUN 往往是關鍵選項。
本篇以繁體中文讀者常見情境撰寫：目標是把TCP／UDP如何進入 Clash、要在設定檔裡對齊哪些概念，以及在 Windows、macOS、Android 上開啟 TUN 時最常踩到的權限與網路異常講清楚。實際鍵名會隨Mihomo（Clash Meta）版本略有差異，請務必對照您手上的核心／GUI 版本文件。
為什麼遊戲與 UDP 場景常指向 TUN
線上遊戲常用的語音、對戰連線、反作弊通道與部分更新管道，會大量使用 UDP。UDP 的特性是不保證可靠傳遞，但延遲較可控；問題在於「走不走代理」並不是瀏覽器選項那麼直覺：程式不一定會把 UDP 送到 SOCKS，也不一定會理會 HTTP Proxy。
- 系統 Proxy 的盲區：許多 Win32／原生程式根本不讀取系統 Proxy；它們會直接用 OS socket API 連線。
- 規則只看「進入核心的流量」：若封包未進入 Clash，規則再完整也無法分流。
- TUN 把問題拉回同一個入口：只要路由設計合理，進入 tun 的流量就有機會依 DOMAIN／IPCIDR／MATCH 等規則決定 DIRECT 或經由代理出站。
也要務實看待：TUN 不是魔術開關。若節點／協定對 UDP 支援不佳、電信商對 QoS 很重、或遊戲伺服器鎖區鎖 ping，開 TUN 未必能把延遲「變好看」。它有時更像連通性與可控性的地基：先把流量真的送進規則引擎，再去調整節點、規則與 DNS。
開始前先確認三件事
支援 TUN 的核心與前端
請確認您的發行版基於相容 Mihomo／Clash Meta 分支的核心，並在用戶端內看得到「TUN」「虛擬網卡」「Meta Core」或類似選項。桌面常見組合包含 Clash Verge Rev；Android 方面則常見 FlClash、Clash Meta for Android 等。
系統權限與安全軟體
Windows 多數情境需要以系統管理員身分啟動 GUI，才能完成路由或驅動層面的調整；macOS 可能會跳出網路延伸／驅動授權；Android 則等同建立VPN 服務（通知列會顯示鑰匙圖示）。若您使用企業安全管理軟體，請預期可能被攔截。
備援：先用系統代理驗證節點
第一次排查時，建議先用瀏覽器或支援 Proxy 的工具確認「至少 TCP 出站是正常的」，再開 TUN。這能把問題縮小：究竟是節點不可用，還是TUN／路由／DNS造成的。
設定檔中的 tun 區塊長什麼樣子
以下是一段示意性 YAML（鍵名請以您的核心版本為準），重點在於呈現您需要在 GUI「開關」之外理解的結構：
tun:
enable: true
stack: system
auto-route: true
strict-route: false
dns-hijack:
- any:53enable：總開關；GUI 開 TUN 時通常會同步設定。stack：常見為system或gvisor（不同平台支援度不同）；遇到相容性問題時可列入對照。auto-route：是否交由核心自動維護路由；大多數使用者會維持開啟。strict-route：更嚴格的路由策略；在某些網路環境可避免流量繞路，但也可能造成局域／特定網段異常，排查時值得試著切換對照。dns-hijack：把送往指定埠的 DNS 查詢攔進核心處理；是否為必要項依設定檔與 DNS 設計而定。
DNS、fake-ip 與「看得到規則卻上不去」
TUN 上線後，DNS 行為常常是第二個瓶頸。許多設定檔會啟用類似以下的區塊（示意）：
dns:
enable: true
enhanced-mode: fake-ip
nameserver:
- https://dns.google/dns-query
fallback:
- https://cloudflare-dns.com/dns-queryfake-ip的本質是把域名解析先在本地映射成「假的 IP」，讓連線決策更早進入規則引擎；對分流精準度常有幫助，但若規則或劫持不完整，也可能出現特定域名異常（例如某些登入器、CDN、或區網服務）。排查時建議：
- 先用最小可行規則確認連線鏈路正常（例如確保 MATCH 走向清晰）
- 針對異常域名檢視是否需要追加 DOMAIN／DOMAIN-SUFFIX 規則
- 對照核心版本文件確認 enhanced-mode、fake-ip-filter、域名嗅探（sniffer）相關鍵是否需調整
Windows：Clash Verge Rev 啟用 TUN 的建議流程
- 確認核心為 Mihomo／Meta 相容分支並已完成初次設定檔載入。
- 結束程式後改以系統管理員身分啟動（右鍵選單）。
- 進入設定頁開啟 TUN；若提示驅動／元件安裝，請允許並在完成後重啟用戶端。
- 檢視連線紀錄：是否有 UDP 會話建立、規則命中是否符合預期。
- 若開啟後整機無網路：先關閉 TUN，檢查防火牆是否放行；再接著調整 strict-route／stack。
Windows 環境的另一個現實面是反作弊與核心隔離：某些競技遊戲對虛擬網卡或流量特徵敏感，即使技術上可走代理，也可能被政策禁止或造成鎖帳風險。請務必遵守遊戲服務條款與在地法律規範；本篇僅說明網路機制，不提供規避策略。
macOS：權限、開發者簽章與「為何開了仍不像全局」
在 macOS 上，TUN 涉及網路延伸（Network Extension）或第三方驅動層級元件；初次使用常在「系統設定 → 隱私權與安全性」看到阻擋提示。請依 GUI 指引逐步放行，否則會出現tun 介面建立失敗或路由未套用。
Apple Silicon（M 系列）請確認您安裝的是對應架構的版本；混用 Rosetta 與原生二進位有時會讓某些相依套件路徑混亂，進而影響驅動載入。若您同時使用 iCloud Private Relay、其他全局 VPN，請避免並行接管。
Android：VPN 服務形式與遊戲電池策略
Android 上的「TUN」多數是以VPNService呈現：通知列會顯示連線中與鑰匙圖示，這是正常的。請在系統設定裡給予不受電池最佳化或類似權限，避免背景被砍造成遊戲中途斷線。
部分 OEM（各家手機品牌）會對後台網路有更 aggressive 的策略；若您發現只在螢幕熄滅後延遲暴升，請優先檢視電池管理白名單，其次才是調整規則或節點。
規則與出站：確保 UDP 真的送往代理
即使開啟 TUN，仍要確認規則尾部兜底（MATCH）是否合理：某些設定檔預設將未知流量導向 DIRECT，會讓您誤以為「代理沒生效」。此外，請確認您的代理協定本身對 UDP 轉發友善；例如節點若未開 UDP relay，表象會像「TCP 能上、UDP 全掉」。這類問題往往在伺服器端設定或提供商公告能得到答案。
對玩家而言，另一個實務技巧是把延遲測試與真實遊戲路徑分開看：HTTP ping 好看的節點不代表對戰伺服器的 UDP path 也好；請以遊戲內連線品質為準。
常見問題排查（照順序做）
開 TUN 後整機無網路
- 先關閉 TUN，確認恢復後再開。
- 檢查是否與其他 VPN／全局代理並存。
- 暫時調整 strict-route、stack，對照差異。
- 查看防火牆是否阻擋虛擬介面。
遊戲仍像直連或無法連線
- 確認程式是否真的把流量送進 tun（連線紀錄／會話面板）。
- 檢視規則是否將該目的地設為 DIRECT。
- 更換支援 UDP 的節點與協定組合。
- 檢查 DNS／fake-ip 是否造成錯誤解析。
安全軟體誤判
某些套件會把「路由表變更」視為高風險行為；若您在公司設備上操作，請先確認資訊政策允許。
為何完整規則引擎仍然值得選擇 Clash 路線
市面上也有不少主打「一鍵全局」的工具，但它們常見的痛點是規則粒度不足或長期維護停滯：你要嘛整包走代理（國內流量也被繞路），要嘛無法細緻區分 UDP／TCP、域名與 IP 段；一旦網路環境改變，就很難只用開關解決。
相比之下，基於 Mihomo／Meta 核心的 Clash 用戶端通常能把TUN、DNS、規則分流與訂閱更新放在同一套工作流程裡：您可以先用規則維持日常網站的直連效率，再在必要時把遊戲與不依系統 Proxy 的流量交給虛擬網卡接管，並保留連線紀錄協助迭代調校。
如果您仍在使用多年前停更、規則語法跟不上核心的舊程式，通常會卡在「開了也像沒開」的灰色狀態；換成仍跟進社群更新的發行版後，設定檔中的 tun／dns／rules 才能真正發揮作用。