為什麼 macOS 上的 TUN 要先過「系統擴展」

在 Windows 或 Linux 上，TUN 模式多半牽涉驅動程式、CAP_NET_ADMIN 或防火牆規則；而在 macOS，Apple 把「會改變網路堆疊行為」的元件收斂到 系統擴展（System Extension）與 Network Extension 框架底下。多數 Clash 圖形客戶端若要建立虛擬網路介面、寫入路由或攔截流量，會以網路擴充功能／篩選器的形式載入；若未通過系統簽章與使用者明確授權，系統會直接阻擋載入，表現為「TUN 開了但沒介面」「日誌顯示 extension 失敗」或通知列出現系統擴展被阻擋。這與單純在本機埠監聽的系統代理不同：後者多半只需在「網路」設定裡指向 127.0.0.1 埠，不必載入核心層擴充。

也因此，排查 macOS 上的 Clash TUN，建議把問題拆成兩條軸：授權軸（系統是否允許該開發者的擴充載入、是否需在「隱私與安全性」按允許）與路徑軸（流量究竟走 TUN、系統代理、還是被其他 VPN／描述檔搶先）。若你對 TUN 與規則的整體關係仍不熟，可先讀 TUN 模式深度解析，再回到本文處理 macOS 特有的權限與介面問題。

ℹ 先釐清目標：若連虛擬介面都沒建立，請優先處理系統擴展／Network Extension 授權；若介面正常卻「只有瀏覽器生效」，再對照系統代理與應用程式是否支援兩條線。

「系統擴展被阻擋」：隱私與安全性裡的授權步驟

第一次啟用 TUN 或更新客戶端後，macOS 可能跳出提示，要求你在系統設定 → 隱私權與安全性（較舊系統為「安全性與隱私」）中允許來自開發者的系統軟體或系統擴展。若你錯過通知，通常仍可在同一頁面底部看到「已阻擋系統軟體」之類的條目，並提供允許按鈕；按下後往往需要重新開機或至少登出再登入，擴充才會穩定載入。部分情境下還需先解除MDM／描述檔對協力廠商核心的限制，企業配發的 Mac 尤其常見。

從 Ventura 起，Apple 對未簽章或使用者未明確同意的核心擴充更嚴格；若你的客戶端文件提到需開啟開發者模式（Developer Mode）或降低 SIP，請僅在理解風險且來源可信的前提下操作，並優先選擇有正規簽章、可從官網或本站下載頁取得的版本。取得安裝檔時，建議以本站 客戶端下載 為主路徑，再於需要時另行查閱上游開源倉庫的簽章與發行說明。

授權完成後，請在客戶端內關閉再開啟 TUN一次，並觀察是否出現 utun／自訂介面名稱；若仍失敗，請複製日誌中與 NEProvider、SystemExtension、codesign 相關的錯誤行，對照該客戶端 macOS 版常見 issue，而不是先改 YAML。

Network Extension、Helper 與權限對齊

多數 Clash 圖形介面會把特權操作（建立 TUN、改路由）放在Helper或登入項目裡，主程式則以一般使用者身分跑設定與 UI。若你曾拒絕過「輔助程式」相關權限，或用手動方式刪過 LaunchDaemons／登入項目，可能出現「介面顯示已開啟、底層其實沒掛上」的半套狀態。建議在系統設定 → 一般 → 登入項目與延伸功能（路徑隨 macOS 版本略異）中，確認該應用程式關聯的網路延伸功能已啟用，並排除被別的管理軟體關閉。

Network Extension與舊式 kext 不同：Apple 鼓勵新應用走使用者空間的延伸模型。若你的客戶端仍附帶核心擴充（kext），在較新 macOS 上可能需額外核准步驟，且與 Apple Silicon／安全啟動策略互動更複雜。實務上優先採用已適配新版延伸模型的客戶端分支，通常比堅持舊 kext 路線更少摩擦。

與 Linux 上 Ubuntu TUN 與 systemd 一類文章對照，macOS 少了 systemd，但多了簽章與 Gatekeeper這一層：排錯時請習慣同時看「應用程式日誌」與「系統是否允許擴充載入」，兩者缺一都會誤判。

TUN 與系統代理同開：重疊與路由混亂

常見誤區是同時勾選系統代理（HTTP／HTTPS／SOCKS）與TUN，以為「雙保險」。實際上，瀏覽器等尊重系統代理的程式可能把流量送到本機代理埠，而 TUN 又在 IP 層做策略路由，兩條路徑疊加容易出現重複轉發、延遲異常或規則命中不如預期。較乾淨的做法通常是二選一作為主路徑：要全系統、含不支援代理的程式，就優先 TUN；只需瀏覽器與少數 App 走代理，可只用系統代理並關閉 TUN。

