Clash Meta mixin で購読覆写：自作ルールが消えない【2026】| Clash ブログ

なぜ「購読を直接編集」が破綻しやすいのか

クライアントは定期的に URL から設定を取り直し、キャッシュへ保存します。エディタで開いた一時ファイルを編集しても、更新タイミングでサーバー側の版に置き換わるのが普通です。ルール順やプロキシ名をローカルだけ変えたつもりでも、次回同期で元に戻り、気づかないうちに「自作の MATCH 行が消えた」「広告リストが薄くなった」といった事故が起きます。

そこで現実的な分離は次の二層です。下層は購読が提供するプロキシ一覧とベースルール。上層は端末に残る mixin／マージで、常に同じパスから読み込まれるローカル YAML です。GUI によって名前は「拡張設定」「Merge」「mixin」など様々ですが、考え方は「購読のあとにローカル差分を合成する」一点に集約できます。

合成の心象モデル：profile と mixin の位置づけ

実装の細部はクライアントのチェーン処理に依存しますが、運用で押さえるべきは次の三点です。(1) 購読由来の巨大な rules は触らない。(2) 自作は リスト操作キー（後述の prepend-rules 等）か、衝突しにくいトップレベルブロック（例：rule-providers の追記）で足す。(3) 更新後は必ずマージ結果のプレビューかログで「自分の行が生きているか」を見る。

すでに購読 URL 自体を加工したい場合は、「Subconverter で Clash YAML にし Meta クライアントへインポート」の流れも選択肢です。本稿は「加工済み／未加工を問わず、クライアント側で安全に重ねる」話に絞ります。

覚えておくと楽な整理

prepend-rules はルール配列の先頭側に差し込みやすく、細かい例外や広告ドメインの早期判定向き。append-rules は末尾へ寄せられ、購読側の MATCH の「直前／直後」に独自の逃げ道を置きたいときに使います。クライアントがどちらをサポートしているかは画面またはドキュメントで要確認です。

Mihomo 単体：mixin ファイルに書く典型形

コアが Mihomo の場合、作業ディレクトリに置く mixin.yaml（名称は環境により異なることがあります）へ、ルールや DNS など本体設定とマージされる断片を置きます。利用中のバージョンでサポートされるキー（例：prepend-rules）はリリースノートや公式ドキュメントで確認してください。

# mixin.yaml — illustrative; keys depend on core version
prepend-rules:
  - DOMAIN-SUFFIX,example-ads.net,REJECT
  - GEOIP,CN,DIRECT

プロキシや策略グループを購読の外側から足すときは、GUI のマージ機能が解釈する append-proxies／append-proxy-groups 系のキーを使う例が多いです（コア単体の mixin.yaml だけで同じ名前が使えるとは限りません）。Clash Verge Rev などではマージ YAML に次のような断片を書けることがあります。

# merge profile (GUI) — illustrative patch-style keys
append-proxy-groups:
  - name: CUSTOM-AUTO
    type: url-test
    proxies:
      - 香港 01
      - 日本 01
    url: https://www.gstatic.com/generate_204
    interval: 300

ここでのポイントは、購読が持っているプロキシ名（例：香港 01）を参照している限り、購読がノード名を変えない限りグループ定義は維持されます。空港が名前規則を頻繁に変える場合は、proxy-groups 側の参照も追従が必要になるため、安定した命名の購読か、自前の append-proxies で固定名を用意するかを検討してください。

自動選局のパラメータ調整だけなら、「Clash Meta の url-test と fallback」と併読すると、tolerance や lazy の意味まで一気通貫で整理しやすいです。

Clash Verge Rev：Merge プロファイルで足せるもの

GUI 利用者にとって現場での呼び名は「マージ」や「拡張」になりがちです。多くの Mihomo 系クライアントでは、購読プロファイルに対してローカル YAML をチェーンし、次のような操作キーを解釈します。

prepend-rules／append-rules：ルール行の前後挿入。
prepend-proxies／append-proxies：プロキシ定義の前後挿入。
prepend-proxy-groups／append-proxy-groups：策略グループの前後挿入。

画面から「購読本体」と「マージファイル」を別エントリとして管理できるため、更新ボタンを押してもマージ側は消えません。複数マージを重ねる UI もありますが、その場合は適用順がトラブルの源になりやすいので、役割ごとにファイルを分けすぎず、まず一枚に集約してから必要なら分割するのがおすすめです。

「全体を上書きする拡張」との混同

グローバルな共通拡張設定は便利そうに見えて、想定外に広いブロックを置換してしまうことがあります。症状が出たら、まずその拡張を外して購読単体で起動できるかを切り分けてください。

