Clash設定ファイルのYAML構造を解説：ポート、proxies、proxy-groups、rulesの読み方

まずは全体像：入口、名前解決、ノード、ポリシー、ルール

Clashの設定ファイルを開いても、先頭から最後まで順に推測する必要はありません。まずはトップレベルの項目を確認しましょう。mixed-portはアプリの接続先ポート、dnsは内蔵DNSによる名前解決、proxiesはノード、proxy-groupsは選択可能な出口、rulesは接続ごとの処理先を設定します。この5つを理解すれば、「設定を読み込めること」と「接続が意図どおりに転送されること」は別だと分かります。

典型的な参照の流れは、ルールがポリシーグループを選び、そのグループがノードを選択する形です。ルールの宛先がDIRECTなら、リモートプロキシノードを経由せず直接接続します。トップレベル項目の並び順は通常、処理順に影響しません。一方、rulesのリストは上から順に評価されるため、順序によってマッチ結果が変わります。

設定項目	役割	優先して確認する点
`mixed-port`	HTTP／SOCKS5プロキシ接続を受け付ける	ポートの競合、アプリに設定した接続先
`dns`	内蔵DNSと拡張モード	有効化の有無、リクエストがコアに届いているか
`proxies`	リモートノードへの接続パラメーター	プロトコル、アドレス、ポート、認証情報
`proxy-groups`	出口を選択・テストする	名前の参照、現在の選択項目
`rules`	条件に応じて接続を振り分ける	マッチ順序、最後に適用するフォールバックポリシー

YAMLの書き方：まずインデント、次に項目の意味を確認

YAMLではインデントで階層を表します。半角スペース2つに統一し、タブは使わないでください。同じ階層の項目は左端をそろえ、リスト項目はハイフンとスペースで始めます。拡張子は.yamlまたは.ymlを使えますが、ファイル名の拡張子を変えても構文エラーは直りません。

proxy-groups:
  - name: "出口選択"
    type: select
    proxies:
      - DIRECT

この設定には、異なる場所で使われる2つの概念があります。トップレベルのproxy-groupsはポリシーグループのリストです。グループ内のproxiesは選択肢となる名前のリストであり、ノードの接続パラメーター一式ではありません。name、type、グループ内のproxiesは同じオブジェクトに属するため、インデントをそろえます。

エディターで確認したい4つのポイント

コロンの後のスペース：mode: ruleのように記述し、キーと値を詰めて書かないでください。
真偽値：allow-lan: falseには真偽値を指定します。falseを引用符で囲む必要はありません。
特殊文字を含む文字列：ノード名やパスワード、#を含む値は、コメントなどの構文として誤認されないよう引用符で囲むのがおすすめです。
キーの重複：ファイル末尾にトップレベルのdnsやrulesを重ねて追加しないでください。パーサーによっては読み込みを拒否したり、先に指定した値を上書きしたりします。

構文エラーでは行番号が示されても、原因が直前の行にあることがあります。たとえばリストのインデントがスペース2つ分足りないと、次の項目でエラーが報告される場合があります。エラー行を確認したうえで、直前の項目やリスト構造もさかのぼって確認しましょう。

トップレベルの設定：mixed-port、allow-lan、mode

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

mixed-port: 7890は、同じ待ち受けポートでHTTPとSOCKS5のプロキシ接続を受け付ける設定です。自分の端末だけで使う場合は、アプリの接続先にアドレス127.0.0.1、ポート7890を指定します。ポート番号に固定の決まりはありません。ログにaddress already in useと表示された場合は、別のクライアントやプログラムがポートを使用していないか確認してください。

allow-lan: falseは、LAN内の端末からこのプロキシ入口への接続を制限します。共有する場合は、この項目だけでなく、待ち受けアドレス、OSのファイアウォール、現在のネットワークが信頼できるかも確認してください。端末内の接続問題を調べるために、すべての受信制限を解除するのは避けましょう。

3つのモードとrulesの関係

rule：ルールリストに従って出口を決定します。ルーティング設定の動作確認に適しています。
global：グローバルポリシーで出口を選択します。通常のルールリストを1件ずつ評価して振り分ける方式ではありません。
direct：接続は直接通信します。このモードでは、プロキシルールを変更しても期待した変化が見られないことがあります。

log-level: infoは、接続状況やエラーを日常的に確認するのに適しています。トラブル調査中は一時的にdebugへ変更し、終わったらログが増えすぎないよう元に戻してください。ipv6: falseはこの記事の初期設定での選択であり、すべてのネットワークでIPv6を無効にすべきという意味ではありません。IPv6を使う場合は、DNSの応答、システムのルーティング、ノードの対応状況をあわせて確認しましょう。

dnsセクション：DNSの有効化と拡張モードの選択

dnsは入れ子になったオブジェクトです。まず内蔵DNSを有効にするか決めてから、enhanced-modeを検討します。以下は一般的な構造を示す例で、項目間の関係が分かりやすいよう従来型のIPアドレスを上流DNSに使っています。あらゆるネットワーク環境に推奨する設定ではありません。

