電腦與手機共用 Clash 設定：訂閱託管、私有儲存庫與 WebDAV 同步比較

一、先區分共用設定與裝置設定

電腦與手機共用 Clash 設定時，適合共用的是節點來源、代理群組名稱與規則分流邏輯，而不是整個用戶端資料目錄。Clash Meta 使用的 mihomo 核心負責讀取設定並處理連線；用戶端則另外管理訂閱更新、系統代理、VPN 授權與設定覆寫。這兩層設定不可混為一談。

例如，Windows 可以將系統代理指向 127.0.0.1:7890；Android 通常透過用戶端建立 VPN 介面來接管流量。即使兩端讀取相同的 rules，流量進入核心的方式也不同。同步成功應代表「規則與節點來源一致，且各裝置的流量接管方式設定正確」，而不是每個開關都相同。

共用設定：proxy-providers、proxy-groups、rule-providers、rules，以及經兩端驗證的 DNS 策略。
裝置設定：mixed-port、allow-lan、tun、監聽位址、控制介面金鑰與本機檔案路徑。
用戶端狀態：目前選取的節點、測速結果、記錄檔、快取與 VPN 權限。預設不納入設定同步。

二、三種同步方式的更新機制比較

方式	更新如何傳送至裝置	主要限制	適用情境
訂閱連結託管	用戶端定時或手動透過 HTTP 擷取	伺服器端內容與用戶端覆寫分開管理	節點經常變動，手機以讀取為主
私有 Git 儲存庫	先拉取提交，再匯入或重新載入檔案	需要 Git 工具與獨立的匯入步驟	規則變更頻繁，需要審閱與還原
WebDAV	同步工具下載檔案，再交由用戶端匯入	檔案衝突與設定生效是兩回事	已有私有儲存空間，且主要由一台裝置編輯

mihomo 不會因遠端 Git 儲存庫有新提交就自動拉取，也不會自動監看 WebDAV。用戶端是否支援這些來源，需要逐項確認。即使用戶端提供 WebDAV 備份，也可能只備份設定與設定索引，而不是將遠端 YAML 當作即時訂閱。

三、訂閱託管：統一來源，保留本機覆寫

先確認訂閱回傳的內容類型

完整的 Clash 設定可以包含 proxies、proxy-groups 和 rules；節點集合則可能只適合透過 proxy-providers 引用。有些訂閱回傳的是編碼後的節點連結，並非 mihomo 可直接載入的 YAML。兩台裝置應使用相同的設定格式，不能只看網址副檔名判斷。

在電腦用戶端的設定管理中新增遠端設定，填入服務商提供的實際訂閱 URL，並先手動更新一次。
在手機上匯入相同連結，檢查代理群組名稱與規則數量。若結果不同，請確認訂閱格式選項，以及伺服器端是否依用戶端識別資訊回傳不同內容。
將裝置差異放在與該設定關聯的本機覆寫中，不要直接編輯下次更新時會被取代的遠端檔案。
分別設定兩端的更新間隔。例如，用戶端支援時可設為 24 小時；手機背景執行受系統限制，定時更新不代表一定會準時執行。

頂層遠端設定的擷取週期通常由用戶端管理。proxy-providers 中的 interval: 3600 表示該提供者每 3600 秒更新一次，不會取代用戶端整份訂閱的更新設定。規則提供者也有各自的更新週期，請分別確認。

託管與轉換服務的隱私界線

將訂閱 URL 交給遠端轉換服務，代表該服務可能讀取訂閱中的節點資料。自架轉換服務也必須妥善保護存取入口、請求記錄與快取。只有兩端確實需要轉換格式時才增加這一層；若原始訂閱已輸出相容 mihomo 的設定，直接匯入通常更容易排查問題。

