Clash 多裝置設定同步方案：WebDAV、訂閱連結與手動匯出比較

先區分設定同步、訂閱更新與用戶端備份

Clash 多裝置同步並不是單一開關。Windows、macOS、Android 與 Linux 用戶端可能都使用 mihomo 核心，但各用戶端儲存的資料並不完全相同。真正需要同步的內容通常分為三層：遠端提供的節點與規則、本機撰寫的 YAML 設定，以及用戶端自己的介面設定與執行狀態。

三類資料不能混為一談

• 訂閱內容：包括代理節點、代理群組、規則和提供者定義。用戶端透過 URL 重新下載，適合由單一遠端來源集中維護。
• 核心設定：包括 dns、tun、sniffer、監聽連接埠、規則集網址等 YAML 欄位。不同核心版本支援的欄位範圍可能不同。
• 用戶端狀態：包括目前選取的代理節點、主題、開機啟動、系統代理開關、視窗大小和日誌層級。這些通常儲存在用戶端資料庫或偏好設定中，不一定包含於 YAML 檔案內。

例如，電腦上啟用系統代理並監聽 127.0.0.1:7890，只是電腦用戶端的執行設定。將同一份設定匯入 Android 後，手機不會取得相同的系統代理狀態，而是透過 Android VPN 介面接管流量。同樣地，桌面端的 TUN 網卡名稱、路由排除項目和系統管理員權限設定，也不應原樣套用到手機。

同步前先記錄四項基準

1. 確認每台裝置使用的核心名稱和版本，例如 mihomo 1.19.x，避免舊核心無法識別新欄位。
2. 記錄混合連接埠、控制連接埠和區域網路監聽設定。常見混合連接埠是 7890，外部控制器常見為 127.0.0.1:9090，但實際值以目前設定為準。
3. 檢查設定中的本機絕對路徑，例如 Windows 的 C:\Users\... 或 Android 私有目錄。這類路徑無法直接跨平台使用。
4. 儲存目前可正常運作的設定副本，並註明日期、裝置和用戶端版本，例如 home-win-2026-08-16.yaml。

方案一：用訂閱連結集中維護節點和規則

訂閱連結是多裝置情境中操作成本最低的方案。電腦和手機分別儲存同一個 URL，需要更新時各自向伺服器取得最新內容。這不是裝置之間互相複製檔案，而是讓所有裝置讀取同一個資料來源，因此不會產生「哪台裝置的副本才是最新版」的衝突。

典型匯入流程

以常見用戶端介面為例，桌面端通常進入「訂閱」→「新增」→「URL」，填寫訂閱網址並設定自動更新時間；Android 用戶端通常進入「設定」→「＋」→「從 URL 匯入」。選單文字會隨用戶端版本變化，但核心動作都是儲存 URL、下載設定、選取該設定並啟動核心。

1. 在第一台裝置上匯入訂閱，確認下載回應正常，並檢查節點數量與代理群組名稱。
2. 切換至規則模式，測試一個直連網站和一個需要代理的網站。
3. 在第二台裝置匯入相同 URL，不要先複製第一台裝置產生的快取檔案。
4. 分別設定更新時間。日常使用可設定為每 1440 分鐘更新一次；節點變動頻繁時可縮短至 360 分鐘，但沒有必要每幾分鐘請求一次。
5. 更新後查看用戶端日誌，確認回應狀態和設定解析都成功。

訂閱方案的優勢與限制

最常見的問題是直接編輯訂閱下載後的 YAML。許多用戶端會將該檔案視為遠端快取，按下「更新」時便會覆寫本機修改。需要長期保留的 DNS、規則或代理群組調整，應放入用戶端支援的覆寫、擴充腳本或合併設定中；如果用戶端沒有這些功能，就維護一份獨立設定，而不要把訂閱快取當作主檔案。

用 provider 拆分可變內容

熟悉 YAML 的使用者可以讓主設定保持穩定，只把節點或規則放進遠端 provider。以下結構展示基本關係，URL 和路徑需要替換成實際可存取的位置：

mixed-port: 7890
mode: rule
allow-lan: false

proxy-providers:
  remote-nodes:
    type: http
    url: "https://example.net/profile/nodes.yaml"
    path: "./providers/remote-nodes.yaml"
    interval: 21600
    health-check:
      enable: true
      url: "https://www.gstatic.com/generate_204"
      interval: 600

rule-providers:
  private-rules:
    type: http
    behavior: classical
    format: yaml
    url: "https://example.net/rules/private.yaml"
    path: "./rules/private.yaml"
    interval: 86400

interval: 21600 表示節點提供者每 6 小時檢查一次，規則的 86400 則是每天一次。provider 的本機 path 是快取位置，不應依賴某台裝置的絕對目錄。不同版本的 mihomo 對 format、規則行為和 provider 欄位的支援可能不同，匯入後應先查看解析日誌。

