選擇建議：先區分 macOS 與 iOS，再確認設定檔相容性

Apple 晶片 Mac 優先選擇提供 arm64 版本、核心資訊透明的用戶端；iPhone 與 iPad 則優先確認訂閱格式及網路延伸功能支援情況。若要保留 Clash 風格的策略群組與規則結構，Mac 可先評估 Clash Verge Rev、FlClash 等 mihomo 圖形化用戶端，iOS 則可先試用 Stash。Shadowrocket、Surge 也是常見的 Apple 平台代理工具，但不代表它們能直接完整執行 Clash YAML 設定檔。

「Clash 蘋果版」是依使用情境搜尋的關鍵字，並非同時涵蓋 Mac 與 iPhone 的單一官方 App 名稱。圖形化用戶端、代理核心與訂閱設定是三個不同層次：用戶端負責管理開關與設定，核心負責處理協定及規則，訂閱則提供節點與可能附帶的策略。選擇時將這三層分開，才能判斷問題出在匯入、語法解析還是連線階段。

  • 只供瀏覽器和日常桌面 App 使用：先確認 macOS 系統代理是否足夠，不必為了功能多就直接啟用 TUN。
  • 終端機、遊戲或不使用系統代理的 App：優先確認 TUN、UDP、DNS 與路由控制，不要只看介面上有沒有開關。
  • Mac 與 iPhone 共用規則：先選擇兩端都支援的設定交集，再決定是否分別維護覆寫檔。

熱門用戶端比較：核心、設定與操作方式

以下比較各專案的定位與使用範圍，不會將某個下載檔的版本視為永久結論。最低系統需求、內建核心版本及 App Store 上架地區，請以預計安裝版本的發行說明或 App 詳情為準。

用戶端 平台與核心定位 設定與流量接管方式 適用情境
Clash Verge Rev macOS 等桌面平台，使用 mihomo Clash 風格 YAML，支援系統代理與 TUN 需要管理訂閱、檢查規則並查看連線
FlClash 跨平台圖形化用戶端，以 mihomo 為基礎 Clash 風格設定；桌面版的接管能力請依實際版本確認 希望在不同裝置上使用相近的操作介面
ClashX Meta macOS 選單列用戶端，採用 Meta 系列路線 Clash 風格設定；進階接管功能需逐版確認 偏好透過選單列操作，也願意自行檢查維護狀況
Stash iOS、iPadOS 代理 App，獨立實作 支援 Clash 風格 YAML，透過系統網路延伸功能接管流量 希望沿用策略群組與規則設定結構
Shadowrocket iOS、iPadOS 代理 App，非 mihomo 用戶端 支援多種節點訂閱，採用自有設定與規則系統 主要匯入節點，並願意另外管理手機規則
Surge macOS、iOS 網路工具，獨立實作 採用自有設定格式，提供策略管理與網路診斷功能 需要細緻的診斷功能，也願意轉換設定語法

Stash、Shadowrocket 與 Surge 的購買方式、供應地區及授權範圍，請至 App Store 或產品頁面確認；macOS 與 iOS 的授權也不一定通用。Clash Verge Rev 和 FlClash 為開源專案，方便查閱實作與問題紀錄，但「開源」本身不能取代對目前版本的相容性測試。

Apple 晶片 arm64：分別確認安裝檔與核心版本

確認 Mac 處理器架構的兩種方式

開啟「蘋果選單」→「關於這台 Mac」：若顯示 Apple M 系列晶片，請選擇標示 arm64、aarch64 或 Apple Silicon 的版本；若顯示 Intel 處理器，請選擇 x86_64 或 x64。Universal 通用版本可能同時包含兩種架構，但仍應確認發行說明中的系統需求。

也可以開啟「應用程式」→「工具程式」→「終端機」執行以下指令。在 Apple 晶片終端機原生執行時，通常會輸出 arm64；若終端機使用 Rosetta 轉譯，輸出可能反映的是轉譯環境，因此判斷硬體仍應以「關於這台 Mac」為準。

uname -m

安裝後開啟「活動監視器」，查看用戶端程序的「種類」，可協助確認是否以 Apple 晶片架構執行。圖形介面與核心通常是不同程序，排查時兩者都要確認；不能只因介面能啟動，就認定核心架構也選對了。

