TUN 模式與「系統代理」差在哪？
在 Clash 系 GUI 客戶端中，常會同時看到「系統代理（System Proxy）」與「TUN／虛擬網卡／透明代理」兩類開關。兩者目標都是讓流量經過 Clash 再做規則分流，但生效範圍與技術路徑不同，也是許多「明明開了代理，某個程式卻完全沒反應」的根源。
系統代理通常是把 Windows 或 macOS 的 HTTP／HTTPS（有時含 SOCKS）代理指到本機的 Clash 連接埠。瀏覽器、部分開發工具與會尊重系統設定的應用程式會自動使用；但不讀取系統代理的程式（常見於某些遊戲啟動器、獨立下載器、自帶網路堆疊的應用）仍會直連，行為與沒開 Clash 時相同。
TUN 模式則是在系統裡建立一張虛擬網卡（例如 Windows 上常見的 Wintun 驅動），由 Clash 在較底層攔截或轉送符合條件的 IP 流量，效果上更接近「整機 VPN」的體驗：許多不支援系統代理的程式，只要其流量被正確導向 TUN 介面並符合你的規則，就有機會一併走代理。代價是設定錯誤時，也更容易出現整台電腦突然完全沒網路的現象，因此需要搭配 DNS、路由與規則一併理解。
| 比較項目 | 系統代理 | TUN 模式（虛擬網卡） |
|---|---|---|
| 典型適用對象 | 瀏覽器、多數尊重 OS 代理設定的應用 | 需「透明」轉發、不讀系統代理的程式 |
| 是否需要虛擬網卡／驅動 | 通常不需要 | 需要（如 Wintun）；macOS 可能涉及系統延伸 |
| 權限需求 | 相對較低 | 常需管理員或完整磁碟／網路權限類授權 |
| 設定錯誤時的症狀 | 多為「部分網站打不開」或僅瀏覽器異常 | 較易出現整機無網、區網或 DNS 異常 |
實務上，許多使用者會同時開啟系統代理與 TUN，或依場景切換：日常瀏覽僅系統代理即可；遇到特定軟體不走代理時再開 TUN。無論哪一種，都建議先確認節點可用與規則未把全部流量送到已失效的群組，可搭配我們的YAML 規則分流教學理解 proxy-groups 與規則順序，避免誤以為是 TUN 壞掉，其實是策略組或 Rule Providers 指向錯誤。
開啟 TUN 前建議先完成的四件事
在桌面端第一次啟用 TUN 前，先花幾分鐘確認基礎條件，可大幅降低「一開就斷網」的挫折感。
第一，確認訂閱與節點本身可用。在僅開啟系統代理、且瀏覽器可正常上網的前提下，再切到 TUN。若連系統代理模式都不穩定，應先處理訂閱更新、TLS、時間同步或節點逾時等問題，而非直接歸咎於虛擬網卡。
第二，備份目前可用的設定檔。TUN 往往會與 DNS 模式（例如 redir-host 與 fake-ip）、dns 區塊及 tun 區塊連動。建議在客戶端內匯出或複製一份工作副本，必要時可一鍵還原。
第三，關閉或暫停其他 VPN／整機代理類軟體。兩套程式同時爭奪預設路由或 DNS 時，最容易出現無法預期的路由迴圈或黑洞。測試 TUN 時建議只保留 Clash 相關服務。
第四，確認客戶端核心為 Clash Meta（mihomo）且版本足夠新。舊核心對 TUN、DNS 或新版協定的支援可能不完整。若你尚未升級，可先參考Meta 核心升級教學完成替換，再回來開 TUN。
Windows 11：如何開啟 Clash TUN 模式
Windows 11 上多數基於 Clash Meta 的 GUI（例如 Clash Verge 系列、部分 Clash for Windows 分支）會在設定或側邊欄提供 TUN Mode 開關。實際用詞可能寫成「TUN」「虛擬網卡」「Mixin」搭配 YAML，但使用者層級通常是「開啟開關 → 允許系統提示」。
管理員權限：安裝或首次啟用 TUN 時，Windows 可能跳出使用者帳戶控制（UAC）提示，需允許程式變更系統設定。若你習慣以非系統管理員身分執行客戶端，TUN 可能無法建立介面，表現為開關打開卻沒有虛擬網卡、或立即自動關閉。
Wintun 驅動：常見實作依賴 Wintun。若驅動未正確安裝或被安全軟體攔截，裝置管理員中可能看不到對應網路介面，或事件檢視器中出現驅動載入失敗。可嘗試以官方安裝程式修復安裝、暫時關閉過度積極的網路過濾軟體後再試，並確認 Windows 未處於阻擋未簽署驅動的極嚴格模式（企業環境較常見）。
防火牆與公共／私人網路設定：新出現的虛擬網卡有時會被 Windows 防火牆詢問是否允許連線。若誤拒，可能導致部分流量被阻擋。可到「允許的應用程式」中確認你的 Clash 客戶端在私人與公用網路下均被允許（依你的實際使用環境勾選）。
操作建議：開啟 TUN 後，到「設定 → 網路和網際網路」檢視是否出現新的介面名稱；再開啟瀏覽器測試一般網站與僅在代理下可存取的網站。若僅特定程式異常，請繼續閱讀下文「部分軟體仍直連」一節，通常與程式是否使用自有協定、固定 IP 或略過系統路由有關。
macOS：如何開啟 Clash TUN 與授權項目
在 macOS 上，TUN 同樣依賴虛擬網路介面與核心權限。多數 Clash GUI 會引導你安裝或啟用系統延伸功能（System Extension）、或在「隱私權與安全性」中允許來自開發者的套件。若略過這一步，TUN 開關可能呈現灰色、或開啟後立即失敗。
管理員密碼與完整磁碟取用：部分客戶端在首次建立 TUN 或寫入設定時需要管理員授權。若公司配發的 Mac 有 MDM 限制，可能無法載入協力廠商延伸功能，此時只能改以系統代理或請 IT 開放權限。
與 Apple 內建防火牆／第三方過濾：與 Windows 類似，安全或網路過濾工具可能干擾虛擬介面的封包轉送。排查時可暫時停用實驗，確認是否為衝突所致。
驗證方式：開啟「網路」設定或終端機指令（如檢視介面列表）確認多出一張由 Clash 建立的介面；再以瀏覽器與命令列工具（例如 curl）分別測試，觀察是否都依規則走代理。若瀏覽器正常而終端機異常，常與環境變數 HTTP_PROXY 或規則未涵蓋該目標有關，不一定代表 TUN 未啟動。
開啟 TUN 後整機上不了網：建議排查順序
這類問題最令人焦慮，但多數可依固定順序縮小範圍。
步驟一：先關閉 TUN，恢復連線。若關閉後網路立刻恢復，表示問題與虛擬網卡、路由或 DNS 劫持路徑相關，而非寬頻本身斷線。
步驟二：檢查 DNS 設定與 fake-ip。開啟 TUN 後，DNS 請求往往改由 Clash 處理。若 dns 區塊指向無法連線的上游、或與 tun、fake-ip-filter 搭配不當，可能出現「所有網域都無法解析」。可對照客戶端日誌中 DNS 錯誤訊息，暫時改為較保守的 DNS 上游測試。
步驟三：檢查預設路由與「繞過中國大陸 IP」類規則。部分規則集會大規模寫入路由；若與本機區網、公司內網或特殊網段衝突，可能導致預設閘道異常。可搜尋設定檔中 auto-route、自訂路由或訂閱附帶的腳本是否改動了系統路由表。
步驟四：確認沒有代理鏈或迴圈。例如系統層另有 HTTP 代理指向 Clash，而 Clash 又將出口再指回本機服務，會造成連線堆疊失敗。測試時可暫時關閉系統代理，僅保留 TUN，或反之。
步驟五：閱讀當次日誌等級。將日誌調為 debug 或 info（依客戶端支援），重現斷網當下是否有大量 dial 失敗、TLS 握手錯誤或規則命中到 REJECT。有時「感覺沒網」其實是所有連線被規則拒絕，與虛擬網卡無關。
部分軟體仍直連：常見原因與處理方向
TUN 並非魔法：若某程式使用硬編碼 IP、自有 VPN 通道，或僅在特定網卡上發送流量，仍可能略過 Clash 期望的路徑。
原因一：程式不經過預設路由。少數應用可指定網路介面；若鎖定在實體網卡而非 TUN，流量就不會進入 Clash。需在該軟體內改為自動或預設路由。
原因二：規則將該流量標記為 DIRECT。若 Rule Providers 或本機規則對該網域／IP 使用直連，行為符合設定，但使用者會誤以為「TUN 沒開」。請用客戶端的連線記錄或日誌確認命中規則。
原因三：UDP／QUIC 與協定分流。部分網站與應用重度使用 QUIC；若節點或策略對 UDP 支援不佳，可能出現「網頁能開但影片卡頓」或「只有某協定失敗」。可嘗試在瀏覽器暫時關閉 QUIC 做對照測試。
原因四：本機與區網應排除。開發者常需讓 localhost、區網段不走代理。若排除規則寫得太寬，可能誤傷其他流量。可參考開發者分流教學中關於本機回環與 IP-CIDR 繞過的寫法，依自己的環境微調。
寫在最後：先把模式分清楚，再談進階玩法
Clash 在桌面端的強項，在於同一套規則可以搭配系統代理或TUN 虛擬網卡兩種承載方式：前者輕量、相容性問題較少；後者覆蓋面廣，但對 DNS、路由與權限要求更高。理解兩者差異後，遇到「開 TUN 就斷網」或「只有某幾個程式不走代理」時，就能依序從權限、驅動、DNS、路由與規則命中著手，而不是反覆重裝客戶端。
相較需要手動拼湊核心、驅動與設定的組合，一體化設計的 Clash 客戶端通常已把 TUN、DNS 與 Meta 核心的相容性預先處理好，訂閱匯入後即可在圖形介面中切換模式並查看連線紀錄，對日常使用者友善許多。若你希望減少折騰、把時間花在規則與節點品質而非環境修補上，可以從本站提供的安裝包開始：
更多策略組設計、Rule Providers 與 DNS 防洩漏觀念，歡迎繼續瀏覽技術專欄內其他文章，與本文搭配閱讀效果更佳。