なぜ YAML 設定を理解する必要があるのか

Clash クライアント（Mihomo コアを含む）の動作は、すべて .yaml 形式の設定ファイルによって制御されます。グラフィカルクライアントでサブスクリプションをインポートするだけでも動作しますが、接続が不安定になったり特定サイトだけ開けないとき、設定の中身を読めないと原因の切り分けができません。特にプロキシノード（proxies）、ポリシーグループ（proxy-groups）、ルールセット（rule-providers）の三つは、ノードの中身・選択ロジック・分流判断を担う中核であり、この構造を理解すれば「なぜこのサイトだけ遅いのか」「なぜ自動選択が意図しないノードを選ぶのか」を自分で解決できるようになります。

本記事は、YAML をゼロから書きたい上級ユーザーだけでなく、サブスクリプションを使いながら設定の意味を把握したい中級ユーザーにも向けています。インストールやサブスクリプション手順がまだの方は、先に Clash Verge Rev インストール・設定チュートリアル をご覧ください。分流ルールの詳細は ルールベース分流の詳細解析 で深掘りできます。

対象コア：本記事の構文例は Mihomo（旧 Clash Meta）を前提としています。レガシー Clash コアでは rule-providers や一部プロトコル（Hysteria2、TUIC など）が使えない場合があります。クライアントのコアバージョンは設定画面またはログで確認してください。

設定ファイルの基本構造

典型的な Clash 設定ファイルは、大きく分けて以下のブロックで構成されます。上から順に読むと「ノード → グループ → ルールソース → 分流ルール → DNS・その他」の流れが把握しやすくなります。

フィールド名 役割 必須か
proxies 個別プロキシノードの定義リスト ノードを直接書く場合は必須
proxy-providers 外部ソースからノードを取得・更新 サブスクリプション運用では一般的
proxy-groups ノードの選択・自動切替・負荷分散 実質必須
rule-providers 外部ルールセット（ドメイン/IP リスト）の参照 大規模分流では推奨
rules トラフィックをどのポリシーへ送るかの順序付きリスト ルールモード利用時は必須
dns / listeners など 名前解決、入站リスナー、TUN 関連設定 環境に応じて追加

YAML はインデント（通常スペース2つ）で階層を表します。タブ文字は使わず、コロン（:）の後にスペースを入れるのが基本です。1文字のインデントミスでもファイル全体が読み込めなくなるため、エディタの YAML 検証機能やクライアントの設定プレビューを活用してください。 

# Minimal skeleton
mixed-port: 7890
mode: rule

proxies:
  - name: "example-node"
    type: ss
    server: 1.2.3.4
    port: 8388
    cipher: aes-256-gcm
    password: "your-password"

proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - example-node
      - DIRECT

rules:
  - MATCH,PROXY

プロキシノード（proxies）：接続先の定義

proxies 配列の各エントリが、1つのプロキシノードに相当します。最低限必要なフィールドは name（クライアントに表示される名前）、type（プロトコル種別）、server、port です。プロトコルごとに追加パラメータ（暗号方式、UUID、TLS 設定など）が異なります。

よく使うプロトコルと記述例

proxies:
  # Shadowsocks
  - name: "JP-SS-01"
    type: ss
    server: jp.example.com
    port: 443
    cipher: aes-256-gcm
    password: "ss-password"
    udp: true

  # Trojan
  - name: "US-Trojan-01"
    type: trojan
    server: us.example.com
    port: 443
    password: "trojan-password"
    sni: us.example.com
    skip-cert-verify: false

  # VMess (V2Ray)
  - name: "HK-VMess-01"
    type: vmess
    server: hk.example.com
    port: 443
    uuid: "00000000-0000-0000-0000-000000000001"
    alterId: 0
    cipher: auto
    tls: true
    network: ws
    ws-opts:
      path: /path
      headers:
        Host: hk.example.com

  # Hysteria2 (Mihomo)
  - name: "SG-HY2-01"
    type: hysteria2
    server: sg.example.com
    port: 443
    password: "hy2-password"
    sni: sg.example.com

name は後述の proxy-groups から参照される識別子です。日本語や絵文字も使えますが、ルールやスクリプト連携では英数字の方が安全です。同一設定内で名前の重複は禁止され、大文字小文字も区別されます。

proxy-providers：サブスクリプションからノードを取得

ノード数が多いプロバイダでは、proxies を直接書かず proxy-providers でリモート YAML を定期取得する構成が一般的です。設定ファイル本体は軽量なまま、ノードの増減を自動追従できます。 

proxy-providers:
  airport:
    type: http
    url: "https://example.com/sub/clash.yaml"
    path: ./providers/airport.yaml
    interval: 3600
    health-check:
      enable: true
      interval: 600
      url: http://www.gstatic.com/generate_204

proxy-groups:
  - name: 自動選択
    type: url-test
    use:
      - airport
    url: http://www.gstatic.com/generate_204
    interval: 300
