mixin を使う判断：単一巨大 YAML の限界

1 台の PC に Clash 系クライアントを 1 つ入れたまま、在宅ではゲーム用の rules 直書き、出社では社内イントラの DOMAIN-SUFFIX や社内 DNS のみを足したい、と考えると、購読が更新のたびに上書きされる proxy-providers 直後に手書き差分を毎回貼る運用に疲れがちです。mixin を使うと、人間が手で触る層を「購読が上書きする層」から切り離し、環境専用の小さな YAML だけ入れ替えればよい、という分業がしやすくなります。GUI によっては「プロファイル」として A/B 切替に見える部分と、ディスク上の mixin 列の両方を同時に使う例もあるため、クライアントの選び方で「プロファイル管理 UI の有無」を先に把握しておくと迷いが減ります。

mixin とは何を「併合」するのか

Mihomo クラスコアでは、メインの設定（多くの場合 config.yaml など 1 本の入り口）に対し、mixin キー配下で追加の YAML ファイルを列挙し、辞書同士を深くマージする、という流れを取ることが多いです。数値や文字列、真偽はあとに来た定義が勝ち、配列（例：ルール行のリスト、ノード行のリスト）については先頭へ追記する文法（例：rules の prepend 系）を別キーに分ける、といった扱いが版によって用意されていることがあります。ここを「上書き＝常に最後のファイルだけが生きる」と誤解すると、rules や dns の一部だけ変えたいのに挙動が期待とズレます。併合後の rules の評価順の基本は、ルール分流のベストプラクティスと同じ前提で、先に書いた行からマッチです。したがって「環境差分でだけ特定ドメインを直進させる」なら、差分ファイル側で上に来る行（または prepend）を意識的に使います。

ℹ 用語メモ：コア内の profile: store-selected など、ノード選択の永続化に使う profile ブロック（設定 YAML のキー名）と、利用者の言葉の「プロファイル＝一組の動作パターン」は別物です。本稿のタイトルでいう profile 上書きは後者（シナリオ切替）の意味に近づきます。

ディレクトリ例と config.yaml エントリ

次の例は、作業用ディレクトリ（コアの作業カレント、またはクライアントが config.yaml へ解決する基準）を ./clash としたときのイメージです。実パスは OS とパッケージ方式で変わるため、絶対パスで書くか、クライアントが ~/.config/... へ展開するかを起動時ログで確認してください。文字コードは UTF-8（BOM なし推奨）に統一し、行末の全角スペースに気をつけると、パース系の不具合を避けやすいです。

Directory layout (example — adapt paths) 
clash/
  config.yaml          # entry; lists mixin files
  base/
    common.yaml        # large stable pieces (optional split)
  env/
    home.yaml          # home-only overrides
    office.yaml        # office-only overrides
config.yaml — mixin list (illustrative) 
# Main entry merges these files in order (details depend on your core build).
mixin:
  - base/common.yaml
  - env/home.yaml

出社に切り替えるときは、最後の 1 行を env/office.yaml に差し替える、あるいは home.yaml を読まない配置に入れ替える、といった運用が分かりやすいです。スクリプト化するなら、シンボリックリンクを active-env.yaml に向ける手法も有効です。

読み込み順と深い併合のイメージ

典型パターンは、config.yaml に port や mixed-port、log-level、proxy-providers の url など不変に近い枠を置き、mixin 側で dns の nameserver だけ差し替え、rules の prepend 相当で社内用の数行を足す、というものです。辞書型の dns ブロックは下位キーが欠けていれば上書きされず、同じキー名なら新しい方に置換、と覚えると事故が減ります。配列の rules について、版が rule-providers と分割している場合は、どのファイルのどの行が、マージ後何行目に来るかを GUI のプレビューや一時的に log-level: debug で起動し、実際のヒット行を追うのが確実です。

考え方 挙動の目安
同じ階層のマップ 同名キーは後勝ち。子キーごとに再帰的にマージされることが多い。
ルール行の配列 単純な「後のファイルの rules が丸ごと上書き」ではなく、prepend／既存行との関係を版定義で確認する。

シナリオ例：在宅用と出社用の差分ファイル