記錄圖形介面與核心版本，不要只記 App 名稱

原版 Clash、歷史上的 Premium 分支與 Clash Meta／mihomo，不能視為功能持續同步的同一套核心。Clash Meta 後續以 mihomo 名稱延續開發；原版與 Premium 的歷史版本不應被當成支援新協定的預設選擇。即使用戶端仍能啟動，舊核心也可能無法辨識新的設定欄位。

  1. 在用戶端的「關於」或版本資訊頁面記錄圖形介面版本，並保留完整版本號與建置標記。
  2. 在核心管理、執行記錄或核心資訊頁面記錄核心名稱與完整版本號；不同用戶端的功能入口名稱不盡相同。
  3. 對照該核心版本的文件，檢查 rule-providers、proxy-providers、DNS 與所需的協定選項，不要從軟體圖示推斷支援狀況。

本文不列出未經確認的「最新版本號」。發行頁上的圖形介面更新與核心更新可能不同步；更新前保留可用的安裝檔與設定副本，比只比較版本號更實用。

TUN 與系統代理：依 App 流量選擇接管方式

先用 macOS 系統代理進行基本測試

系統代理會為遵循系統設定的 App 提供 HTTP、HTTPS 或 SOCKS 代理入口，不代表所有程序都使用同一個對外連線。在 macOS 13 或更新版本中，可前往「系統設定」→「網路」→目前的網路服務→「詳細資訊」→「代理」檢查實際設定；連線類型與系統版本可能會影響按鈕名稱。

假設用戶端已明確設定 mixed-port: 7890，可以使用以下指令單獨測試本機 HTTP 代理。這裡的 7890 只是範例連接埠，並非所有用戶端的固定預設值；請替換成介面顯示的實際監聽連接埠。

curl --proxy http://127.0.0.1:7890 --connect-timeout 10 --head https://example.com

這項測試只能確認該次請求嘗試透過指定代理，不代表所有 App 都已接管，也無法證明對外連線符合預期。若指令成功但瀏覽器失敗，請檢查瀏覽器本身的代理設定、擴充功能與 DNS 行為，不要立刻重新安裝用戶端。

TUN 能接收更多流量，但不代表所有連線都會經過遠端

TUN 會透過虛擬網路介面與路由，將符合條件的流量交給核心處理，適合不使用系統代理的 App。接管後的連線仍會依規則選擇代理、直連或拒絕；區域網路、排除路由及系統限制也會影響接管範圍。UDP 能否正常使用，還取決於節點協定、伺服器與網路路徑。

  • 授權機制：macOS 用戶端可能使用特權輔助服務，也可能使用網路延伸功能；不能將所有 TUN 開關都解讀為必須授權同一種系統延伸功能。
  • DNS 行為：檢查用戶端的 DNS 設定與 TUN DNS 接管選項；瀏覽器加密 DNS、其他 VPN 和安全軟體也可能改變 DNS 查詢路徑。
  • 網路衝突：先關閉其他會修改路由或 DNS 的工具，再測試 TUN；公司 VPN 的分流策略則需另外確認。

iOS 代理 App 通常會透過 Network Extension 建立 VPN 設定檔。首次連線時出現允許新增 VPN 設定的系統提示，屬於這種流量接管方式，與在 Mac 上手動填寫代理連接埠不同。一般個人使用時，應避免同時啟用兩款爭用同一 VPN 通道的 App；受管理裝置可能還有其他限制。

訂閱與規則相容性：Mac、iPhone 共用設定的檢查順序

訂閱連結可能回傳完整 YAML，也可能只回傳編碼後的節點清單。完整設定可能包含 proxies、proxy-groups 和 rules；節點清單通常不含完整的分流策略。這兩種內容都可能在介面上被稱為「訂閱」，因此只看連結副檔名無法判斷匯入內容。

