一、這篇文章解決什麼：開 TUN 與授權主線
TUN 模式在 macOS 上的用途，可以用一句話概括：讓不依循系統 HTTP／SOCKS 代理欄位的程式，仍能把 IP 封包交給本機的 Mihomo 做規則與策略決策。相較之下，若僅啟用系統代理而不開 TUN，則多半只改寫「會去讀系統設定」的那一條路徑；兩者不是互相取代的同一顆按鈕，而是兩種不同層級的導流手段。也因此，開 TUN 時你幾乎一定會碰到 Apple 對網路延伸與系統延伸的核准流程——這不是 Verge Rev 獨有，而是平台安全模型的一環。
本站另有一類主題專門處理「Windows 上開 TUN 後整機斷線、WFP、虛擬介面卡」等長鏈路排障；那條路在企業環境與防火牆互動上很常見，但與「在 Mac 上把 TUN 打開並完成授權」是不同取向。本篇把讀者帶到：介面操作 → 系統允許延伸 → 設定檔 tun 區塊合理 → 用觀測手段確認路由與連線是否命中預期。若你在過程中遇到的是「開關顯示成功、Safari 卻仍像直連」且尚未用到 TUN，請改從 《Clash Verge 在 macOS 上系統代理不生效》那條權限軸切入，再回到本文啟用 TUN，會省下大量試錯時間。
二、開始之前：核心、設定檔與競品軟體
在碰 TUN 之前，請先用最小成本確認底層沒壞：Clash Verge Rev 已啟動、Mihomo 日誌或狀態列顯示核心運行中、訂閱或本機設定檔能成功套用，且你能在用戶端內看到節點清單。若你習慣先靠系統代理上網，請確認混合埠或 HTTP 埠與「系統設定 → 網路 → 代理」一致；這一步通過，代表「寫入 macOS 網路設定」這條鏈路大致可用，後續再把流量搬到 TUN 時，也比較不會把問題全怪到延伸授權。
同機若還開著其他商用 VPN、公司全域代理、內容過濾或宣稱「最佳化網路」的工具，常常是虛擬介面先被佔用或routing table 先被改寫。入門驗收建議短暫只保留 Verge Rev，減少變數。若裝置受 MDM 管理，延伸載入可能被政策攔截，此時再怎麼在 GUI 裡打開 TUN 也無法載入驅動，需要先與管理單位確認。
fake-ip、dns 與規則集，請一次只改一個軸，並保留可在用戶端一鍵關閉 TUN 的後路，避免把自己鎖在無法連回管理介面的狀態。
三、在 Clash Verge Rev 介面啟用 TUN
不同版本的選單命名會微調，但主線幾乎一樣：在側邊或設定頁找到與「TUN」「虛擬網路介面」「增強模式」語意相近的開關，先閱讀一行說明文字再切換。首次開啟時，系統常會彈出需要授權延伸的對話；請不要略過，因為 macOS 會把你當下的選擇記錄下來，日後可在「隱私權與安全性」回溯。
開關切換後，建議觀察兩件事：一是用戶端是否提示重啟核心或自動重載成功；二是日誌是否仍出現持續的 permission denied 或 extension 相關錯誤。若介面顯示「已啟用」但日誌每秒刷拒絕訊息，代表GUI 狀態與實際載入延伸脫鉤，此時應回到下一節處理系統層，而不是先改規則。
與規則模式（Rule／Global／Direct）的關係
TUN 負責「把封包送進來」；規則模式負責「進來之後怎麼分流」。若你想測試 TUN 本身是否工作，可短暫切到較粗的策略做對照，但請理解這會改變出口與日誌形貌，測完記得回到日常設定。長期仍建議維持規則分流，讓境內常用服務直連，降低延遲與計費噪音。
四、macOS 系統延伸與網路延伸授權
在較新的 macOS 上，能攔截或轉送系統流量的模組，多半走 Network Extension 一類機制；對使用者而言，最直觀的入口仍是「系統設定 → 隱私權與安全性」裡與系統延伸、允許來源相關的區塊。當你在 Verge Rev 第一次開 TUN，若畫面要求你打開系統設定並按下「允許」，請在數分鐘內完成，逾時有時需要重開機或重新觸發一次開關。
也常見「輔助使用」「登入項目」與延伸授權交織：例如用戶端 helper 沒隨登入啟動，導致你在選單列點了開啟，實際延伸卻沒載入。可把 macOS 系統代理與網路延伸排查中關於登入項目與輔助使用的段落當作清單，逐項勾掉；那篇文章以系統代理現象切入，但權限層與 TUN 高度重疊。
升級小版本 macOS 後，偶爾需要「重新允許」延伸；若你剛更新系統就出現 TUN 失效，優先檢查隱私權頁面是否出現黃色提示，而不是先懷疑機場節點故障。
五、核對 YAML：tun 區塊與合併結果
圖形介面開關最終仍會對應到 Mihomo 可理解的設定。你可以在進階編輯、完整設定或「合併預覽」裡找 tun: 區段，確認 enable 為真，並留意 stack（常見為 system、gvisor、mixed 等，實際支援度以核心版本為準）。下列為教學用骨架，實際鍵名與預設請以你使用的核心說明與訂閱產物為準，不要照抄後抱怨與機場模板衝突：
tun: enable: true stack: system auto-route: true auto-detect-interface: true # dns-hijack 等欄位是否啟用，請對照你的 DNS 與 fake-ip 策略
若你使用遠端訂閱，遠端產生的完整設定可能已含 tun，而被本地開關再覆寫一次；也可能相反——遠端關閉、本地想開。遇到「介面說開、合併結果卻是關」時，請以合併後最終 YAML為準，必要時在 Verge Rev 提供的覆寫（override／mixin）區塊寫入你想要的 tun，再重載。
權限與 YAML 是兩個正交維度：延伸沒核准時，設定寫得再漂亮也不會真的建起虛擬介面；延伸已核准但 auto-route 與你手動靜態路由衝突時，則會出現「部分網段繞過 TUN」的現象，需要回到網路拓樸思考，而不是單純換節點。
六、路由與連線紀錄：確認真的走核心
完成授權後，第一個實務驗證是用 Clash Verge Rev 內建的連線或日誌面板：在瀏覽器造訪你信任的測試站、或啟動一個先前不走系統代理的 App，觀察是否出現對應目標網域或 IP 紀錄。若完全沒有新連線卻聲稱已開 TUN，要懷疑虛擬介面未建立或路由未接管。
第二層驗證可用內建或熟悉的終端指令粗查路由（需自行承擔指令輸入風險）。例如在「終端機」執行 netstat -nr 或 route -n get default，把輸出與 TUN 介面存在與否交叉比對：預設閘道與介面名稱在開啟前後是否出現合理變化。這不是為了變成網路工程師，而是用最低成本回答「路由有沒有變」這個問題。若你主要關心命令列工具是否走代理，亦可延伸閱讀 終端機環境變數與混合埠對齊；該文與 TUN 可並用：TUN 管「未設環境變數的行程」，環境變數則對齊顯式走本地 HTTP 埠的工具。
請勿過度依賴來路不明的「查 IP」網頁；若要做出口比對，挑你長期信任且可驗證網域的服務，並理解任何第三方頁面都可能記錄查詢行為。
七、系統代理與 TUN：何時二選一、何時並行
下表整理日常決策時最常用的對照，實際開關仍以你使用的版本文案為準：
| 項目 | 系統代理 | TUN |
|---|---|---|
| 適用程式 | 會讀取 macOS 系統代理設定的瀏覽器與多數圖形 App。 | 更多底層 socket、忽略系統代理欄位的程式也有機會被納管（仍受規則與策略限制）。 |
| 權限成本 | 主要是寫入網路設定與可能的輔助使用授權。 | 通常必須處理網路延伸／系統延伸，並接受對路由表的改動。 |
| 除錯感受 | 問題多半集中在埠號、被覆寫的代理、瀏覽器外掛。 | 需同時看核心日誌、虛擬介面與 DNS／fake-ip 政策是否打架。 |
實務上，很多人會「系統代理常駐、必要時再加 TUN」——這在 Mac 上可行，但驗收請以連線紀錄與出口為準，不要只看兩個開關都是綠燈就以為沒有疏漏。若你發現開 TUN 後只有瀏覽器異常，先回頭查是否安裝了會劫持本機埠的瀏覽器外掛或安全工具，再進階懷疑規則。
八、常見問題
macOS 上開 TUN 一定要連同系統代理一起開嗎？
不一定。許多情境僅 TUN 就足以把多數程式導入 Mihomo；但若你仍依賴瀏覽器或工具只讀系統代理欄位，可暫時並開兩者做對照。重點是避免同一流量被多層改寫卻未察覺，驗收時以連線紀錄為準。
按下開啟 TUN 後 macOS 跳出系統延伸封鎖怎麼辦？
到「系統設定 → 隱私權與安全性」查看是否出現需允許的延伸項目，必要時重新開機後再開 App 觸發一次；企業管理或第三方 MDM 可能限制延伸載入，需先與管理員確認。
YAML 裡沒有 tun 段落，介面卻顯示 TUN 已開？
圖形介面可能注入預設 tun 片段或透過 Mixin 合併；請在完整合併後的設定檢視中確認實際生效欄位。若合併結果與預期不同，改用使用者覆寫區塊明確寫入 tun，並重載設定。
九、小結
把 Clash Verge Rev 在 macOS 上的 TUN 模式開好，關鍵不是你的規則寫得多炫，而是延伸授權是否完成、合併後 YAML 的 tun 是否真如預期，以及你是否用連線紀錄與路由觀測確認流量真的進了 Mihomo。與花上整晚改機場模板相比，先把這條主線跑通，通常更能穩定日常上網體驗。
市面上不少「一鍵全域」工具把細節藏在使用者看不到的後台，短期省事，長期卻常犧牲規則可觀測性與跨平台一致性。相較之下，Clash 生態的長處在於規則語意清楚、社群範本與教學多，且有像 Verge Rev 這類圖形殼把 Mihomo 的能力拆成可理解的開關；缺點則是你必須願意理解 macOS 的系統延伸流程——一旦跨過門檻，後續維護成本往往低於反覆更換封閉工具。若你希望一次取得各平台安裝資源並延續本站教學架構，歡迎前往下載頁取得最新連結。