Clash設定ファイルのYAML構造を読み解く：基本フィールドからルールセクションまでの完全ガイド

まず構造を読む：YAMLの順序と設定の依存関係は別のもの

Clash、Clash Meta、および後継のmihomoカーネルでは、通常YAMLファイルで動作パラメータを記述します。完全な設定には、リスニングポート、動作モード、DNS、プロキシノード、プロキシグループ、ルールセット、トラフィック嗅探などが含まれる場合があります。YAMLのマッピング自体は、記述順によって処理上の優先度を表しません。そのため、rulesをファイルの前方に記述しても、ポート設定より先にルールが適用されるわけではありません。

実際のトラブルシューティングでは、依存関係に沿って読むのがおすすめです。まず基本のリスニング設定と動作モードを確認し、次にDNS、続いてノードの取得元とプロキシグループの参照関係、最後にルールがリクエストをどのプロキシグループへ送るかを確認します。この順序はYAMLパーサーが強制する読み込み順ではなく、問題を見つけやすくする確認手順です。

基本フィールドは、クライアントがローカルのトラフィックをどのように待ち受け、ルール、グローバル、または直接接続のどのモードを使うかを決めます。
DNSフィールドは、ドメイン問い合わせの入口、上流サーバー、Fake-IPのマッピング方式を決めます。
proxiesとproxy-providersが利用可能なプロキシノードを提供します。
proxy-groupsはノードや他のプロキシグループをまとめ、選択可能な出口を構成します。
rule-providersがリモートのルールコレクションを提供し、rulesが最終的なマッチング順を決めます。

基本フィールド：ポート、LANアクセス、動作モード

基本セクションは通常ファイルの先頭に置き、クライアントがどの入口を開いているかをすぐ確認できるようにします。クライアントによっては、これらの一部をGUIから上書きするため、ファイル内の値が実行時の最終値と一致するとは限りません。問題を確認するときは、設定ファイルとクライアントの現在のステータス画面を併せて確認してください。

mixed-port: 7890
allow-lan: false
bind-address: "*"
mode: rule
log-level: info
ipv6: false
external-controller: 127.0.0.1:9090

mixed-portはHTTPとSOCKSのプロキシ接続を同時に受け付けるため、ローカルプロキシポートを1つだけ設定したい場合に適しています。設定によってはportとsocks-portを分けて使うこともあります。同じ種類の入口を競合する複数のポートで重複して開く必要はありません。ポートが他のプログラムに使用されている場合、カーネルがリスニングを開始できないことがあります。

allow-lanは、LAN内のデバイスが本機のプロキシポートへ接続できるかどうかを制御します。trueに設定した場合は、システムのファイアウォールとリスニングアドレスも確認してください。bind-addressは待ち受けるネットワークインターフェースの範囲を決めますが、実際の挙動はカーネルのバージョンに依存します。本機だけで使う場合は、LANアクセスを無効にしておくほうが入口を管理しやすくなります。

modeでよく使われる値はrule、global、directです。ルールモードはrulesを順番に照合し、グローバルモードはトラフィックをグローバルプロキシグループへ渡し、直接接続モードはプロキシを経由しません。GUIクライアントのモード切り替えは実行時設定を直接変更することが多く、サブスクリプションファイルへ書き戻されるとは限りません。

フィールド	主な役割	確認ポイント
`mixed-port`	HTTPとSOCKSのプロキシ接続を受け付ける	ポートが使用中でないか、アプリが同じポートを指定しているか
`allow-lan`	LAN内デバイスの接続を許可または拒否する	リスニングアドレス、ファイアウォール、デバイスが属するネットワーク
`mode`	ルール、グローバル、直接接続のモードを選択する	クライアントの実行状態がファイルの値を上書きしていないか
`log-level`	ログの詳細度を設定する	DNS、ルール、接続情報をトラブルシューティング時に確認できるか

DNSセクション：問い合わせ入口、上流サーバー、Fake-IPマッピング

DNS設定は、単なるサーバーアドレスの一覧ではありません。内蔵DNSを有効にすると、カーネルはリスニング入口、名前解決モード、デフォルトの名前解決サーバー、実際の上流サーバーを決める必要があります。TUNでトラフィックを接管する場合は、DNSハイジャックとルーティング設定によって、リクエストがカーネルへ入るかどうかも変わります。

dns:
  enable: true
  listen: 0.0.0.0:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "localhost.ptlogin2.qq.com"
  default-nameserver:
    - 223.5.5.5
    - 1.1.1.1
  nameserver:
    - https://dns.alidns.com/dns-query
    - https://1.1.1.1/dns-query

default-nameserverは主に、暗号化DNSの上流サーバー自体のドメイン名を解決するために使われ、通常は直接アクセスできるIPアドレスを指定します。nameserverは通常のドメイン問い合わせを担います。mihomoの設定によっては、proxy-server-nameserverでプロキシサーバーのドメイン名を専用に解決したり、nameserver-policyで指定ドメインごとに異なる上流サーバーを選択したりできます。

