Clash 多裝置設定同步：訂閱連結、私人託管與本機覆寫比較

先劃分同步範圍：節點、規則與裝置參數

Clash 多裝置設定同步，不代表要複製整個用戶端資料夾。節點憑證、分流規則和系統代理狀態各屬不同層級。將桌面設定原封不動匯入手機，可能遇到欄位不支援、連接埠衝突或 TUN 啟動失敗。較穩妥的做法是共用節點來源與規則設定，網卡、監聽連接埠和系統整合則留在各裝置本機管理。

也要先區分用戶端與核心。使用 mihomo 的桌面用戶端可能支援相同的核心欄位，但設定合併、背景更新和指令碼執行方式由用戶端決定。其他核心或行動裝置代理程式即使接受部分 Clash 格式，也不代表能完整使用 mihomo 設定。本文的 YAML 範例以 mihomo 為準，匯入前請確認目標核心及其支援的欄位。

方案一：在各裝置匯入相同的訂閱連結

兩到三台裝置使用同一家服務商時，訂閱連結通常是維護成本最低的選擇。在每台用戶端的訂閱或設定頁面加入相同網址，手動更新並啟用設定即可。同步的是各裝置從伺服器取得的內容，而不是裝置之間直接傳送設定。

分別檢查設定更新與連線狀態

1. 先在電腦匯入訂閱，確認節點清單、策略組和規則都能正常使用，再匯入手機和平板。
2. 檢查各裝置的訂閱更新設定。若用戶端支援，可將檢查週期設為 24 小時；這是維護建議，並非 Clash 的統一預設值。
3. 服務商調整節點後，逐台手動更新一次，並確認目前啟用的仍是這個訂閱。
4. 在連線頁面檢查實際套用的規則和出口，不能只看設定檔是否顯示「更新成功」。

更新訂閱不會自動同步策略組目前選取的節點。電腦選了某個地區的節點，手機仍可能保留自己的選擇；連線紀錄、系統代理開關和 TUN 開關通常也各自獨立。若要讓各裝置使用一致的策略，可在設定中採用相同的自動選擇組設計，但各裝置測得的延遲仍會因網路不同而有差異。

主要限制：更新時間取決於用戶端排程

手機應用程式在背景執行時，可能遭系統暫停。即使設定每 24 小時更新，也無法保證會在指定時間成功下載。電腦進入睡眠或訂閱伺服器無法連線，也會延後更新。計畫停用舊節點時，應預留過渡時間，並在手機上開啟應用程式後手動更新一次。

也要確認服務商對裝置數量、同時連線數及帳戶使用方式的規定。共用訂閱不代表可以無限制散布。訂閱 URL 通常含有存取權杖，取得網址的人可能讀取節點資訊，應視同帳戶憑證妥善保管。

方案二：以私人方式託管 YAML，集中管理規則

自訂規則較多，或需要審核設定變更時，可將設定來源存放在私人儲存庫，再透過受控的 HTTPS 入口提供給各裝置。儲存庫用來記錄版本，下載入口則負責身分驗證，兩者用途不同。私人儲存庫的網頁網址通常會顯示登入頁面，不能直接當作 YAML 訂閱網址。

完整設定與獨立規則集的差異

託管完整設定時，裝置下載後應取得包含代理、策略組和規則的可用設定；若只託管規則集，則須在主要設定中使用 rule-providers 引用，再由 rules 呼叫。單獨的規則集檔案不能當作完整訂閱啟用。

以下以本機檔案說明規則集的結構。先將規則檔放到核心工作目錄下的 rules/shared-direct.yaml，內容如下。example.com 是保留的示範網域，用來驗證規則格式；正式部署時請改成實際使用的網域。

payload:
  - DOMAIN-SUFFIX,example.com

在主要設定中加入以下片段，並保留原有節點和策略組。範例假設現有策略組名稱為「節點選擇」；若名稱不同，請在最後一行填入設定中實際使用的名稱。

rule-providers:
  shared-direct:
    type: file
    behavior: classical
    format: yaml
    path: ./rules/shared-direct.yaml

rules:
  - RULE-SET,shared-direct,DIRECT
  - MATCH,節點選擇

rules 會由上而下比對，最後的 MATCH 是預設規則。上述清單僅用來說明順序，不應直接取代訂閱中的所有既有規則。若改用 HTTP 規則提供器，須設定 type: http，並另行指定實際下載網址、快取路徑和 interval。例如 interval: 86400 表示更新間隔為 86400 秒，也就是 24 小時；這項設定控制規則提供器的更新，不是完整訂閱的更新。

存取權限與備援副本