ルール順を誤らない：prepend と購読側ルールの関係

Clash 系は基本的に上から順に最初の一致で決まります。広告ブロックや社内ドメインの例外を購読ルールより先に評価したいなら prepend-rules が向きます。逆に、購読が用意した細かい地域ルールの後ろで独自の最終 MATCH を置きたいなら append-rules を検討します。

購読側にすでに広い GEOIP,CN や巨大な MATCH がある場合、prepend に足した行が本当に先に評価されているかをログで確認しないと、「書いたのに効いていない」状態が続きます。接続ログのポリシー列と、該当ホストがどの行に当たったかを突き合わせるのが最短です。

目的	足し方の例	注意
特定ドメインだけ直結	`prepend-rules` に `DOMAIN`／`DOMAIN-SUFFIX`	購読側のより具体的な行に負けないよう順序確認
大陸向けトラフィックの既定	`GEOIP,CN,DIRECT` を prepend か、購読ルールより前に来る位置へ	CDN 越境や誤判定に備え例外ドメインも併記
巨大な広告リスト	`rule-providers` ＋ `RULE-SET` 行を prepend	更新間隔とファイルパスは別稿の設定と整合

rule-providers の保存場所や更新間隔を詰める場合は、「rule-providers のダウンロードパスと更新間隔」を参照してください。mixin 側に rule-providers ブロックを足し、購読ルールより上に RULE-SET 行を置く、という二段構えが保守しやすいです。

DNS・TUN と併用するときの落とし穴

ルールを増やすと同時に、dns ブロックや TUN モードの有無で挙動が変わります。例えば fake-ip を使っている環境では、ドメインルールの見え方と実接続先のログがイコールにならず、誤って「ルールが死んでいる」と判断しがちです。DNS まわりで詰まったら「接続中なのに繋がらない？DNS と fake-ip」で変数を一つずつ戻してください。

Windows や macOS で TUN を初めて有効にする場合は、先に「Clash for Windows」や「Clash Verge Rev（macOS）」で権限とスタックを安定させ、その後に mixin でルールを厚くするほうが切り分けが楽です。

購読更新後も安心する検証ステップ

更新直後にやるべき確認

クライアントの「マージ後／実効設定」プレビューを開き、prepend-rules に置いた行が配列の意図した位置にあるか目視する。
テスト用ドメインへブラウザでアクセスし、ログ上で期待するポリシー（REJECT や DIRECT）が選ばれているか確認する。
意図したプロキシグループを選び、url-test 系グループなら遅延測定が動いているかを見る。
購読を手動更新し、もう一度 (1) を繰り返す。ローカル mixin が消えていなければ合格。

ログの見方はクライアントごとに UI が違いますが、「ホスト名」「マッチしたルールの種類」「最終ポリシー」の三点セットを追えば十分です。自動更新を短い間隔にしているほど、mixin の typo に気づくのが遅れがちなので、設定変更直後は一度だけ手動更新で検証する癖をつけると安全です。

よくある質問

購読がノード名を変えたらカスタムグループが壊れた

append-proxy-groups が参照している名前が存在しなくなった状態です。購読側の最新名に合わせるか、mixin で append-proxies により自前の固定名ノードを定義し、それだけを参照する構成に切り替えてください。

prepend したはずのルールが効かない

別のマージやスクリプトが後段でルール配列を再生成している、あるいは購読内のより優先度の高い行（プロセスルールなど）が先に当たっている可能性があります。実効設定の順序とログを突き合わせてください。

エディタで購読ファイルを直したら反映された

一時的に見えるだけで、次回同期で消えます。恒久対応は mixin／マージへ移すか、自前ホストした静的 YAML を購読 URL にするかの二択になります。

運用チェックリスト

購読本文は編集せず、ローカル差分は mixin／マージに集約した。
ルールは目的に応じて prepend-rules か append-rules を選び、順序をログで確認した。
巨大セットは rule-providers に逃がし、コア設定は読みやすいまま維持した。
購読更新のたびにプレビューと簡易接続テストを行う手順を決めた。

まとめ

リモート購読は「生きた設定」であり、ローカル改変との相性が悪いのが普通です。Clash Meta エコシステムが提供する mixin／マージは、その摩擦を減らすための公式な逃げ道に近い存在です。合成順を頭に入れ、更新後に数分だけ検証の儀式を積むと、広告除去や国内直結、独自策略グループを長期運用で保てます。

Clash を無料ダウンロードして、快適な接続を体験する

Clash Meta（Mihomo）の mixin／マージでリモート購読を覆写し、自作ルールを購読更新で消さない