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

在 Windows、macOS、Linux 與行動裝置之間使用 Clash 或 mihomo 時，通常不只需要同步一份 YAML。代理節點可能來自訂閱，規則來自遠端規則集，策略群組屬於個人偏好，而連接埠、TUN、區域網路存取與 DNS 監聽位址又取決於裝置環境。若直接複製客戶端的整個資料目錄，很容易連同快取、執行狀態、資料庫與平台專屬欄位一起帶到另一台裝置，最後造成連接埠衝突、設定無法載入或本機修改遭到覆蓋。

較穩定的做法是先劃分設定層級：將持續更新的遠端資料交給訂閱或 Provider，把跨裝置一致的規則與策略放進可審閱的基礎設定，再把連接埠、TUN、DNS 與區域網路參數留在裝置覆寫層。訂閱連結、覆寫檔案與私有儲存庫並非互斥的三選一方案，而是分別解決資料分發、裝置差異與版本管理問題。

先確認同步範圍：設定來源、裝置參數與執行資料

多裝置同步的第一步不是選擇工具，而是確認哪些內容應該擁有同一個權威來源。建議將 Clash 設定拆分為以下四類：

• 遠端資源：代理節點訂閱、代理 Provider、規則 Provider。這類內容由遠端維護，客戶端會依設定週期更新。
• 共用邏輯：策略群組名稱、規則順序、網域規則、區域分流與預設策略。這些內容適合放入基礎 YAML 或版本儲存庫。
• 裝置參數：mixed-port、控制連接埠、區域網路監聽、TUN 開關、網卡選擇及部分 DNS 監聽參數。這些內容應依裝置個別維護。
• 執行資料：日誌、快取、連線記錄、Geo 資料下載結果、Provider 快取與客戶端資料庫。這些資料應由各裝置自行產生。

客戶端的「設定目錄」往往同時包含上述多種資料，因此不宜直接透過雲端硬碟雙向同步整個目錄。兩台裝置同時執行時，資料庫與狀態檔案可能反覆遭到覆蓋；不同作業系統也會寫入不同的路徑、權限與換行格式。需要移轉時，應匯出明確的 YAML 或客戶端提供的備份檔案，而不是把正在使用的資料目錄當成共用資料夾。

方案一：使用訂閱連結同步節點

訂閱連結最適合解決「多台裝置取得同一批節點」的問題。每台裝置分別匯入同一個訂閱網址，再由客戶端定期更新。如此不必手動複製節點清單；當節點名稱、位址或可用狀態發生變化時，各裝置都能獨立取得最新內容。

但訂閱本身通常只提供代理項目，或提供一份由服務端產生的完整設定。若服務端的完整設定包含策略群組與規則，客戶端更新時仍會以遠端內容為準。為避免本機自訂內容遭到覆蓋，可以保留一份未修改的訂閱設定，再透過客戶端支援的合併、腳本或覆寫功能加入裝置規則。不同客戶端對「覆寫」「合併設定」與「前處理腳本」的實作並不一致，移轉客戶端前應先確認其處理順序。

對於 mihomo 設定，也可以將節點來源宣告為 proxy-providers，讓共用基礎設定只引用遠端 Provider。以下結構展示更新週期、快取路徑與健康檢查之間的關係：

proxy-providers:
  primary:
    type: http
    url: https://sub.example.net/profiles/team-laptop.yaml
    path: ./providers/primary.yaml
    interval: 21600
    health-check:
      enable: true
      interval: 600
      url: https://www.gstatic.com/generate_204

proxy-groups:
  - name: 手動選擇
    type: select
    use:
      - primary
    proxies:
      - DIRECT

interval 控制 Provider 的抓取間隔；健康檢查間隔則用於檢測其中的代理，並不等同於重新下載訂閱。快取路徑應保持為目前裝置的本機路徑，不需要放入同步儲存庫。範例網域僅用於說明結構，實際使用時請填入自己的訂閱網址，並依網路環境選擇可存取的測試網址。

隔離訂閱憑證的方式

訂閱 URL 往往帶有可用於存取資源的憑證，應按照敏感資訊處理。不要將真實訂閱網址寫入公開儲存庫、截圖、故障日誌或可公開分享的設定片段。多裝置使用時，可以在每個客戶端本機儲存訂閱網址，共用儲存庫只維護不含憑證的策略與規則。若服務端支援為不同裝置簽發獨立網址，分別使用裝置層級憑證會更方便停用單一裝置的存取權。

還要注意，普通 Clash 客戶端未必能直接讀取需要 Git 登入狀態的私有儲存庫網址。瀏覽器能開啟某個私有檔案，並不代表核心發出的 HTTP 請求也會帶有相同的驗證資訊。短期有效的下載網址到期後同樣會導致自動更新失敗，因此訂閱分發端應提供適合客戶端長期抓取的存取方式。

