そもそも Clash の YAML は何を表すか

Clash 系のデスクトップや Android クライアントでは、経路選択や転送モードなどの振る舞いをひとつのテキストファイルで宣言します。それが一般的に config.yaml と呼ばれる設定で、GUI が内部で書き換えているのも同じスキーマに沿った YAML です。検索クエリとして「YAML」「プロキシーグループ」「購読」が一緒に並ぶ理由は、このファイルが接続本体・出口戦略・振り分けルール・外部リストの境界面だからです。

Mihomo（旧 Clash.Meta）などコアによって利用できるキーやプロトコル名は増えますが、インデントで階層が決まること、名前参照が文字列一致であること、ルールは上から最初の一行が勝つことは共通の設計思想です。本稿では入門者が躓きやすい構文から、複数ノードを束ねるプロキシーグループ設計までを日本語で一直線に整理します。

YAML 入門：Clash 設定で必ず踏む構文ルール

YAML は人間が読みやすいことを優先したマークアップですが、初見ではエラーメッセージが分かりにくい場合があります。Clash では次の点が特に重要です。

  • インデントはスペースのみ：タブ文字が混ざるとパーサによっては一瞬で失敗します。エディタで「タブをスペースに変換」を有効にしてください。
  • コロンの後にスペース：key: value の形。詰めすぎると別トークンと解釈されます。
  • リストはハイフン＋スペース：proxies: の下に - { name: ... } や短縮形を並べます。ハイフンのインデント階層が一段ずれるとリストの親子が崩れます。
  • 引用符：パスワードや URL に : や # が含まれるときはシングルクォートで囲むと安全です。

アンカー（&）やエイリアス（*）で重複を避ける上級テクニックもありますが、購読生成物と手書きを混ぜる運用では可読性が落ちやすいです。まずはフラットな繰り返しで慣れ、慣れてから共通化を検討するとトラブルが減ります。

ファイル先頭：モード・ポート・ログなど「全体スイッチ」

実装ごとにデフォルト値は違いますが、多くの例で冒頭に並ぶのが port（HTTP プロキシ）、socks-port、mixed-port、mode（rule／global／direct）、log-level、ipv6、TUN や DNS 関連のブロックです。ここは「OS やアプリがクライアントにどう繋ぐか」「DNS を誰に聞くか」といったインフラ寄りの宣言になります。

mode: rule を選ぶと rules 節が有効になり、本稿で後述するプロキシーグループ名がルール右辺にそのまま現れます。global は実質「常に選んでいる出口」に寄せるデバッグ向き、direct はルールを迂回して全直結です。トラブルシュートでモードを切り替えたら、意図せず別プロファイルに戻っていないか GUI の表示も併せて確認してください。

proxies：ノードそのものの列挙

proxies: は個々のサーバ行を配列で並べます。各要素は少なくとも name、type、接続先 server／port、プロトコル固有の鍵（例：cipher、password、uuid）を持ちます。名称 name は後述の proxy-groups から参照されるため、短くても一意で衝突しないことが必須です。

# Example proxy entries (fill with your real nodes)
proxies:
  - name: node-a
    type: ss
    server: example.com
    port: 8388
    cipher: aes-256-gcm
    password: 'your-secret'
  - name: node-b
    type: vmess
    server: edge.example.net
    port: 443
    uuid: 00000000-0000-0000-0000-000000000000
    alterId: 0
    cipher: auto
    tls: true

コアがサポートする type の集合はバージョンで増減します。ドキュメントにない略称をコピーした場合、静かに無視されるのではなく起動時に丸ごと失敗する方が普通です。アップデート後に急に読み込めなくなったときは、リリースノートで廃止されたキー名がないかを最初に疑ってください。

proxy-providers：購読でノード塊を取り込む

手で数十行書くより、プロバイダが配る Clash 互換リストを proxy-providers から取り込む運用が主流です。type: http で URL を指定し、path にローカルキャッシュ、interval で更新間隔を決めます。フィルタや正規表現で表示名を薄くする拡張もありますが、まずは素の購読がそのまま取り込めるかをブラウザとログで確かめるのが近道です。

失敗の多くは「URL が 302 で別形式に飛ぶ」「TLS を企業プロキシが差し替える」「Clash 行ではなくサブリンクだけが返る」といった輸送層の問題です。クライアント内の更新ボタンと、端末ブラウザの直叩き結果を突き合わせると切り分けが速いです。

proxy-groups 入門から実践まで（いわゆる戦略グループ）

日本語コミュニティで「戦略グループ」と呼ばれるものは、ほぼすべて proxy-groups: に相当します。name がアプリのドロップダウンやルールの右辺に露出するラベルになるため、ASCII のままにするか日本語にするかは好みですが、ルール側のスペルと完全に同じ文字列にしてください。

select

利用者が手で選ぶグループです。リストは proxies: にある name の列挙か、別グループへの参照です。シンプルで分かりやすい反面、品質の悪いノードへ張り付いたままになるので、後段で url-test 系と組み合わせる構成が多いです。

url-test／fallback／load-balance

