1. 複数サブスクのままだと詰まる典型
「とりあえずURLを足した」状態で一番多いのが、trojan や vmess の名前が両方とも「Japan-01」など同じ文言になり、YAML 側で参照がぶつかるケースです。クライアントが自動で頭に番号やベンダ略号をつけて見えていても、proxy-groups の並び順や選択肢のラベルだけでは、どのアップストリームに紐づく経路か把握しにくくなります。また、複数ソースをそのまま重ねた結果、貼り付いたルール群がMATCH,DIRECT と手動グループへの MATCH のどちらで終わっているかだけが違い、体感の「サイトが直結しない」症状は表面では同じでも根が異なることがあります。
検索クエリにある「Clash で複数のサブスクをマージしたい/YAML で合成したい」は、単にリストを並べればよいだけではなく、rules の評価順や名前空間が重なっているかどうかまで含めて一つのプロファイルとして設計し直す、という問題だと見るほうが正確です。ここまでの共通の土台についてはルールの上から下へのマッチの解説と、サブスクリプションの取り込みを先に押さえておくと、以降の手順が迷子になりにくいです。
2. 「1つの動く設定」をつくる2つのモデル
実務で「合成」と言ったとき、次のどちらに近いかで打ち手が変わります。(A)常に1本の config.yaml(または生成物)の中に、複数 URL 由来のノードを同居させる。あるいは(B)用途別にプロファイルを分け、切り替え時だけ別 YAML を読み込む。(A)は「社用と家庭用のサブスクを同一画面で選びたい」に向き、(B)は「仕事用は極力ルールを薄く、プライベートは分流を厚く」のように衝突しそうな行を論理的に離すのに向きます。両方とも正しいので、自分の頭のなかで「名前とルールが互いを上書きしているか」を切り口にすると判断が楽になります。
| モデル | 長所 | 注意点 |
|---|---|---|
| A:単一プロファイル内統合 | proxy-providers でソースを並列管理しやすく、グループ構成を一元化できる。 |
名前衝突とルール列の競合には設計が要る。rules が長くなりログ読みも重くなりやすい。 |
| B:複数プロファイル運用 | 衝突を「ファイル境界」で断ち切れる。アップストリーム側の暴走ルールの影響を局所化しやすい。 | 切り替え忘れや、クライアント側の一覧管理の手間。同じサイトを両方で触るなら別プロファイルでも混乱は残る。 |
3. proxy-providers で複数ソースを束ねる
mihomo / Clash Meta 系では、購読 URL をただ貼るだけでなく、proxy-providers: に URL・ローカルパス・更新間隔を列挙し、ここから展開されたプロキシを proxy-groups に束ねる、という形が「複数サブスクを YAML 上で合成する」中心的なパターンです。各エントリに意味のあるキー名(例:airport-a、backup-vendor)を付け、健康チェックやダイアラップを付けるかはアップストリームの性質次第です。GUI から追加した購読が「マージされない」ように見える場合、実際には別ファイルに落ちている/別の provider 名で二重管理になっていることがあり、生成された設定の生テキストを一度開いてトップレベルのキーがどこで折り合っているかを確認してください。
次の抜粋は説明用の骨格です。キー名や必須項目は利用中のコアの版とクライアントの生成ルールに合わせ、空のまま起動に失敗する場合は公式サンプルと突き合わせてください。
proxy-providers: provider-from-A: type: http url: "https://example.com/sub-a" path: ./providers/airport-a.yaml interval: 43200 # health-check: ... (optional, match your core version) provider-from-B: type: http url: "https://example.com/sub-b" path: ./providers/airport-b.yaml interval: 43200 proxy-groups: - name: 🔰 手動(全ノード) type: select proxies: - provider-from-A - provider-from-B
ここで proxies に書くのは「展開後のプロキシ名の束」ではなく、provider 名をそのまま渡す書き方もあれば、クライアントが展開済みの一覧を列挙する書き方もあります。自分の生成物に合わせることが最優先で、テンプレの丸写しは失敗しやすいポイントです。購読取得そのものが不安定なときは、Windows 向けの購読まわりのログの切り分けと併せて確認すると、マージ以前の段階で詰まっていないか判別しやすくなります。
4. 名前の衝突を潰す:プレフィクスとグループ構成
各アップストリームが同じノード名を吐く場合、対策は大きく二つです。(1)GUI やスクリプトが提供する「名前のプレフィクス/リネーム」機能を使い、展開後の表示名を一意にする。(2)マージを諦めずに、proxy-groups 側で「ベンダ A 専用」「ベンダ B 専用」の select を分け、上位の select でさらに束ねる。後者は画面の階層が増えますが、意思決定の単位が「どの契約の出口を使うか」で区切れるため、家族やチームでURLを分けている場合に追いやすいです。
さらに上のレイヤでは、負荷分散型の load-balance や url-test を使うかどうかで、出口の振る舞いはまったく変わります。複数サブスクを束ねた「あと」をどう遊ばせたいかが決まっていれば、名前衝突の解決策も自然と絞られます。
5. オーバーライドで購読を壊さず追記する
購読 URL の生データを直接編集すると、翌日のアップデートで差分ベンダが上書きし、追加したDOMAIN, 行やローカルだけのグループが消える、という運用トラップに入り込みやすくなります。そこで Clash Verge Rev などによくある Override / Merge(名称はクライアント側)による「上流のブロックとは別レイヤーの追記YAML」が有効です。イメージは、基底が購読由来のリストと自動生成グループであり、その上から自分だけの rules: 断片や、追記したい proxy-groups: を重ねる形です。重ねる順番(マージ順)がクライアントの設定でどう定義されているかは必ず読み、その順で「自分のDOMAINルールが上か下か」を確認してください。上流の広いMATCH が先に当たると、追記側が一生効かない、という話はルール読み順の解説とセットで頭に置くのがよいです。
# Override snippet — personal rules only rules: - DOMAIN-SUFFIX,workspace.example,🚀 ワーク用 - DOMAIN,mybank.example,DIRECT
運用上の鉄則は、「購読が更新されるたびに消えない場所だけに自分専用の差分を置く」です。複数サブスクのマージ作業より先に、この“置き場所”を決めておくだけでも事故はかなり減ります。
6. profiles:シーン別には分け、競合しない動かし方
「1本にまとめたい」一方で、用途が違うからサブスクとルールを混ぜたくない場合は、クライアントのプロファイル切替を積極的に使うのが現実的です。例えば「国内向けの軽いプロファイル」と「海外向けにルールを厚くしたプロファイル」を分け、切り替え時に購読URLの集合までが入れ替わるようにしておくと、YAML 上の名前衝突と心理的重荷の両方を減らせます。旧来の Windows クライアントからの移行でプロファイルの考え方を揃えたい場合は、CFW からの移行ノートもあわせて読むと、設定の持ち方の差分が掴みやすいです。
重要なのは、「プロファイルを分けた=分流が自動で整理される」ではない点です。どのプロファイルでも同じブラウザプロファイルを触るなら、Cookie や DNS キャッシュの観点では依然として一本化された体験になります。シーン分けは設定ファイルの責務の分離であり、利用者の習慣まで自動では切り替わりません。
7. 購読更新後も破綻しない運用ルール
マージやオーバーライドを入れたあとでトラブルが出やすいのが、アップストリームがノード名やグループ名をリネームした瞬間です。ローカルでproxy-groups から特定の文字列を参照していると、更新後に参照切れでコアが起動しない、あるいは静かにフォールバックに落ちる、が起こり得ます。対策としては、(1)参照は可能なら provider 名や安定したエイリアスに寄せる、(2)更新直後にログで欠損名を探す、(3)本番投入前にドライラン相当の文法チェックを挟む、の三段が実務的です。
また、複数URLを足した結果ルールが長大化したときは、rule-providers や外部ルールセットに寄せて整理する余地があります。本稿の主眼は「購読の束ね方」ですが、ここまで来たら「ルールのリポジトリ化」も検討肢に入ります。
本サイトのドキュメントは特定事業者の推奨や違法行為の助長を意図するものではありません。契約・法令・利用規約の範囲で、自己責任で利用してください。
8. まとめ
複数の空港サブスクを扱うとき、mihomo / Clash Meta ではproxy-providers でソースを明示的に区切り、proxy-groups で出口の意思決定を一元化するのが、YAML マージの主戦場です。名前衝突はプレフィクスかグループ階層で潰し、購読更新で消えない追記はオーバーライド(Merge)レイヤに寄せる。用途が水と油ならプロファイルを分けて切り替える、という三層のどれを主に据えるかを決めれば、「合成しても迷子にならない」状態にかなり近づきます。
クライアントとコアは更新が早いので、安定したパッケージから試し、生成された設定の生テキストで突き合わせるのが確実です。まずは → 無料で Clash をダウンロードし、快適な接続体験を試す からどうぞ。
関連記事 · 同じテーマ
トピックの近さで選んだ関連記事 — 同じカテゴリの Clash 実践ガイド。
IPv6 デュアルスタックで Clash TUN が漏れる?OS 遮断と DNS・分流校正(2026)
TUN でも本名が出る二本線を、Happy Eyeballs と DNS 漏えいの切り分けで整理。Windows/macOS/Linux で IPv6 を抑え、mihomo の TUN・DNS・IP-CIDR6 で IPv4 と同じ策略へ着地。rule-providers/Sniffer 稿と補完。
続きを読むClash Meta(mihomo)の external-controller と Secret:Web コンソール(Yacd-meta)と REST をローカル/LAN で安全に開く順序と注意(2026)
管理面の 9090 前後とプロキシ用 mixed-port を分離。mihomo の external-controller/secret/バインドを揃え、Bearer と curl で確認。allow-lan 共有稿はプロキシ口の話で別問題。信頼できない LAN では開かないチェックリスト付き。
続きを読むClash Meta で DNS は fake-ip と redir-host どちら?分流が効かないときの対照と修正手順(2026)
mihomo の dns.enhanced-mode による名前解決とルール評価のズレを整理。モード別の狙い・典型トラブル・debug ログでの確認順、fake-ip-filter/nameserver-policy と Sniffer 稿との関係。ブラウザ DoH 稿・購読ログ稿と補完。
続きを読む