若你同時安裝其他 VPN（企業 Zero Trust、商業 VPN），也可能出現路由指標（metric）與預設路由被改寫，導致 Clash TUN 看起來啟動了，實際出口仍走另一張虛擬網卡。建議在排查時暫停其他 VPN，只保留 Clash，確認穩定後再逐一加回。亦可對照 常見問題 中與模式、DNS 相關的說明，避免把「路由被搶」誤認成「節點慢」。

少數使用者會在「網路」進階設定裡手動填過代理，又在 Clash 內開系統代理，造成代理鏈路繞圈。若你發現只有 Safari／Chrome 異常，可先關閉 Clash 的「設定系統代理」選項、僅保留 TUN，再觀察是否恢復。

部分 App 仍不走代理：沙盒、略過代理與 DNS

即使 TUN 已成功建立，仍可能有程式不經過使用者態代理堆疊：例如具備特殊權限的程式、使用自有網路堆疊的開發工具、或明確略過代理（bypass proxy）的連線。macOS 上還有沙盒與本機網路權限（例如首次連線區網服務時的提示），會讓表象變成「同一台機器，瀏覽器可走代理、某個 App 卻直連」。此時應先看連線日誌是否出現該程式的 flow，若完全沒有，代表流量未進核心；若有卻策略錯誤，再回去調規則。

DNS也是常見分歧點：系統 DNS、VPN 分流的 DNS、與 Clash 內建 DNS 若不一致，會出現「IP 顯示已代理、網站仍打不開」的假像。建議在變更 TUN／代理組合時，固定一種 DNS 決策順序，並在啟用 fake-ip 時同步檢查 fake-ip-filter 與本機／區網名稱，細節可延續閱讀 Fake-IP 與區網路由 專題中的 DNS 段落。

若你使用終端機工具（curl、git），請注意它們常不吃系統代理，除非另設 HTTPS_PROXY 等環境變數；TUN 模式下則通常可一併覆蓋，但若該工具綁定特定介面或走 Unix socket，仍可能例外。這類問題與「權限」無關，而是程式行為，需個別對照。

設定檔 tun 區塊（示意）與客戶端差異

底下為 Clash Meta／Mihomo 風格設定中 tun 區段的示意，實際鍵名、預設值與是否支援 gvisor／system stack，請以你使用中的核心版本與客戶端文件為準。圖形客戶端常把這些選項包成開關，不一定直接暴露 YAML。

config.yaml — tun block (illustrative, verify against your core)

tun:
  enable: true
  stack: system
  auto-route: true
  auto-detect-interface: true
  strict-route: false

auto-route 會影響系統路由表；與其他 VPN 並存時，請特別留意預設路由是否被覆寫。strict-route 若設得過於激進，可能影響區網或本機服務連線，建議在熟悉路由表操作前維持較保守設定。若你以純設定檔管理核心，挑客戶端時可參考 如何選擇適合自己的 Clash 客戶端，選擇對 macOS 權限與日誌呈現較友善的一款。

⚠ 合規與安全：請在合法、授權的網路環境中調整路由與代理。勿將本文用作規避組織資安政策；公司或學校設備請依管理員規範操作。

可列印檢查清單

建議依序勾選，將「macOS 權限」與「Clash 規則／節點」分開驗證：

  1. 系統設定中是否已允許系統擴展／網路延伸功能，必要時重新開機後再試一次開啟 TUN。
  2. 登入項目與延伸功能中，該 App 的 Network Extension 是否為啟用狀態、未被管理軟體停用。
  3. 是否同時開啟系統代理與 TUN：若異常，先改為只保留其一做對照。
  4. 是否還有其他 VPN 佔用預設路由：先暫停，再測試 Clash 單獨運作。
  5. 「網路」進階設定裡是否留有舊的手動代理：清除或關閉後再測。
  6. 連線日誌中是否能看到問題 App 的連線：若看不到，偏向流量未進核心；若看得到但策略錯誤，再調規則。
  7. DNS 是否多頭馬車：固定一種解析路徑後再測試；fake-ip 場景一併檢查過濾清單。

結語

Clash macOS 上啟用 TUN 模式，關鍵不在多勾幾個選項，而是把系統擴展與 Network Extension 授權先跑通，再決定流量要以 TUN 還是系統代理為主幹，並接受「少數 App 因沙盒或自身行為而不走代理」這個現實。把授權、路由與 DNS 分層排查，多數「開了卻沒效」的狀況都能收斂到可重現的幾類原因，而不是無止境更換節點。

相比僅能在單一埠監聽的工具，能把 Meta 系核心、透明模式與清楚日誌放在一起的客戶端，在 macOS 這種權限與簽章特別嚴格的平台上，通常更利於長期維護；選擇更新積極、對 Network Extension 適配完整的分支，也能減少每次系統升級後的意外停擺。

→ 立即免費下載 Clash，開啟流暢上網新體驗，在完成系統擴展授權、對齊 TUN 與代理設定後，把時間花在真正想連上的服務與內容。