方案二：使用覆寫檔案保存裝置差異

覆寫層適合處理「規則大致相同，但系統參數不同」的情況。例如桌上型電腦需要 TUN 接管部分不讀取系統代理的程式，辦公裝置只啟用系統代理，家用裝置則允許區域網路存取。若將這些差異硬塞進同一份 YAML，每次同步後都得手動改回本機參數。

可以讓共用基礎設定維持中性狀態，再為每台裝置維護簡短的差異檔案。邏輯上可依下列方式拆分：

profiles/
  base.yaml
overrides/
  windows-desktop.yaml
  macbook.yaml
  linux-shell.yaml
rules/
  local-direct.yaml
  service-routing.yaml

Windows 桌面覆寫可以啟用 TUN 並指定自動路由，Linux 命令列環境可能只需要固定的混合連接埠，macOS 則依使用的客戶端與系統權限決定是否啟用 TUN。allow-lan、bind-address 與外部控制器監聽位址也應視為裝置參數，因為它們會改變區域網路中的可存取範圍。

mixed-port: 7890
allow-lan: false

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true

覆寫並不代表任意 YAML 都能自動疊加。不同客戶端可能採用淺層合併、深層合併、腳本處理或欄位替換；陣列尤其容易產生差異。例如覆寫中的 rules 陣列，可能會完整替換基礎設定中的規則，而不是追加到末尾。策略群組陣列也可能以整體替換處理。第一次建立同步流程時，應使用少量測試規則確認實際合併結果，再移轉完整設定。

DNS 設定也需要區分共用項目與裝置項目

DNS 的規則邏輯可以共用，例如是否使用 Fake-IP、哪些網域加入排除清單、哪些規則集用於分流；但監聽位址、區域網路 DNS 服務與系統 DNS 接管方式取決於裝置環境。行動熱點、家庭區域網路與公司網路可能有不同的內部網域解析需求。若所有裝置同步同一個 nameserver 與監聽設定，一台裝置正常並不能證明另一台也適用。

使用 TUN 時，還要確認客戶端核心版本與平台權限是否支援相應欄位。mihomo 的擴充設定不應直接交給只相容於舊版原始 Clash 欄位的客戶端。跨平台同步前，先確認各客戶端實際使用的核心，再決定共用設定採用哪一組欄位。

方案三：使用私有儲存庫管理共用設定與修改歷史

當設定包含較多自訂規則、多個裝置覆寫與需要長期維護的腳本時，私有 Git 儲存庫比反覆傳送 YAML 更容易追蹤變更。儲存庫的主要價值是記錄「誰修改了哪段邏輯、為什麼修改、出現問題時要回退到哪裡」，而不是直接取代訂閱服務。

建議儲存庫只保存可審閱的來源檔案，不要提交客戶端執行目錄。可納入版本管理的內容包括基礎 YAML、裝置覆寫、規則文字、產生腳本與使用說明；應排除日誌、快取、資料庫、真實訂閱網址以及客戶端自動下載的 Provider 檔案。

clash-config/
  profiles/
    base.yaml
  overrides/
    desktop.yaml
    laptop.yaml
    server.yaml
  rules/
    private-network.yaml
    work-services.yaml
  scripts/
    build-config.js
  README.md
  .gitignore

如果團隊或家庭成員需要共用同一套規則，可以在儲存庫中約定策略群組名稱。例如規則只能引用 手動選擇、自動選擇 與 DIRECT，裝置覆寫不得任意改名。如此新增規則時，就不會因為某台裝置缺少目標策略群組而載入失敗。

私有儲存庫中的設定可以透過兩種方式部署。第一種是在每台裝置上拉取儲存庫，再由本機腳本將基礎層與裝置層合成最終 YAML；第二種是在受控環境產生最終設定，再發布到客戶端可存取的分發網址。前者方便本機除錯，但要求裝置具備 Git 與產生環境；後者更適合只負責匯入訂閱的客戶端，但需要妥善管理分發權限。

避免儲存庫與客戶端爭奪修改權

應明確決定儲存庫與客戶端誰是權威來源。若以儲存庫中的規則為準，就不要長期手動修改客戶端產生的最終設定；需要調整時，應回到來源檔案修改、測試並重新產生。若某台裝置臨時增加規則，應先記錄為本機實驗，確認有效後再合併到共用層。否則客戶端中的修改可能在下一次拉取或產生時消失，儲存庫也無法說明這次差異的來源。

YAML 錨點可以減少同一檔案內的重複內容，但錨點無法自然跨越多個獨立檔案。拆分設定後的組合方式仍取決於客戶端覆寫功能或外部產生步驟。不要只憑檔案副檔名判斷它們能否直接合併。

固定更新順序：先遠端資源，再覆寫，最後驗證