• 在每種目標用戶端上測試下載入口，確認取得的是 YAML，而不是登入頁面、轉址頁面或錯誤訊息。
• 若需要自訂驗證標頭，請先確認用戶端及對應的下載機制是否支援；瀏覽器已登入，不代表用戶端也能存取。
• 儲存庫中盡量只存放規則與產生設定的邏輯。節點密碼、訂閱權杖和控制介面金鑰應分開管理。
• 每次發布都保留一份已驗證的舊版本；設定解析失敗時，可改用本機副本。

私人儲存庫不代表機密不會外洩。憑證一旦提交，即使之後刪除檔案，也不會自動從版本記錄中移除。若不慎提交，應先撤銷或更新憑證，再處理歷史記錄。請勿將含權杖的下載網址貼到公開討論區或截圖中。

方案三：更新訂閱後套用本機覆寫

本機覆寫適合「節點跟隨上游，裝置設定維持不變」的情境。用戶端通常會先取得訂閱，再透過合併設定或指令碼產生最終執行設定。不過，「覆寫」並非所有 Clash 用戶端都遵循的統一協定；檔案格式、合併順序和指令碼支援情況，須依實際使用的用戶端確認。

桌面版可在用戶端提供的合併設定或覆寫功能中管理以下裝置參數。此片段僅示範監聽本機的混合代理連接埠，不設定系統代理，也不啟用 TUN。

mixed-port: 7890
allow-lan: false
bind-address: 127.0.0.1
mode: rule

如果用戶端統一管理監聽連接埠，建議直接在設定介面修改，避免介面設定與覆寫檔互相覆蓋。手機的 VPN 接管機制與桌面系統代理不同，不必為了「同步」而硬套用桌面端的連接埠設定。

清單合併最容易出錯

rules、proxies 和 proxy-groups 都是清單。不同用戶端可能會取代整份清單，也可能支援前置、後置或指令碼處理。不要假設新增兩條本機規則後，原有數千條規則仍會保留。修改後應查看最終執行設定，確認原有清單沒有意外遭清除。

• 自訂直連規則應放在能夠比對的位置，通常要放在最後的 MATCH 之前。
• 新增規則引用的策略組必須存在，組名中的空格與大小寫也必須一致。
• DNS 設定應一併檢查。只修改 enhanced-mode，並不能確保各平台採用相同的 DNS 接管方式。
• TUN 的裝置名稱、路由排除項目和權限設定應留在本機，避免直接套用到其他系統。

三種方案的更新速度與維護成本

以一台電腦、一支手機和一台平板為例，可先透過統一訂閱更新節點，再讓電腦保留獨立的本機監聽設定。等共用規則確實需要頻繁調整時，再導入託管規則集。這樣只增加必要的維護步驟，不必一開始就部署設定產生服務。

若三台裝置都在前景執行，手動更新通常比等待排程更容易確認結果，但不能因此保證固定秒數內完成同步。實際更新時間至少包含發布、用戶端排程、網路下載和重新載入四個階段。應記錄實際更新時間，而非只比較設定的檢查週期。

上線與排錯：使用同一條連線進行驗證

首次發布的五項檢查

1. 記錄環境。分別記下用戶端名稱與版本、核心名稱與版本，避免只寫「最新版」。
2. 保存舊設定。匯出目前可正常使用的設定，並記錄策略組目前的選擇；備份檔應依含有憑證的資料妥善保管。
3. 逐台更新。先更新電腦，再更新手機，確認各裝置的下載時間與目前啟用的設定；不要同時修改所有裝置。
4. 檢查執行設定。查看 mode、規則順序和引用的組名，確認覆寫已套用至最終設定。
5. 測試實際連線。存取同一網域，比對連線紀錄中的匹配規則、策略組和最終節點，再測試一個應直接連線的網站。

設定相同，分流結果為何不同？

先確認所有裝置是否都處於規則模式。全域模式不會依相同的規則清單進行分流。接著確認應用程式流量是否進入核心：桌面瀏覽器可能透過系統代理，其他程式卻未使用代理；手機則可能由 VPN 接管。最後再比對 DNS 結果、規則提供器快取和策略組目前的選擇。

更新成功了，為什麼還是舊規則？

依序檢查「下載檔案 → 目前啟用項目 → 合併結果 → 核心執行設定」。常見原因包括更新了未啟用的訂閱，或本機覆寫在最後一步重新寫入舊規則。完整訂閱與 HTTP 規則集也可能各自使用獨立快取；更新訂閱後，還應檢查規則提供器的狀態。

如何回復設定，同時保留排錯線索？

先保存錯誤訊息與失敗版本，再切回上一個可用設定。若修改涉及 TUN 或系統代理，也應恢復對應的裝置開關，避免用戶端關閉後，系統仍指向失效的監聽連接埠。後續每次只修改一個層級：先驗證節點來源，再驗證共用規則，最後啟用本機覆寫。多裝置同步的目標是讓分流策略可追蹤、裝置差異可解釋，而不是讓所有檔案逐字相同。