なぜ「購読 YAML を触らない」ことが現実的なのか
多くのユーザーは、プロバイダーが配布するサブスクリプション URLからそのまま設定を取り込み、GUI でノードを切り替えて運用しています。ここで困るのが、リモート側の YAML は更新のたびに再取得され、手元で直した内容が消えるという挙動です。ダッシュボードでノード名を整えたつもりでも、次の自動更新で元に戻る、というのは珍しくありません。
そこで必要になるのが、リモートの成果物を「ベースライン」として受け取り、その上にだけ本機固有の差分を載せるという発想です。Clash Meta（コミュニティでは実行体名から Mihomo と呼ばれることも多い）では、この差分をオーバーライド／マージ／追記ルールとして表現し、購読そのものやプロバイダーのサーバ上のファイルを編集しなくて済むようにできます。本稿では、そのための考え方と、実務で使いやすいパターンを順に整理します。
Clash Meta における「オーバーライド」のイメージ
コアが最終的に読むのは一つの論理設定ですが、その生成過程は、複数の断片をマージして一つの config に畳み込むというモデルで理解すると混乱が減ります。リモート購読が proxies と proxy-groups と rules をまとめて運んできても、ユーザー側には次のようなレバーがあります。
- ルールの先頭・末尾への追記：評価順が結果に直結するため、特定ドメインだけ先に処理したいときに有効です。
- 独自プロキシ定義の追加：自宅 VPS や社内 SOCKS など、購読に含まれないノードを
proxiesに足し、既存のポリシーグループから参照します。 - ポリシーグループの再定義・差し替え：セレクタの候補リストや既定選択（
useやproxiesの並び）を、ローカル側の宣言で上書きします。 - クライアント付帯のマージファイル：Clash Verge Rev などでは、GUI から「購読の下に重ねる YAML」を指定できるため、エディタに慣れていなくても運用できます。
どの手段を選んでも共通なのは、「購読が更新されたら再びマージされる」という一点です。ローカル差分は別ファイルや別入力欄として管理し、リモート本文を直接編集しない運用に寄せると、トラブル時の切り分けが格段に楽になります。
ルールを足すときは「順番」がすべて
Clash 系のルールエンジンは、上から順に評価し、最初にマッチした行で出口が決まります。したがって DOMAIN／IP／GEOIP などを追加するときは、既存ルールとの位置関係が最重要です。末尾にだけ足すと期待どおりに効かない、逆に先頭に入れすぎると広すぎるマッチで後段が死ぬ、といった典型パターンが起きやすいです。
実務では、まずログで対象トラフィックがどのルール行に当たっているかを確認し、その一つ上か下かに差し込む、という手順が安全です。接続ログの読み方全般は、当ブログの接続ログ解説記事と併せると、試行錯誤の回数を減らせます。
prepend-rules と append-rules の考え方
Mihomo 系の設定では、生成済みルール列の前に挿入・後に追記を明示できる文法が用意されていることがあります（クライアントやバージョンによりキー名や UI ラベルは異なります）。意味合いとしては、prepend は「より優先させたい例外」を、append は「最後の保険やフォールバック」を置くイメージです。
例として、社内ドメインだけ常に DIRECT にしたい場合、購読側が末尾に広い MATCH を持っていても、先頭側に DOMAIN ルールを差し込む必要が出ます。逆に、購読が細かいルールを大量に持っているときに末尾へ雑に足すと、そもそも到達しない行になることがあります。
# Example only — adjust keys to your client / core version
prepend-rules:
- DOMAIN-SUFFIX,corp.example,DIRECT
append-rules:
- DOMAIN-SUFFIX,lab.local,REJECT上記は概念を示すための断片です。実際のキー名や配置場所は、利用中のコアのドキュメントと GUI の「マージ／拡張設定」画面を照合してください。
購読外ノードを足してポリシーグループに載せる
たとえば「プロバイダーのリストには無い自前の VM だけ、特定のセレクタの一番上に常に出したい」という要望はよくあります。その場合、ローカル専用の proxies エントリを定義し、対象の proxy-groups の proxies: 配列にその名前を差し込みます。名前の衝突にだけは注意してください。購読側と同じ名前を誤って二重定義すると、マージ結果が読みにくくなります。
ポリシーグループの設計そのもの——国内を DIRECT、海外をプロキシへ、といった分流の骨格——は、分流ルールの記事で扱っている戦略と直結します。オーバーライドは、その骨格に対する個人向けの微調整レイヤーだと捉えると実装がブレません。
GUI クライアントでの運用（マージファイルの置き場所）
コマンドラインで config.yaml を直接編集する代わりに、Clash Verge Rev などの GUI では「プロファイルに追加で重ねる YAML」「スクリプトやパッチ」といった入力欄が用意されていることがあります。ここにだけ自宅用の追記を書いておけば、購読更新のボタンを押してもローカル差分は消えません。
操作名はバージョンで変わるため、記事本文で特定のボタンラベルに縛られない方がよいのですが、探すときのキーワードは Merge／Patch／拡張／プロファイル結合あたりが手掛かりになります。初回は小さな prepend-rules だけを入れてリロードし、ログで意図どおり先に評価されるかを確認すると安全です。
つまずきどころ：DNS・fake-ip・ルールプロバイダ
ルールを増やしても挙動が変わらないとき、実はドメイン解決の段階で別経路に流れているケースがあります。fake-ip モードでは見かけ上の IP と実ドメインの対応がログ上わかりにくく、初心者ほど「ルールが効いていない」ように見えがちです。DNS セクションとルールをセットで読み直す癖をつけると、オーバーライドの効果を正しく検証できます。
また、Rule Provider を HTTP で取りに行く構成では、ローカルミラーへ差し替えたいというニーズも出ます。購読全体を書き換えずに済ませるには、プロバイダ定義側の url をローカルファイルパスに向ける、あるいは追記ルールで局所的に上書きする、といった整理が必要です。いずれにせよ、「どのレイヤで上書きしているか」を一つに決めないと、同じドメインに対して二重管理になります。
購読の取り込み自体をまだ整えたい場合
オーバーライドの前に、そもそもサブスクリプションが安定して取り込めているかを確認してください。URL の期限切れや User-Agent 制限、複数ソースの命名衝突などは、マージ以前の問題として表面化します。当ブログの購読 URL チュートリアルで、インポート周りを先に整えると、その後の差分運用がずっと楽になります。
オープンソースの参照について
コアや GUI のソース、Issue、ライセンスは各プロジェクトの GitHub で公開されているのが一般的です。挙動の細部を追うには有用ですが、初めてインストールするビルドの入手は、必ずしもリリースページだけに限定する必要はありません。当サイトでは検証のしやすさを重視し、入手導線をダウンロードページに集約しています。
まとめ
Clash Meta 系クライアントで「購読 YAML を触らずに済ませたい」というニーズに対して、有効な答えはリモートをベースに、ローカル差分だけを別レイヤで持つことです。ルールは順序が命であり、ノード追加は名前衝突に注意し、DNS まわりはルールと一体で検証します。GUI のマージ欄を活用すれば、エディタに不慣れでも同じ方針を実践できます。
実際に手元で試すときは、変更を小さく刻み、ログで命中を確認しながら広げていくのが最短です。プラットフォームごとに最適なパッケージは異なるため、環境に合ったクライアントを選びたい場合は、当サイトの一覧から入手するのが確実です。準備が整ったら、→ Clash を無料ダウンロードして、オーバーライド込みの運用を試すところから始めてみてください。