Clash 多裝置設定同步方案：訂閱共用、覆寫檔案與私有儲存

先劃分設定中的可同步與裝置專用部分

Clash 多裝置同步並不等於把一個完整的 YAML 檔案複製到所有終端。桌面系統、行動系統以及不同用戶端對設定目錄、網路介面、系統代理伺服器和 TUN 權限的處理方式並不一致。直接覆蓋整個執行設定，常見結果是節點可以讀取，但發生連接埠衝突、TUN 啟動失敗，或行動裝置引用了只有桌面端才存在的檔案路徑。

更穩定的做法，是先將設定拆成三個層次：遠端訂閱負責節點與服務商下發的策略資訊；共用覆寫負責自訂規則、策略群組命名和通用 DNS 邏輯；裝置本機層則負責監聽位址、連接埠、控制器、TUN、網路介面與用戶端狀態。同步時只覆蓋前兩個層次，裝置本機層由各用戶端分別儲存。

方案一：在每台裝置上共用同一個訂閱

訂閱共用是最直接的多裝置方案。每台裝置分別儲存同一個訂閱網址，由各自的用戶端定期擷取並產生本機設定。節點增刪、名稱調整和服務商規則更新會隨訂閱重新整理同步到裝置，而連接埠、TUN 與系統代理伺服器狀態仍由本機用戶端管理。

這種方式適合裝置數量較少，主要需求是維持節點清單一致的情境。不要求裝置彼此可見，也不依賴電腦持續上線。某台裝置更新失敗時，其他裝置仍可依照自己的更新週期運作。

訂閱共用的界線

訂閱網址通常帶有用於識別帳戶的參數，應視為存取憑證，而不是一般網頁連結。不要將訂閱網址寫入公開程式碼儲存庫、螢幕截圖、工單或公開分享文件。裝置轉讓、遺失或停止使用時，應從用戶端刪除訂閱，並視服務提供者的功能更新訂閱憑證。

還要留意服務條款中的同時連線數與裝置數量限制。同一個訂閱可以匯入多個用戶端，不代表伺服器一定允許這些裝置同時建立大量連線。若出現節點可見但連線遭拒的情況，需同時檢查帳戶狀態、同時連線上限與節點可用性。

更新節奏與失敗處理

1. 先在一台常用裝置上手動重新整理，確認訂閱回傳的是 Clash 或 mihomo 可解析的設定內容。
2. 再讓其他裝置依固定週期更新，避免在短時間內連續重複請求。
3. 更新後檢查策略群組是否仍有成員，避免節點名稱變更導致手動撰寫的策略引用失效。
4. 保留用戶端上一份可用設定；新設定解析失敗時，先還原，再檢查回應內容與欄位相容性。

訂閱共用解決的是「節點來源一致」，不會自動同步手動新增的規則、策略群組選擇結果或每台裝置的用戶端偏好。若需要統一這些內容，應加入覆寫層，而不是反覆編輯由訂閱產生的主要設定。

方案二：使用覆寫檔案統一規則與策略結構

覆寫檔案用於將個人維護的設定邏輯疊加到訂閱結果之上。支援覆寫、合併或腳本處理的用戶端，可以在訂閱更新後自動追加規則、修改策略群組，或替換部分 DNS 欄位。如此既能保留遠端節點更新，也能避免每次重新整理後都重新編輯產生的檔案。

不同用戶端對「覆寫」的定義並不一致。有些依 YAML 鍵值合併，有些使用 JavaScript 處理設定物件，還有些只提供簡單的前置與後置規則。部署前應查看用戶端實際支援的處理順序，尤其要確認陣列是追加、替換，還是依名稱合併。對 rules、proxies 和 proxy-groups 而言，陣列處理方式會直接改變最終結果。

共用覆寫應保持精簡明確

rules:
  - DOMAIN-SUFFIX,example.org,DIRECT
  - DOMAIN-SUFFIX,internal.example,DIRECT
  - MATCH,節點選擇

上例只表達規則順序，不負責連接埠、控制器或 TUN。實際使用時，節點選擇 必須與最終設定中的策略群組名稱完全一致。規則會依照由上至下的順序比對，兜底規則應放在最後；若覆寫工具處理規則插入位置有誤，新項目可能永遠不會命中。

不要把執行狀態當成設定同步

策略群組目前選取的節點，可能由用戶端寫入本機資料庫或快取，不一定存在於 YAML 中。即使兩台裝置載入相同設定，A 裝置選擇「香港節點」，B 裝置仍可能維持「自動選擇」。這通常是合理行為，因為行動網路、家用寬頻和公司網路的延遲結果各不相同。需要統一的是策略群組結構，而不是強行複製一次性的選擇狀態。

方案三：透過區域網路傳輸設定檔案

區域網路傳輸適合臨時遷移、首次部署或少量受控裝置。例如在電腦上整理設定後，透過系統檔案共享、隔空投送、傳輸線檔案傳輸或本機檔案伺服器交給手機和平板。資料不必經過公開分享頁面，傳輸完成後也可以關閉共享服務。

這種方案的優點是過程直觀，適合傳遞完整 YAML、規則集和說明檔案；限制則是後續更新仍需手動執行。裝置數量增加後，很容易出現檔名相同但內容不同、舊設定覆蓋新設定，或某台裝置遺漏更新等問題。因此，區域網路傳輸更適合作為「分發動作」，不適合作為長期自動同步機制。

