Clash 設定多裝置同步:手機電腦訂閱與規則保持一致的可行方案

先分清:多裝置要同步的其實是兩類東西

談多裝置同步之前,先拆開看一台裝置上的 Clash 用戶端到底存了什麼。設定可以分成兩類:一類來自訂閱,一類長在本機。

訂閱下發的內容包括節點清單、代理策略群組與分流規則,由訂閱連結背後的服務方維護,服務方更新後,各端重新拉取即可拿到同一份。本機設定則完全不同:執行模式(規則、全域、直連)、混合埠、系統代理開關、TUN 模式、開機自動啟動、介面偏好,這些全部寫在各裝置的本機儲存空間裡,任何同步方案都不會替你搬過去。

所以多裝置同步的本質,是解決訂閱內容的統一下發與即時更新;本機設定只能逐台設定。下面三種方案,差別就在於前者怎麼落實。

方案一:訂閱連結天然同步

適用場景:節點全部來自同一家訂閱服務方,不維護或只維護少量自訂規則。這是維護成本最低的方案,也是多數人的起點。

做法只有一句話:同一條訂閱連結,在每台裝置的用戶端裡各新增一次。節點、策略群組、規則都來自訂閱內容,服務方更新後,各端各自按一次更新即可恢復一致。

1. 在訂閱服務方後台複製標註為 Clash 或 Clash Meta(mihomo)的訂閱連結。
2. 桌面端(Clash Verge Rev、Clash Nyanpasu 等)在設定頁新增遠端設定,貼上連結並儲存。
3. Android 端(Clash Meta for Android、FlClash)同樣新增訂閱設定,iOS 端用戶端操作方式一致。
4. 各端把自動更新間隔設為 24 小時上下,節點與規則隨服務方更新自動對齊。

這個方案容易踩的雷:

• 用戶端差異:有些用戶端預設拉取通用節點清單再在本機轉換,與直接下發 Clash 設定的訂閱表現不同,盡量使用服務方標註為 Clash 或 mihomo 的訂閱網址。
• 更新時機:各端自動更新的時間點不同,節點清單會短暫不一致,屬正常現象,手動更新一次即可對齊。
• UA 範本:部分服務方會依用戶端識別碼下發不同設定範本,兩台裝置拿到的規則細節可能有差異,請以服務方文件為準。

方案二:私有設定託管,自訂規則全量下發

適用場景:自行維護了大量自訂規則、多個策略群組、DNS 段落,希望所有裝置拿到逐字節一致的一份設定。

做法是把整理好的完整 YAML 設定放到一個只有自己能存取的 URL,各端把它當作遠端訂閱新增。此後只改這一份,各端更新即生效,規則順序、策略群組結構、DNS 行為全部一致。

可行的託管方式:

• 私有 Git 儲存庫:GitHub 私有儲存庫的 raw 檔案連結搭配存取權杖,或私有 Gitee 儲存庫;改動提交後各端更新訂閱即可。
• 自架訂閱轉換:在自己的伺服器或 NAS 上跑 subconverter 之類的後端,把上游訂閱加自訂規則範本輸出成完整 Clash 設定,網址帶獨立 token。
• 內網靜態服務:NAS 或家用伺服器用 WebDAV、簡易 HTTP 服務掛出設定檔,僅家用內網或加密通道可存取。

託管設定中依需求引用遠端規則集的 mihomo 片段範例:

mixed-port: 7890
dns:
  enable: true
  nameserver:
    - 223.5.5.5
    - 119.29.29.29
rule-providers:
  my-rules:
    type: http
    behavior: classical
    url: "https://你的託管網址/rules/my-rules.yaml"
    path: ./providers/my-rules.yaml
    interval: 86400
rules:
  - RULE-SET,my-rules,Proxy
  - MATCH,DIRECT

這個方案容易踩的雷:

• 核心差異:Clash Meta(mihomo)支援 rule-providers、tun 等欄位,已停止更新的原版 Clash 不認識這些鍵值;共用設定要按各端核心的公共子集撰寫,或依核心分開維護兩份。
• 憑證保護:設定內含節點伺服器與密碼,託管網址必須帶不可猜測的存取憑證,一旦外流後果等同訂閱外流。
• 快取問題:Git 平台的 raw 連結有快取,改完立刻更新可能拉到舊版本,等幾分鐘或在 URL 上加版本參數。
• 路徑問題:設定裡引用本機規則檔的路徑在各平台不一致,盡量改用 rule-providers 遠端規則集,避免相對路徑。

方案三:手動匯出匯入

適用場景:裝置只有兩三台、設定改動很少,或不希望任何資料經過第三方。

桌面端用戶端一般支援把目前設定匯出成 YAML 檔或整份備份;手機端用戶端支援從檔案匯入。傳輸用區域網路互傳、隨身碟或加密壓縮檔即可。

1. 在主力裝置上匯出目前生效的設定檔。
2. 透過區域網路或加密壓縮檔把檔案送到目標裝置。
3. 目標裝置用戶端選擇從檔案匯入,儲存後啟用。
4. 逐項核對埠、DNS 與 TUN 設定是否按預期生效。

這個方案容易踩的雷:

• 版本落差:改了一端忘了另一端,幾週後兩份設定已經分岔;排查時先核對兩份檔案的修改時間。
• 平台差異:Android 用戶端對設定欄位的支援與桌面 mihomo 不完全一致,匯入後先確認 DNS 與 TUN 段落是否真正生效。
• 授權帶不走:HTTPS 解密憑證、TUN 所需的系統管理員或 VpnService 授權都綁定單一裝置,設定檔帶不過去,需要逐台重新授權。

三種方案對比與選擇建議

方案	同步內容	一致性	憑證風險	維護成本	適合誰
訂閱連結天然同步	服務方下發的節點與規則	高,同源自取	訂閱連結需保密	最低	節點來自同一訂閱、不折騰規則
私有設定託管	自訂全量設定	最高,同一份檔案	取決於託管方式	中	重度自訂規則與策略群組
手動匯出匯入	匯出當下的快照	隨時間漂移	不經第三方	低,但每次都要手動	裝置少、改動少、注重隱私

多數人的最優解是方案一打底:訂閱連結解決節點與規則,本機設定逐台配好一次即可。只有當你開始維護規模化的自訂規則時,才值得升級到方案二;方案三留給出差應急或對隱私要求極高的場景。

同步之外,各端仍需單獨處理的事

• 執行模式、混合埠、系統代理、開機自動啟動都是本機設定,三種方案都不會同步,逐台設定一次即可。
• TUN 模式要依裝置單獨開關:桌面端需要系統管理員或 root 授權,Android 走 VpnService 彈窗授權,授權結果互不相通。
• 各端核心版本盡量保持接近;跨大版本升級時,新欄位先查 mihomo 文件再寫進共用設定。
• 系統時間必須準確:訂閱更新與節點 TLS 交握都仰賴正確時間,偏差過大會直接失敗,表現為訂閱抓不下來或節點全部逾時。
• 改完設定想驗證效果,看用戶端記錄與連線面板裡每條連線命中的規則,比憑感覺可靠。