若要託管自己的完整設定，請使用 HTTPS 與存取控制，並避免在記錄中留下含敏感資訊的 URL。支援要求標頭驗證的用戶端可使用獨立憑證；只支援 URL 的用戶端則須妥善保管連結。連結外洩後，應撤銷或輪替權杖；只更改本機設定名稱無法撤回存取權。

四、私有 Git 儲存庫：規則版本管理與還原紀錄

Git 適合管理自訂網域規則、代理群組架構與各裝置的覆寫設定。建議儲存庫只保存可供審閱的設定原始檔；訂閱權杖、節點密碼與控制介面金鑰則分別在裝置端管理。私有儲存庫雖能限制存取範圍，仍須妥善管理提交記錄、協作者權限與 CI 記錄。

可以採用以下目錄規劃。base.yaml 儲存共用邏輯，兩個覆寫檔則儲存裝置差異。目錄結構不會自動合併設定，最終仍須透過用戶端的覆寫功能，或自行撰寫的建置流程，產生可用的設定。

clash-config/
├── base.yaml
├── overrides/
│   ├── desktop.yaml
│   └── android.yaml
└── README.md

電腦端的基本更新流程

在已複製的儲存庫目錄中執行以下命令。先確認工作目錄沒有尚未提交的變更，再使用僅快轉方式拉取，避免更新時意外產生合併提交。拉取完成後，依專案規範產生執行設定，並在實際載入前先進行測試。

git status --short
git pull --ff-only
git log -3 --oneline

mihomo -t -f ./runtime.yaml

runtime.yaml 是此流程產生的完整設定，並非 Git 內建檔案。測試命令要求本機已安裝 mihomo；引用本機提供者檔案時，也應使用與實際執行相同的工作目錄，必要時以 -d 指定。測試通過只代表設定可供檢查，不代表每個節點都能連線。

手機端可先使用可信任的 Git 工具拉取，再透過用戶端的本機檔案匯入功能更新。不要將一般儲存庫網頁 URL 當成訂閱位址。私有儲存庫的原始檔案通常也需要驗證才能下載，而用戶端未必支援相應的驗證方式。

設定損毀時如何還原

先保留目前正在使用的設定，再比對最近一次規則變更。對於已共用的提交，可以使用 git revert 建立還原提交，而不是強制改寫所有裝置都依賴的歷史記錄。若敏感訂閱已進入歷史記錄，只刪除最新版本中的那一行仍無法消除外洩風險；應先輪替憑證，再處理儲存庫歷史與副本。

五、WebDAV：分開處理檔案傳輸與設定載入

已有 NAS 或私有儲存空間時，WebDAV 是合適的選擇。建議採用「電腦寫入、手機讀取」的單一寫入端流程。若兩台裝置同時編輯 config.yaml，可能發生後上傳的版本覆蓋先前版本，或同步工具產生衝突副本；Clash 用戶端不會負責合併這些檔案。

在儲存服務中建立專用的設定目錄，並為手機設定唯讀憑證；實際可設定的權限取決於伺服器。
電腦先將準備發布的設定上傳為獨立版本檔案，例如 config-2026-09-08.yaml，完成後再更新約定的分發檔案。
手機先下載至本機，再透過用戶端的檔案匯入功能載入。若用戶端提供原生 WebDAV 設定入口，請先確認它是否真的會更新設定內容。
保留上一個可用版本。匯入失敗時還原舊檔，不要一再覆寫目前唯一的副本。

不要直接將 WebDAV 帳號密碼串接在 URL 中。一般的「遠端訂閱」欄位不一定支援 WebDAV 所需的驗證方式；遇到 HTTP 401 時，請檢查憑證與用戶端支援情況，不可透過停用 TLS 驗證來繞過問題。若是憑證錯誤，應修復憑證鏈、網域名稱比對或裝置時間。

六、各裝置覆寫設定：連接埠、TUN 與規則清單

桌面端覆寫片段

