電腦與手機共用一套 Clash 設定：訂閱連結、私人儲存庫與覆寫腳本比較

同步界線：共用規則，保留裝置參數

電腦與手機共用 Clash 設定，通常不是把正在運作的 YAML 原封不動複製到所有裝置，而是讓各裝置參照同一組節點與分流規則，再各自保存系統相關設定。訂閱提供節點來源，設定檔負責組織節點與規則，用戶端則負責匯入、更新及啟動核心；這三層各自保有狀態，不能只靠複製一次檔案全部同步。

例如，Windows 的系統代理會指向本機 127.0.0.1:7890，手機則通常透過系統 VPN 介面接管流量。兩台裝置可以使用相同名稱的策略組，但不應因此強制採用相同的 TUN 參數、網卡名稱或檔案路徑。Android 的依應用程式代理與桌面系統的處理程序規則，也不是能直接互換的設定。

做法一：所有裝置訂閱同一個網址

如果只需要讓電腦和手機使用同一批節點，分別匯入同一個訂閱網址是最簡單的做法。先確認服務提供者是否允許多台裝置使用，再核對同時連線數、流量計算方式與方案限制。設定可以複製，不代表帳戶允許任意多台裝置同時連線。

先確認訂閱提供的內容

• 完整 Clash YAML：通常包含 proxies、proxy-groups 和 rules，可依用戶端支援的方式匯入為遠端設定。
• 節點清單：用於節點提供者時，常見的頂層結構是 proxies。它不會自動補上完整設定所需的策略組與分流規則。
• Base64 節點連結或其他核心格式：能否匯入取決於用戶端是否具備解析或轉換功能。副檔名是 .yaml，也不足以證明內容相容。

特別要分清遠端設定更新與 proxy-providers 更新。前者可能會取代整份設定，後者主要是更新提供者中的節點；更新節點提供者，不會自動把主設定的 rules 換成服務提供者的新規則。完整設定網址能否同時作為節點提供者使用，應以目標核心的實際解析結果為準。

更新頻率不等於即時同步

在支援的 HTTP 節點提供者中，interval: 3600 代表更新間隔為 3600 秒，也就是 1 小時。用戶端遠端設定的自動更新週期則是另一項設定，不能用這個欄位取代。手機進入休眠、背景執行受限或用戶端未啟動，都可能使更新時間晚於預期。

1. 先在第一台裝置匯入訂閱，檢查節點數量、策略組名稱及設定載入記錄。
2. 在第二台裝置匯入相同網址，手動更新一次，確認沒有匯入舊的本機副本。
3. 將更新週期設定為一致的目標，例如 1 小時；並確認兩個用戶端都支援該週期及背景執行方式。
4. 服務提供者更換節點後，分別檢查兩端的更新時間；不要因為「電腦已更新」就推定手機也已更新。

這種做法的維護成本最低，但分流規則是否一致，取決於訂閱內容與本機覆寫。如果手機匯入時自動加入一套規則，而電腦沒有，兩端的運作方式仍會不同。

做法二：用私人儲存庫保存設定與規則

如果需要維護自訂網域例外、規則順序或多台裝置的設定，私人 Git 儲存庫更適合作為設定的版本來源。它能保留變更記錄並支援回復，但不是用戶端之間的即時同步服務，也不會自動解決用戶端下載時的驗證問題。

將儲存庫拆分為共用層與裝置層

clash-config/
├── shared/
│   └── rules.yaml
├── desktop/
│   └── override.yaml
├── mobile/
│   └── override.yaml
└── README.md

以上只是檔案組織範例，並非 Clash 自動辨識的目錄慣例。用戶端不會因為目錄名稱是 shared 就自動合併內容。規則集必須由主設定透過 rule-providers 參照，並以 RULE-SET 規則加入；覆寫檔則需要用戶端支援相應的合併或匯入機制。

如果使用 YAML 格式的網域規則集，以下內容可作為格式範例。其中 example.com 是文件示範網域，不代表建議直連的服務網址。

payload:
  - "+.example.com"

這類內容可供 behavior: domain、format: yaml 的規則提供者使用。主設定還需要定義提供者名稱、取得方式及比對後採用的策略。規則集檔案本身不包含出口選擇，不能直接取代完整的 rules 清單。

私人儲存庫的存取憑證應分開管理

• 瀏覽器能開啟，不代表用戶端也能取得：瀏覽器已有登入工作階段，核心發出的請求通常不會沿用這些 Cookie。
• 下載連結可能只有短期效力：附有臨時授權參數的原始檔案網址，過期後可能會回傳登入頁面或錯誤頁面。
• 各端的驗證能力不同：需要自訂要求標頭或特殊驗證流程的網址，必須逐一在各用戶端測試。
• 不要將訂閱憑證提交到版本記錄：將儲存庫設為私人只能限制存取範圍，無法消除歷史記錄、複製副本及備份中的外洩風險。

Git 較適合存放不含訂閱權杖的規則來源檔；私密網址則透過本機設定注入。如果確實需要發布合成設定，應限制存取權限，並確認發布流程的記錄不會輸出完整內容。不要只為了讓手機方便取得，就把私人設定改成公開檔案。

分開處理回復與上線

可以在桌面維護端使用以下命令檢查變更，並撤銷已提交的錯誤變更。建立回復提交後，仍須讓各用戶端重新取得並載入設定；Git 操作成功不代表手機上的設定已生效。

git diff -- shared/rules.yaml
git add shared/rules.yaml
git commit -m "調整共用網域規則"
git log --oneline -5
git revert HEAD

做法三：訂閱搭配本機覆寫或腳本

