TUN 模式到底是什麼？為什麼它能「接管全部流量」
多數使用者第一次接觸 Clash 類用戶端時，最先學會的往往是「開啟系統代理」。這種做法本質上是告訴作業系統：請把支援 HTTP 或 SOCKS 代理的程式流量，轉送到本機的代理埠。聽起來很合理，但現實世界裡，並不是每個程式都會乖乖讀取系統代理設定。遊戲用戶端、某些桌面工具、以及大量終端機指令，常常會略過代理設定而改走直連，結果就是「瀏覽器顯示 IP 已變，但遊戲或終端機仍像沒開代理」。
TUN 模式則走另一條路：它會在系統內建立一張虛擬網卡（常見名稱會包含 Clash、Meta、Mihomo 等字樣），並透過路由表或策略路由，把符合條件的 IP 封包導向這張網卡。用戶端核心（例如 Clash Meta／Mihomo）在 TUN 介面上讀取封包後，再依你的 rules 與 proxy-groups 決定要走哪個節點、或是否直連。因為這發生在更接近網路堆疊底層的位置，所以不需要應用程式主動支援代理，也能讓多數 TCP／UDP 流量進入同一套路由決策流程。
也因此，社群常把 TUN 描述成「更接近 VPN 體驗」：它不是把 VPN 隧道加密包起來那種技術路線，但在「讓系統層流量集中進入同一個轉送點」這件事上，體感會比單純系統代理更接近全域接管。若你想先把 Clash 的基本名詞與文件入口整理清楚，建議先瀏覽站內的說明文件總覽，再回到本文逐步設定。
系統代理與 TUN：差異一眼看懂
如果把網路連線想成「從 App 到網際網路的一條水管」，系統代理比較像在水管出口貼一張告示：請支援代理的程式改走這個門。TUN 則像在水管中途加了一個分水站：只要路由表把水流導進來，就會被集中處理。
系統代理的主要限制在於應用程式配合度。許多程式會使用自己的網路堆疊、或明確設定不使用系統代理。相對地，TUN 模式通常能覆蓋更廣的 TCP／UDP 情境，特別適合你遇到「只有瀏覽器生效」這類典型痛點。
但 TUN 也不是沒有成本：它需要安裝驅動或授權輔助工具、常常需要管理員／系統層權限，且一旦規則或 DNS 設定不當，更容易出現「整台電腦突然全斷線」的感受。換句話說，TUN 更強大，也更值得你花時間把規則、DNS、自動路由三件事設定穩。
什麼情境應該開 TUN？什麼情境先別急
優先建議開 TUN 的典型情境包括：你希望遊戲或語音軟體走代理或走規則分流；你在終端機使用 git、npm、curl 等工具，但不想每個工具各自設定代理環境變數；你使用的程式不讀系統代理，卻仍需要依網域或 IP 做分流；或你希望 DNS 查詢也納入同一套路由策略，降低 DNS 洩漏造成的「以為有代理、實際解析仍在本地」的落差。
可以先維持系統代理的情境也有：你只在乎瀏覽器上網；公司環境對虛擬網卡與驅動安裝有嚴格控管；或你暫時只需要快速測試節點延遲與可用性。此時把 TUN 留給「真的遇到死角」再開，通常更省心力。
設定檔裡最常見的 TUN 相關欄位（Mihomo／Clash Meta）
不同核心的鍵名可能略有差異，但在 Mihomo 生態中，常見會看到 tun 區塊。你可以先掌握幾個高頻概念：enable 決定是否啟用；stack 關乎封包處理堆疊（常見如 system 與 gvisor，實際可用選項請以你使用的核心版本文件為準）；auto-route 通常用來協助自動寫入系統路由，降低手動維護成本；strict-route 則與避免流量繞路相關，設定過度激進時也可能提高相容性風險。
另一個常被忽略、卻非常影響體感的是 DNS。TUN 模式下，若 DNS 仍停留在「由不相干的介面解析」，可能出現某些網站看似能開、但實際走錯線路或解析結果不一致。許多使用者會搭配 fake-ip 或 DNS 劫持相關策略，讓查詢與連線決策更一致。這裡不鼓勵抄一段來路不明的設定檔直接套用；比較穩健的做法是：先理解你訂閱提供的預設 DNS 段落，再逐步調整，並用瀏覽器與終端機交叉驗證。
若你採用「規則分流」而非整包全域節點，請務必確認 rules 的優先順序合理：例如本機與區網應先放行，避免把區網印表機或 NAS 導去代理。建議延伸閱讀站內的規則分流教學，建立「先直連、再代理」的直覺。
Windows：如何正確開啟 TUN（權限、驅動、常見卡關）
在 Windows 上，TUN 幾乎永遠繞不開兩件事：系統管理員權限與虛擬網卡驅動。多數 Clash Meta 圖形用戶端會在首次啟用 TUN 時提示安裝驅動；若你習慣雙擊啟動但沒有提升權限，可能會出現驅動安裝失敗、或路由寫入不完整，外觀就像「開了 TUN 但世界仍不變」。
建議流程是：先從本站用戶端下載頁取得可信來源的安裝包並完成安裝；接著以系統管理員身分啟動用戶端；在設定中啟用 TUN；最後用工作管理員或網路介面清單確認虛擬網卡已出現。若你曾安裝過其他同類軟體，請留意是否留下舊驅動或舊網路介面，必要時在裝置管理員清理後再重新安裝。
Windows 另一個常見誤解是：以為只要勾選 TUN，所有程式就會自動走代理。實際上仍取決於路由與規則。若你遇到「開 TUN 後整台斷線」，請優先檢查是否誤把預設閘道或必要路由改壞、或 DNS 被導到無法連線的伺服器。除錯時最有效的動作通常是先關閉 TUN，確認系統恢復，再縮小問題範圍。
macOS：輔助工具授權、系統設定與 Sequoia 注意事項
macOS 的路徑與 Windows 不同：你更常遇到的是「輔助工具」授權、以及系統對第三方網路延伸的提示。多數用戶端第一次啟用 TUN 會要求輸入登入密碼，請把它視為正常流程，而不是可疑行為——但前提是，你確定下載來源可信。
在較新的 macOS（例如 Sequoia 15.x）上，系統對 VPN／代理類元件的控管更嚴格。若你已授權但仍無法啟動 TUN，可以到「系統設定」裡檢查網路相關權限、描述檔、以及是否被其他安全軟體攔截。與 Windows 類似，除錯時同樣建議先關閉 TUN 與相關自動路由，回到可用狀態再逐步啟用。
若你同時使用公司 MDM 管控的裝置，請先確認是否允許使用者安裝網路驅動或系統延伸。某些企業政策會直接封鎖 TUN 類元件，這時候硬切系統代理或改用允許的方案，反而更符合實務。
Android：VPN 服務權限與「類 TUN」體驗
在 Android 上，許多 Clash 用戶端會以系統的 VPN 服務形式建立本機 VPN，讓流量進入用戶端處理。它的互動方式與桌面 TUN 不完全相同，但使用者目標很接近：讓更多 App 的流量進入同一套路由。首次啟用時系統會跳出 VPN 權限確認，請務必理解這代表用戶端有能力轉送你的網路流量，因此更應該挑選可信來源與持續更新的版本。
常見問題排查：從「沒生效」到「全斷線」
開了 TUN，但特定程式仍像直連
先確認該流量是否真的是 TCP／UDP、以及規則是否把目標位址判成直連。某些程式會使用自己的 DNS 快取，或固定連線到特定 IP；此時可搭配規則中的 IP 規則、或調整 DNS 段落，並用封包側錄工具輔助定位。若你只是要快速驗證 TUN 是否工作，建議先用瀏覽器與終端機各做一次對照測試。
開啟 TUN 後整台網路瞬間掛掉
優先關閉 TUN 並重啟用戶端。若仍無法恢復，可暫時停用虛擬網卡介面或移除剛安裝的驅動，讓系統回到乾淨狀態。這類問題多半與路由、閘道、或 DNS 被導向不可用位址有關，請把最近新增的 auto-route、strict-route 或 DNS 劫持設定列為第一懷疑對象。
瀏覽器正常，但終端機工具不走代理
這正是系統代理最常見的死角之一。當你確認需求是「讓終端機也遵循同一套分流」時，TUN 通常是比反覆設定 HTTP_PROXY 更一致的做法。若你已開 TUN 但仍異常，請檢查該工具是否固定走代理以外的介面，或是否使用了自己的 TLS 指紋與連線策略。
寫在最後：把「能接管」變成「接管得穩」
TUN 模式的本質，是把 Clash 的決策點搬到更接近系統網路的位置，讓「全域代理」不再只是口號，而是可以被規則精準描述的行為。它帶來的自由度很高，但也代表你更需要對 DNS、路由與規則優先順序有基本認識。相較之下，一個持續更新、能把複雜選項用清楚介面收斂的用戶端，會大幅降低你日常維護的心力。
若你正在找可長期使用的 Clash Meta 用戶端，建議優先選擇能一鍵啟用 TUN、並在出問題時容易還原預設的產品路線。比起自行拼湊來路不明的設定檔，從可信下載入口取得安裝包、再搭配本文逐步啟用，通常是最省時間的路。→ 立即免費下載 Clash，開啟流暢上網新體驗