どんな悩みを解くのか
多くの読者の現実的な手順は次の通りです。外から落としてくるClash用の一括サブスクリプションには、proxy-providers・proxy-groups・rules、必要なら rule-providers まで既に焼き込まれている。そこへ家計内の自前ノード、別事業者の二番目の購読、社内向けの例外ドメインを足したい。ところが、落ちてきた大本体を毎回エディタで直すと、「更新」ボタン一発で上書きされ、追記が消えてしまいます。そこで更新対象と自前の差分を層に分け、合流点でだけつなぎ合わせる、というのが中級以降の「設定管理」の一連です。mixin による覆写はその中核、GEOIP や GEOSITE 単体の解説文 や、Sniffer 文法稿とは補完関係にあり、主題の重なりを避けています。
「mixin も書いたのに効いていない」と感じる場合、構文の誤りに加え、合流後の rules 全体のどこに自分の行が来ているかが肝になります。せっかく DOMAIN を足しても、もっと上の行で既に拾われてしまえば、後段は評価されません。併せて 本サイトの「ルール順序と MATCH」 を読めば、合流の仕方と同一テーブル内の優先度の両方が揃います。
mixin とは何か：第二の全体設定ではなく「増分レイヤー」
Mihomo の起動引数に渡す メイン config.yaml には、多くの場合 mixin として同じマシン上のもう一つのYAML（例: ./mixin.yaml。基準は作業目録とクライアントの解釈に従う）を指定できます。起動・再読み込み時、コアはこの断片をメイン文書に深い意味でのマージ（辞書形のキーは多くの場合統合、既存の配列とどう合わせるかはフィールドの型と実装版に依る）します。得られる一番の利点は、遠隔から毎晩入れ替わる大きい購読ブロックを、ローカルでは小さな mixin ファイルだけ管理できること、そして Git での差分が読みやすいことです。
Clash Verge Rev などのGUIは、文面上は「Merge」「覆写」名義で同種の層を提供し、prepend-rules や append-rules といった分割キーで、ルール表の前後差しを明示する場合もあります（Merge 手順）。名称は配布物ごとに違っても、読み心は共通で、本編が「空気の顔色」、覆写が「自宅の上書きメモ」、と考えると戸惑いにくいです。外部からまず Subconverter で Clash YAML へ揃えてから取り込み、mixin では自宅だけ知っている追記に専念する、という分業にもなじみます。
購読の併合と rules 追記：型ごとの落とし穴
proxy-providers のような名前付きの辞書に対しては、mixin 側に新しいキー（例: sub-work、my-home）を足す考え方が素直で、メイン購読の provider 行を毎度コピーし直さずに別路の購読を懸架できます。あとは、利用したい proxy-groups の proxies 配列、あるいは use 指定に、その名前を入れて一つの策略グループに集約すれば、GUI のセレクタ一つで切り替え可能です。同名グループのマージが「置き換え」なのか「配列の連結」なのかは、使っている版とフロントの実装差があるため、最終的にはデバッグ用に書き出した合流後 YAMLの見た目を正としてください。
GUI の Merge（prepend-rules など）を使う場合
Clash Verge 系のドキュメントが警告しているとおり、append-rules だけに頼ると、すでに末尾にある MATCH,… より後ろに行が来て到達不能になる例があります。多くの実務シーンでは、例外を表の上側に差し込む prepend-rules（または同等の前挿入）の方が安全です。mixin ファイルを手書きで一本化する場合も、「この行は合流時に MATCH より前に来るか」を頭に置き、MATCH 行の扱いを再確認するのがよい習慣です。
rules は順序付き配列です。メイン文書と mixin の双方に rules: があるとき、最終的に一列に直列化されるのか、片方が丸ごと置換されるのか、GUI が内部で前後挿入に割り振るのかを、バージョンとシェルごとに暗記しない方が身のためです。自前の分岐をブロック化したいなら、RULE-SET や rule-providers に逃がし、1行の参照にまとめた方が、表の中での位置が追いやすいです。大きな国別・ドメイン集合と組み合わせる例は GEOIP／GEOSITE 稿 へ。
# config.yaml (excerpt) — point to a local mixin
mixin: ./mixin.yaml
# mixin.yaml (excerpt) — add provider + group hint + your rules
proxy-providers:
my-extra:
type: http
url: "https://example.com/extra-clash.txt"
path: ./p-my-extra.yaml
interval: 3600
health-check:
enable: true
url: https://www.gstatic.com/generate_204
interval: 300
proxy-groups:
- name: PROXY
type: select
proxies: [DIRECT, my-extra, sub-main]
# rules: verify the merged order in your exported "running" config
rules:
- DOMAIN-SUFFIX,internal.corp,REJECT
- DOMAIN-SUFFIX,example.com,DIRECT
上の PROXY やノード名はあくまで仮です。主設定側に同じ名の策略グループが既にあり、深いマージで proxies 配列が合流する場合、最終的に意図した通りの一覧かをエクスポートで点検してください。コメント行は英語に限定し、手元のファイル間で表記を揃えると、共有や検索置換がしやすいです。
profile とは違う：永続化と「枠取り」
Mihomo の一般設定（MetaCubeX のドキュメント）で説明される profile: は、store-selected（最後に選んだ出口を起動越しに覚えるか）、store-fake-ip（Fake-IP マッピングを保持するか）のような、実行時の振る舞いとローカルキャッシュに向いています。ここをいじっても、遠方の二つ目の購読URLが自動でつながるわけではありません。一方、一部の配布物が言う「プロファイル（複数のメイン設定を切替）」は、シェル製品の多構成ストレージの話で、上記の profile キー名と紛れやすいです。心がけは次の三行で足ります。mixin＝文法上の上書き合流、profile 節＝選びとキャッシュ方針、GUIのプロファイル＝今どの config を読むか、の三分離です。
運用の流れ：戻りが少ないチェックポイント
- 主購読は、これまで通りURL取得／アプリ内購読管理のままにする。
- mixin 専用ファイルにだけ、足したい provider 名、策略グループの追記、自前
rulesまたはrule-providersを書く。 - メインの先頭、または配布物の案内に従い
mixin: <相対パス>を指定し、再読み込みする。 - アプリの完全な実行中設定のエクスポート（名称は各クライアント差あり）を開き、
proxy-providersに想定の全路が出ているか、rulesの上から下への並びが想定通りかを目視する。 - サブスク更新でノード名が変わると、策略グループや
DOMAIN,…,任意の名も一緒に壊れうる。mixin 以前の、いつもの一貫性の話です。
Docker や Linux の常駐で動かすとき
ボリュームに載せるパス、コンテナ作業目録、systemd の WorkingDirectory の三つがずれると、./mixin.yaml が「見つからない」事故が出ます。compose の巻とポートは Mihomo の Docker 稿、裸マシンなら Linux ＋TUN 常駐の稿 と併せて通しで読み、external-controller まで開いていれば、Yacd や REST から合流後の中身覗きで確認も速いです。
注意：GUIの「最前列／最後列に差す」枠、手書きの mixin、巨大な RULE-SET を同時に積み上げると、最後に効く rules の形は一発で頭に来ません。挙動が不可解なら、接続ログでFQDNを押さえたうえで、エクスポートした rules 全文と睨み合ってください。
入手先：インストール用のパッケージは 当サイトのダウンロードページ を先に。挙動の深掘りやIssue追跡は、公式のソース倉庫を併用し、バイナリの主入口と心の中で分けておくと誤解が減ります。
法令順守：利用地域の法律と契約、組織のネットワーク方針に従い、信頼できる供給者からの設定のみ扱うこと。不特定の第三者ノードに依存する場合のリスクも自覚してください。
まとめ
Mihomo における mixin（覆写）の目的は、遠方で更新され続けるメイン購読と、あなただけが保守したい増分を、編集衝突なく重ね合わせることです。複数 proxy-providers・策略グループの拡充・自前の rules／rule-providers は、いずれも独立 YAML へ分離可能です。profile 節の領分は 状態の持ち方。GUIの「中身の違うメイン枠」は それ自体が別物。ここを混ぜないことが、中級者の長期運用で一番効きます。最終的にトラフィックの出口を左右するのは、常に 合流後の rules 全体の全順序である点だけは、当サイト全般の ドキュメント案内 や、前述の ルール順序稿 と一緒に焼き付けておくと、トラブル時の仮説が一気に速くなります。
画面操作だけで Merge まで辿り着ける Clash 系クライアントも多く、一方で中身のYAMLに触れる余地も残るため、観測しやすい・差分が小さいメンテがしやすいのが利点です。一つの遠方ファイルに幾層もテープで肉薄するより、mixin にだけ自分の層を置く方が、更新の衝突が少ない典型です。