方案二：透過 WebDAV 進行備份與還原

WebDAV 更接近「將用戶端資料打包儲存到遠端，再在另一台裝置還原」。它適合儲存多個設定、覆寫腳本、規則檔案和部分用戶端偏好，但前提是兩端用戶端都實作相容的 WebDAV 備份格式。WebDAV 只規定檔案存取方式，並未規定 Clash 用戶端必須採用相同的備份結構。

適合使用 WebDAV 的情境

• 在兩台桌面裝置之間遷移同一個用戶端，例如從舊電腦換到新電腦。
• 需要同時儲存多個設定檔、腳本和用戶端設定，而不只是節點訂閱。
• 希望定期保留還原點，在設定弄壞後退回昨天或上週的版本。
• 遠端服務支援 HTTPS、獨立帳號和檔案版本歷程。

若用戶端提供此功能，入口通常位於「設定」→「備份與還原」→「WebDAV」或「設定」→「資料」→「WebDAV」。填寫伺服器網址、使用者名稱、密碼和遠端目錄後，應先執行「測試連線」，再建立第一份備份。網址可能是服務根路徑，也可能是完整目錄，例如 https://dav.example.net/remote.php/dav/files/user/clash/，具體格式以伺服器端說明為準。

一套穩妥的首次同步順序

1. 在主要裝置停用自動還原，手動建立一個附帶時間的遠端備份。
2. 登入 WebDAV 服務確認檔案已產生，並記錄檔案大小。例如正常備份為 2.8 MB，若只有幾十位元組，應檢查是否上傳了錯誤頁面。
3. 在第二台裝置安裝相同用戶端的大版本，再設定 WebDAV 連線。
4. 先下載備份清單，不要立即開啟雙向自動同步。
5. 選擇明確時間點進行還原，重新啟動用戶端，然後逐項檢查訂閱、規則模式、DNS 和 TUN 開關。
6. 確認第二台裝置運作正常後，再決定是否啟用定時備份。

連線失敗時，可根據 HTTP 狀態縮小範圍：401 通常表示憑證驗證未通過，403 表示帳號缺少目錄權限，404 常見於路徑填寫錯誤，409 可能是上層目錄尚未建立，507 則表示遠端空間不足。用戶端只顯示「備份失敗」時，需要同時查看 WebDAV 伺服器端日誌。

WebDAV 不等於即時雙向合併

如果電腦與手機分別修改同一份設定，然後都上傳至相同檔名，後上傳的一方可能會覆蓋前一份。大多數用戶端不會像協作文件那樣逐欄位合併 YAML，也無法判斷代理群組變更和 DNS 變更是否都應保留。

跨用戶端還原尤其需要謹慎。用戶端甲可能將設定儲存為 YAML 和 JSON 索引，用戶端乙可能使用資料庫記錄設定 ID。即使兩者都使用 mihomo，WebDAV 備份也未必互通。更換用戶端時，應優先匯出標準 YAML 或重新匯入訂閱，而不要直接還原另一款用戶端的完整資料包。

方案三：手動匯出與匯入 YAML

手動匯出最容易理解，也最適合低頻率遷移：從現有用戶端匯出設定檔，透過區域網路檔案傳輸、資料線或個人儲存空間傳送到另一台裝置，再從檔案匯入。它不會自動更新，但每次傳遞的內容明確，方便封存和比較。

標準操作步驟

1. 在用戶端進入「設定」或「訂閱」，找到目前啟用的項目，選擇「匯出」或「開啟設定目錄」。
2. 複製主 YAML 檔案；若設定引用本機 provider、腳本或規則檔案，也要一併複製對應目錄。
3. 使用文字編輯器搜尋絕對路徑、區域網路位址和裝置專用網卡名稱。
4. 將檔案命名為包含用途和日期的形式，例如 travel-phone-2026-08-16.yaml。
5. 在目標裝置進入「設定」→「＋」→「從檔案匯入」，完成後先查看解析錯誤，再啟動代理。

跨平台時應重點檢查這些欄位

• external-controller：若寫成 0.0.0.0:9090，控制介面可能會對區域網路開放。一般僅供本機使用時可改為 127.0.0.1:9090。
• secret：控制介面權杖應在各裝置重新設定，不建議長期將同一值複製到所有裝置。
• allow-lan：只有在電腦要為其他裝置提供代理時才需要開啟；手機匯入後通常應重新評估。
• interface-name：網卡名稱具有平台差異，Windows、Linux 和 Android 不能直接共用。
• tun：桌面端的路由、DNS 劫持和自動網卡偵測參數不一定適合行動裝置。
• path：檢查 provider、規則集和腳本是否使用了目標裝置不存在的絕對路徑。