區域網路傳輸檢查清單

1. 傳送前關閉設定編輯器的自動儲存衝突處理，確認檔案內容已完整寫入。
2. 在檔名或同一目錄的說明中記錄日期與版本，避免只用 config.yaml 區分多個版本。
3. 匯入後先執行設定語法檢查，再啟動系統代理伺服器或 TUN。
4. 確認接收裝置沒有沿用傳送端的區域網路監聽位址、控制器位址與平台專用路徑。
5. 傳輸結束後關閉臨時共享目錄，並刪除接收裝置下載目錄中的重複副本。

若透過 HTTP 在區域網路中提供檔案，應只綁定可信任網路可存取的位址，並限制共享時間。公共無線網路中的其他終端可能與裝置處於同一網段，因此「只在區域網路內」並不自動代表存取範圍可控。

方案四：使用私有儲存維護共用設定

需要持續維護規則與覆寫檔案時，可以將共用層放入自行管理的 Git 儲存庫、WebDAV、家用儲存裝置或具備存取控制的物件儲存中。各裝置透過用戶端支援的遠端設定功能、檔案同步工具或手動下載取得最新版本。這種方案更適合裝置較多、設定具有明確維護歷史的情境。

私有儲存的關鍵不只是把檔案放到遠端，而是確定存取憑證、版本還原與衝突處理方式。同步工具若在檔案寫入一半時觸發用戶端重新載入，可能產生短暫的解析錯誤。較穩妥的流程是先下載至暫存檔，完成語法檢查後再替換正式設定；若使用用戶端內建的遠端訂閱，則由用戶端負責下載與切換，不要再讓另一個同步工具同時改寫同一檔案。

將敏感資訊與共用邏輯分離

共用儲存庫更適合保存規則、策略群組範本和公開規則集引用。訂閱憑證、控制器密碼、私有節點驗證資訊應放在權限更嚴格的位置，或由每台裝置個別輸入。即使儲存服務要求登入，也應依照最小存取範圍分配帳號，避免多位家庭成員或裝置共用管理權限。

如果用戶端不支援變數替換或外部金鑰檔案，不要為了追求自動化而把所有資訊合併到一個長期同步的 YAML 中。可以保留一份不含裝置憑證的基礎範本，再於終端匯入後補充本機欄位。這種方式雖然多一步操作，但故障界線清楚，也便於裝置停用時個別撤銷存取權。

Git、WebDAV 與家用儲存的選擇

建議工作流程：分開維護訂閱、共用層與本機層

對大多數個人使用者而言，較均衡的結構是：每台裝置獨立保存訂閱網址；規則與策略範本存放在受控位置；連接埠、TUN、控制器與系統代理伺服器設定留在本機。如此節點清單由訂閱更新，共用規則只有一個維護來源，平台差異也不會被遠端檔案反覆覆蓋。

1. 建立基準裝置：先選擇一台桌面裝置驗證訂閱、規則順序、DNS 解析與策略群組引用，確認設定能由目前的核心完整載入。
2. 擷取共用層：只保留跨平台欄位，將監聽連接埠、TUN 網卡、控制器與本機路徑移出共用檔案。
3. 小範圍驗證：先匯入第二台裝置，檢查用戶端的覆寫語意、陣列合併方式與欄位支援情況。
4. 記錄設定版本：每次修改只處理一個主題，例如策略群組改名或新增規則集，避免多項變更同時套用到所有裝置。
5. 保留還原入口：更新前保留上一份可載入的設定。出現解析錯誤、DNS 異常或規則比對失效時，先恢復運作，再比較變更內容。
6. 定期清理裝置：刪除不再使用的訂閱、遠端儲存憑證與舊設定副本，避免已停用的裝置繼續取得後續更新。

同步後必須驗證的項目

• 設定檢查是否通過，記錄檔中是否存在未知欄位、重複策略名稱或規則集載入錯誤。
• 策略群組是否包含有效節點，手動撰寫的規則所引用的策略名稱是否仍然存在。
• DIRECT、代理策略與 REJECT 是否依預期命中，而不是全部落入最後的規則。
• DNS 請求是否由預期的解析器處理，Fake-IP 或 Redir-Host 模式是否符合用戶端能力。
• 桌面端系統代理伺服器與行動端 VPN 權限是否仍由本機狀態控制。
• TUN 啟動後是否出現路由迴圈、區域網路存取中斷，或與其他 VPN 軟體衝突。

依裝置數量與維護目標選擇方案

只有兩、三台裝置，且主要在意節點一致時，優先採用訂閱共用；需要統一分流規則時，再加入小型覆寫檔案。偶爾將桌面設定遷移到手機，可使用區域網路傳輸，但要手動核對平台欄位。裝置較多、規則長期演進，或需要審閱變更時，私有 Git 儲存庫與受控檔案儲存會更合適。

沒有任何方案應該同步所有執行狀態。Clash 與 mihomo 設定中的一部分描述代理邏輯，另一部分則直接關聯作業系統網路堆疊。前者可以集中維護，後者必須尊重裝置差異。劃清同步界線，比尋找一個涵蓋所有終端的單一檔案更可靠。

最終結構可以概括為：訂閱負責節點來源，覆寫負責共用規則，私有儲存負責版本與分發，本機設定負責系統介面。依這四項分別排查，就能快速判斷問題出在遠端更新、合併過程、檔案傳輸還是裝置權限，而不必在多個完整設定副本之間反覆比對。