多台裝置同步 Clash 設定的可行方案:訂閱連結、WebDAV 與手動匯出
電腦、手機、平板同時用 Clash 時設定怎麼保持一致?比較訂閱連結統一分發、WebDAV 同步與手動匯出匯入三種做法的適用情境與注意事項。
門診記錄裡,「多裝置設定不一致」算換季高發病:症狀不凶險,卻極耗心神——節點時對時錯,規則時靈時不靈。先別急著換節點,把病因問清楚,再決定抓哪張方子。
症狀:多裝置設定為什麼會越用越亂
先問症狀。電腦、手機、平板同時跑 Clash 的人,主訴通常逃不出三種:
- 節點不同步:主力裝置上訂閱剛更新,新增的節點在另一台裝置上遍尋不著,舊節點卻已失效。
- 規則不一致:在一台裝置上為某個網站加了直連規則,換裝置後同一個網站又走了代理,排查半天才想起改動沒跟過去。
- 斷線集中爆發:訂閱續費或更換套餐後只更新了一台裝置,其餘裝置接連連不上,誤以為是節點全滅。
病因一句話可以說清:Clash 的設定(Profile)以檔案形式存放在每台裝置的本機目錄裡,各用戶端互不知曉。哪台裝置點了更新,哪台才是新的;沒點的那台,就一直服用舊藥,直到某天節點失效才暴露。治本思路只有兩條——要麼讓設定來源只有一份,要麼讓各裝置定期對齊。下面三張方子,對應三種病情輕重。
方子一:訂閱連結統一分發
適用症狀:節點與規則主要來自訂閱、自訂改動少、裝置在三台以上。這是最省事的一檔,也是多數人的正解。
做法是同一條訂閱連結,在每台裝置上各新增一次,之後各自定時更新。設定內容託管在訂閱伺服器上,各裝置抓取的是同一份,天然一致,不存在「誰忘了同步」的問題。
按方照抓:
- 在每台裝置的用戶端裡,用同一條訂閱 URL 新建遠端設定(Profile),命名保持一致,便於日後辨認與對照。
- 開啟自動更新:Clash Verge Rev 可在訂閱項目上設定更新間隔,mihomo 系行動端用戶端普遍支援定時刷新。間隔建議 24 小時——太頻繁徒增請求,太稀疏則節點變動跟不上。
- 若訂閱原始內容不完全合用(要統一附加自訂規則或調整分組),在訂閱轉換層處理一次,各裝置訂閱轉換後的同一條連結;日後改動只維護轉換層這一處。
訂閱連結即憑證
誰拿到連結,誰就能消耗套餐流量。分發範圍僅限自己的裝置,勿貼進群組聊天、公開文件或截圖。
禁忌:自訂修改不要直接寫進訂閱產生的設定檔——下次更新即被覆寫。要改,改在用戶端的覆寫機制裡:Clash Verge Rev 用全域擴充設定(Merge / Script),mihomo 設定則把自訂段與訂閱段分開維護。這樣訂閱照常更新,改動照常生效。
方子二:WebDAV 同步
適用症狀:自訂改動多——自寫規則、多個本機設定並行——希望一處改、處處用。
以 FlClash 為代表的多平台用戶端內建了 WebDAV 同步,部分桌面用戶端也提供 WebDAV 備份入口。原理相同:把設定目錄打包上傳到同一個 WebDAV 帳戶,其餘裝置從同一帳戶抓取還原。堅果雲、Nextcloud、Synology NAS 的 WebDAV 服務都可充當這只藥櫃。
按方照抓:
- 備好 WebDAV 帳戶:堅果雲需在安全設定裡開啟第三方應用密碼;自建 Nextcloud 則記下伺服器位址、帳號、密碼三項。
- 在主力裝置的用戶端裡填入 WebDAV 資訊,執行一次備份上傳。
- 其餘裝置填入同一帳戶,執行還原下載。此後每次大改之後上傳一次;支援自動同步的用戶端可開啟定時。
禁忌三條:
- WebDAV 同步的是設定檔,不是執行狀態。還原後需重新選擇啟用中的設定、重測延遲,代理模式也要重新確認。
- 多數實作遵循「後寫覆蓋先寫」。兩台裝置先後改動再同步,先改的那份會被吞掉。養成固定順序:改完即傳,用前先抓。
- 設定內含訂閱位址與節點憑證,WebDAV 帳戶的防護等級應等同於代理帳戶本身:獨立密碼,能開兩步驟驗證就開。
還原完成後,先用一條指令驗證通路,再投入使用:
curl -x http://127.0.0.1:7890 https://www.google.com
方子三:手動匯出匯入適用症狀:裝置少(一到兩台)、改動不頻繁,或者只是換機、重灌系統時需要一次性搬遷。劑量最小,人人可抓。
做法是把設定檔從一台裝置複製到另一台:桌面用戶端一般在設定管理頁提供匯出,或直接到設定目錄裡取 YAML 檔;行動端多用分享或匯出功能,走區域網路傳輸、雲端硬碟、傳輸線均可。
按方照抓:
- 在來源裝置匯出設定:Clash Verge Rev 的設定目錄通常在系統應用程式資料目錄下的 profiles 資料夾,每個訂閱對應一個 YAML;FlClash 等用戶端在設定裡直接提供匯出入口。
- 把 YAML 檔傳到目標裝置,在用戶端裡選擇「匯入本機檔案」。
- 匯入後核對連接埠設定——若兩台裝置的
mixed-port、外部控制連接埠衝突或不同,按目標裝置的習慣改回。 - 核對訂閱更新位址:若 YAML 是訂閱更新後的產物,目標裝置上它只是一份靜態檔案,後續更新仍需在目標裝置重新新增訂閱連結,或定期重複本流程。
提示
手動匯出得到的是某一時刻的快照。它適合搬遷,不適合長期保持一致——時間一長,各裝置又會漸漸岔開。
抓藥對照:三種方案怎麼選
三味藥性不同,按裝置數量、改動頻率、是否依賴訂閱三味主症抓藥:
| 方案 | 適用情境 | 同步內容 | 主要代價 |
|---|---|---|---|
| 訂閱連結統一分發 | 裝置多、改動少、設定以訂閱為主 | 訂閱內的節點與規則 | 自訂改動須走覆寫層,不能直接改訂閱檔案 |
| WebDAV 同步 | 自訂多、多設定並行、希望一處改處處用 | 整個設定目錄(視用戶端實作) | 依賴第三方儲存,後寫覆蓋先寫 |
| 手動匯出匯入 | 裝置少、換機搬遷、低頻改動 | 單個設定檔快照 | 全靠自覺,時效性最差 |
複方也常見:訂閱連結打底保證節點新鮮,WebDAV 或手動匯出負責搬運自寫規則與本機設定。兩者不衝突,各管一段。
醫囑:同步之後的注意事項
方子抓齊,另有幾句醫囑,免得好好的設定越同步越亂:
- 連接埠統一:各裝置的
mixed-port(預設 7890)盡量保持一致,瀏覽器代理、命令列工具裡的設定才能一套通用。 - 模式對齊:規則、全域、直連三種模式是各裝置本機狀態,不隨設定同步。換裝置後先確認模式,再談其他。
- 核心版本別差太多:新版 mihomo 的設定欄位(如
sniffing相關寫法)放到舊核心上可能報錯。跨裝置共用同一份 YAML 時,以最低版本用戶端的語法為準。 - TUN 與系統代理是裝置層級設定:不隨設定檔走,每台裝置按需單獨開啟,別開完一台就以為處處生效。
- 改動留底:大改規則之前,先匯出一份舊設定存檔。同步機制只會忠實地把錯誤也一併分發到每台裝置。
多裝置這件事,本質不是技術難題,而是秩序問題:定一個設定源頭,定一條更新紀律,剩下的交給用戶端按時執行。源頭一亂,再多工具也補不回來。