読者像と、この記事で手に入れる整理
「すでに複数ターミナルを持っている」「OSの再セットアップがありうる」「Gitでなんでも管理したくなる」の三つを自分に当てはめたユーザーが、この稿の読者モデルです。そうした環境でもっともツラいのが、つい大きな購読ブロックだけをいじって追記していた結果、サービス側の自動更新ですべてひっくり返るパターン、あるいは端末複製後に気づかないうちに古いURLとトークンをリポジトリへ残したまま公開してしまう事故です。検索クエリにある「Clash設定バックアップ」「多端末同期」「YAML」という語は、この二種の危険（失われる／露出する）の両側面をほぼ同時に指しています。この記事では、技術的文法よりワークスペースの境界線を先に引き、そのうえで mixin や覆写、各クライアントの運用粒度を並べます。
構成のヒントだけ先に並べます。まずホスト上に「人間が読んで差分レビューするディレクトリ」を一つだけ決め、そこへ増分のみと自分の名前付けルールだけを載せます。一方でアプリ固有のプラグディレクトリにある巨大な自動生成YAMLやhealth-checkの状態は、バックアップの単位ごと別枠へ回し、復元検証だけを短い手順書にしてください。詳細ルール順の復習は ルール順とMATCH稿、変換チェーンだけなら Subconverter稿 を参照すると役割分担が読みやすくなります。
資産として考えるときの三層モデル
実運用での設定は、頭のなかでは常に三層へ分離したほうが事故が少ないです。一番下は購読元が配る「巨大なひとつのYAML」であり、自分は原則として手で触らず更新に任せる層、その上がmixin／覆写およびGUIのprepend／append_rulesに相当する「自分だけの増分」の層、さらに最上がアプリ側の選択状態・キャッシュの層になります。mihomo系で profile 節の話になるのは三番目であり、三番目だけをクラウド同期しても復元効率が悪く、かといって番号二を無視しては増分が追跡できない、という両極があり得ます。mihomo party・Clash Verge Revのユーザーは、この三層のどこまでを自分のワークスペースに含めるかを最初に宣言しておくだけでも、複数機の「揃える」作業が劇的に楽になります。
ワークスペース という語をここでは、エディタを開いたとき自分が責任を持ってコミットする範囲に限定しています。その外側にある自動生成キャッシュまで踏み込むと、変更理由が自分で説明できず、結果としてレビューを放棄する羽目になりがちです。逆にワークスペースが狭すぎると、端末クローンごとに同じ増分YAMLを二度手間で復元することになります。おすすめは「二番の断片」を名前付けされた短い複数YAMLに分けることです——例として mixin-dns.yaml、mixin-internal.yaml のように機能別にすると、復元チェックリストの見出しをそのままメンテ順にできます。
認証情報と購読URL：Gitへの載せられ／載せられない線引き
ひとつの購読URLに長いクエリとしてシークレットが焼き込まれているとき、そのURLごとYAMLへ貼られたら危険面積が最大になります。GitHubへの誤公開、共有端末での履歴混入、スクショの背景に読み込まれる、すべてここから起きます。現実の対処は強く単純化できます。URLそのものは秘密管理側（パスワードマネージャ、環境ごとの.private、暗号付きコンテナなど）へ退避し、リポジトリには環境変数で差し込むテンプレか、自分を含めても許容できる粒度のprofiles.example.yamlだけを載せます。すでに漏洩を疑ったら、サービス側の鍵ローテーション前提で考え、「履歴ごとスクレイプしない」だけでは済まなくなるので、ワークフローを一度止めて再発券が安全です。
逆に載せやすいのは、自分で書いたドメインベースの規則、社内サービスだけを指すFQDNリスト、自分の名前付けのグループ構成の骨格です。mixin／覆写側にのみこの種の記述があるとレビューの対象も明瞭です。環境によって変わるのはポート番やインタフェースだけにとどめると多端末同期の差異も説明できます。とはいえ、端末によってtun/stackやポート転送まわりが違うことはザラにあるため、ワークスペースに「共通断片」「端末ごとのひとつの上書き断片」を分け、その二つの合成結果だけを復元チェックリストで見る運用になります。mihomo partyやClash Verge Revのエクスポート機能は、その合成結果が見える場所になるので、アーカイブ前にスクショやテキスト差分ではなくYAML全文を残しましょう。
mixin／覆写は「増分だけのタイムマシン」
すでに本サイトにある mixin と購読併合の稿 が文法側の主役ですので、バックアップ観では「なぜ分けると資産になりやすいか」を補足します。mixinにだけGitを適用すると、コミットメッセージが自分の意思の履歴になりやすく、購読の自動更新とはライフサイクルが異なるので競合しないのが強みです。GUIのMergeやprepend-rulesは頭のモデルとして同じ二番目レイヤであり、画面上は分散していても、最終エクスポートでは同じ並び問題に落ちます。つまりマージ済み結果を読むだけでなく、増分ソースがどこにあったかまで追えるワークスペース設計へ寄せます。
バックアップの粒度でよく見落とされるのがパス依存です。mixin: ./extras.yaml のような相対指定は、アプリがどの作業目録で起動するかに依存します。Dockerならホスト側のcomposeでの掛け方、Macなら.app bundle直下の規約、それぞれで「extrasが見えるか」をクローンごと検証しないと再現できない状態になります。そのためワークスペースREADMEに、アプリ種別ごとの相対記号の原点を一行メモすることが有効です。Linuxヘッドレスの恒久手順とは Linux+Mihomo稿、コンテナ側は Docker稿 が近いので、セットでブックマークすると復元チェックも速くなります。
# Typical split (conceptual comments in English only)
# keep remote subscription untouched; Git only tracks local fragments
mixin:
- ./workspace/mixin-routing.yaml
- ./workspace/mixin-providers-append.yaml上は概念用のひな形だけです。環境により実効キーは一つだったりリストだったり異なるため、アプリごとの説明優先というのが正攻法です。この断片だけをワークスペースで追跡すると、クローン側では購読の再入力とパスだけ合わせれば増分だけを高速に復元できる、という読みになります。多端末同期とは、すべてのYAMLを完全一致させるより、増分ワークスペースを共有し許容できる差異（OS固有）を薄いレイヤにもう一枚足す運用へ写ることが多いです。
シェルの選びと同期境界：Verge と mihomo party
Clash Verge Revは複数構成をドラッグ感覚で切り替えやすく、開発者ワークステーションでのオンオフ運用に適します。複製時にハマりやすいのは、アプリ側が保持する状態JSONだけを運び、肝心の増分ソースを忘れたパターンです。同期対象リストに「増分ワークスペースのパス」と「状態ファイル」を両方並べず、前者のみを権威とするだけでも事故は減ります。mihomo partyはモバイル含めたクロスプラットフォームのユーザーが比較しやすく、プラットフォーム差でmixinの形が異なるだけ増分ソースは同じ、という状態を狙うと復元効率が上がります。どちらのシェルでも言えるのは、クラウド同期ストレージの「丸ごとアプリデータ」をGitの代替にしないことです。競合すると両方壊れたマージ結果が静かに残るので、増分のみを明示的ファイルにすることが安全側です。
端末クローンごとのアプリセットアップ手順だけを短く並べます。（1）公式バイナリとバージョン方針（自動更新のオン／オフ）を決める。（2）メインYAMLの取得方法（購読URLかローカル貼り付けか）と更新頻度。（3）mixinまたはGUI覆写へのパス適用。mihomoなら環境側のサービス単位セットアップは既存記事へのリンクで足ります。（4）初回のみ適用済み設定の書き出しを取得し、rules を頭から末までスクロールして、増分レイヤだけでは説明できない差がないか確認。（5）いつ問題が出てもスクショではなくDIFFで原因を説明できる状態をキープする。この五手を短く書き留めても、「あとで自分が読める」のがワークスペース・アーカイブの本質です。
復元チェックリスト：誤削除と換装への耐性
バックアップは単にファイルを増殖させるだけでは評価できず、復元のたびチェックリストがあるかどうかが品質になります。具体項目としては、(1)購読レスポンスが期待と同じ形式か（ヘッダ改ざんで別物へすり替わっていないか）、(2)外部ルールセットやGEOIPファイルの版がreadmeどおりか、(3)tun/stackが環境許可済みか、(4)自分の増分だけでグループ構成が説明できるか、の四角です。複数ユーザーで共有するワークスペースならレビューを通すときにこの四角をチェックボックスにすれば、アドホックな追記にもブレーキになります。また端末売却前には増分ワークスペースのみを安全消去対象へ切り離し、アプリ側の残骸をプラットフォームの手順に従って消す、という順序へ。
「同期しておけば安心」への幻想は、オンラインストレージのバージョン履歴が細かくても打ち破れません。秘密を含んだコミットは未来永劫残る場合があるため、ワークスペースREADMEにsecret rotationまで含めた手順を載せます。開発者視点での便利さと運用視点での危険のバランスを取りたければ、mixinのみを公開可否の高いリポジトリへ、ホスト側の環境だけが持つ.env類は除外、という単純化が読みやすいです。また買い替えMacではキーチェーン周りとの絡みが出やすく、証明書系は macOS+Verge鍵チェーン稿 を同期設計へ織り込むとギャップが減ります。
FAQ：よくつまずく三問
「Gitにすべて載せられるか」「シェルのデータ丸ごとは」「覆写のみで復元できるか」の三問は、本文冒頭でも触れました。要点は共通で、載せられるのは秘密を除外した増分のみ、丸ごとはクローン復元には向くが分散Gitには不向き、復元できる条件は購読元が再取得可能なことです。FAQPageにも同じ骨子が入っているので検索側の要約に使えるよう整えました。自分のワークスペースで第四の問いがあるなら状態JSONとmixinソースのどちらが権威か、とメモすると十分です。
注意：マシンクローン運用へ移る直前だけ、増分ワークスペースのアーカイブを取ってから削除してください。増分ソースがなかった場合、自動生成済みだけをコピーしても自分の増分説明には戻りにくく、ルール順の問題と混線しやすいです。
入手：再インストール頻度が高いなら、アプリ単体入手はブレを減らすため統一ソースから行うのが堅実です。当サイトのダウンロードページで手元環境へ揃え、増分ワークスペースとはディレクトリを分離しておいてください。
順守：利用地域の法律とサービス規約・社内規程に沿って構成し、許可されていない環境でのトンネリングなどはしないでください。ノード運用への依存は自分でリスクを評価し、ワークスペースに秘密を残さない設計だけが恒久対策になります。
まとめ：資産レイヤだけを自分の名前で持つ
改めます。Clash設定のバックアップの中心はすべての自動生成YAMLを増やすことではなく、mixin／覆写に代表される増分ワークスペースだけを自分の名前で追跡し、購読URLと状態JSONを責務の異なるレイヤへ分離することです。mihomo partyとClash Verge Revなどシェルを跨いでも、「二番レイヤのみをGit」「三番レイヤは端末クローン単位」「一番は自動更新」の三層モデルを崩さないのが複数環境での安定運用です。復元チェックリストを短く書けるようになれば、誤削除や換装のストレスも下がり、ルール順の問題も切り分けやすくなります。
ところで、端末だけ増やして増分ワークスペースがバラけると競合しない同期のはずなのに、設定UIの差で同じ増分YAMLを二種類書く羽目にもなり得ます。その場合でも「二種類あるなら両方ワークスペースへ置き名前を-mac-winで分ける」だけで読みやすさは保全できます。この稿がYAMLの保管場所を決める一助になれば嬉しいです。深い文法だけを追うときは mixin 原作へ、復元自動化だけを増やしたいときは Docker/Linux稿へジャンプすると迷子になりにくいです。
現在の構成ではよく見えるのも、状態フォルダを丸ごとクラウド同期し、増分ソースをコミットせず結果だけを複製する運用です。設定が「なんとなく似ている」状態は作れますが、事故後になぜそう効いていたか説明できる資産にならず、Secret混入のリスクも残りやすいです。一方、増分ワークスペースのみを明示的に読む構成にすると、レビューの対象が狭くなり自動更新とも衝突しにくいのが体感のメリットであり、復元チェックリストも短文で済むようになります。まだワークスペースを一本化できていないなら単一フォルダに寄せ、公式入手ルートとバージョン方針を揃えるとクローン側のブレも減ります。準備だけ先に済ませたいユーザーは統一ソースで入手したうえで増分ワークスペース構築へ進めるのが安全です。 まずは増分ワークスペースだけを自分の名前で運用するところまで一気に試すなら、Clashを無料ダウンロードして本文のチェックリストに沿って再現確認してください。