health-check を有効にすると、不通ノードをグループ選択から外しやすくなります。ただしチェック URL や間隔を短くしすぎると、プロバイダ側のレート制限やローカル CPU 負荷が増えます。interval: 3600（1時間）程度から始めるのが無難です。

ポリシーグループ（proxy-groups）：ノード選択の中枢

ルールが「このトラフィックを PROXY へ」と指示しても、実際にどのノードへ接続するかは proxy-groups が決めます。グループ名（name）は rules の第3列から参照されるため、PROXY、自動選択、ストリーミング など、ルールと一致する命名が重要です。

select：手動選択

最もシンプルなタイプで、クライアントの「プロキシ」画面でユーザーがノードを選びます。メインの「ノード選択」グループに適しています。 

proxy-groups:
  - name: ノード選択
    type: select
    proxies:
      - JP-SS-01
      - US-Trojan-01
      - HK-VMess-01
      - DIRECT

url-test：遅延に基づく自動選択

指定 URL への接続遅延を定期的に測定し、最速ノードを自動で選びます。「自動選択」「Auto」グループでよく使われます。url と interval（秒）が必須です。 

  - name: 自動選択
    type: url-test
    proxies:
      - JP-SS-01
      - US-Trojan-01
      - HK-VMess-01
    url: http://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50

tolerance は、現ノードと新ノードの遅延差がこの値（ミリ秒）未満なら切り替えを抑制します。頻繁なノード切替によるセッション切断を防ぐのに有効です。

fallback：順次フォールバック

リスト先頭から順に疎通確認し、最初に成功したノードを使います。メインノード＋複数バックアップという運用に向いています。 

  - name: 故障転送
    type: fallback
    proxies:
      - HK-VMess-01
      - JP-SS-01
      - US-Trojan-01
    url: http://www.gstatic.com/generate_204
    interval: 300

load-balance：負荷分散

複数ノードへ接続を分散します。strategy に consistent-hashing（同一宛先は同一ノード）や round-robin を指定できます。ダウンロードやクロール用途で使われることがありますが、日常ブラウジングでは select や url-test の方が一般的です。

ネスト（グループの中にグループ）

proxies リストに別のグループ名を書くことで階層構造を作れます。例えば「ストリーミング」グループの下に地域別サブグループを置き、ルールからは常に ストリーミング だけを参照する、といった設計が可能です。 

  - name: ストリーミング
    type: select
    proxies:
      - 自動選択
      - ノード選択
      - DIRECT
循環参照に注意：グループ A がグループ B を参照し、B が再び A を参照するようなループは設定エラーになります。また、rules で参照するグループ名が proxy-groups に存在しないと、該当トラフィックはマッチ失敗します。

ルールセット（rule-providers）：大規模分流の基盤

数万件のドメインを rules に手書きするのは現実的ではありません。rule-providers は外部のルールファイル（テキストまたは YAML）を読み込み、rules から RULE-SET,プロバイダ名,ポリシー 形式で参照します。国内直結・GFW リスト・広告ブロックなど、カテゴリ別に管理する標準的な方法です。 

rule-providers:
  reject:
    type: http
    behavior: domain
    url: "https://cdn.jsdelivr.net/gh/Loyalsoldier/clash-rules@release/reject.txt"
    path: ./ruleset/reject.yaml
    interval: 86400

  gfw:
    type: http
    behavior: domain
    url: "https://cdn.jsdelivr.net/gh/Loyalsoldier/clash-rules@release/gfw.txt"
    path: ./ruleset/gfw.yaml
    interval: 86400

  cn:
    type: http
    behavior: domain
    url: "https://cdn.jsdelivr.net/gh/Loyalsoldier/clash-rules@release/cn.txt"
    path: ./ruleset/cn.yaml
    interval: 86400

主要フィールドの意味

  • type：http はリモート取得、file はローカルファイル参照。オフライン環境では file が有効です。
  • behavior：domain（ドメインリスト）、ipcidr（IP 範囲）、classical（従来のルール行形式）のいずれか。
  • path：取得したルールのキャッシュ保存先。初回起動時に自動作成されます。
  • interval：自動更新間隔（秒）。86400 は1日1回更新。

コミュニティで広く使われる Loyalsoldier/clash-rules は、cn（国内）、gfw（要プロキシ）、reject（広告）などに分類済みで、Mihomo との相性も良好です。プロバイダのサブスクリプションには同様の構成が組み込まれていることが多く、自作する場合のテンプレートとしても参考になります。

rules との接続

rule-providers を宣言しただけでは分流されません。rules リストで明示的に呼び出す必要があります。ルールは上から順に評価され、最初にマッチした時点で処理が確定します。 

rules:
  - DOMAIN-SUFFIX,local,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - RULE-SET,reject,REJECT
  - RULE-SET,gfw,PROXY
  - RULE-SET,cn,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