訂閱負責更新節點，本機覆寫則保留個人設定，是多數多裝置情境下的折衷方案。關鍵是將覆寫保存在用戶端提供的獨立層，而不是直接修改每次更新都會被取代的訂閱快取檔。

合併規則比檔案內容更重要

不同用戶端可能採用淺層合併、深層合併、清單取代或專用的前置追加機制。同一份 YAML 片段在一個用戶端中會追加規則，在另一個用戶端中卻可能取代整份清單。以下僅示範希望寫入最終設定的欄位，不是通用於各用戶端的匯入格式：

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

mixed-port 是 HTTP 與 SOCKS 共用的混合監聽連接埠。兩台不同裝置都使用 7890，通常不會互相占用；同一台裝置同時啟動兩個監聽相同位址與連接埠的處理程序，才可能發生繫結衝突。手機用戶端是否允許使用者覆寫這個連接埠，應以其介面與執行設定為準。

規則清單尤其需要仔細檢查。例如，若要將一條本地域名規則放在兜底規則之前，應調整規則順序，而不是直接在檔案末尾加一行。如果 MATCH 已比對所有剩餘流量，排在它後面的規則就不會執行。共用規則所參照的策略組名稱，也必須存在於最終設定中。

腳本是用戶端功能，不是通用的核心欄位

部分桌面用戶端提供 JavaScript 設定處理介面，可在載入訂閱後修改設定物件。此類腳本的入口函式、執行時機與可用介面都由用戶端決定，不能直接複製到所有 Android 或 iOS 用戶端，也不要與舊版 Clash 設定中的腳本功能混為一談。

1. 固定欄位先使用靜態覆寫，減少對腳本執行環境的依賴。
2. 只有確實需要依節點或策略組動態產生內容時，才使用用戶端腳本。
3. 為腳本記錄目標用戶端、適用版本與測試日期；升級用戶端後，重新檢查輸出結果。
4. 檢查最終執行設定，而不只確認腳本是否成功儲存。

平台差異：DNS、TUN 與核心功能

Clash 設定生態包含不同核心與圖形化用戶端。即使兩個用戶端都使用 mihomo，也可能因核心版本、用戶端產生設定的方式或系統權限不同而有不同表現。判斷相容性應查看實際使用的核心與版本，不應只因應用程式名稱含有 Clash，就認定所有欄位都通用。

DNS 的 fake-ip 模式會使用合成位址，並由核心處理連線；不應把某台裝置執行期間產生的 DNS 快取當成需要同步的設定。手機從 Wi-Fi 切換到行動網路後，上游解析的可達性也可能改變；即使設定相同，仍須分別在兩種網路環境下測試。

iOS 上提供類似代理功能的應用程式，不一定使用 mihomo，也不一定能直接接受完整的 Clash YAML。挑選時應先確認訂閱匯入格式、規則語意與本機覆寫能力，再決定共用哪些來源檔。跨核心使用轉換結果時，也要重新檢查協定參數與規則行為，不能只看是否出現節點名稱。

更新驗收：確認兩端載入相同版本

設定同步應該搭配可重複執行的驗收步驟。以下提供一輪建議檢查流程，並非特定用戶端的實測效能結果。選單名稱會因用戶端而異，操作時可尋找遠端設定更新、執行設定、連線與記錄等相關入口。

1. 記錄來源：記下設定名稱、訂閱更新時間及共用規則的 Git 短版提交編號；記錄中不要包含完整訂閱權杖。
2. 手動重新整理：兩端分別更新遠端設定；若使用提供者，再確認節點與規則提供者的更新時間。
3. 確認載入成功：記錄中沒有 YAML 解析錯誤、未知策略組、提供者取得失敗或連接埠繫結失敗。
4. 核對最終設定：確認執行模式為 rule，檢查覆寫是否保留，以及兜底規則是否仍在清單末尾。
5. 檢查實際連線：各端分別連線至一個預期直連網址和一個預期代理網址，在連線清單中核對命中規則與出口；延遲測試成功只代表測試目標可連線。
6. 另外測試網路切換：手機分別在 Wi-Fi 與行動網路下驗證，桌面端則檢查區域網路服務是否仍可正常存取。

如果電腦正常、手機失敗，先確認手機實際載入的設定與提供者更新時間，再檢查 VPN 權限、背景更新、DNS 及協定支援。不要一開始就把所有規則改成全域代理，否則雖可能暫時避開分流問題，卻會失去追查原因的線索。

建議組合與憑證管理

• 只共用節點：各裝置訂閱同一個網址，裝置參數各自保存；維護重點是帳戶限制與更新狀態。
• 共用節點與少量例外規則：訂閱搭配獨立覆寫；優先採用各端都能表達的靜態規則，並分別確認清單合併方式。
• 長期維護多台裝置：以私人儲存庫保存規則來源檔與變更記錄，訂閱憑證留在裝置端，再依平台產生或匯入不同設定。
• 需要動態產生策略組：在具備相應功能的維護端處理，再提供相容的結果給其他裝置；不要假設手機能執行桌面腳本。

訂閱 URL 通常含有存取憑證，QR Code、設定匯出檔與記錄截圖也可能包含相同的存取能力。分享問題截圖前，請遮住查詢參數、節點密碼與控制介面金鑰。若網址已遭他人取得，應在服務提供者後台重設訂閱權杖，再更新所有裝置；只刪除聊天訊息或將儲存庫重新設為私人，都無法讓已複製的網址失效。

控制介面同樣不是需要同步到手機的公共入口。不要為了遠端管理，就直接將 external-controller 開放至公網。多裝置同步的目標是分發設定與規則，而不是共用本機管理權限。先界定共用層，再保留裝置差異，通常比追求所有 YAML 位元組完全一致更容易維護。