Mac、iPhone、iPad 共用 Clash 設定：遠端訂閱與 iCloud 同步方式

先說結論：共用規則來源，保留裝置差異

Mac、iPhone、iPad 若要長期使用同一套 Clash 設定，建議採用相同的遠端設定來源，再搭配各裝置的本機設定。iCloud 雲碟適合手動傳送檔案，Git 私有儲存庫則適合管理規則變更與還原版本。這三種方式同步的內容各不相同，不能把「檔案已更新」直接當成「用戶端已套用」。

這裡所說的「同一份」，首先是指節點來源、策略組名稱與分流規則一致，不代表每部裝置上的 YAML 都要逐字相同。macOS 的監聽連接埠、TUN 路由與輔助服務設定，不宜直接套用到 iOS 用戶端；iPhone 和 iPad 使用的用戶端，也不一定能直接讀取 Clash YAML。

同步前檢查：核心、設定層與本機狀態

Apple 晶片架構不會決定設定格式

Apple 晶片 Mac 請選擇 arm64 版本，Intel Mac 則選擇 x86_64 版本；這項差異會影響程式執行，不會自動改變 YAML 語法。真正決定設定相容性的是核心與用戶端的實作。原版 Clash、Clash Meta（現稱 mihomo），以及採用其他核心的 iOS 用戶端，對協定、規則集、DNS 和 TUN 欄位的支援可能各有不同。

建議在每部裝置記錄用戶端版本、核心版本、設定名稱，以及最近一次成功載入的時間。即使 App 版本相同，核心也可能不同；訂閱更新成功只代表下載階段可能已完成，仍須檢查解析結果與目前啟用的設定。

將設定分成三個層次

• 共用內容：節點來源、策略組名稱、網域與 IP 分流規則、規則集網址。各裝置應盡量保持一致。
• 裝置設定：監聽連接埠、區域網路存取、TUN、DNS 接管與記錄等級。請依各自的系統和網路環境設定。
• 執行狀態：目前選取的節點、測速結果、連線記錄。這些通常儲存在用戶端資料庫中，不會隨 YAML 檔案自動同步。

例如，每部裝置都有名為「日常代理」的策略組，不代表它們會自動選取同一個節點。若要確保對外連線位置一致，必須逐一確認每部裝置上策略組目前選取的項目；自動測速組也可能因 Wi-Fi、行動網路和測試時間不同而產生不同結果。

方式一：使用同一個遠端訂閱，各裝置分別更新

遠端訂閱最適合日常使用：由可信任的 HTTPS 網址提供設定，每部裝置各自取得。請先確認網址回傳的是完整 Clash YAML、只有節點清單，還是 Base64 節點字串。後兩者不能未經處理就當成包含規則與策略組的完整設定。

首次匯入與更新步驟

1. 在 Mac 的用戶端設定管理介面新增遠端設定，貼上訂閱網址，並取個容易辨識的名稱，例如「Apple 裝置共用規則」。
2. 下載後檢查解析記錄，確認 proxies 或 proxy-providers、proxy-groups、rules 等必要內容完整，再將其設為目前使用的設定。
3. 在 iPhone、iPad 的用戶端中，透過遠端設定匯入功能新增相同來源。若不支援該格式，請改用來源提供者提供的相應格式，不要只更改副檔名。
4. 在三部裝置上分別更新並重新載入一次，確認規則數量、策略組名稱與載入錯誤。不要只比對設定顯示名稱。
5. 最後分別測試一條直連與代理連線，並在連線記錄中確認實際套用的規則和出口。

不同用戶端的選單名稱可能是「設定」、「Profiles」或「訂閱」，沒有一套適用於所有 App 的統一操作步驟。系統代理或 VPN 開關與設定更新也是兩個不同動作：下載新檔案後，有些用戶端仍須切換設定或重新連線隧道，才會套用新內容。

更新完整訂閱與更新節點提供器並不相同

用戶端的「自動更新訂閱」通常會更新整份設定；mihomo 的 proxy-providers 則負責更新節點提供器內容。即使提供器的 interval: 3600 表示每隔 3600 秒嘗試更新，也不會代替你修改主設定中的 rules。同樣地，rule-providers 更新的是對應規則集，不等於重新下載整份 YAML。

