為什麼 macOS 上的 Clash「第一次最難」
許多使用者在 Windows 或 Android 上已習慣「匯入訂閱、按開啟系統代理」的流程，換到 Mac 卻卡在兩個看似不相干、其實常連動的點：系統延伸功能（System Extension）沒有通過審核，以及訂閱更新在圖形介面裡顯示失敗或逾時。前者會讓 TUN／核心網路元件無法正常掛載，代理開關亮了卻沒有真正接管流量；後者則讓你連節點清單都載不進來，後續規則與測速更無從談起。
與本站已涵蓋的 Windows TUN 排查、Android 指南相比，macOS 多了一層由Gatekeeper、使用者核准的延伸功能、隱私權與安全性構成的門檻。這不是「你不會設定」，而是作業系統刻意把高權限網路行為放在可見的同意流程裡。理解這一點後，排查會變成有地圖可走，而不是到處試密碼或重灌。
下文以 Mihomo（Clash Meta）核心與常見桌面用戶端（含 Clash Verge Rev 類型）為主，描述症狀與對應設定路徑。請在合法合規前提下閱讀；本文僅討論權限、網路與用戶端行為，不提供規避法規或濫用網路資源的指引。
先對症狀分桶：是「權限」還是「拉不到訂閱」
建議先用兩分鐘做粗分，避免同時改十個選項。若你開啟 TUN 或「虛擬網卡／系統核心」類選項時，介面提示需要系統延伸功能、或系統彈窗顯示已阻擋來自開發者的軟體，優先走本文「延伸功能與安全性」一節。若核心能啟動、系統代理也能開，但更新訂閱按下去就出現 TLS、timeout、403、404 或空白錯誤，則優先檢查訂閱網址與當下網路路徑。
當然也有疊加型問題：延伸功能未載入時，某些用戶端仍會嘗試用系統代理去拉訂閱，若你同時把系統代理指到本機 Clash，卻又還沒有可用節點，可能形成「自己代理自己」的迴圈，表面上像訂閱壞掉。後文會用固定順序把這類假訊號排除掉。
系統延伸功能：該去哪裡按「允許」
在較新的 macOS 上，涉及封包轉送、虛擬介面或驅動層能力的元件，常需通過使用者核准的系統延伸功能。安裝或首次啟用 TUN 相關能力時，系統可能跳出安全提示；若你順手關掉或錯過時機，之後就會變成「用戶端顯示已開啟、實際沒有介面」的曖昧狀態。
請打開系統設定（或舊版「系統偏好設定」對應項目），進入隱私權與安全性。在頁面下方或「安全性」相關區塊，尋找與系統延伸功能、允許、仍要允許有關的按鈕。不同 macOS 版本用詞略有差異，但邏輯一致：系統要你明確同意哪個開發者／哪個套件可以載入延伸功能。按下允許後，經常還需要重新開機或登出再登入，變更才會完整套用。
若你只看到「已阻擋」而沒有允許按鈕，可嘗試：再次於用戶端觸發需要延伸功能的操作，讓系統重新產生提示；或依 Apple 文件建議的流程，暫時到「隱私權與安全性」解除封鎖後再試。請避免從不明來源下載所謂「一鍵破解版」，那類安裝包最常同時帶來無法預期的延伸功能狀態與資安風險。安裝包建議一律從本站下載頁取得對應平台版本，再與上游開源資訊交叉核對。
Gatekeeper 與「無法打開，因為來自身份不明的開發者」
另一條平行線是應用程式本身未通過首次開啟驗證：按兩下沒反應、或提示來自身份不明。此時可在 Finder 裡對 App 使用右鍵 → 打開，在彈出視窗中選擇仍要開啟，讓系統記錄你的信任決定。若你從壓縮檔解出後直接執行，偶爾會遇到隔離屬性（quarantine）相關限制，將 App 移到「應用程式」資料夾再開啟，成功率通常較高。
這一步與延伸功能不同：Gatekeeper 處理的是App 本體能不能跑；延伸功能處理的是高權限元件能不能載入。兩者都要過關，TUN 才可能穩定存在。若你只解了 Gatekeeper、沒解延伸功能，症狀會變成「程式能開、TUN 永遠轉圈」。
TUN 與系統代理：哪一種比較不容易在 Mac 上踩雷
對首次設定者而言，建議先用系統代理驗證「訂閱能更新、節點能連、規則有命中」，再開 TUN 做全裝置覆蓋。原因是 TUN 依賴延伸功能與路由／DNS 協作，變因較多；系統代理則多半只要本機 listener 正常、瀏覽器願意讀系統設定即可。
若你使用 Clash Verge Rev 等圖形介面，介面用詞可能寫成「系統代理」「TUN 模式」「堆疊」之類，底層仍應對應到 Mihomo 的 tun、listeners 與系統設定。建議搭配Clash Verge Rev 完整教學把開關與實際設定檔對齊，避免「介面顯示開、核心其實沒啟用」的錯位。若你希望連 DNS 路徑一併檢查，可再讀DNS 防洩漏與解析設定指南，把解析與分流放在同一套敘事裡。
訂閱更新失敗：先分「網址錯」還是「路徑不通」
訂閱在瀏覽器打開是一串 YAML 或 base64，不代表用戶端一定拉得到。常見原因包含：網址複製時少了查詢參數、服務商對 User-Agent 或來源 IP 有限制、需要 Cookie 或登入態的網頁被誤當成純訂閱連結、以及短時間內請求過多被限速。若錯誤訊息含 403 或 401，先回到服務商後台確認連結是否仍有效、是否需要換發。
若錯誤偏向 TLS handshake、certificate、x509，請檢查系統日期與時間是否正確、是否在公司網路被HTTPS 檢查攔截。時間大幅偏移會讓憑證驗證直接失敗；企業中介憑證若未納入信任，也會讓部分用戶端拒絕連線。相對地，若只有 timeout 而沒有 TLS 細節，則偏向路由或防火牆丟棄，可改用手機熱點對照，快速判斷是不是區網或電信商的問題。
進階使用者若手動改過 proxy-groups 或外部規則，也要確認沒有在「更新訂閱」這條路徑上意外走需要先有節點才能通的 outbound。簡單說：更新訂閱應盡量走 DIRECT 或明確的本地策略，避免形成雞生蛋迴圈。圖形介面若有「更新訂閱時使用系統代理」類選項，請在測試期間關閉或改為直連，對照一次差異。
本機防火牆、其他 VPN 與 iCloud 私密轉送
Mac 上很常見的另一變因是多層網路軟體同時存在：Little Snitch、Lulu、公司 VPN、其他「加速器」、或 iCloud 的私密轉送。它們可能改寫 DNS、插入本機代理、或與 TUN 路由競爭。排查時建議採單變因：暫停其中一類軟體、重啟 Clash 核心，再試訂閱更新與開啟網頁。若一停某個軟體就好，代表衝突點已縮小，之後再決定要調規則還是調啟動順序。
若你身處需要網頁認證的公共 Wi‑Fi（captive portal），在登入前 HTTPS 請求常會被導向入口頁，用戶端會解讀為異常回應。此時先用 Safari 完成登入，再回用戶端更新訂閱，通常就能排除假性失敗。
仍卡住時：用日誌對照是「連出去」還是「本機沒起來」
當介面訊息過於簡略，建議改看核心或應用程式日誌。若出現 listener 綁定失敗、延伸功能相關錯誤，優先回到權限與安裝完整性；若出現對訂閱網域的 dial 逾時或 TLS 錯誤，則對照上一節的網路與憑證線索。更細的關鍵字分流可參考連接埠與節點逾時排查文，把「本機埠」與「對外連線」兩類訊息拆開解讀。
什麼情況下該考慮解除安裝後乾淨重裝
若你已確認隱私權畫面允許、Gatekeeper 已放行，但 TUN 仍完全無法建立，且日誌反覆出現延伸功能或驅動載入失敗，可考慮依官方建議完整移除後再安裝：包含刪除應用程式、清掉殘留的設定目錄（操作前請自行備份訂閱與設定檔）、重開機後再從可信來源裝回。重裝的意義不在「迷信新版本」，而是把殘留的拒絕紀錄與半套元件一次清乾淨，讓系統有機會重新跑完整授權流程。
重裝後請先完成訂閱更新與基本連線測試，再逐步開啟 TUN、進階 DNS、規則提供者等選項，避免一次打開全部高階功能而不知道卡在哪一層。
設定語意與欄位：需要查表時從哪裡看
當權限與網路都正常後，仍有可能因設定檔欄位語意與版本不相容而出現怪異行為。此時可交叉閱讀本站使用文件總覽與上游 Mihomo 說明，確認 tun、dns、proxy-providers 等區塊是否與當前核心版本一致。若需核對原始碼或更新紀錄，也可至 GitHub 上的 Mihomo 倉庫查閱；安裝包取得仍建議以本站下載頁為主，與原始碼資訊分開理解，較不容易混用錯版本。
小結：把 macOS 首次設定變成可重複的檢查清單
Clash macOS 首次設定，核心往往不是「會不會寫規則」，而是系統延伸功能是否核准、訂閱 HTTPS 路徑是否乾淨。先把 Gatekeeper 與延伸功能兩條線走完，再用系統代理驗證訂閱與節點，最後才開 TUN 做全裝置覆蓋，能省下大量無效重試。相較於只盯著節點延遲數字，這種按層排查的方式更貼近實際支援案例裡的真實根因。
若你希望略過手動拼湊核心與權限提示的摩擦，可選用已整合 Mihomo、並對 macOS 常見提示做過梳理的桌面用戶端；與零散來源相比，這類組合在升級後也比較不容易出現「介面顯示正常、底層延伸功能其實沒載入」的錯位。建議前往本站下載頁依平台取得安裝包，再依本文順序逐項確認。