先檢查設定結構，再確認用戶端專屬功能

  1. 檢查策略群組：確認設定中引用的群組名稱確實存在，尤其是 rules 中指定的目標。即使節點匯入成功，策略群組缺失仍會讓設定無法使用。
  2. 檢查遠端資源：確認是否支援 rule-providers 與 proxy-providers，以及資源 URL 是否可下載。規則集格式與行為類型也必須相符。
  3. 檢查平台專屬欄位：不要直接將 Mac 的 tun、監聽連接埠、控制介面與本機檔案路徑套用到 iOS。
  4. 檢查本機修改的儲存位置：更新遠端訂閱可能會覆蓋直接編輯的內容。優先使用用戶端提供的覆寫、合併或獨立本機設定功能。

以下片段僅用來說明欄位之間的關係，並非完整可連線的設定。DIRECT 是內建的直連策略；即使啟用了 TUN，這條最終規則仍會讓符合條件的流量直連，不會自動取得遠端代理出口。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
rules:
  - MATCH,DIRECT

轉用 Shadowrocket 或 Surge 時，應依目標 App 的格式重新確認規則與策略，不能只轉換節點就視為完成整份設定遷移。Stash 支援 Clash 風格結構，也不代表相容所有 mihomo 擴充欄位；請以相應版本的設定文件為準。

介面與更新狀況：用相同任務比較用戶端

選擇介面不必只看外觀。使用同一份測試設定完成以下工作，就能直接判斷操作方式是否符合習慣：匯入訂閱、選擇策略、查看某次連線套用的規則、排查 DNS 錯誤，以及還原上一份設定。選單列工具適合頻繁切換狀態；完整視窗則更方便同時檢查連線與記錄。

檢查項目需要記錄的結果判斷依據
更新一次訂閱策略選擇與本機覆寫是否保留避免每次更新後都要重新設定
切換 Wi-Fi 與手機熱點連線恢復狀況與 DNS 錯誤記錄確認網路變更後能否恢復
闔上 Mac 後再喚醒系統代理或 TUN 是否恢復驗證日常睡眠情境
重新啟動用戶端代理狀態、規則模式與連接埠是否一致確認設定是否持續保留
升級後再降回舊版舊設定是否仍可讀取避免設定遷移後無法還原

評估更新狀況時，應參考最近幾個版本的發行說明：是否交代核心變更、修正已知的系統相容性問題、提供對應架構的安裝檔，以及標明可能造成設定不相容的變更。發行次數多不代表每個版本都適合立即升級，尤其是穩定使用中的裝置，最好先測試再替換。

節點延遲測試也不適合直接拿來替用戶端排名。同一節點的測試網址、連線重用、DNS 快取與所選協定都可能不同。若要比較，至少要統一網路、節點、測試目標與接管模式，並分別記錄延遲、連線成功率和下載表現；本文不提供未經實測的效能數據。

依使用情境選擇：三種搭配建議

Apple 晶片 Mac，主要使用瀏覽器

從提供 arm64 版本的 mihomo 圖形化用戶端開始，先匯入訂閱並啟用系統代理。確認規則模式、策略群組與實際對外連線符合預期後，再評估是否需要 TUN。Clash Verge Rev 和 FlClash 都可列入試用清單，最後依記錄是否清楚、訂閱覆寫是否方便，以及目前版本是否支援本機 macOS 來決定。

希望 Mac 與 iPhone 共用策略結構

以兩端都支援的 YAML 欄位為基礎，Mac 使用合適的 mihomo 用戶端，iPhone 則評估 Stash 的相容範圍。遠端設定保留節點與通用規則，連接埠、TUN 和裝置路徑則留在各平台的本機設定中。先用少量規則測試，再逐步加入遠端規則集，能更快找出差異。

需要網路診斷，或只想管理手機節點

若需要更完整的診斷流程，可評估 Surge，但應將設定遷移與授權成本納入考量。若主要在 iPhone 上使用節點訂閱，並願意自行維護規則，可評估 Shadowrocket。無論選擇哪一款，都應先確認訂閱匯入、規則套用、網路切換與關閉後還原這四項，再作為長期使用方案。

最終選擇順序：系統與架構相符 → 設定可解析 → 流量接管正確 → 更新與回復可控。用戶端名稱相似，不代表實際行為相同；保留一份已驗證的設定與清楚的版本紀錄，才能讓 Mac、iPhone 和 iPad 後續維護更容易掌握。