Clash TUN 模式完全指南：開啟全域代理，徹底解決應用程式不走代理問題

為什麼開了代理，有些程式仍然「不走代理」？

在 Clash 生態中，常見的系統代理（System Proxy）多半只會告訴瀏覽器或少數會讀取系統設定的應用程式：請把 HTTP／HTTPS 流量送到某個本機埠。這種做法門檻低、設定快，卻有明顯邊界：不遵守系統代理的程式、純 UDP 或自訂協定、以及硬編碼直連的連線，都可能完全繞過你以為已經開好的「全域」效果。

TUN 模式（在實作上常與虛擬網路介面、行動裝置的 VPN 通道並稱）則往下一層移動：由系統核發一個虛擬網路介面，讓符合路由規則的流量先進入 Clash／Mihomo 核心，再依規則分流或轉送到節點。概念上，它更接近「透明攔截」，而不是「請應用程式自律去用代理」。因此，當你的目標是盡量讓多數應用程式的 TCP／UDP 都納入同一套規則時，TUN 往往是比單純系統代理更穩健的選項。

系統代理與 TUN：差異到底在哪裡？

用一個粗淺但實用的對照來說：系統代理像「在路口立告示牌」，懂得看告示的程式會改道；TUN 像「在特定路段設檢查哨」，只要路由把車流導向該介面，就較難靠「不理告示」直接繞開。技術上，系統代理多數只涵蓋瀏覽器生態系常見的 HTTP 代理語意；而 TUN 則可在核心支援範圍內處理更廣的 IP 層流量型態（實際仍受核心能力、規則與作業系統限制）。

也因此，若你發現「只有 Chrome／Edge 生效，終端機的 curl、某款遊戲啟動器、或是自架服務的連線測試仍顯示本機 IP」，第一步不是急著改規則，而是先確認：這些流量是否真的進入了核心。在許多案例中，開啟 TUN 或等效的虛擬介面模式後，問題會立刻縮小到「規則怎麼寫」與「DNS 是否洩漏」，而不是「程式根本沒走代理」。

TUN 模式在作業系統裡如何運作？

當你啟用 TUN，用戶端通常會向作業系統註冊一個虛擬網路介面，並下發一組路由或策略，使得目標流量被導向該介面。Clash／Mihomo 核心在收到這些封包後，會進行還原、比對規則集，再決定直連、拒絕或送往某個 proxy-groups 所選的節點。這條路徑一旦打通，應用程式本身往往不需要支援 HTTP 代理，也能被納管——這正是許多人所說的「全域」感知的來源。

要注意的是，「全域」並不等於「百分之百所有位元組都會進核心」。作業系統仍可能保留本機回環、區域網段、或特定繞過清單；某些安全軟體、企業管理政策或其他 VPN 也可能佔用唯一的 VPN 槽位（在行動裝置上特別常見）。因此實務上仍建議把 TUN 理解為在合理範圍內盡量統一出口，而不是魔法開關。

設定檔中的 TUN 區塊：該關心哪些欄位？

在 Mihomo（Clash Meta）系家族的設定中，常見會看到 tun 相關選項，例如是否啟用、堆疊模式（stack）、以及自動路由等。不同版本與用戶端包裝會以 GUI 開關呈現，但底層觀念類似：啟用代表核心嘗試建立虛擬介面；stack 則關係到使用系統堆疊、使用者態實作或其他折衷方案，對相容性與效能會有不同取捨。

若你在某個 stack 下遇到特定遊戲斷線、P2P 異常，可記錄時間點並嘗試切換 stack 或暫時改回系統代理對照——這屬於典型的「環境相依」問題，未必是節點故障。任何進階 YAML 修改前，建議先備份設定檔，並以最小變更逐步驗證。

DNS 與 TUN：為什麼「能開網頁」仍可能洩漏意圖？

許多使用者只看瀏覽器能否開啟頁面，卻忽略 DNS 查詢可能仍走向系統預設解析路徑。當核心嘗試做 fake-ip、或希望由內部 DNS 模組統一處理時，若作業系統或應用程式繞過核心的解析流程，就可能出現「網頁看似正常、規則卻怪異」的現象。這也是為什麼在啟用 TUN 之後，仍要一併檢視 DNS 相關設定與是否啟用「劫持／覆寫」類功能——名稱依版本而異，但精神一致：讓查詢與連線決策盡量在同一套邏輯內完成。

若你使用 fake-ip 模式，更要理解它本質上是一種加速與匹配規則的機制，搭配不當的略過清單或本機服務，可能衍生看似「解析錯誤」的症狀。遇到疑難時，可先切換較保守的 DNS 模式做 A／B 測試，並保留日誌片段以便比對。

Windows：服務模式、管理員權限與常見卡點