external-controller: 127.0.0.1:9090
secret: "replace-with-device-specific-secret"
allow-lan: false

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

這段設定適合作為檢查範例，不代表所有平台都應原樣啟用。Android 用戶端通常透過系統 VPN 權限執行，桌面系統則可能需要系統管理員權限建立 TUN 網卡。若匯入後出現「設定有效但無法連線」，可先關閉 TUN，只開啟系統代理或應用程式內 VPN，確認基礎節點可用後再逐項恢復。

手動方案最容易遺漏的檔案

主設定中的 proxy-providers 和 rule-providers 若使用 HTTP 類型，目標裝置通常可以重新下載快取；若使用 type: file，則必須連同本機檔案一起遷移。設定中引用的腳本、自訂 GEO 資料和憑證檔案也不會自動嵌入 YAML。

另一個常見誤區是把執行快取當成原始設定。名稱類似 cache.db、profiles.json 或 state 的檔案可能只對目前用戶端有效。跨平台遷移時，優先尋找用戶端明確提供的「匯出設定」功能，而不是複製整個程式資料目錄。

三種同步方式怎麼選

推薦的組合方式

多數使用者不必三選一。更穩定的結構是：訂閱連結負責節點和公共規則，用戶端覆寫負責各裝置的 DNS、TUN 與區域網路設定，WebDAV 或手動匯出負責保留還原點。如此一來，即使某台裝置的設定損壞，也能重新匯入訂閱，再還原少量裝置專用參數。

1. 公共層：節點、代理群組和公共規則從訂閱或 provider 取得。
2. 裝置層：連接埠、TUN、系統代理、區域網路存取和控制介面在本機設定。
3. 備份層：每次大幅修改前建立附帶日期的 WebDAV 備份或匯出 YAML。
4. 驗證層：更新後檢查設定解析、DNS 查詢、規則命中和實際連線能力。

例如，Windows 桌面端可以使用混合連接埠 7890 並開啟系統代理，Android 端則透過 VPN 模式執行；兩端共用代理節點和規則，但不要求共用執行狀態。目前選取的節點也可以不同：電腦選擇低延遲節點，手機則依行動網路穩定度選擇另一個節點。

同步後無法使用時的排查順序

第一步：確認設定是否成功解析

先查看用戶端日誌，不要立即歸因於節點。出現 field not found、yaml unmarshal 或重複鍵提示時，通常是核心版本不支援欄位、YAML 縮排錯誤或合併設定產生衝突。YAML 應使用空格縮排，避免使用 Tab；同一層級的欄位不要重複定義兩次。

第二步：檢查遠端資源

• 手動更新訂閱，確認 URL 可存取且回傳的是設定內容。
• 檢查 provider 下載狀態，確認快取檔案不是空的。
• 核對裝置系統時間，時間偏差可能影響 HTTPS 連線。
• 確認訂閱更新沒有覆蓋本機覆寫，代理群組中仍可看到預期節點。

第三步：分開測試 DNS、規則與 TUN

1. 暫時關閉 TUN，僅使用用戶端支援的基礎代理方式測試節點連線。
2. 暫時將模式切換至全域，判斷問題來自節點還是規則比對。
3. 恢復規則模式，查看日誌中請求命中了哪條規則和哪個策略群組。
4. 檢查 DNS 監聽與劫持。若本機已有服務佔用 53、7890 或 9090，應調整連接埠或停止衝突程序。
5. 最後重新開啟 TUN，確認系統權限、預設路由和網卡自動偵測正常。

多裝置維護的長期做法

裝置越多，就越需要減少在各裝置上直接編輯。公共規則最好只有一個維護來源，裝置專用設定則明確保留在本機。不要讓電腦、平板和手機各自儲存三份略有差異、卻沒有版本標記的完整設定，否則幾個月後很難判斷哪一份包含最新修改。

建立簡單的版本記錄

• 檔名加入日期和用途，不使用「最終版」「最新版」這類無法排序的名稱。
• 每次修改記錄具體欄位，例如「調整 fallback-filter」或「為 Android 關閉 allow-lan」。
• 大幅修改前保留舊設定，確認運作 24 小時後再清理較早版本。
• 分開管理訂閱、WebDAV 和控制介面的憑證，裝置遺失時可以單獨撤銷。
• 每月執行一次還原測試，確保備份檔案不只是成功上傳，也確實能夠匯入。

最終選擇可以很直接：只想讓多台裝置使用同一批節點，就選訂閱連結；需要完整遷移同一個用戶端，就選 WebDAV；只是臨時複製或跨用戶端搬運，就選手動匯出。對經常修改規則的進階使用者，則採用「遠端公共設定＋本機裝置覆寫＋定期備份」的分層方式，維護成本最低，也更容易定位同步後的異常。