在宅 env/home.yaml では、ローカル NAS のサフィックスを DOMAIN-SUFFIX, DIRECT に寄せ、出社 env/office.yaml では社内ドメイン群と、社内が許可する dns.nameserver（Split DNS 相当）に寄せる、と衝突しないキーに分けると、片方のファイルを外しても他方の前提が壊れにくいです。DNS の詳しい書き方は Mihomo DNS 設定と線でつながり、TUN で「トンネル外に DNS が抜けている」違和感は TUN モード解説と併読すると、レイヤ（ルーティングと名前解決）の切り分けが速くなります。

env/home.yaml (snippet — example only) 
rules:
  - DOMAIN-SUFFIX,local.nas,DIRECT
  - DOMAIN-SUFFIX,plex.direct,DIRECT

dns:
  nameserver:
    - 192.168.1.1
env/office.yaml (snippet — example only) 
rules:
  - DOMAIN-SUFFIX,corp.example,DIRECT
  - IP-CIDR,10.0.0.0/8,DIRECT

dns:
  nameserver:
    - 10.0.0.53
⚠ 注意：上のルール行・DNS は教育用の例です。自組織のポリシーと法令に従い、許可されたネットワークでのみ検証してください。キー名・prepend の有無は利用中のコア版に合わせてください。

上書きが反映されないときのチェック

  1. パス：mixin の相対パスは「コアの作業ディレクトリ基準」か「設定ファイル基準」か。起動ログに open ... No such file が出ていないか。
  2. 文法：インデント（スペース 2 段）の崩れ、タブ混在、コロン抜け。ビルドによっては厳格なスキーマ検証で無視されないか。
  3. 重複キー：同じ dns.nameserver を二重定義し、思ったより前の行が効いていないか。
  4. クライアント層：GUI が起動時に 独自の一時 config を生成し、mixin 列がそこに反映されていない。設定画面で「最終的にロードされた YAMLのエクスポート」があれば比較する。
  5. 再起動：一部クライアントは mixin 列変更後に コア再読込が必須。ホットリロードが購読だけに効いている点に注意する。

リモートの 外部コントローラから設定を当てる場合、POST した内容とローカル mixinのどちらが最終的に優先されるか、クライアントの設計上の注意書きに従います。併用すると「ローカルで直したのに戻る」原因になりがちなので、運用の正を 1 つに決めておくのが安全です。

DNS・TUN・ルール整流との併用のコツ

mixin は起動前の静的な併合の話に近いです。一方、dns の enhanced-mode: fake-ip や、TUN モードでシステム全体を巻き込む層は、実際の問い合わせ経路がオンメモリのルーティングに依存します。mixin で dns だけ美しくしても、ブラウザの DoH や、別の VPN クライアントの DNS フックと二重化していると、見た目は「mixin の上書きが効いていない」に見えます。切り分けの順序としては、（1）最終ロード YAML の抜粋、（2）TUN/システムプロキシの有効範囲、（3）アプリの独自 DNS 設定、の 3 点を上から潰すと早いです。

profile: ブロック（永続化）との混同を避ける

設定内の profile: { store-selected: true } のような行は、ノードの選択・ワンチャンネル測定結果の保存先を指す文脈で出てきます。これは mixin によるファイル合成とは別物で、「環境 A/B の切替」とは直接対応しません。ユーザーが口にする profile 覆写（家／会社用の上書き）を YAML で表すなら、mixin 列＋差分 YAML か、GUI の プロファイル切替＋同梱のスニペットのどちらを正にするか、先に整理してからファイルを分けると、設定リポジトリ内の呼び方もブレにくいです。

まとめ

Clash Meta／Mihomo の mixin は、購読の自動更新層と、人間の手で差し替える環境専用層を分け、同一マシン上で「ベース＋在宅」／「ベース＋出社」といった プロファイル的な上書きを現実的にするための仕組みです。読み込み順序と、マップ配列のマージ挙動を版ドキュメントで確認し、最終的にロードされた設定をエクスポートして差分比較できるようにしておくと、トラブル時の説明責任と自分自身の再現性の両方が上がります。GUI での作業導線は製品差があるため、基本は コアを最新帯に保ち、クライアント付属の表示と突き合わせてください。ソースや Issue 追跡に GitHub を使うのは有効ですが、配布物の入手はサイト上の導線を主眼に置くと、端末のセキュリティ方針とも折り合いが付きやすいです。

分散した YAML を 1 本の運用体験に戻しながら、多環境の差分を小さなファイルに閉じ込めたい方は、Clash を無料ダウンロードし、最終挙動をログと同一画面で追えるクライアントから試してみてください。