Clash 購読覆写入門：
mixin でノード表示を整えルールを追記し、更新しても手元の修正が消えない

1 なぜ「購読ファイルの直編集」が破綻するか

多くの Clash 互換クライアントでは、プロバイダーが配る URL から proxy-providers 用のキャッシュ YAML を取り込みます。このファイルはクライアントが自動で再生成するため、ユーザーがエディタで追記したコメントやルール行は、更新タイミングで消えるのが正常動作です。逆に言えば、「購読が作るリスト」と「自分用の調整」が同じファイルに同居している時点で、運用はいつか衝突します。ノードの表示名を読みやすくしたい、デフォルトの戦略グループを変えたい、社内ドメインだけ直結させたい、といったニーズはすべて購読の外側に逃がすのが筋です。

ここで登場するのが、コア設定に対するマージ（合成）です。Mihomo 系では、メインの config.yaml に加え、別ファイルや UI 上の「覆写」欄に書いた断片が後から重ね合わさる仕組みがあり、これを俗に mixin や Merge／Override と呼びます（クライアントによってラベルは異なります）。重要なのは名前より責務の分離で、購読は「プロバイダーが配る事実」、手元は「自分のルールと表示の好み」、と割り切ることです。

2 mixin と覆写が担う役割

mixin は、最終的にコアへ渡る設定の追加レイヤーを指す用語として広く使われます。実装としては、メイン設定のキーとディープマージされる別 YAML を置く方式や、GUI の「マージ用エディタ」に断片だけ書く方式があります。ここに rules: の追記、proxy-groups: の微調整、dns: のローカル上書きなどを置くと、購読を更新しても手元のファイルや GUI 欄は触られないため、変更が維持されやすくなります。

一方、覆写（Override）は、Clash Verge Rev のようなクライアントが、プロファイル単位で「ベース設定に上から被せるパッチ」を編集する UI を指すことが多いです。中身は結局 YAML ですが、視覚的に「購読由来」と「自分用」が分かれていると、トラブル時に切り分けやすいというメリットがあります。どちらの経路でも、心の中では同じモデルを持てば十分です。下流（購読キャッシュ）＝揮発してよい、上流（mixin／覆写）＝バージョン管理したい、という二層です。

3 Clash Verge Rev での典型的な運用イメージ

Clash Verge Rev は Mihomo を同梱し、購読 URL の登録からプロファイルの切り替えまでを GUI でまとめられます。実務では、まず購読を取り込みノード一覧が出る状態を作り、そのうえでマージ用・覆写用の編集画面（名称はアップデートで変わる場合があります）に、自分専用の断片だけを書く、という順序が安全です。初日から巨大な config.yaml を一ファイルで管理するより、購読は自動・差分は手元に分けた方が、半年後の自分が助かります。

インストールや初回起動の手順がまだの場合は、Windows 向けの入門記事や macOS 向けガイドとあわせて環境を整えてから、本稿の「追記レイヤー」に進むと迷子になりにくいです。ポイントは、購読更新ボタンを押しても消えてよい場所にだけ手を入れないことです。

4 ノード表示名の整理：proxy-providers の override

Mihomo では、proxy-providers エントリに override を付けて、取り込んだプロキシ名に接頭辞・接尾辞を付けたり、パターンでリネームしたりできます。購読側のノード名が長すぎる・意味が分かりにくい、といった場合でも、キャッシュ YAML を手で直さずに済みます。以下は概念を示す短い例です（キー名やネストは実際のバージョンのドキュメントに合わせてください）。

proxy-providers:
  airport:
    type: http
    url: "https://example.com/subscribe"
    path: ./proxies/airport.yaml
    interval: 3600
    override:
      additional-prefix: "[Air] "

additional-prefix を付けると、一覧上では [Air] 香港-01 のように見え、複数購読を併用しているときにどのセット由来か一目で分かるようになります。より細かい変換が必要な環境では、正規表現ベースの proxy-name 置換などが使える場合もあります。いずれにせよ、設定は proxy-providers 側に残るため、購読 URL が更新されてノードが増減しても、命名ルールは継続します。

戦略グループのデフォルト選択を変えたいだけなら、proxy-groups の use やメンバー順序を mixin 側に書く方法もあります。自動選択が欲しい場合は、url-test／fallback の記事で述べているように type: url-test などを別グループとして定義し、ルールの向き先をそちらに寄せる、という組み合わせが現実的です。

5 ルールの追記と評価順序

独自の分流を足すときは、どこに挿入されるかが成否を分けます。Clash 系は基本的に rules: を上から順に評価し、最初にマッチした行が勝ちます。購読テンプレートがすでに広い GEOIP や MATCH を抱えている場合、mixin に書いた行がそれより下だと一生到達しない、という典型トラブルがあります。対策は、ローカル用のルールをより上に置くマージ順序を確保すること、あるいは購読側のテンプレート自体を見直してキャッチオールの位置を理解することです。

mixin に書く内容の例としては、社内 Git や監視ツール向けの DOMAIN-SUFFIX、特定ゲームクライアントの PROCESS-NAME（対応コア・OS に依存）、自宅 NAS 向けの IP-CIDR 直行などが挙げられます。外部のルールセットを rule-providers から引いている場合は、ACL4SSR 系の解説と同様に、behavior と優先度を把握したうえで、自分用の短いリストを先頭近くに置くと運用が楽です。

# Example: fragments merged into final config (conceptual)
rules:
  - DOMAIN-SUFFIX,corp.example,DIRECT
  - DOMAIN-SUFFIX,git.internal,DIRECT

6 注意点と切り分け

• 名前の不一致： mixin 側の proxy-groups が参照する名前と、購読更新後の実ノード名がズレると、そのグループが空になったりエラーになったりします。override で接頭辞を付けたなら、ルールやグループ側も同じ命名規則に合わせます。
• 二重管理： 同じドメインを購読テンプレと手元の両方で書くと、どちらが効いているか分かりにくくなります。長期運用では「例外だけ手元」に寄せるのが安全です。
• クライアント差： Verge 以外の GUI でも「マージ」概念はありますが、保存場所とファイル名が異なります。マシン移行するときは、覆写 YAML を別途バックアップしてください。
• 規約と信頼： 購読元の利用条件を守り、不信な設定ファイルを混ぜないことは以前と変わりません。mixin は便利ですが、悪意ある追記を自動マージする危険もあるため、出所のはっきりした断片だけを使う習慣が重要です。

7 まとめ

空港購読は更新のたびに再生成される揮発レイヤーとして扱い、ノード表示の整形・デフォルト戦略・自前ルールは mixin／覆写に逃がす。これが「更新しても手元の修正が消えない」ための基本形です。Mihomo では proxy-providers の override で表示名を整え、ルールはマージ順と MATCH の位置を意識して追記します。Clash Verge Rev のような GUI では、その YAML を画面越しに編集できるため、購読ボタンとエディタの境界さえ押さえれば、初心者でも再現性のある運用に乗れます。

単体の軽量プロキシより、ルールと DNS、戦略グループを一体で扱える Clash 互換スタックの方が、購読＋パッチという二層モデルに向いています。まずは小さな mixin から試し、最終設定のプレビューで意図どおりマージされているかを確認しながら広げてください。

グラフィカルに購読とマージを管理したい場合は、ダウンロードページから OS に合うビルドを選ぶと、同じ考え方を画面操作に落とし込みやすいです。

→ 無料で Clash をダウンロードし、mixin で購読と自分用ルールを分けて運用する