多裝置同步最常見的問題不是設定寫錯，而是更新順序不一致。一台裝置先更新訂閱再套用覆寫，另一台裝置先覆蓋完整設定再更新訂閱，最後得到的策略群組與規則可能不同。建議所有裝置採用同一流程：

1. 確認目前的權威來源。檢查這次要修改的是訂閱、共用基礎設定還是裝置覆寫，避免直接編輯產生結果。
2. 拉取共用設定。從私有儲存庫取得最新基礎層與規則檔案，先處理版本衝突。
3. 更新遠端資源。重新整理代理 Provider 與規則 Provider，確認網址仍可存取。
4. 套用裝置覆寫。加入本機連接埠、TUN、DNS 監聽與區域網路參數。
5. 執行設定測試。使用客戶端的設定檢查或核心測試功能，確認 YAML 語法、策略群組引用與規則目標有效。
6. 重新載入並驗證流量。分別測試直連網域、代理網域、DNS 查詢及不讀取系統代理的應用程式。
7. 提交有意保留的修改。只有確認屬於共用邏輯的變更才進入儲存庫；臨時連接埠與本機路徑保留在裝置層。

更新過程中不建議讓多台裝置同時向同一個雲端硬碟檔案寫入結果。Git 可以處理文字版本，但客戶端資料庫與產生檔案通常不適合合併。需要在另一台裝置繼續修改時，應先完成提交與推送，再於目標裝置拉取，避免兩邊都根據舊版本編輯同一段規則。

同步衝突與載入失敗的排查方法

訂閱更新後自訂規則消失

先確認自訂規則是否直接寫在訂閱產生的檔案中。若是，更新時遭遠端完整設定覆蓋屬於預期結果。請將規則移至客戶端支援的覆寫層，或維護獨立的基礎設定，再透過 rule-providers 引用規則。還要檢查覆寫的執行順序：某些客戶端會在訂閱更新後自動重新套用覆寫，另一些客戶端則需要手動重新產生設定。

同一份設定在一台裝置可用，另一台卻無法啟動

優先檢查核心類型、欄位支援與本機資源。原始 Clash、Clash Meta 與 mihomo 對擴充欄位的支援範圍不同；TUN 還取決於系統權限與平台網路堆疊。接著檢查連接埠是否被佔用、本機路徑是否存在、外部控制器位址是否衝突。不要急著刪除規則，因為規則通常不會導致監聽連接埠建立失敗。

策略群組提示找不到代理或 Provider

檢查 use 引用的 Provider 名稱是否與 proxy-providers 中完全一致，並確認 Provider 已成功下載。若共用設定使用固定的策略群組名稱，裝置覆寫不應將其改名。YAML 對縮排很敏感，Provider 若縮排到錯誤層級，也可能顯示為找不到引用。

不同裝置的規則命中結果不一致

先比較最終載入的設定，而不只是比較儲存庫中的來源檔案。不同裝置可能使用不同版本的規則 Provider 快取，也可能在覆寫時替換整個 rules 陣列。確認規則順序一致，尤其是範圍較大的網域規則、GEOIP 規則與末尾的 MATCH 預設規則。Clash 通常會依規則由上而下比對，較早命中的規則會決定後續流量的去向。

私有儲存庫網址可在瀏覽器開啟，客戶端卻更新失敗

這通常與驗證方式有關。瀏覽器保存了登入狀態，但 Clash 核心發出的 Provider 請求沒有相同憑證。檢查網址是否依賴網頁工作階段、暫時授權或轉址頁面。客戶端必須能直接取得 YAML 內容並收到正常的 HTTP 回應；若回傳的是登入頁面，即使狀態看似成功，也會因內容不是有效 YAML 而解析失敗。

三種方案的組合建議

只有兩三台個人裝置、規則變更較少時，可以採用「訂閱連結加客戶端覆寫」：由訂閱更新節點，連接埠與 TUN 留在各裝置，自訂規則放入客戶端明確支援的覆寫設定。這種方式的維護成本較低。

需要長期維護大量規則時，可以採用「訂閱 Provider、共用基礎設定、裝置覆寫」三層架構。基礎設定負責策略群組與規則順序，Provider 負責節點與遠端規則，裝置覆寫負責平台差異。最終設定由客戶端合併，或透過本機腳本產生。

多人協作或裝置數量較多時，再加入私有儲存庫管理基礎設定、規則與產生流程。儲存庫不保存真實訂閱憑證，也不負責同步客戶端快取。每次修改都經過拉取、測試、提交與部署，裝置只使用與自身對應的最終設定。

無論選擇哪種組合，都應避免同時存在多個權威來源。節點由訂閱維護，規則由儲存庫維護，裝置參數由本機覆寫維護；每一類內容只在一個位置編輯。邊界清楚後，多裝置同步就能從「複製整份設定」轉變為「分層更新並驗證」，訂閱更新、規則迭代與平台差異也更容易分開處理。