Mac、iPhone 與 Windows 共用Clash 設定檔的同步方式

同步範圍：共用規則，保留裝置設定

「共用一份設定」更適合理解為共用設定來源，而不是讓三部裝置載入完全相同的最終 YAML。節點、策略群組名稱和分流規則可以盡量一致；本機監聽連接埠、TUN 接管方式、控制介面與用戶端偏好則應分開管理。如此一來，更新節點時就不會連帶覆寫其他裝置的網路設定。

還要先區分核心與圖形介面用戶端。mihomo 負責解析其支援的設定、比對規則及建立代理連線；用戶端則負責更新訂閱、選擇設定、套用覆寫及整合系統。不同用戶端在這些功能的介面與儲存方式上各有差異。iPhone 上的用戶端也不一定使用 mihomo；能匯入節點訂閱，不代表能完整執行 Clash YAML 中的規則、DNS 和策略群組。

• 適合共用：節點來源、穩定的策略群組名稱、網域規則，以及各端都支援的規則集。
• 適合保留在本機：mixed-port、external-controller、控制介面密鑰、TUN 與網路介面卡相關設定。
• 需要確認：通訊協定支援、proxy-providers、rule-providers、DNS 欄位及用戶端自有擴充功能。

三種同步方式比較

訂閱連結適合持續接收上游節點更新；iCloud 資料夾適合在少數裝置間傳送手動維護的檔案；私人 Git 儲存庫則適合需要檢視規則變更及還原版本的使用者。三種方式都只負責將設定送到裝置，不會自動同步目前的連線狀態、節點選擇或系統代理開關。

如果主要需求是「Mac 和手機使用相同的節點」，優先試用訂閱。如果主要需求是「修改一條規則後，各裝置都保持一致」，先建立共用規則來源，再決定透過檔案同步或 Git 發佈。不要為了共用節點，就把每部裝置的整個用戶端資料夾都複製過去。

訂閱連結：各裝置匯入、從同一來源更新

匯入與更新順序

1. 先向服務提供者確認訂閱的輸出類型：完整 Clash 設定、節點清單，還是其他用戶端專用格式。
2. 在 Mac 用戶端的設定管理頁面匯入連結，手動更新一次，確認策略群組與規則都存在後，再啟用該設定。
3. 在 Windows 用戶端匯入相同來源，確認實際收到的內容是否一致。有些服務會依要求參數或用戶端識別資訊回傳不同格式。
4. 在 iPhone 用戶端選擇支援的訂閱類型，並檢查匯入結果。如果只匯入節點，規則與 DNS 就需要另外設定。

三個用戶端的訂閱更新彼此獨立。Mac 更新成功，不會代替 iPhone 更新；行動裝置也可能受到背景執行限制。可以先將自動更新間隔設為 24 小時，節點有變更時再手動更新。這只是初始設定建議，實際可選間隔與背景執行情況仍以用戶端為準。

避免修改內容被訂閱覆寫

直接編輯訂閱下載的檔案，下一次更新時可能會失去修改內容。支援覆寫的用戶端，應將本機連接埠、DNS 調整與自訂規則放在獨立的覆寫設定中；若不支援覆寫，請保留一份獨立的本機設定，並明確規劃之後如何更新節點。如果各端都支援，也可以透過節點提供者將節點更新與主要設定分開。

訂閱網址通常包含存取權杖，應像密碼一樣妥善保管。不要將完整連結放進公開截圖、記錄檔或公開儲存庫，也不要為了轉換格式而隨意交給不熟悉的線上服務。如果連結已外洩，請向服務提供者更換權杖，再逐一更新各裝置的來源。

iCloud 資料夾：同步檔案並重新匯入

在 Mac 的「Finder」→「iCloud 雲碟」中建立專用資料夾，例如 ClashConfig，只放入準備發佈的設定檔。iPhone 可透過「檔案」→「瀏覽」→「iCloud 雲碟」查看；Windows 則需安裝並登入 iCloud，啟用 iCloud 雲碟後再前往相應資料夾。

1. 指定一部裝置作為主要編輯端，先儲存 shared.yaml，並等待檔案完成上傳。
2. 在目標裝置確認檔案已下載至本機，而不只是顯示雲端檔案的佔位項目。
3. 透過用戶端的匯入檔案功能選取該檔案，檢查解析結果後，再切換為目前使用的設定。
4. 修改後先在一部裝置上驗證，再於其他裝置重新匯入，或使用用戶端支援的重新載入功能。

關鍵在於區分「讀取原始檔案」和「匯入副本」。有些用戶端會將 YAML 複製到自己的資料夾；此時即使 iCloud 中的檔案已更新，用戶端仍在使用舊副本。可以暫時調整一個容易辨認的策略群組名稱，重新匯入後查看介面是否有變化，以確認實際載入來源。

不要讓兩部裝置同時編輯同一份 YAML。檔案同步可能產生衝突副本，手動合併時也容易破壞縮排或規則順序。建議一次只由一部裝置編輯，保留上一份可用檔案，確認接收端已套用後，再進行下一輪修改。

私人 Git：檢視規則與還原設定

Git 更適合保存自行維護的規則與設定架構，而不是帳號憑證。可以依照下方目錄分層；檔名只是專案慣例，Clash 或 mihomo 不會自動辨識，必須在用戶端明確匯入，或透過自訂產生流程組合。

clash-config/
├── shared.yaml
├── rules/
│   └── direct.yaml
├── local/
│   ├── mac.yaml
│   └── windows.yaml
└── .gitignore

其中 shared.yaml 用來保存共用策略群組與規則，local/ 則存放裝置差異。含有實際訂閱網址或密鑰的檔案應排除在提交之外；即使後來才加入忽略規則，也不會自動移除已存在於歷史紀錄中的機密，仍須更換憑證。私人儲存庫只是其中一道存取控管措施，不應成為長期存放所有機密的理由。