在 Windows 上，GUI 用戶端（例如 Clash Verge Rev）通常會提供 TUN 開關與「服務模式」選項。服務模式的意義在於：即使未登入桌面工作階段，背景仍可能有元件以較高權限維持轉送能力，對開機啟動與長時間連線較友善。若你只以一般使用者身分執行、又拒絕 UAC 提示，TUN 介面可能無法成功建立，最後表現成「按了開關卻沒效果」。

此外，第三方防毒、防火牆、或公司端點管理軟體，偶爾會攔截虛擬介面驅動程式的載入。排除方式沒有單一標準答案，但可優先嘗試：暫時關閉即時掃描做交叉測試、檢查是否同時安裝了其他 TUN／VPN 產生器、以及確認 Windows 版本是否過舊導致驅動不相容。每個環境不同，重點是把「權限」與「驅動載入」列為首要檢查項。

macOS：系統延伸、隱私權與「為什麼一直要我核准？」

在較新的 macOS 上，網路延伸與系統延伸權限是常見門檻。首次啟用 TUN 時，系統可能要求你進「隱私權與安全性」手動允許來自開發者的延伸功能；若略過，介面可能顯示已開啟，實際卻沒有封包進核心。建議依照用戶端官方文件的順序操作，並在更新 macOS 小版本後重新檢查延伸是否被重置為拒絕。

若你同時使用其他 VPN 用戶端，也可能發生延伸衝突或路由表互相覆寫。此時可嘗試只保留一個會修改全系統路由的軟體啟用，其他完全結束程序，再測試 Clash 的 TUN 是否恢復正常。

Linux：tun／tap 裝置與權限

在 Linux 桌面或伺服器環境，核心通常已具備 TUN 能力，但使用者是否需要額外群組權限（例如存取 /dev/net/tun）則依發行版與安裝方式而異。若你以 systemd 服務執行，請確認服務使用者的 capabilities 是否足夠；若以一般使用者執行 GUI，則要留意發行版對網路命名空間與政策（例如 SELinux、AppArmor）的限制。

除錯時可搭配 ip route、ip addr 觀察路由是否如預期指向 utun／tun 類介面，並對照核心日誌。相較於 Windows／macOS，Linux 的可塑性高，但也代表發行版差異會更明顯，教學步驟不宜硬套。

Android：VPN 權限與「同時間只能一個 VPN」

在 Android 上，與 TUN 等效的能力幾乎都透過系統 VPN 介面呈現。使用者授權後，系統會建立一條通道，讓流量依應用程式與路由設定進入 Clash 類用戶端。若你發現只有瀏覽器可走代理，優先檢查是否曾拒絕 VPN 權限、或是否已有另一個 App 佔用 VPN 連線。

部分廠牌還會在「省電」「背景限制」中斷長連線，導致 TUN 看似隨機斷線。將應用程式設為不受背景限制、允許背景資料，往往比反覆重啟節點更有效。更多行動端操作脈絡可延伸閱讀本站 教學文件 與 FlClash 相關篇章。

「全域模式」與 TUN 的關係：別把名詞混在一塊

在 Clash 介面上，Global／Rule／Direct描述的是規則如何挑選節點；TUN 則描述流量如何進入核心。你可以同時開啟 TUN 並使用 Rule 模式，讓大多數程式進核心、但仍依規則把在地影音或區網流量直連；也可以（在理解後果的前提下）使用 Global，讓可代理的流量預設走同一策略群組。兩者是正交概念，混在一起思考容易誤判問題根源。

實務上，建議預設仍以 Rule 為主，必要時短暫切換 Global 做對照測試，確認症狀是否來自規則匹配而非「沒進核心」。測試完記得切回，避免長時間把所有流量送往單一路徑造成延遲或額度消耗。

除錯檢查清單：依序排除最有效率

• 確認 TUN 真的建立成功：作業系統是否彈出權限視窗、用戶端日誌是否出現介面建立失敗訊息。
• 確認沒有其他 VPN 搶占：特別是行動裝置與企業管理環境。
• 確認規則與 DNS 一致：流量已進核心卻仍異常時，再檢視規則與解析路徑。
• 對照系統代理-only 情境：關閉 TUN、只開系統代理，若問題立刻復現，代表原本就與「未進核心」有關。
• 保留最小可重現步驟：哪個應用程式、哪個網域或連線埠、何時開始異常，有助於縮小範圍。

結語

總結來說，若你的痛點是「只有部分程式尊重代理」，將視角從「再加一條規則」轉成「先讓流量穩定進核心」，通常會省掉大量無效嘗試。TUN／透明代理正是處理這個層次的工具；它不是萬能，但在正確權限與乾淨網路環境下，往往是桌面與行動平台上最接近「全系統統一出口管理」的實務解。

相較於四處搜尋過期設定片段，使用持續維護的核心與官方或本站整理的用戶端，通常較能跟上協議與系統 API 的變化。若你尚未安裝合適的 Clash 用戶端，建議先從本站下載頁取得對應平台版本，再依 Verge Rev 教學 或文件完成訂閱匯入與模式切換。