Apple Silicon Mac 安裝 Clash Verge Rev：系統代理與 TUN 首次設定分步教學

1. 這篇要解決哪些「M 系列 Mac 才有的搜尋情境」

泛用關鍵字「macOS 安裝 Clash Verge Rev」底下，實際上榜的疑問常混著 Intel 與 Apple 晶片兩條路徑。Apple Silicon 使用者更常搜的是：M1／M2 Mac 安裝 Verge、開 TUN 跳出網路延伸、或 系統代理設了但終端機沒吃到。這些都不是單一開關能解釋的題目，而是「作業系統把流量交給誰」的層次問題：應用程式是否讀系統代理、核心是否以虛擬介面接到更底層、以及 DNS／fake-ip 與規則是否與你觀察到的現象一致。

Clash Verge Rev 本質仍是圍繞 mihomo（Clash Meta）核心的圖形前端：負責訂閱與覆寫維護、切換策略組、顯示連線與日誌。你要做的，是先把「核心能穩定跑、節點選得到」做成真，再決定用系統代理或 TUN 把應用程式流量喂進核心。跳過這一步，很容易在權限與模式之間空轉。

2. Apple Silicon 與安裝包：別混用 Intel-only 組建

在選擇下載檔時，請以「關於本機」裡的晶片欄位為準：顯示 Apple M1、M2、M3、M4（或 Pro／Max／Ultra）即屬 arm64 平台。發行版若區分 x64 與 arm64，請選與晶片相符或標示 Universal 的版本。只標給 Intel 的舊包在 Rosetta 轉譯下或許能開，但虛擬網卡、背景服務與節能行為都可能出現額外變數；首次教學不建議把 Rosetta 當成預設路徑。

macOS 版本也會影響「系統設定」選單名稱與路徑（例如 Sequoia 與前代在「一般」「隱私權與安全性」「登入項目與延伸功能」等頁面的排版差異）。下文以近兩年 macOS 的通用邏輯描述；若你螢幕上的字樣略有不同，請以語意相同的頁面為準（網路、代理、延伸模組、背景項目）。

3. dmg、門禁提示與「隱私權與安全性」首次放行

請從本站 下載頁取得標示適用 macOS、且與你晶片相符的安裝包。下載完成後若出現「無法打開，因為來自身份不明的開發者」之類訊息，多半是 Gatekeeper 未辨識簽章：可改用右鍵 → 打開，再到 系統設定 → 隱私權與安全性底部按「仍要打開」或同等按鈕（實際文案隨版本略有出入）。這步與代理規則無關，卻是第一次安裝最常卡關的畫面。

應用程式拖入「應用程式」資料夾後，第一次啟動建議先完成語系、是否登入時啟動、選單列圖示等基礎偏好設定，但先不要急著開 TUN。理由與 Windows 版教學相同：TUN 會牽涉延伸模組與路由，若訂閱或核心尚未穩定，錯誤會被誤判成「權限壞了」或「Apple 晶片不相容」。

4. 匯入訂閱並確認 mihomo 核心已正常啟動

在用戶端新增遠端訂閱或匯入本機設定後，請執行更新並確認沒有 YAML 語法錯誤、逾時下載或被路徑誤導的 TLS／DNS 失敗（日誌關鍵字例如 timeout、certificate）。介面用語可能因版本微調，操作流程可搭配站內 節點訂閱匯入教學 與 使用教學總覽，先把「資料有進來」做穩。

選定一台延遲合理的節點後，確認介面顯示核心已執行，且本機 mixed-port 或分列的 HTTP／SOCKS 埠與設定檔一致。若核心無法監聽，常見肇因是埠被占用或設定錯誤——請先修法，再往系統代理與 TUN 前進。

5. 系統代理：macOS「網路」面板該對到哪幾項

系統代理在 macOS 的具體落點，是「對每一個使用中介面」的細部設定：系統設定 → 網路 →（選擇目前使用的網路服務）→ 詳細資訊 → 代理（路徑用語在不同版本會寫成「 … 」「更多 …」類似層級，但核心是找到該介面的 Proxies／代理區塊）。

在 Verge Rev 側啟用「設定系統代理」或語意相近選項後，請到上述頁面核對：網頁代理（HTTP）與安全網頁代理（HTTPS）伺服器為 127.0.0.1、埠與程式顯示一致；若有提供 SOCKS，亦應與設定檔相符。並留意「略過這些網路和網域的代理伺服器」或 Bypass／例外清單：模板若把過多本機服務列入略過，有時會讓你看到「規則在動、但某一類本機請求怪怪的」的假性問題。

只影響「會讀系統代理」的程式

許多終端程式預設不採用前述 GUI 設定，而是看世界變數 HTTPS_PROXY／ALL_PROXY 或套件自有設定。結果就是經典假象：瀏覽器已走代理（因為會吃系統或自家通道），但 curl、git、gRPC 工具像沒過。這並不一定是 Verge Rev 失效，而是你測試的程式根本沒接上同一條管子。