dns:
  enable: true
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - 223.5.5.5
    - 119.29.29.29

nameserverは上流DNSサーバーのリストです。ここで指定する通常のIPアドレスの上流サーバーは、一般に従来型のDNS通信を使います。DoH、DoT、より細かなDNS振り分けを使う場合は、コアの対応状況と上流サーバーへの到達性を確認してください。トップレベルのipv6とdns.ipv6は同じスイッチではありません。後者は主に、内蔵DNSがAAAAクエリをどう処理するかを制御します。

fake-ipは、対象となるドメインに合成アドレスを返します。コアはアドレスとドメインの対応を保持し、接続時にドメインに応じて通信を処理します。198.18.0.1/16はベンチマーク用に予約されたアドレス範囲です。ノードのパブリックIPアドレスではないため、ノードのserverには指定しないでください。

dnsを設定しても、システムの名前解決が変わらないのはなぜ？

enable: trueで有効になるのは内蔵DNS機能だけであり、システム全体のDNSリクエストが必ずそこを通るわけではありません。プロキシプロトコルでドメイン名を渡す場合、システムが直接ドメインを解決する場合、TUNとDNSハイジャックを組み合わせる場合では、通信経路が異なります。まずアプリがどの経路を使っているかを確認し、クライアント側で対応するDNS制御が設定されているか調べましょう。

LAN内の名前解決、ゲーム、デバイス検出に問題がある場合は、必要に応じてfake-ip-filterを設定し、特定のドメインには合成アドレスを使わないようにできます。出所の分からないフィルター項目を大量にコピーするのは避けてください。フィルター適用後の実際のDNS応答と、その後のルーティングも確認が必要です。

proxiesとproxy-groups：ノードの接続情報と出口名を分けて理解する

トップレベルのproxiesにはノードオブジェクトを記述します。各オブジェクトには、参照に使うnameが少なくとも1つ必要です。その他の必須項目はプロトコルによって異なります。たとえばShadowsocksノードでは通常、type、server、port、cipher、passwordが必要です。ほかのプロトコルではUUID、TLS、トランスポート層などの設定が必要な場合もあります。あるプロトコルの項目一覧を、別のプロトコルにそのまま当てはめないでください。

ノードの接続情報は、実際のサービス設定または信頼できるサブスクリプションから取得してください。この記事では実在しないサーバーや認証情報は掲載しません。後半の完全な設定例ではproxies: []として、ノードリストを空にしています。これならYAML、待ち受けポート、ルールからの参照を先に検証でき、見た目だけ整って実際には接続できないノードを使わずに済みます。

proxies: []

proxy-groups:
  - name: "出口選択"
    type: select
    proxies:
      - DIRECT

selectは手動選択用のグループです。グループ名の「出口選択」はルールから参照する宛先となり、グループ内には現在、組み込みのDIRECTだけが登録されています。実際のノードを追加する場合は、まずトップレベルのノードリストに完全なノードオブジェクトを登録し、そのnameをグループ内のリストにそのまま追加してください。スペース、大文字・小文字、記号も一致させる必要があります。ノード名だけを追加しても、ノード自体は作成されません。

自動速度測定グループには何が必要？

url-testなどのグループタイプでは、速度測定先のURLや測定間隔なども設定します。測定結果は特定のテストリクエストに対する結果であり、すべてのサイトにアクセスできることや、実際のダウンロード速度を保証するものではありません。設定の読み方を学び始めた段階では、まずselectで各出口を確認してから、自動選択を追加するのがおすすめです。

rulesセクション：上から順にマッチさせ、MATCHは最後に置く

ルールモードでは、コアはリストを上から順に照合し、最初にマッチした項目の宛先を使います。宛先にはポリシーグループやノード名のほか、DIRECT、REJECTなどの組み込みポリシーを指定できます。管理しやすくするため、ルールでは個々のノード名を並べるのではなく、ポリシーグループを宛先にするのが一般的です。

rules:
  - DOMAIN,example.com,DIRECT
  - DOMAIN-SUFFIX,example.org,出口選択
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - MATCH,出口選択

DOMAINはドメイン名を完全一致で判定します。このルールが一致するのはexample.comだけで、すべてのサブドメインは対象になりません。
DOMAIN-SUFFIXはドメインのサフィックスで判定します。この例では、example.orgとそのサブドメインが対象です。
IP-CIDRは宛先のIPv4アドレス範囲で判定します。192.168.0.0/16は一般的なプライベートアドレス範囲の一つで、すべてのLAN内アドレスを網羅するわけではありません。
no-resolveは、このIPルールのためにドメイン名の解決を積極的に行わない指定です。宛先IPアドレスがすでに分かっている場合は、そのまま判定に使えます。
MATCHはフォールバックルールです。それ以前のルールに一致しなかった接続を受け持つため、通常はリストの最後に置きます。