提交、拉取與驗證

git diff -- shared.yaml rules/
git add shared.yaml rules/
git commit -m "調整直連規則順序"

# 更新其他桌面裝置的工作副本
git pull --ff-only

git pull --ff-only 遇到分歧時會停止，讓你先處理本機修改，而不是直接產生不易察覺的合併。成功拉取後仍須讓用戶端重新載入設定。如果 iPhone 沒有合適的 Git 工作流程，可以透過可信任的檔案匯入方式接收發佈檔案，不必勉強在手機上重現整套桌面開發流程。

在以 mihomo 為核心的桌面環境中，可以先測試最終產生的檔案，再套用設定。以下的 effective.yaml 指已合併共用內容與本機差異的檔案；執行命令前，本機必須已有可呼叫的 mihomo 執行檔。

mihomo -t -f effective.yaml

設定測試通過，代表核心接受這份設定；不代表遠端節點可連線，也不代表系統代理已啟用。發生問題時，可以從 Git 取回上一版檔案，再匯入或重新載入。還原檔案本身不會復原系統網路設定，這些設定仍須分別檢查。

本機覆寫：連接埠、TUN 與規則順序

Mac 與 Windows 可以共用規則邏輯，但應保留各自的入口設定。以下是以 mihomo 為核心的桌面本機設定欄位範例，並非完整代理設定；範例使用混合連接埠 7890，控制介面僅監聽回送位址 127.0.0.1:9090。

mixed-port: 7890
allow-lan: false
mode: rule
external-controller: 127.0.0.1:9090
tun:
  enable: false

這些欄位應透過用戶端支援的本機設定或覆寫機制套用，不能假設所有用戶端都以相同方式合併 YAML。尤其是清單欄位：有些機制會取代整個清單，有些則支援插入開頭或附加至末尾。套用後應檢查最終設定，確認原有代理群組和規則沒有意外消失。

• 連接埠：先檢查 7890 是否已被其他程序占用。變更連接埠後，也要同步修改終端機的代理環境變數，以及手動設定的應用程式代理。
• TUN：桌面端會涉及權限、路由與其他 VPN 的配合；iPhone 通常透過系統網路延伸功能接管連線，不能直接照搬桌面端的 tun.stack 或網路介面卡名稱。
• DNS：先保留各裝置可正常運作的解析設定。若要共用 DNS 策略，請逐項確認支援情況，不要只因 YAML 能解析，就認定實際行為一致。
• 控制介面：通常不需要開放給其他裝置存取。若確實需要從區域網路控制，應另外設定驗證方式與存取範圍，不要直接將監聽位址改成所有網路介面。

自訂規則應放在最終兜底規則之前

Clash 風格的規則會依序比對。以下是規則片段，用來說明網域直連規則必須放在最終兜底規則之前；PROXY 必須是完整設定中已存在的代理或策略群組名稱。

rules:
  - DOMAIN-SUFFIX,example.org,DIRECT
  - MATCH,PROXY

如果將新規則加在現有 MATCH 之後，通常就不會有機會比對到。共用規則也應避免依賴特定裝置才有的策略群組名稱。建議各端統一保留相同名稱的群組，再讓每部裝置各自選擇不同節點；群組名稱一致，不代表節點選擇也必須完全相同。

公司內網網域、區域網路位址或特定 Wi-Fi 的例外規則，較適合留在本機設定。這些規則可能只適用於 Mac 目前連線的網路，複製到使用行動網路的手機上未必有用，甚至可能改變預期的連線出口。

同步後檢查與常見問題

每次更新都依照「來源 → 最終設定 → 規則比對 → 實際出口」的順序檢查，比反覆重新安裝用戶端更有效。先在一部裝置上驗證，再套用到其他裝置，有助於縮小問題範圍。

1. 確認來源：查看訂閱更新時間、檔案修改時間或 Git 提交紀錄，確認三端收到的是同一批變更。
2. 確認設定：檢查目前啟用的設定名稱、策略群組數量，以及新增規則是否出現在最終生效設定中。
3. 確認接管狀態：桌面端檢查系統代理或 TUN 狀態；iPhone 則檢查用戶端連線狀態，並留意是否與其他 VPN 衝突。
4. 確認分流：分別連線至一項預期直連和一項預期透過代理連線的服務，並在連線紀錄中確認命中的規則、策略群組與實際節點。

相同訂閱，節點清單卻不同

先檢查輸出格式、用戶端的通訊協定支援及本機篩選條件，再比較更新時間。訂閱服務也可能依用戶端識別資訊產生不同內容。不要只憑清單長度判斷同步失敗，更不要公開含有權杖的完整回應內容來進行比較。

規則相同，連線出口仍不同

這可能是正常情況。手動選取群組的目前節點通常會保存在各裝置本機；自動測速群組則會依各裝置所在的網路分別測試。Mac 連上家用 Wi-Fi、iPhone 使用行動網路時，即使策略群組定義相同，也可能選到不同節點。若要重現問題，請暫時在各端選擇相同節點，再觀察差異。

檔案已更新，用戶端仍使用舊內容

優先檢查是否匯入了副本、是否啟用了另一份設定，以及訂閱更新後是否成功重新載入。先保留目前可用的設定，再重新匯入測試。長期使用時，建議採用「相同訂閱或規則來源＋各端本機覆寫」的架構；需要追蹤規則歷史時再加入 Git，少量手動交換檔案則可使用 iCloud。同步範圍越明確，越容易找出跨平台問題。

連接埠與規則欄位可參閱YAML 設定手冊；首次匯入與網路接管步驟請見設定教學。