# Example: show current proxy-related env vars in zsh/bash
env | grep -i _proxy

6. TUN 與網路延伸：授權、登入項目與背景

在 Apple Silicon Mac 開 TUN 模式，核心是讓 mihomo 透過網路延伸建立虛擬介面、在較接近系統網路堆疊處統一轉發。第一次在 Verge Rev 切換到相關開關時，通常會跳出 macOS 的權限與延伸模組對話——請謹慎閱讀後允許需要的項目；若不慎拒絕，往往要在「登入項目與延伸功能」裡手動找回並啟用，或重裝／重置延伸授權（依 Apple 該版本行為而定）。

建議你到 一般 → 登入項目與延伸功能，展開網路延伸（或標示封包／篩選功能的那一段），確認與 Verge／Clash 相關的延伸已勾選為開啟；若公司有 MDM／防毒套件額外控管網路篩選，也可能需要管理員協助放行。並檢視「允許在背景運行」或相似開關，避免系統在低電力模式下早早掛起延伸，使你誤判為連線不穩定。

TUN 並非萬用開關

設定檔若仍把大量域名導向 DIRECT，或 DNS 仍以不相容於 fake-ip 的方式解析出「你不想看到的」位址，症狀一樣會是「網頁怪怪的」。需要更細的分流時可延伸閱讀 規則分流指南，並與站內 DoH／fake-ip Mac 對照文一起校準 DNS 段落。

7. 什麼時候先只用系統代理，什麼時候換 TUN

若以瀏覽器、電子郵件用戶端、多數會吃系統代理的程式為主，且不碰命令列工具的出站需求，可先維持系統代理：對系統來說這條路的侵入性通常較小，也方便關閉用戶端後還原先前寫入的代理設定（仍建議確認網路面板是否真的還原）。當你開始需要 不依賴系統 Proxy 的桌面程式統一走核心、或想用較一致的底層轉發涵蓋部分非 HTTP 類流量時，再上 TUN 會更符合成本效益。

另一個常被忽略的決策因素是iCloud 私人轉送或其他系統級「對 DNS／出口做統一決策」的功能：這些會改變你觀察到的解析與路由，請在排除問題時暫時關閉交叉驗證，再逐步加回去。這與機場品質無關，而是 macOS 多層網路功能疊加的常見雜訊來源。

8. 常見異常排查：雙標準連線與跟其他 VPN 並存

步驟一：先讀用戶端與核心的日誌。比只看圖示燈號可靠得多；對照是否有介面建立失敗、堆疊重複、DNS 異常或被規則導致頻繁繞線。

步驟二：比對「會讀系統代理」與「不會讀」的兩種路徑。先用瀏覽器確認訂閱與規則大致正常，再開終端以明確環境（有無 HTTPS_PROXY，有無經過 TUN）重試；結果分歧時，問題多半在程式堆疊，而不是節點本身。

步驟三：確認沒有其他 VPN／篩選延伸同時改寫路由表。Cisco／企業 Tunnel／其他品牌 Clash Fork 並存時，最常見是可連一下又斷、或只剩瀏覽器看似正常——那是路由被覆寫而非單一路徑能解決的題目。

步驟四：重置期待值。若你把 所有程式、所有協定在任何時刻都必須經過代理當唯一成功標準，實際上許多組建仍會對本機埠、區網、mDNS 放行；請以「對外目標是否正常、延遲與日誌是否一致」為驗證基準。

9. 常見問題（速查）

為什麼我要特別區分 Intel 版與 Apple Silicon 版？ 因為發行構建對虛擬網卡、簽署與二進位的預設路徑不同；混用最常付出的是時間成本與莫名其妙的「第一次裝就上不了」。

我可以只開「自動代理 PAC」而不要手動填入 127.0.0.1 嗎？ 部分模板會提供 PAC／腳本路徑，但對第一次使用者來說，先以明確埠號驗證連線會比繞過腳本除錯更省時；熟悉後再視需求換成自動組態。

更新了 macOS 之後 Verge Rev 的 TUN 突然不能用了怎麼辦？ 請先確認延伸模組與網路段落是否仍在登入項目裡為啟用；其次檢視新版是否對背景或篩選權限有新的開關。若新版本已修正相容性問題，也可以考慮隨發行説明更新用戶端。

10. 上游資源與站內延伸閱讀

若要核對版本、授權或回報問題，可參考上游儲存庫 clash-verge-rev／clash-verge-rev 的發行紀錄。一般下載入口仍建議以本站 下載頁為起點，再依本篇補授權與對照順序。

若以「訂閱多久拉一次、失敗要不要通知」這類議題為下一步，可看 Verge Rev 訂閱更新間隔；若要橫向比對其他 GUI 客戶端，請讀 2026 圖形客戶端對照清單。