ここでは予約済みのサンプルドメインを使って構文を説明しており、実際のサービス向け振り分けは設定していません。MATCH,出口選択を先頭に移すと、後続のルールはマッチしなくなります。また、ファイル内のセクションの並びがルールの優先順位を決めると誤解しがちですが、確認すべきなのはrules内の項目順です。

GEOIPやRULE-SETを使う場合は、対応するデータベースやルールプロバイダーも必要です。ログにリソースの読み込み失敗が表示されたら、まずリソースの問題を解決してください。ルールが参照するデータを読み込めていないのに、ルールの記述だけを繰り返し変更しないようにしましょう。

最小構成で動作確認：まず直結を検証し、実ノードは後から追加

以下は、この記事で扱った主な階層を含む、ローカル環境で直結を検証するための完全な設定例です。プロキシの待ち受け口を作り、ルールとポリシーグループを通じてリクエストを直接接続します。リモートプロキシノードは含まれていないため、リモートプロキシサービスの動作確認には使えません。前述のFake-IPの例とは異なり、ここではredir-hostを選び、初回の検証で合成アドレスの対応付けに依存しないようにしています。

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

dns:
  enable: true
  ipv6: false
  enhanced-mode: redir-host
  nameserver:
    - 223.5.5.5
    - 119.29.29.29

proxies: []

proxy-groups:
  - name: "出口選択"
    type: select
    proxies:
      - DIRECT

rules:
  - DOMAIN,example.com,DIRECT
  - IP-CIDR,127.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - MATCH,出口選択

保存と動作確認の手順

現在使える設定を別名でバックアップしてから、上記の内容をUTF-8でconfig.yamlとして保存します。エディターが末尾に.txtを自動追加していないことも確認してください。
mihomoのコマンドラインを使う場合は、mihomo -t -f config.yamlを実行して設定を検証できます。GUIクライアントでは、クライアント内の設定検証またはインポート機能を使ってください。操作の名称や場所はバージョンによって異なります。
検証に通ったら設定を読み込み、ポートの競合、未対応項目、存在しないポリシーなどのエラーがログにないか確認します。GUIクライアントでは、元の設定にポート、DNS、TUNなどの設定が上書きされる場合があります。最終的に動作している設定を確認してください。
システムプロキシの有効・無効に左右されないよう、プロキシを明示してリクエストを1回送信します。テストサイトに接続できるかどうかは、現在のネットワークで直結できるかにも左右されます。

curl -I --proxy http://127.0.0.1:7890 https://example.com

Windows PowerShellでcurlが別のコマンドとして解釈される場合は、curl.exeを使ってください。テスト中はクライアントの接続ログも確認します。宛先がexample.com、一致したルールがドメイン完全一致、出口がDIRECTになっていることを確認してください。HTTPレスポンスが返っただけでは、設定した経路を通ったかどうかは分かりません。

直結の検証が終わったら、実際のサブスクリプションまたはサービス設定からノードを追加し、そのノード名を「出口選択」に登録して、クライアント上で手動選択します。一度に変更するのは一種類だけにしましょう。まずノード、次にポリシーグループ、最後にルーティングルールの順で追加すれば、問題が起きたときに直前の変更箇所を特定しやすくなります。

読み込み失敗・ルールが効かない場合：エラーが起きた層から確認

症状	優先して確認する項目	対処方法
YAMLの解析エラー	インデント、タブ、コロン、引用符	エラー行と、その直前のリストを確認する
ポリシーまたはノードが見つからない	ルールの宛先とグループ内の名前	対応するnameと一字ずつ照合する
7890で待ち受けできない	別のクライアントまたはバックグラウンドのコア	重複プロセスを終了するか、ポートを変更してアプリ側の設定も合わせる
ルールを変更しても反映されない	現在のモード、有効な設定、上書き設定	ruleモードに戻し、実行中の設定を確認してから新しい接続を作成する
サブスクリプション更新後に変更が消える	編集したファイルがサブスクリプション生成ファイルかどうか	クライアントが対応する上書き・マージ機能を使う

ルールや出口を変更しても、既存の接続は確立時の経路を使い続ける場合があります。検証時は新しいリクエストを送信し、必要に応じて対象アプリの既存接続を終了してから、新しいルールのマッチ記録を確認してください。長時間接続が以前の出口を使い続けているだけで、設定が読み込まれていないと判断しないようにしましょう。

サブスクリプション管理では、元の設定と実際の動作設定を区別する必要があります。クライアントはサブスクリプション、グローバル設定、上書きルールを統合して最終的な設定を作ることがあります。サブスクリプションのダウンロードファイルを直接編集すると、次回の更新で変更が上書きされる可能性があります。ポートやルーティングの変更を維持するには、そのクライアントのドキュメントで正式に案内されている上書き機能を使い、更新後に最終設定を確認してください。

クライアントがまだない場合は、まずクライアントのダウンロードページでOSに合ったものを選んでください。設定のインポート、システムプロキシの有効化、初回接続の手順は設定ガイドで確認できます。ログや設定を共有して相談する前に、サブスクリプションURL、パスワード、UUIDなどの認証情報を削除してください。