需要自訂規則時，優先使用用戶端明確支援的本機覆寫、合併或指令碼機制；直接編輯下載快取中的 YAML，修改內容可能在下次訂閱更新時遭到覆蓋。並非所有裝置都支援覆寫功能，使用前請確認它是在下載前、下載後還是載入時生效。

方式二：透過 iCloud 雲碟同步檔案，再手動匯入用戶端

若你自行維護一份設定，偶爾再分發到另外兩部裝置，iCloud 就很適合。它負責同步檔案，不會檢查 YAML，也不保證用戶端會監控檔案變更。透過系統檔案選擇器匯入時，App 可能會將檔案複製到自己的沙箱；之後來源檔案變更，該副本也不會自動更新。

建立清楚的檔案交接流程

1. 在 Mac 開啟「系統設定」→「Apple 帳號」→「iCloud」→「雲碟」，確認同步功能已開啟；較舊系統可能會顯示「Apple ID」。
2. 在 Finder 的「iCloud 雲碟」中建立 Clash-Shared 資料夾，並儲存 UTF-8 編碼的 shared.yaml。避免使用會加入富文字格式的編輯方式儲存。
3. 在 iPhone、iPad 開啟「設定」→「Apple 帳號」→「iCloud」→「雲碟」，並開啟「同步此 iPhone」或「同步此 iPad」。
4. 前往「檔案」→「瀏覽」→「iCloud 雲碟」→ Clash-Shared，等待檔案實際下載完成，不要只確認看得到檔名。
5. 在用戶端使用本機檔案匯入功能，選取該 YAML，並確認匯入後的名稱、解析結果和啟用狀態。若之後修改來源檔案，請依相同步驟重新匯入或重新整理。

以上路徑採用近年系統常見的名稱，實際位置可能隨系統版本調整。若在「檔案」中找不到 iCloud 雲碟，請先檢查帳號和雲碟設定，不要反覆新增設定來排查雲端同步問題。

透過版本註記確認是否取得新檔案

可以在 YAML 頂端保留一行註解，方便在支援檢視原始內容的用戶端中核對。這行註解僅供人工辨識，不會改變規則運作，也不保證會顯示在用戶端清單中。

# config-revision: 2026-09-09-r1

• 約定只在 Mac 編輯主檔，iPhone 和 iPad 僅負責匯入，以減少同時修改造成的衝突副本。
• 保留上一份可用檔案，例如 shared-2026-09-08.yaml；確認三部裝置運作正常後，再整理舊副本。
• 若 App 無法持續存取雲碟檔案，請透過系統檔案選擇器重新授權或重新匯入，不要假設原有的存取權限會永久有效。

方式三：以 Git 私有儲存庫管理規則與版本還原

若你經常調整分流規則，Git 的價值在於記錄每次變更、檢視差異並還原舊版本，而不是讓 iOS 自動執行 Git。較穩妥的做法是：儲存庫只放可公開檢視的規則與範本，由 Mac 取得並產生最終設定，再透過遠端網址或檔案匯入，將結果提供給手機和平板。

分開儲存規則與憑證

建議將自訂規則放在 rules.yaml，將實際訂閱網址和本機產生的檔案放在不納入版本控制的資料夾。以下是可採用的 .gitignore 內容；檔名應配合實際的產生流程。

secrets/
runtime/
*.local.yaml
.DS_Store

.gitignore 只會忽略尚未納入版本控制的檔案，不會移除已進入提交歷史的憑證。若權杖曾經提交，請先在服務端撤銷或更新，再處理儲存庫歷史。私有儲存庫雖可限制存取，仍應避免將長期有效的訂閱憑證留在版本記錄中。

在 Mac 檢視變更，再分發到其他裝置

以下指令假設儲存庫已完成複製、遠端名稱為 origin，共用分支為 main。先確認工作目錄狀態，再查看遠端規則差異；若本機有尚未完成的修改，請先儲存並處理，避免直接覆寫。

