Clash／Mihomo のプロファイルをバックアップし複数 PC で安全に同期する実務チェックリスト：Git運用・暗号アーカイブ・購読スナップショット（2026）
OS 換装 やSSD 交換、開発用マシンの入れ替えで Clash／Mihomo のローカル差分ごと消失する経験を避けたいなら、この記事では Git によるレイヤーの切り分け、暗号アーカイブ による複数世代の保管、購読 と ルールセット のうち「復元できるもの」「URL だけ再発行になるもの」を仕分けするところまで一気に整理します。Clash Verge Rev のような公式寄りから派生した GUI と、コンソールのみの構成の両方へ当てはまる前提です。購読の更新間隔と失敗時の挙動は 購読の自動更新記事、細かな追記レイヤーの考え方は Mixin とプロファイル覆写 と併読すると頭の中の地図が揃います。
検索されている悩み：なぜ「バックアップしたつもり」がすぐ無効になるのか
複数検索クエリには共通項があります。Clash の設定ファイルをコピペしただけ で満足し、数日後には購読の自動更新によりローカルで足した自分専用のルール が上書き消えていた、またはリポジトリに認証つき購読 URL を載せていてしまい事故が広がった、といった運用レイヤーの落とし穴です。Mihomo 互換スタックでは mixin や profiles、各種 provider キャッシュという異なるライフサイクルが同居するため、「丸ごと home 直下をZIPにして終わり」のままでは 災害復旧 が再現できません。何が再ダウンロードで再現できるか と 書き換えられてしまうので残したいソースはどこか を決め打ちしないと複数マシンの同期でも破綻します。
レイヤーマップ：Verge と Mihomo で握るべき三層構造
頭のモデルだけ先に決めます。(1) 上流の購読テンプレ ── 自動更新によりリモートの YAML が落ちてくる層、(2) 自分でメンテするローカル断片 ── mixin、自分の RULE-SET ファイル、開発用ホストリストなど、(3) 取得済みキャッシュとログ ── GEO キャッシュや rule-providers のディスクキャッシュ。この三つをごちゃまぜに Git へ入れた瞬間から差分ログが読めなくなるので、「追跡する／追わない」をテーブルベースで書き換えられるよう文章化しておくのが複数ユーザーや自分の過去自分へのギフトになります。rule-providers のキャッシュ運用記事 では interval と path がどう協調するか触れているため、レイヤーマップとの対応だけ押さえると復元順が一段クリアになります。
Git を使う意味：構成のドラフトであり履歴でありロールバック手段
Git が向いているのは「URL の秘匿」を完全に自動化しない代わりに、変更理由をコメント付きブランチ として記録できる点です。TUN とシステムプロキシを切り替えたときのポート設定、購読失敗検知までのワークフロー など運用ログをコミットメッセージに残せると、複数 PC で同じ失敗を繰り返しません。とはいえ、購読の raw やログに混入したクエリログを載せ続ける運用ではリポジトリが地雷原になるため、「追跡するのはソースコードに近い断片のみ」という割り切りが安全です。Mihomo と Clash Verge Rev が同一リポジトリを参照する構成ならブランチ名を home, office のように環境単位でもよいですが、根本の YAML が同じなら差分だけ local-patch.yaml を分離したほうがマージ競合が減ります。
最初に書くべき最低限の .gitignore アイディア例
パスそのものではなく規則の例だけ示します。実環境のアプリごとのディレクトリ名へ読み替えてください。トークン やクエリパラメータ付きファイル名は絶対に ignore しないと漏洩経路になります。また LFS に巨大ルールセットを載せず、再取得運用できるならソース URL メタのみを載せます。
# Example .gitignore – adapt paths to your Clash Verge Rev / Mihomo layout
**/subscriptions/*.yaml
**/cache/**
**/geo**
*.log
.env
secrets.toml上記はあくまで雛形で、自動更新側が異なる名前で保存している場合があります。運用開始の初日だけディレクトリツリーをスクリーンショットに残したうえで「除外した結果必要なときに復元できるか」をシミュレーションしてください。
暗号アーカイブの役割：Git を使わない人・両方やる人向けの二段ロック
Git が苦手でも、強固な OS 共通のコンテナまたは Zstandard／7z 系の強い暗号アルゴリズムを備えたアーカイブにだけ全体をぶち込む、という二段ロックは複数ユーザーで共有しない個人復旧には十分機能します。GPG／age／BitLocker など自分がパスワードローテを忘れない範囲で選んでください。暗号キーだけ別 USB という古典も有効です。アーカイブを取る頻度は「購読が壊れたときだけ」ではなく、ルールセットのソースがリポジトリ移転する前 のように外部イベントとも同期させます。オンライン同期ストレージに平文で複数年置くのが不安なときほど、この層が価値を出します。
購読とルールセットのバックアップ・同期の決めゴマ
購読 URL は URL だけをパスワードマネージャや暗号ノートへ置き、アプリ側の自動更新とは別レイヤーの「契約リスト」として月一で棚卸します。RULE-SET や rule-providers が指すソースは、アップストリームのドキュメントにある利用条件を順守してください。自分でホストしないなら、アーカイブの中身より再取得トリガとなるメタ情報 と 失敗ログの読み取りチェックリスト が長期資産になります。購読 FAQ の典型トラブルと突き合わせると、バックアップ以外の復旧にも流用できます。カスタムルール入門 では自分のリストを増やしていくときの記法が整理されているので、Git に載せたいソースを書き換えるときのレビューを兼ねられます。
複数 PC 運用での同期パターン A〜C
パターン A は 完全に同一構成 を求めるワークステーション開発者向け。Git の main と同一プロファイルのみを両端で pull します。pull タイミングはアプリ側の自動更新とはずらします。ズラさないと「Git の最新」と「自動更新済み」の二重世界が競合します。パターン B はホームだけ TUN を使う、オフィスはシステムプロキシのみという異なるポートと DNS の差異を mixin に閉じ込めるパターン。ブランチではなく環境フラグだけ差し込むときに競合が起きやすいので、共通 core の宣言は極めて細くしてください。パターン C は家族や小チームでの共有であり、自分のブランチに個人 mixin を置いたうえでメインはオーナーの購読を流用。チュートリアル総覧 の語彙に合わせて README を日本語短文で書くと新人が復元順を読み間違えません。WSL と Windows が同居する構成 でパス問題が発生することがあるため、クロスプラットホーム構成なら相対パスと実パスの対応辞書だけはリポジトリに残します。
災害復旧の実演ワークフロー（ロールフォワードしない検証）
SSD を交換しないとテストになりません。その代わり、月一で「新ユーザーと同様にアプリのみ入れた仮マシン／仮ユーザー」へ復元ドライルンをしましょう。手順としては、アプリ標準ディレクトリを空で起動させ、(1) 購読の再登録または同期されたメタのみを流す、(2) mixin やローカル YAML を順に適用、(3) rule-providers と GEO を再フェッチさせる、(4) 代表的サイトとログを見ながら期待ルールとの差分チェック、この四段構えです。このとき「貼り付けられるコミットのハッシュをメモしていたか」だけで復元時間は半分にも二倍にもなるため、ドライルンは Git のタグにも紐付けられます。Mihomo コアのバージョン差でキー無効となるケースがあります。両端のアプリ自動更新チャンネルが揃っているかだけは README に一行メモしましょう。
CFW からの移行者がバックアップで詰まる典型
過去構成をすべて引きずると自動更新サービス側の変更に弱くなります。Clash for Windows から Verge への移行記事 の観点に立つと、アーカイブの主役は「最新の自動生成物」よりも「自分のカスタム断片」のはずです。移行済み環境での Git 構成を読み終えてから古い Profiles フォルダを捨てると事故が減ります。
よくある質問
購読 URL は Git に載せていいですか
載せません。プライベートでも誤操作で公開権限が付く過去コミットを完全に除去するには履歴書き換えが必要になります。URL はパスワードマネージャ や会社の許可があるシークレットストアのみにしましょう。
rule-providers は同期すべきですか
再ダウンロードで復元できるならソース URL と interval メタのみで足ります。巨大ファイルをリポジトリに直置きする場合ライセンスと容量を確認してください。オフライン出張のみローカルコピーを持ち歩く、という特例はあります。
Mihomo 以外のフォークにも使えますか
レイヤーマップのアイディア自体は共通です。Mihomo 互換 YAML を中心におけばほとんどのコミュニティ GUI と相性があります。ウィンドウ専用の設定 UI は復元しない前提でソース YAML と購読を先に復元しましょう。
まとめ
バックアップの本質は「ZIP を取る癖」よりも、(1) 秘密と構成の境界、(2) 自動更新レイヤーを壊さない Git の粒度、(3) 暗号で眠らせた世代管理、(4) 別 PC でのクリーン復元ドライルンの四つセットです。Clash Verge Rev と Mihomo の組み合わせは自由度が高い反面、構成が散らばりやすいのでここでの線引きがそのまま複数年のストレスになります。自動更新設定 と RULE-PROVIDER のキャッシュ を参照しながら、このチェックリストを README サイズまで薄く落とすとチームにも渡せます。
一方で、設定をテキストとして差分管理できないクローズド製品では、復元タイミングでの仕様ロックインや不透明な自動更新により、自分の環境に合わせたロールバックが難しいことがあります。ルールレイヤーを YAML で持てる強みは単なる自由度ではなく自分の復元ドライルンを自動化できる ところにあります。長期運用を前提にプラットフォーム別の安定版／実験版を比較したい方は、入手導線を揃えたうえで Clash のダウンロード一覧 から自分の環境と更新頻度に合ったクライアントを検討してみてください。