enhanced-mode: fake-ipでは、まずドメインに仮想アドレスを割り当て、接続時にドメイン情報を復元してルールを照合します。これにより、アプリが独自に名前解決することによるマッチングのずれを減らせます。LAN内のホスト名、一部のデバイス検出プロトコル、特定のゲーム、または実アドレスの応答を必要とするドメインでは、fake-ip-filterへの追加が必要になる場合があります。除外ルールは実際に問題がある対象だけに絞り、広範囲のドメインをすべて除外するのは避けてください。

プロキシノードとプロキシグループ：まずメンバーを定義し、次に出口を構成する

proxiesには、ファイルへ直接記述したノードを保存します。各ノードには少なくとも、名称、プロトコル種別、サーバーアドレス、ポート、そしてプロトコルが要求する認証パラメータが必要です。プロトコルごとにフィールドは大きく異なるため、あるプロトコルのパラメータを別のプロトコルへそのままコピーすることはできません。サブスクリプション変換ツールが生成したノードも、カーネルが実際にサポートするフィールドを基準に確認してください。

proxies:
  - name: "ノード A"
    type: socks5
    server: proxy.example.com
    port: 1080
    username: account
    password: passphrase
    udp: true

proxy-groups:
  - name: "ノード選択"
    type: select
    proxies:
      - "自動速度テスト"
      - "ノード A"
      - DIRECT

  - name: "自動速度テスト"
    type: url-test
    proxies:
      - "ノード A"
    url: https://www.gstatic.com/generate_204
    interval: 300

名称は参照キーです。プロキシグループ内のノード Aは、スペース、大文字・小文字、全角記号を含め、ノード名と完全に一致しなければなりません。プロキシグループは別のプロキシグループを参照することもできるため、先に「自動速度テスト」を作成し、それを「ノード選択」のメンバーにできます。参照が循環すると、カーネルは有効な出口を取得できないため、階層を見直してください。

selectはユーザーがメンバーを手動で選択します。url-testはテスト結果に基づき、遅延の低い利用可能なノードを自動選択します。fallbackは順番に利用可能なメンバーを選ぶ方式です。load-balanceは指定した方式に従って複数のメンバーへ接続を分散します。遅延テスト用URLは利用可否と応答時間を測るためのもので、すべての対象サイトで実際に高速であることを示すものではありません。

DIRECT、REJECTなどは組み込みアクションなので、proxiesで重複して定義する必要はありません。DIRECTは直接接続、REJECTは接続拒否を意味します。ルールのターゲットからこれらのアクションを直接指定することもできますが、よく使う出口をプロキシグループにまとめておくと、通常はクライアント上で切り替えやすくなります。

ルールセクション：上から順に照合し、最初に一致した結果を適用

YAMLのトップレベルマッピングとは異なり、rulesは順序を持つリストです。カーネルは通常、先頭から確認し、一致すると後続の照合を停止します。そのため、具体的なルールを広範囲なルールより前に置き、フォールバックルールを末尾に配置します。MATCHを前方へ移動すると、後続のドメインルールやIPルールが機能しなくなります。

rules:
  - DOMAIN,example.com,DIRECT
  - DOMAIN-SUFFIX,example.org,ノード選択
  - DOMAIN-KEYWORD,media,ノード選択
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,ノード選択

DOMAINは完全一致のドメインを照合し、DOMAIN-SUFFIXは指定ドメインとそのサブドメインを照合します。DOMAIN-KEYWORDはキーワードで照合するため、通常はより広い範囲に適用されます。IP-CIDRは対象IPのネットワーク範囲に適用され、no-resolveを付けると、このルールを照合するための追加のドメイン解決を避けられます。ただし、接続コンテキストに対象IPがすでに存在する場合に限り、直接判定できます。

GEOIPは地理データベースを使ってIPを分類します。mihomoはGeoSite、ルールコレクション、その他のルールタイプにも対応していますが、利用可否はカーネルのバージョン、データベースファイル、設定方法によって異なります。ルールのターゲットは、存在するプロキシグループ、ノード名、または組み込みアクションでなければなりません。ログにプロキシが見つからないと表示された場合は、まずルールの末尾とproxy-groupsの名称を確認してください。

ルールモードは出口を選択するだけで、すべてのデバイスのトラフィックを自動的にClashへ送るものではありません。ブラウザーやシステムでシステムプロキシを使用するか、TUN仮想ネットワークインターフェースでトラフィックを接管する必要があります。「ルールが反映されない」場合は、まず接続がクライアントのログに出ているかを確認してください。ログに対象接続がまったくないなら、ルールの順番ではなくトラフィックの入口を確認するのが先です。

リモートコレクション：proxy-providersとrule-providers

ノード数が多い場合は、proxy-providersを使ってリモートURLやローカルファイルからノードコレクションを読み込み、プロキシグループからuseで参照できます。ルールコレクションはrule-providersで定義し、rules内でRULE-SETを使って呼び出します。名称は似ていますが、提供するデータの種類が異なるため、互いに置き換えることはできません。