git status --short
git fetch origin
git diff HEAD..origin/main -- rules.yaml
git pull --ff-only

更新後先在 Mac 檢查產生的設定，並使用實際用戶端載入測試。若已安裝 mihomo 命令列程式，可用它檢查最終檔案：

mihomo -t -f runtime/shared.yaml

檢查通過表示該設定符合這個核心的驗證要求，不代表所有代理節點都能連線，也不能取代 iOS 用戶端的相容性測試。接著再發布設定，或放入 iCloud，讓其他裝置更新。遠端規則集也必須符合用戶端支援的 behavior 與檔案格式；一般規則片段不能直接視為任何類型的規則提供器檔案。

Git 私有儲存庫的原始檔案網址經常需要驗證，也可能遇到重新導向、快取或存取期限。不要假設將網頁網址貼到用戶端就能下載 YAML；請確認回傳的是檔案內容，而不是登入頁面。若無法安全完成用戶端驗證，維持「由 Mac 取得，再分發檔案」的流程會更容易管理。

哪些設定應留在 Mac、iPhone 和 iPad 本機

同步規則前先劃清界線，可減少「Mac 正常、手機卻斷網」的情況。以下是適用於支援這些欄位的 Clash 系列核心的本機設定片段，並非包含節點與策略組的完整可用設定；若用戶端透過圖形介面管理連接埠，請以最終生效的設定為準。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

此處的連接埠 7890 僅為範例，並非所有用戶端的固定預設值。即使 Mac 開啟系統代理，也只會影響遵循這項設定的 App；TUN 的接管範圍則會受到路由與排除項目影響。同步設定無法代替 macOS 輔助服務授權，也無法代替 iOS 上的 VPN 設定授權。

DNS 設定更不宜直接照搬。家用 Wi-Fi、公司網路與行動網路，對同一個 DNS 服務的連線狀況可能不同；若共用設定包含 fake-ip、分流解析或 DNS 接管設定，請分別檢查各裝置的支援情況。先確認 DNS 解析正常，再檢查規則是否命中，避免把解析失敗誤認為訂閱失效。

同步後規則不一致：依五個檢查點逐步排查

1. 確認來源相同。檢查三部裝置是否訂閱相同的設定來源、使用相同格式與選項。訂閱轉換的輸出參數不同，節點和規則也可能不一樣。
2. 確認已取得新內容。查看最後成功更新時間、版本註解和規則數量。iCloud 顯示檔案不代表下載已完成；遠端介面即使回傳 HTTP 200，也可能只回傳錯誤說明文字。
3. 確認設定已載入。檢查目前啟用的設定，而不只是查看設定清單。載入失敗時，有些用戶端會保留舊設定繼續運作，請查看錯誤記錄。
4. 確認覆寫順序。檢查本機覆寫是否變更 mode、DNS、策略組或規則。一般規則通常依序比對，前面的寬鬆規則可能會比後面的精確規則更早生效。
5. 確認實際出口。在連線記錄中比對目標網域、命中規則、策略組與最終節點。同一策略組在不同裝置上，可能有不同的手動選取結果或測速結果。

透過一項小幅變更驗證整個流程

先更新版本註解，再於設定中調整一條已知測試網域的精確規則，並使用設定中實際存在的策略組。將這條規則放在可能提早命中的寬泛規則之前，並置於兜底 MATCH 之前。三部裝置更新並重新載入後，建立新的測試連線，再核對命中記錄；既有的長連線不一定會依新規則重新建立。

若只想確認檔案是否傳送完成，比對版本註解即可；若要驗證分流是否生效，就必須查看連線記錄。將兩種測試分開，才能區分「傳輸未更新」、「解析失敗」和「規則順序錯誤」。測試結束後請撤回暫時新增的規則，並保留已驗證可用的版本。

開始設定前，可先查看用戶端比較，確認各平台用戶端支援的格式與功能，再依照快速入門完成首次匯入。若已遇到連線或解析異常，請參考疑難排解指南逐項檢查，避免同時更換訂閱、DNS 與隧道模式。