一、mixin と patch と profile override は別レイヤーとして考える
現場での混乱の多くは、「購読を取ったあとユーザーが編集しているテキスト」がひとつのファイルにしか見えず、でも実際にはコア側の機能とクライアントの保存ロジックが数段順番どおり合体していることへ気づいていないところから起きます。ここでの整理は単純化したモデルであり、環境により名称が違いますが、(A) ベースのプロファイルYAML（購読取り込みの結果または手元のひな形）、(B) mixin と呼ばれる深い合体レイヤー、(C) mihomo が解釈する patch 項目（ルールリストの先頭押し込みなど）、(D) GUI が JavaScript／別YAML で足す Override——の順に頭の中へ置くと検索窓への日本語質問とも噛み合いやすいです。
検索クエリにある優先順位は二種類あります。①設定ファイルの合体の順（どのレイヤーの値が効くか）、②ルールリストの行の並び順としての先に当たった行が勝つというルーティング上の評価です。両方をごちゃ混ぜにせず、(1) まず「最終的にファイルとしてコアへ渡っている一本の YAML に何が入っているか」を見える化する、(2) それからログでどの規則に吸われたか追う、(3) prepend で先に置くべきだったのではと疑う——の三段に分けると、症状と原因の線が細くほどけます。「Meta」と「Mihomo」という呼び方も混線しがちですが、ユーザー向けの記事語感としては両方とも同じ広いコードベース上の機能で、キーだけが版で進みます。mixin だけをいじれば足りないケースはルールリストの並び問題であることがよくありますから、次節へ進みます。
prepend-rules に置く、とレイヤ規約をチームまたは半年後の自分へ残しておいてください。Patch パスという語はクライアントが mixin ファイルをどこに探しにいくか、あるいは mixin： 以下にどんな構造が合体するか、の両方を指していることがあるのでチャット質問するときには「コア入力の単一YAMLに入った結果」を添えると伝わります。
もし上流のリストを巨大化させたくないだけなら、mixin と patch での追記だけでなくrule-providers と RULE-SETの利用もセットで検討します。rule-providers・path・interval の記事へ飛んで、自分の構成が「リストに直線で DOMAIN を足す」のか「名前付きプロバイダで差し込む」のか決めます。両方とも最終YAMLの rules: 表現は似ますが、mixin／patch と組み合わせるとき並び順の設計自由度が変わります。
購読のたびに同じ変更をクリップボードから貼り戻していた経験があれば、それはレイヤーを一段上へ引き上げるサインです。ここまで読むユーザーは大抵すでに tun-mode やポートを触っており、mixin と patch が「細かく触りたい層」の入口機能だとみなして大丈夫です。mixin： と書かれたひな型をひとつのリポジトリに置いて、端末ごとには購読URLだけ別にする構成も運用効率が高いです。この記事でも後半へ進むごとに、どの機能がどのクエリ語に対応するかを明示しておきます。
二、mixin ブロック：マップの深い合体とパス運用の勘所
多くの文脈では mixin はメインYAMLの直下（または環境規約で決めたひとつの親キー）にあり、そこへ書いた dns: や profile: ほかオブジェクト構造になっている設定片がベース側へ載ります。このとき期待される想像はクラシックなインフラの「親テンプレ＋環境別values」の関係です。スカラーのスイッチひとつ、たとえば tun： 配下の特定フィールドだけをオンにするときにも便利です。mixin と patch で全部を書くのではなく、まず親ファイルで購読と巨大な一覧を済ませ、ローカルの mixin 側には自分専用の短いYAMLだけを並べ続けると差分レビューの負荷が読みやすくなります。
# Example: conceptual mixin fragment merged into runtime config shape
mixin:
dns:
enable: true
profile:
store-selected: false上は説明用途の概念的な断片であり、自分の環境へそのまま貼れば必ず効くとは限りません。キーの真偽はリリースノートで読み換えられるため、読者はコピペより自分の親YAMLに無い項目だけ mixin へ動かしたかを見てください。mixin が参照する別ファイル運用になっている構成もあり、その場合でも「最終合体後の入力ツリー」だけがコア視点での真実になります。mixin と patch が同居する設定では、mixin が先でも後でも環境規約になるので、アップデート直後だけはマージ済みダンプへ目を走らせるクセをつけます。
Patch パスを気にするとき、mixin が外部ファイル読みになるケースでは相対パス基準がワークディレクトリだったり親プロファイルの所在だったりします。コンテナ実行やサービスユーザーで動かしていると想定より深い別ディレクトリがルートになり、読み込めない・古い mixin が残る問題がちらほら出ます。ここでの実務チェックリストは、(1) 親プロセスのカレントを知る、(2) コンテナボリュームに mixin をマウントする、(3) 権限があるか読む、(4) シンボリックリンクを跨ぐと視界がずれるので避ける、(5) systemd の -d フラグ直下に置くときはサービス単位テンプレを揃える、の順です。mixin と patch がどちらも相対依存だと複合しやすいので、mixin は絶対パス寄りに統一するとチーム開発では事故が少ないという声もあります。
proxy-groups： や rules： のように配列本体を丸ごと差し替えたいときは、mixin だけでは読み勝ちが難しい場面があります。環境により patch 側の一覧操作キーを使わないといけなかったり、mixin と二重適用になると名前衝突で起動しないこともあります。迷ったらリスト操作は明示的な prepend／append 系へ逃がすのが安全です。
mixin と patch の境界は「マップ増補」か「並び順付きリスト操作」か
mixin が得意なのはフラットになりすぎていないオブジェクトへの追記／上書きであり、評価順が命である rules: 自体を巨大にいじりたいなら、mixin と patch が意味上別物として頭に入っているとラクです。名前解決側を同時に変更するとログが増えますから、別稿の DNS の nameserver／fallback を整える手順と切り離し、mixin と patch がルーティング層だけ変えているか単層レビューを推奨します。
| 視点 | mixin 寄り／patch（prepend／append）寄り |
|---|---|
| dns.enable などフラグ | mixin で短いフラグだけ置く運用が多い——ただし他レイヤにも同フラグがあると最後側が勝ち |
| 長大ルールリスト | 一覧の頭・尻への追記には patch 側の一覧キーまたはクライアントGUIの並び機能を確認 |
| 秘密鍵ポート番号など | GUIロックやセキュア値は読み込み順で勝てないときがあるので「マージ後プレビュー」必須 |
| 名前空間設計 | 両方とも手元名前にローカル用プレフィクス——購読の命名規則と離す |
三、prepend-rules／append-rules などリスト系 patch と評価順
ルール配列への追記については、mihomo 系資料やコミュニティ解説によくprepend-rulesおよびappend-rulesといった名前が並びます。日本語クエリでの「YAML 」「patch」「優先」の多くは、この頭に縫う／後ろに縫うレイヤへの当たりを探している状態です。prepend-rules側へ社内FQDNや自分専用の例外を載せれば、購読の巨大リストより上流で先取りさせられます。append-rules側はリストの末尾寄りでの追記になりがちであり、評価上はMATCH で総取りされる前までに入っていれば意味を持ちます。MATCH のあと続く行があるとユーザー期待と食い違うので、この制約だけは頭に叩き込む価値があります。
# Example: prepend / append semantics (adapt keys to your exact core build)
prepend-rules:
- DOMAIN-SUFFIX,example.corp,DIRECT
append-rules:
- PROCESS-NAME,MyApp,DIRECTMihomo では名前の似た一覧操作キーがプロキシ一覧などにも増えている版があり、自分の構成が「自分のローカル専用 vmess だけ二つ増やしたい」のか、「ルールの順番問題だけ」を直したいのかによって選びます。mixin と patch が表に出ずに済むときも、内部では同種のリスト合成が動いているクライアントがあるので、アプリ画面上の並びドラッグだけ信用せず合体結果の確認が肝です。mixin と patch を重ねれば重ねるほど、GUI の「自動整形」によってキー並びへ無意識の意味を読み込まないよう気をつけます。
レイテンシ選定グループとは別次元ですが、ルール並び換えだけで体感が変わる場面があります。url-test・interval と tolerance を整理した記事とも役割分担し、ノード選びとリスト設計が同じ日に暴れないよう変更を順に適用しましょう。細かく「このアプリだけ直結」を足したければ、mixin と patch のどちらか片方だけを触っているかチームへ共有すると再現ヘルプが早くなります。
ルール評価順の再確認（上から先勝ち）
ルールの評価はリスト先頭から下へ順に評価し、一度マッチすると残りへ進みません。prepend-rules の意図はまさにここであり、上流で DOMAIN-SUFFIX を広く取っている購読を崩さず社内だけ例外を頭に載せる、という型が鉄板です。逆に広いセットを頭に載せ過ぎると下流の自分用の細かな行が二度と見られません。mixin と patch を使うときも並び順の設計レビューだけは昔ながら人手でやるしかない領域です。
四、同名プロキミとマップ競合、mixin と patch をまたいでの事故予防
購読が配る proxies： 配列に同名のオブジェクトがあると、mixin と patch がどちらから追記していてもYAMLパーサの解釈とコア側の名前解決が競合します。ローカルの追加分には LOCAL- や端末コードを頭に付けて名前空間を物理的に分けると、半年後の自分が購読更新後に「なぜかゾンビノードが残る」事故を減らせます。proxy-groups 経由で参照するときも、policy 名のスペルが一文字違うだけで「ルールは当たったのに hop がない」となります。mixin と patch を使う設計では参照整合性を手元スクリプトか簡易テストでなぞると安心です。
rules： 行で参照するポリシー名と、実際の proxy-groups： のキー名は大文字小文字も含め一致している必要があります。海外ドキュメントを読み替えると表記ゆれが起きやすいので、mixin と patch にローカル用の短いコメント（英語一行で十分）を残す文化を推奨します。JSONに近い厳密さを求めるとテキスト編集はしんどいですが、Clash 系はそこが甘いと静かに破綻するタイプの設定言語です。
さらに踏み込むと、client-side profile override は JavaScript で購読JSONをいじるレイヤーもあり、mixin と patch の静的YAML合成とは別脳みそで動きます。同一キーを静と動の両方が触ると予測不能になるので、チームでは「動的スクリプトはここまで、静的は mixin」など境界を固定します。
五、Clash Verge 系などGUIと「結合済みYAML」の見え方
多くのデスクトップクライアントは、画面上の「プロファイル」が実ファイルの一本と一対一ではありません。購読取得→（スクリプトやOverride）→mixin／patch→最終入力、のパイプを意識し、エクスポートやプレビューで最終形を保存して差分を見るのが最短です。「保存したつもりが次回開いたら消える」問題は、mixin と patch 以前にGUIが空キーを強制削除する実装だったり、mixin と patch と三方の競合だったりがあります。ログに「未定義ポリシー」と出たら名前衝突を疑う前に、まず合体結果を確認します。
モバイルではファイルパスへ直接触れず、画面上の項目と内部ストレージの対応だけを追えることもあります。mixin と patch の概念説明だけ読んでも運用につながらないケースがあるので、アプリ側の「高度な編集」「カスタム」メニューを開き、mixin と patch が効いているか公式ヘルプと照合してください。ここで触った external-controller や秘密は、セキュリティレビューとセットで扱います。
抽象レイヤーとして述べると、ブラウザ拡張やOS付属の簡易トグルは短いタスクには向いていても、数十メガバイト級のルールと prepend／append の設計、fake-ip と整合したDNS、TUNまで含めた再現性を長期で求めるとツールがばらけがちです。一方 Clash 系は設定モデルが一続きで説明でき、mixin と patch で購読を壊さず足し算できるのが実務上の利点です。GUIによってはスクリプトまで含めたマージ順が文書化されているので、自分の版の告知を一度通読してから本番端末へ載せると安全です。
ここまで読み、mixin と patch を使い始めたい方は、ルールとノードのバランスを崩さないよう Clash クライアントを無料ダウンロードし、公式ドキュメントと合わせて一度だけマージ済みYAMLのバックアップ運用を始めてみてください。
六、rule-providers・DNS・url-test との補完関係
mixin と patch は局所の差分に強い一方、巨大ルールをリモート更新で追従させるなら rule-providers が補完軸です。本サイトの rule-providers・path・interval・RULE-SET と本稿をペアにすると、「リストを購読へ直書きしない」設計が揃います。DNS はルールと独立して名前解決を崩すので DNS・fake-ip まわりと干渉しないよう変更を分けます。レイテンシ自動選択は url-test 記事と役割分担してください。
これらは検索上もキーワードが隣接しやすく、mixin と patch を覚えたあと「次に何を足すか」の導線として自然です。rule-providers を mixin で path だけ上書きする、といった合成もありますが、そのときも最終ツリーで重複キーがないか確認します。
七、よくある質問
mixin を書いたのに dns セクションが変わらない
GUIまたは別レイヤが同じキーを後段で上書きしている可能性が高いです。mixin と patch を含めマージ後の dns ブロックをエクスポートして比較し、期待するフィールドが残っているか見てください。環境によっては購読テンプレが空の dns を毎回配り、ローカル設定が負けるケースもあります。
prepend-rules が購読ルールより下に見える
クライアントが購読ルールを先に展開し、そのあとGUIの並び替えで見た目がズレている可能性があります。見た目ではなく実際の配列順をダンプで確認してください。また購読側に似た広い DOMAIN 行が先頭付近へ入っていて、prepend を相対的に無力化しているパターンもあります。
profile override と mixin のどちらを先に触るべきか
チームに合わせます。静的で追いやすいなら mixin、mihomo の patch キーやGUIのスクリプトで動的に購読をいじる必要があるなら後者を先に固めます。どちらも触るとデバッグが難しくなるので、最初の三ヶ月は片方に寄せるのが安全です。
八、まとめ
Clash Meta／Mihomoで購読を維持したまま差分を足すには、mixinでマップ項目を増補し、ルール配列はprepend-rules／append-rulesなどのpatch 系キーで位置を制御し、さらにクライアントの profile overrideが重なるなら結合済みYAMLで検証する——この四点セットが「パス・書式・優先」の検索意図に対する答えの骨格です。ルール評価順とマージ順は別物なので混同しないこと、MATCH より後ろに行を足しても無意味なこと、同名プロキシは避けること、を守れば運用はかなり静かになります。
世の中にはブラウザ拡張やOS付属のプロキシ切替だけで済ませるワークフローもありますが、mixin と patch のようにレイヤー化した YAML 合体まで含めて再現性を取ると、規則やクライアントの版が変わるたびに手作業へ戻りがちです。rule-providers／GEOIP／DNSまで一続きのモデルで説明できるClash系は、長期運用でその差が出やすく、購読とローカル差分を分けてGit やバックアップにも載せやすいのが利点です。mixin／patch の設計を自分の端末に一度通したい方は、そのまま Clash を無料ダウンロードし、公式ドキュメントとマージ済みYAMLの保存をセットで始めてください。
追加の共通仕様は ドキュメント索引とリリースノートをセットで読み、mixin と patch のキー名が版で変わったらこの記事の手順も読み替えてください。