proxy-providers:
  provider-main:
    type: http
    url: https://sub.example.com/profile.yaml
    path: ./providers/provider-main.yaml
    interval: 3600
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 300

proxy-groups:
  - name: "サブスクリプションノード"
    type: select
    use:
      - provider-main

rule-providers:
  private-network:
    type: http
    behavior: ipcidr
    format: yaml
    path: ./rules/private-network.yaml
    url: https://rules.example.com/private-network.yaml
    interval: 86400

rules:
  - RULE-SET,private-network,DIRECT
  - MATCH,サブスクリプションノード

pathは、リモートコンテンツをダウンロードした後のローカル保存先です。実行環境では、カーネルが該当ディレクトリへ書き込める必要があります。intervalは通常秒単位で、更新間隔を表します。ヘルスチェックの間隔とサブスクリプション更新の間隔は別々の設定です。ヘルスチェックは既存ノードをテストするだけで、サブスクリプション更新の代わりにはなりません。

ルールプロバイダーのbehaviorは、ドメインコレクション、IPネットワーク範囲のコレクション、クラシックルール形式など、コンテンツの構造に対応していなければなりません。mihomoのバージョンによって、format、バイナリルールセット、behaviorタイプのサポートが異なる場合があります。リモートルールの読み込みに失敗したときは、ログに表示されるダウンロード状態、ファイル形式、解析エラーを確認し、ブラウザーでURLを開けるかどうかだけで判断しないでください。

インデント、引用符、YAMLの型：最も起こりやすい解析エラーの境界

YAMLではインデントで階層を表現します。空白を統一して使い、タブを混在させないでください。同じ階層のフィールドは同じインデントにそろえ、リスト項目にはハイフンを使います。次の2つの記述は似ていますが、2つ目ではenableがdnsの外側に置かれており、意味が変わっています。

dns:
  enable: true
  enhanced-mode: fake-ip

dns:
enable: true
enhanced-mode: fake-ip

コロン、シャープ記号、前後の空白を含む文字列や、真偽値として解釈されやすい文字列には引用符を使うのが適切です。ノード名とプロキシグループ名は一致していれば、日本語を使用できます。ポートは数値、スイッチはtrueまたはfalseで記述し、すべての値を文字列にしないでください。文字列形式を許容するフィールドもありますが、型の互換性はカーネルのドキュメントとエラーログを基準に確認してください。

YAMLのアンカーとエイリアスを使うと重複設定を減らせますが、複雑なサブスクリプションは、クライアントによる上書き、形式変換、再エクスポートの後にアンカー構造が展開されることがあります。手動で管理するファイルでは慎重に使用してください。サブスクリプション変換を頻繁に通す場合は、重要なフィールドを明示的に記述したほうが問題を切り分けやすくなります。

フィールドの上書き関係と完全な確認手順

実行時の設定は、リモートサブスクリプションの原文、クライアントのローカル上書き、GUIでの一時的な選択、カーネルの起動パラメータなど、複数の階層から構成される場合があります。最終的な適用値は、クライアントがこれらのソースをどのようにマージするかによって決まります。同じフィールドが複数回定義されている場合は、ファイル上の位置だけで結果を推測せず、クライアントが生成した最終設定または実行状態を確認してください。

プロキシグループの現在の選択は、通常クライアントまたはカーネルのキャッシュに保存されます。サブスクリプション更新後も、グループ名とメンバー関係が利用可能であれば、以前の選択が維持される場合があります。ノード名が変更されたり削除されたりすると、クライアントはグループ内の別のメンバーへ切り替えることがあります。ルールの更新だけではノードが利用可能だとは限らず、ノードのヘルスチェックに成功してもルールのターゲットが正しいとは限りません。

YAML構文を検証：インデント、コロン、リスト記号、引用符が正しいか確認し、まず解析不能な問題を除外します。
ローカルの入口を確認：mixed-port、システムプロキシ、TUNの状態を確認し、対象の接続がログに入っているかを確認します。
DNS経路を確認：問い合わせがカーネルに受信され、上流へ到達でき、Fake-IPの除外範囲が適切かを確認します。
ノードの取得元を確認：静的ノードまたはプロキシプロバイダーが正常に読み込まれ、サーバーのドメイン名を解決できるか確認します。
名称の参照関係を確認：ルールのターゲットからプロキシグループをたどり、さらにノードまたはプロバイダーまで確認します。
ルールの順序を確認：具体的なルールを前に、広範囲なルールを後ろに置き、末尾には明確なフォールバックを残します。
実行時の上書きを確認：クライアントのGUIで選択したモード、ポート、プロキシグループが、想定した設定を上書きしていないか確認します。

読み込み、トラフィックの接管、名前解決、出口の選択まで可能になって初めて、設定は完全なチェーンを形成します。障害が発生したら、「入口 → DNS → ノード → プロキシグループ → ルール → 出口」の順に各段階を確認すると、一度に複数のフィールドを変更するより原因を特定しやすくなります。毎回1つの要素だけを調整し、ログで結果を検証すれば、構文、ネットワーク、ルールの問題が互いに影響するのを防げます。