url-test は指定 URL へのレイテンシ計測で自動的に別ノードへ切り替えします。閾値・テスト間隔・ tolerance の意味を理解してから触ると「頻繁に股抜けする／逆に全然切り替わらない」を避けられます。fallback は劣化検知での階段フォールバック、load-balance は分散出口向きと覚えると混乱が減ります（実装差は README 必読）。

relay

複数ホップを順に積むタイプです。遅延は伸びますが、トポロジ上の要件で使うことがあります。ループ参照や名前の綴り間違いは起動拒否につながりやすいので、最小構成で一度通してから本番値に置き換えてください。

# Example proxy-groups (names must match rules on the right side)
proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - AUTO
      - node-a
      - node-b
      - DIRECT
  - name: AUTO
    type: url-test
    proxies:
      - node-a
      - node-b
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50

名前整合の鉄則：rules: の行末に書く PROXY や DIRECT は、ここで宣言した name と一致している必要があります。Proxy と PROXY の大文字小文字違いでもマッチ失敗します。コピペで二重定義したグループが残っていないかも検索で確認してください。

rules との接続：グループ名がここで効く

rules: はトラフィックを条件で分類し、右辺のポリシーへ送ります。右辺が DIRECT や REJECT ならビルトイン、それ以外は proxy-groups の name です。DOMAIN 系・IP 系・GEOIP・RULE-SET・最終 MATCH などの書き方自体は別稿のルーティング解説と合わせて読むと理解が早いですが、YAML 観点ではルール列のインデントとコロン位置が崩れると全体が読めなくなる点に注意してください。

サブブロックである rule-providers を併用する場合、RULE-SET,provider-name,policy の policy にも同じくグループ名が入ります。provider 名とグループ名を取り違えないよう、エディタのハイライトや検索置換で二重チェックすると安全です。

dns: やその他ブロック：ルールと連動させる

高度な運用では dns: ブロックで fake-ip やフォールバック DNS を指定し、ルール評価前の名前解決挙動を制御します。設定が長くなるほど「DNS がプロキシ経由でループする」「国内ドメインまで海外 DNS に飛ぶ」といった症状が出やすく、トラブル時は DNS ログとルールログを同じタイムラインで見る必要があります。入門段階ではクライアント既定に近い最小構成から始め、必要になったキーだけ足す方が学習コスト対効果が高いです。

組み立てのおすすめ順序と典型の落とし穴

実務では次の順が安定しやすいです。(1) トップレベルのポートとモード、(2) proxies か proxy-providers で実体を確定、(3) proxy-groups で UI に出す名前を固定、(4) rules を上から狭い例外→広い集合→MATCH、(5) DNS や TUN を足す。逆に「ルールだけ先に貼って名前は後で考える」と、存在しないグループ名を量産しがちです。

他ツールの設定を丸ごとコピーした際、スキーマの微妙な差で動かないこともあります。たとえば別フォーク専用のキー、廃止済みの旧キー名、コメント記法の違いです。差分は Git で追い、エラーログの行番号を足がかりに最小再現へ削ると原因が見えます。

検証のコツ：まず select 型の単一グループと DIRECT だけで起動し、次に url-test を足し、最後に長大な rules をマージする三段に分けると、どの段で壊れたかが即わかります。

よくある質問

コメントアウトはどう書けばよいですか

行頭の # が一般的です。// 形式は YAML 標準ではないためクライアントによっては単なる文字列になります。# を値の途中に入れたいときは引用符で囲んでください。

同じ name のプロキシを二つ定義してしまいました

後勝ち／先勝ちなど実装依存の挙動になり得ます。重複名は削除し、一覧をソートできるエディタで機械的に検出するのが確実です。

GUI で触ったあとファイルが上書きされました

多くのクライアントは GUI 操作で YAML を再シリアライズします。手書きコメントが消えたりキー順が変わったりするのは仕様に近い挙動です。大切な注釈は別リポジトリや断片ファイルに残し、生成物と分離する運用が安全です。

テキストで持てる設定がもたらすメリット

ワンクリック VPN 型の製品は初期導入は軽い一方、例外ルートや複数端末の同期を後から積み増ししにくいことがあります。社内ドメイン直行、ストリーミングだけ低遅延ノード、開発用ツールだけ別出口——といったきめ細かな方針を、レビュー可能なテキストとして残せるかどうかが長期運用の分かれ目になります。更新が止まったクローズド派生では、新しいプロトコルや provider 形式に追従できず、コピーした YAML がそのままでは解釈されない場面も増えます。

Clash 系スタックは、proxies／proxy-groups／rules が同じ語彙で語られるため、記事で学んだパターンをノートPCとスマホに横展開しやすいのが利点です。GUI のトグルだけでは再現しづらい挙動も、config.yaml の差分なら原因の切り分けが早くなります。利用クライアントを揃えたい場合は 公式のダウンロードページ から入手元を整理し、本稿の順序立てをテンプレートに書き換えて試すと学習曲線がなだらかです。

公式経路から Clash を入手し、YAML ベースの設定を始める →