以下是提供給支援合併覆寫功能的用戶端使用的裝置片段，並非可單獨匯入的完整訂閱。桌面端先保留系統代理接入方式並關閉 TUN，避免第一次同步時同時變更兩種流量接管路徑。若用戶端提供「允許區域網路」或連接埠設定介面，請確認儲存後沒有再次覆寫這些值。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
tun:
  enable: false

系統代理的 HTTP 代理位址應為 127.0.0.1，連接埠為 7890。若本機已有程式占用該連接埠，可改用 7891，並同步更新系統代理與應用程式內的手動代理設定。不要只修改 YAML，卻保留舊的系統代理連接埠。

Android 端覆寫片段

手機端只需覆寫兩端共同支援的基本項目，VPN 流量接管則交由用戶端處理。不同 Android 用戶端建立及傳遞 TUN 檔案描述元的方式各異，不建議直接套用桌面端的 tun.auto-route、介面名稱或路由排除項目。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

啟動時應完成 Android VPN 連線授權，並檢查用戶端的分應用程式代理清單。即使遠端規則相同，被排除在 VPN 之外的應用程式也不會進入 mihomo 的規則比對流程。兩台裝置使用相同的本機連接埠 7890 不會互相衝突，因為它們是不同裝置。

規則覆寫不可假設會自動追加

YAML 對映項目與清單項目的合併方式取決於用戶端實作。以下是完整取代 rules 的最小範例，前提是最終設定中已存在名為「節點選擇」的代理群組。若只想將一條規則移至最前面，應使用用戶端明確提供的規則前置功能，不要預設清單會自動串接。

rules:
  - DOMAIN-SUFFIX,home.arpa,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
  - MATCH,節點選擇

規則會依序比對，MATCH 應放在最後。以上片段只示範區域網路直連與預設處理方式，不包含原訂閱中的其他分流規則；直接取代會使那些規則消失。網域比對也不會負責解析 home.arpa，內網網域仍須交由可連線的本機 DNS 解析。兩端所在網路不同，DNS 上游與內網解析位址應保留在裝置設定中。

七、同步後驗收與常見問題排查

先在一台裝置上驗證，再更新另一台。不要同時更新訂閱、替換 DNS、啟用 TUN 和變更規則順序，否則連線失敗時很難判斷原因。以下檢查不需要虛構測速結果，可直接在用戶端介面與記錄中完成。

來源一致：確認兩端使用相同的訂閱或相同的 Git 提交；WebDAV 流程則檢查下載檔名與修改時間。
合併正確：查看最終執行中的設定，而不只是訂閱原文，確認連接埠為 7890、模式為 rule，且覆寫沒有意外刪除代理群組。
規則命中：連線至已明確設定規則的網域，在連線記錄中確認命中的規則與最終策略，不要只比較出口 IP 位址。
本機網路：連線至實際存在的路由器管理位址或內網服務，確認區域網路規則與 DNS 均可正常運作。
更新可重複：再次手動更新訂閱，確認裝置覆寫仍保留，且規則順序沒有改變。

電腦可用、手機無法使用時，先檢查哪些項目

先確認 Android VPN 是否正在執行、目標應用程式是否遭排除，再檢查設定載入錯誤。若出現「策略不存在」，通常應確認規則引用的代理群組名稱；若本機檔案讀取失敗，請檢查共用設定是否寫入電腦專用路徑。若兩端核心支援範圍不同，請記下各自的用戶端與核心版本，針對錯誤欄位排查，不要只憑用戶端名稱判斷相容性。

如何選擇適合的方案

只需要節點隨服務更新時，優先使用相同訂閱搭配本機覆寫。若需頻繁修改規則並審閱差異，可使用私有 Git 管理共用設定原始檔。已有私有儲存空間，且主要由電腦編輯時，可用 WebDAV 分發檔案。三種方式也能搭配使用：以 Git 管理規則、以訂閱提供節點，並在裝置端保存權限與連接埠設定；但每一層都應明確指定更新責任，避免不同來源互相覆蓋。