ここでの PROXY は組み込みキーワードではなく、前述の proxy-groups 内のグループ名を指します。ルールセットで「プロキシが必要」と判定されたトラフィックは、PROXY グループ（多くの場合「ノード選択」や「自動選択」へのエイリアス）を経由して実際のノードへ接続されます。

三大核心の連携：データの流れを追う

実際の接続が成立するまでの流れを整理すると、三大核心の関係が明確になります。

  1. アプリが example.com へ接続を開始する。
  2. rules が上から照合され、RULE-SET,gfw,PROXY などにマッチする。
  3. マッチ先の PROXY は proxy-groups のグループ名。例えば url-test 型の「自動選択」なら遅延最小ノードが選ばれる。
  4. 選ばれたノード名が proxies または proxy-providers 由来のエントリと一致し、実際の server・port へトンネルが張られる。

この連鎖のどこか一つでも名前の不一致や構文エラーがあると、「ルールは当たっているのに接続できない」「自動選択が空になる」といった症状が出ます。トラブル時はクライアントのログで rule matched と実際に使われたノード名を照合するのが近道です。

実践：ミニマムから実用までの完全例

以下は、単一ノード＋ルールセット＋自動選択を組み合わせた、学習用の実用サンプルです。本番ではパスワードやサーバー情報を実環境の値に置き換えてください。 

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

dns:
  enable: true
  enhanced-mode: fake-ip
  nameserver:
    - 223.5.5.5
    - 8.8.8.8

proxies:
  - name: "MyNode"
    type: trojan
    server: node.example.com
    port: 443
    password: "secret"
    sni: node.example.com

proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - 自動選択
      - MyNode
      - DIRECT
  - name: 自動選択
    type: url-test
    proxies:
      - MyNode
    url: http://www.gstatic.com/generate_204
    interval: 300

rule-providers:
  gfw:
    type: http
    behavior: domain
    url: "https://cdn.jsdelivr.net/gh/Loyalsoldier/clash-rules@release/gfw.txt"
    path: ./ruleset/gfw.yaml
    interval: 86400
  cn:
    type: http
    behavior: domain
    url: "https://cdn.jsdelivr.net/gh/Loyalsoldier/clash-rules@release/cn.txt"
    path: ./ruleset/cn.yaml
    interval: 86400

rules:
  - IP-CIDR,127.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - RULE-SET,gfw,PROXY
  - RULE-SET,cn,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

よくある設定ミスと対処法

  • インデント崩れ：YAML パーサーがファイル全体を拒否します。変更後は必ずクライアントで再読み込みし、エラーメッセージの行番号を確認してください。
  • グループ名の typo：rules の PROXY と proxy-groups の name が1文字でも違うと参照できません。
  • rule-providers だけ宣言して rules に未使用：ルールセットはダウンロードされても分流に参加しません。RULE-SET,名前,ポリシー 行を追加してください。
  • MATCH の位置：MATCH は必ず rules の最後に置きます。途中にあると以降のルールが無視されます。
  • プロバイダサブスクリプションの直接編集：リモート YAML は更新で上書きされます。カスタムは Merge（上書き）で行い、本体は触らない運用が安全です。

よくある質問

proxies と proxy-providers は併用できますか？

はい。proxy-groups の proxies リストに直接ノード名を書き、use でプロバイダを参照する、という混在構成が可能です。自作のテストノードを1つ足しつつ、残りはサブスクリプションから取得する、といった使い方に適しています。

ルールセットなしで GEOIP だけ使えますか？

可能ですが、精度と初回接続速度は劣ります。海外ドメインが国内 CDN に解決されるケースなど、GeoIP だけでは誤判定しやすいです。rule-providers と GEOIP の併用が現在の主流です。

設定を変更したのに反映されない

サブスクリプションの自動更新がローカル編集を上書きしていないか確認してください。グラフィカルクライアントでは「設定の再読み込み」またはアプリ再起動が必要な場合があります。Merge ファイルの構文エラーがあると、マージ結果全体が無効になることもあります。

多くの商用 VPN クライアントは設定を公開しておらず、ノード切替や分流のカスタマイズができません。一方、サブスクリプション変換サービスに依存する方法は、変換ルールの品質次第でプロトコル互換やルールの鮮度にばらつきが出ます。Clash の YAML 方式なら、proxies・proxy-groups・rule-providers の三層がすべて可視化され、Mihomo コアの継続的なプロトコル対応（Hysteria2、TUIC など）と組み合わせて、自分のネットワーク環境に合わせたチューニングが可能です。設定ファイルを毎回ゼロから書きたくない場合でも、当サイトの クライアントダウンロードページ から入手できる Clash クライアントは、サブスクリプション取り込みとルールテンプレートが統合されており、YAML の構造を理解しながら実運用へスムーズに移行できます。

今すぐ Clash を無料でダウンロードし、YAML 設定を実践で学びましょう →