TUN 模式與系統代理怎麼選？完整對比與建議
在 Clash Verge Rev、FlClash 這類用戶端裡，最常讓人猶豫的兩個開關就是系統代理與 TUN 模式。一句話區分：系統代理是「請應用程式自己走代理」，TUN 模式則是「在網路層直接把流量接走」。前者輕巧、不需要額外權限；後者覆蓋徹底，但要求更高的系統權限。
兩者不是新舊世代的關係，也沒有誰絕對比較好。差異的根源只有一個：誰決定流量要不要走代理。這一點會連帶影響覆蓋範圍、權限需求，以及出狀況時的疑難排解難度。
下面先用一張表把差異攤開，再談實際情境該怎麼選。想補基礎的話，可以搭配系統代理的原理說明與TUN 模式詳解一起看。
TUN 模式與系統代理對比表
| 比較項目 | 系統代理 | TUN 模式 |
|---|---|---|
| 工作層級 | 作業系統層的代理設定，本質是一種宣告 | 建立虛擬網路卡，在網路層接管 IP 流量 |
| 覆蓋範圍 | 只涵蓋願意讀取系統代理設定的程式 | 幾乎所有對外連線，不需要程式配合 |
| 權限需求 | 一般使用者權限即可 | 需要較高權限（Windows 需服務模式或系統管理員） |
| 設定複雜度 | 開關按一下就好 | 首次要安裝服務或授權，並留意 DNS 設定 |
| 疑難排解難度 | 低，關掉開關就回到原狀 | 較高，可能與其他 VPN、虛擬網路卡互相干擾 |
| 典型適用情境 | 瀏覽器、一般桌面軟體 | 遊戲、指令列工具、不理會代理設定的程式 |
覆蓋範圍為什麼差這麼多
系統代理的本質是作業系統提供的一組設定值：位址、連接埠、例外清單。應用程式啟動時「自願」去讀這組設定，讀了就走代理，不讀就直接連出去。瀏覽器幾乎都會遵守，所以開了系統代理之後網頁能通，是很正常的結果。
問題出在那些不讀設定的程式：部分遊戲、自帶網路模組的桌面軟體，以及多數指令列工具。它們會繞過代理直接連線，這正是「網頁開得起來、但某個程式就是連不上」的典型原因。指令列工具還有救——可以自己設 http_proxy 與 https_proxy 環境變數；但寫死在程式內部的連線邏輯，你從外面改不了。
TUN 模式的作法完全不同。它建立一張虛擬網路卡，把系統的對外流量在網路層引導進 mihomo 核心處理，程式端根本不需要知道代理存在，也就沒有「自願不自願」的問題。需要全域接管時，這是比較可靠的路徑。
權限、穩定性與效能怎麼取捨
覆蓋範圍換來的代價是權限。TUN 要操作虛擬網路卡與路由，Windows 上通常得先安裝服務模式或以系統管理員身分執行，macOS 與 Linux 也會跳出對應的授權要求。系統代理則只是改寫使用者層級的設定，開關幾乎沒有副作用。
穩定性方面，系統代理的失敗模式很單純：不是沒生效，就是設定殘留。TUN 牽涉虛擬網路卡與 DNS 接管，變數比較多——同時裝了其他 VPN 軟體、公司網路本來就有的路由規劃，都有機會互相打架。至於效能，兩者的差距在日常使用中通常不是重點，真正左右速度的是節點品質與線路狀況。
提醒：TUN 模式接管流量後，DNS 通常也交由核心處理。如果開啟後完全沒有網路，優先檢查 DNS 相關設定，而不是急著換節點。
日常該開哪一個
給多數人的建議其實很簡單：
- 只是用瀏覽器查資料、看影片：系統代理就夠了，開關方便，出問題也好復原。
- 發現某個程式繞過代理（遊戲、下載工具、開發用指令列）：改開 TUN 模式，或至少在該情境下開啟。
- 行動裝置上不必糾結：CMFA 與 FlClash 的 VPN 模式本質上就等同 TUN，授權一次之後照常使用即可。
還沒安裝桌面用戶端的話，可以到下載中心取得 Clash Verge Rev 2.5.2，兩種模式都在同一個介面裡切換（介面配置可能隨版本略有差異，以你手上的版本為準）。
兩個同時開啟會怎樣
技術上可以同時開，實務上不建議在排查問題時這麼做。流量可能先被系統代理接走、也可能先進入虛擬網路卡，路徑一旦不確定，你就很難判斷某個現象到底是誰造成的。
養成一個習慣：排錯時一次只開一個。先只留系統代理，確認網頁是否正常；再只留 TUN，確認全域接管有沒有生效。若過程中冒出其他錯誤訊息，可以對照常見錯誤疑難排解逐項處理。
結論清單
- 系統代理＝應用程式自願遵守；TUN＝網路層強制接管。
- 權限需求：系統代理低，TUN 高（Windows 需服務模式或系統管理員）。
- 網頁通、但單一程式不通 → 那個程式多半不讀系統代理，改用 TUN。
- TUN 開啟後全面沒網 → 先看 DNS 與其他 VPN 軟體是否衝突。
- 排查問題時一次只開一個，不要兩個一起試；不確定就從系統代理開始。