応用設定 読了時間：約12分

Clash YAML設定ファイルを徹底解説：mixed-portからrulesまで

mixed-portなどの基本設定からdns、proxies、proxy-groups、rule-providers、rulesまで、各項目の意味を順に解説。よくあるインデントミスも紹介します。

1. 設定ファイルの構成：クライアント設定とコア設定を区別する

Clash Verge Revで使われるmihomoコアは、接続、DNS、ルール判定を担います。YAMLは設定を記述する形式であり、プロキシプロトコルではありません。YAMLパーサーで読み込めても、それは構文が正しいというだけです。ノードの種類がサポートされているか、ポリシーグループ名が存在するかは、コア側で確認する必要があります。

サブスクリプションの設定を読むときは、「接続ポート → DNS → ノード → ポリシーグループ → ルールセット → マッチルール」の順に見ると分かりやすくなります。実際の動作は、ファイルを上から順に実行するわけではありません。たとえば rules は前に定義したポリシーグループを参照し、そのグループはさらにノードを参照します。これらの名前が設定項目同士を結び付けています。

  • mixed-portやmodeなどのトップレベル項目で、ローカルの接続ポートや動作モードを指定します。
  • dnsはマッピングで、その中に有効・無効の設定、名前解決モード、上流DNSサーバーなどを記述します。
  • proxies、proxy-groups、rulesはリストです。各項目の先頭にはハイフンを付けます。
  • rule-providersは名前をキーにしたマッピングで、外部ルールセットを定義します。

2. mixed-port：アプリが接続するローカルポートを設定する

mixed-portは、1つのポートでHTTPとSOCKSの両方のプロキシ接続を受け付けます。以下では具体例として7897を使いますが、すべての環境でこの値が使われるわけではありません。クライアントに現在表示されている待ち受けポートを確認してください。

mixed-port: 7897
allow-lan: false
mode: rule
log-level: info
ipv6: false
項目設定例の意味確認ポイント
mixed-port: 7897ローカルの混合プロキシポートは7897手動でプロキシを設定するアプリにも同じポートを指定する
allow-lan: falseLAN内のデバイスからの接続を許可しないこのPCだけで使う場合は、通常オフのままにする
mode: ruleルールに応じて接続先を選択グローバルモードではrulesによる振り分け結果を確認できない
log-level: info通常の動作情報を記録するトラブル調査中は一時的にdebugへ変更し、終了後に戻す
ipv6: falseコアのIPv6サポートを無効にするOSのIPv6を無効にする設定ではない

HTTPプロキシを手動設定する場合、ホストに127.0.0.1、ポートに7897を入力します。クライアント側のポートを7898に変更した場合は、手動設定も合わせて変更してください。システムプロキシをクライアントが管理している場合は、アプリで設定した後、システム側に反映された値を確認しましょう。

混合ポートはDNSポートでも、コアの制御用インターフェースでもありません。ブラウザーのプロキシ設定にexternal-controllerのアドレスを入力しないでください。LAN内で共有する場合は、待ち受けアドレス、ファイアウォール、アクセス認証も確認が必要です。allow-lanをtrueにするだけでは設定は完了しません。

3. dns：名前解決モード、上流サーバー、通信の取り込み

dnsはコアのDNS機能を制御します。有効にしても、OSのすべてのDNSリクエストがクライアントに送られるとは限りません。OSのDNS設定、アプリ内のセキュアDNS、TUNのDNSハイジャック設定などが、実際のリクエスト経路に影響します。まずリクエストがどこへ送られているかを確認してから、上流サーバーを変更しましょう。

dns:
  enable: true
  listen: 127.0.0.1:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - https://1.1.1.1/dns-query
    - https://1.0.0.1/dns-query

fake-ipが返すのは対応付け用のアドレス

fake-ipはドメイン名に対応するアドレスを割り当て、コアがドメイン名とアドレスの対応関係を保持して、その後の接続処理に利用します。198.18で始まる結果が表示されても、すぐにDNS汚染と判断する必要はありません。このアドレス範囲はテスト用であり、接続先サイトの実際のグローバルIPアドレスではありません。

1053で待ち受けても、OSのDNS設定は自動で変わらない

listen: 127.0.0.1:1053は、ローカルのDNSサービスがポート1053で待ち受けることを示します。一般的なOSのDNS設定で指定できるのは通常サーバーのIPアドレスだけで、ポートは入力できません。そのため、127.0.0.1を設定するだけで1053番ポートに接続できるわけではありません。TUNモードでは、クライアントが生成したtunとdns-hijackの設定を合わせて、通信の取り込み方法を確認してください。

  • nameserverでは、コアが名前解決に使う上流サーバーを指定します。例では具体的なDoHアドレスを2つ使っていますが、接続できるかどうかは利用中のネットワークによって異なります。
  • ドメイン名形式の暗号化DNSアドレスを使う場合、上流サーバーのドメイン名を最初に解決するため、default-nameserverも必要になることがあります。
  • 一部のデバイスやアプリでfake-ipが正しく動作しない場合は、対象ドメインのfake-ip-filterを確認しましょう。まずDNS関連の設定をすべて無効にするのは避けてください。

サブスクリプションにDNS設定一式がすでに含まれている場合、この短い設定だけで上書きするのはおすすめしません。元の設定には、ノードのドメイン解決、地域に応じた名前解決の振り分け、特定ドメイン向けの処理などが含まれていることがあります。原因を特定できるよう、調査では一度に一項目だけ変更し、変更前後のログを残してください。

4. proxiesとproxy-groups：ノードの設定と接続先の選択

proxiesでは各ノードの接続パラメーターを定義します。proxy-groupsはノードをまとめ、手動選択や速度テストによる選択などのポリシーを設定します。ノード名は説明文ではなく、他の設定から参照する識別子です。スペース、大文字・小文字、文字列を正確に一致させてください。

以下はShadowsocksノードの項目構成だけを示す例です。192.0.2.10はドキュメント用アドレス、example-only-not-a-secretは説明用のパスワードであり、この設定では実際のプロキシに接続できません。実際のサーバー、ポート、暗号化方式、パスワードはサービス提供元から入手してください。推測で設定してはいけません。

proxies:
  - name: "サンプルノード"
    type: ss
    server: 192.0.2.10
    port: 443
    cipher: aes-128-gcm
    password: "example-only-not-a-secret"
    udp: true

proxy-groups:
  - name: "手動選択"
    type: select
    proxies:
      - "サンプルノード"
      - DIRECT

selectとurl-testは別の機能

selectはメンバーを手動で選ぶポリシーです。一方、url-testは設定したテスト用URLと間隔に基づき、候補の接続性を測定します。測定結果が示すのは主にテスト先への接続状況であり、ダウンロード速度そのものではありません。また、すべてのサイトで同じ接続先が最適とは限りません。

DIRECTは組み込みの直接接続先であり、proxiesに別のノードを追加する必要はありません。ノードのudp: trueは、該当するUDP機能を許可する設定にすぎません。サーバー側の対応状況、プロトコルの機能、ローカルでの通信取り込み方法も満たす必要があります。

5. rule-providers：ルールを別ファイルに分ける

rule-providersでは、ルールセットの取得元、形式、動作を定義します。ただし、宣言しただけではルールは有効になりません。rulesでRULE-SETを使ってルールセット名を参照し、マッチした場合の接続先も指定する必要があります。

ここでは、使用可能なルールソースと誤認しないよう、ローカルファイルを使った例を紹介します。まず、コアが許可する設定ディレクトリにrules/local-direct.yamlを用意し、その後メイン設定を読み込みます。相対パスはコアの作業ディレクトリとパス制限に従って解決され、ブラウザーや記事の場所を基準にはしません。

rule-providers:
  local-direct:
    type: file
    behavior: domain
    format: yaml
    path: ./rules/local-direct.yaml

このルールファイルには、次のように記述できます。

payload:
  - "example.com"
  - "+.example.org"

example.comは単一ドメインの例、+.example.orgはそのドメインとサブドメインの例です。どちらもドキュメント用のドメインであり、実際に必要な振り分けリストを示すものではありません。

  • behavior: domain：ルールの内容にはドメインのマッチ条件を記述します。DOMAIN-SUFFIX,...のような完全なルール形式にはしないでください。
  • behavior: ipcidr：ルールの内容には、192.0.2.0/24のようなIPネットワークを記述します。
  • behavior: classical：DOMAIN-SUFFIXなどの従来形式のルール式を使用できます。ルールセット内の項目には通常、接続先を記述せず、参照する側で指定します。

type: httpに変更する場合は、実際にアクセスできるurlとキャッシュ先のパスを設定します。たとえばinterval: 86400は、更新間隔が86400秒、つまり24時間であることを示します。ダウンロードの失敗、ファイル形式の不一致、ルールが参照されていない状態は、それぞれ別の問題です。ログ、ファイルの内容、メイン設定を分けて確認してください。

6. rules：順番にマッチさせ、最後にデフォルトの接続先を指定する

ルールモードでは、rulesはリストの上から順に評価され、通常は最初にマッチしたルールで接続先が決まります。例外的なルールを先に、対象範囲が広いルールを後に置き、MATCHは最後に配置します。「すべてのルールを評価してから最適なものを選ぶ」仕組みではありません。

rules:
  - DOMAIN,example.com,DIRECT
  - DOMAIN-SUFFIX,example.net,手動選択
  - RULE-SET,local-direct,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - MATCH,手動選択

この設定は、前述の手動選択ポリシーグループとlocal-directルールセットが定義済みであることを前提としています。単独では完全な設定として読み込めません。DOMAINは指定したドメインにマッチし、DOMAIN-SUFFIXはそのドメインとサブドメインにマッチします。名前が似ているからといって、置き換えて使わないでください。

no-resolveはDNS全体を無効にする設定ではない

IP系のルールでは、ドメイン名のリクエストにマッチさせるために名前解決が行われることがあります。例のno-resolveは、このルールのためだけにドメイン名の名前解決を開始しないという指定です。リクエストが最初からIPアドレスである場合や、利用可能な解決結果がすでにある場合は、引き続きマッチ対象になります。DNS機能全体を無効にする設定ではなく、他の処理で名前解決されないことを保証するものでもありません。

MATCHを先頭に置くと、後続のルールが評価されない

最初のルールがMATCH,DIRECTだと、その後にあるドメインのプロキシルールはマッチしません。「ルールを設定したのに反映されない」ときは、まずクライアントの「接続」ページで新しい接続のルールと接続先を確認し、その前に対象範囲の広いルールがないか調べてください。変更後は新しい接続で検証します。確立済みの長時間接続は、ルールを変更しても自動的に別の接続へ切り替わりません。

7. YAMLのインデントミス：構文解析と動作を分けて確認する

各階層のインデントには半角スペース2つを使い、Tabは使わないでください。YAMLではインデントで階層が決まり、コロンの後には通常スペースが必要です。リスト項目はハイフンの後にスペースを入れます。エラーに表示される行番号は、パーサーが異常を検出した位置であり、原因が前の行にある場合もあります。

ミス1：項目のインデントが親階層になっている

以下のenableはdnsの下に配置されていません。YAMLとしては有効でも、意図したコア設定の構造になっていない可能性があります。

# 誤り：enableがトップレベル項目になっている
dns:
enable: true

# 正しい例
dns:
  enable: true

ミス2：リスト項目と所属する設定項目の階層が合っていない

# 誤り：DIRECTとproxiesが同じ階層にある
proxy-groups:
  - name: "手動選択"
    type: select
    proxies:
    DIRECT

# 正しい例
proxy-groups:
  - name: "手動選択"
    type: select
    proxies:
      - DIRECT

ミス3：特殊文字や重複キーによって内容が変わる

: や、スペースの後に#を含むパスワードや名前は、引用符で囲むのがおすすめです。たとえばname: "回線: A #1"と書けば、文字列全体を明確に保持できます。同じ階層にdns:やrules:を2つ書いて、自動的に統合されることを期待してはいけません。パーサーがエラーを出す場合も、一方だけを残す場合もあり、どちらもオーバーライドの方法として適切ではありません。

「ポリシーグループが見つからない」「ルールセットが存在しない」は、通常、インデントではなく参照先の誤りです。ノード名、ポリシーグループ名、ルールセット名を一文字ずつ照合してください。エラー行だけを見て、空白を増減させ続けないようにしましょう。

8. 設定の反映を確認する：接続先、名前解決、ルールを順に検証

上記の各例をすべてつなげて、そのまま本番設定にしないでください。それぞれ設定の構造を説明するためのもので、ノードにはドキュメント用アドレスを使い、ルールセットには事前に作成したローカルファイルが必要です。実際に変更するときは、現在使えるサブスクリプションをベースにし、対象の項目を一度に1つだけ変更しましょう。

  1. 変更前の状態を記録。現在の設定をバックアップし、混合ポート、動作モード、選択中のポリシーグループのメンバーを記録します。「設定」ページで、編集した項目が有効になっていることも確認してください。
  2. 設定の読み込みを確認。変更を適用したら「ログ」ページを開き、まず構文エラーと名前の参照エラーを解消します。設定が正常に読み込まれていない状態で、アクセス結果から新しいルールの動作を判断しないでください。
  3. 接続ポートを確認。実際の待ち受けポートが、想定した7897または変更後の値になっていることを確認します。アプリがシステムプロキシに従わない場合は、手動プロキシ設定またはTUNによる通信の取り込みが必要か判断してください。
  4. 名前解決を確認。DNSのタイムアウト、ノードのドメイン名解決の失敗、接続先ドメインの名前解決の失敗を区別してください。fake-ipが有効な場合、マッピング用アドレスが表示されても、それだけでは失敗とは判断できません。
  5. 接続先を確認。「プロキシ」ページでポリシーグループが実際に選択しているメンバーを確認し、「接続」ページで新しいリクエストにマッチしたルールと接続経路を確認します。
  6. 設定の保持を確認。サブスクリプションを更新するか設定を再読み込みし、カスタマイズした内容が残っているか確認します。上書きされる場合は、適切なオーバーライド機能にカスタマイズを移してください。

各項目の関連をさらに詳しく確認する場合は、応用設定もご覧ください。混合ポート、ポリシーグループ、TUNの意味がまだ分からない場合は、先に用語ガイドを確認しましょう。YAML全体を一度に置き換えるより、まずリクエストがクライアントに届いているかを確かめ、その後DNSとルールを検証するほうが、原因を特定しやすくなります。

Clashクライアントをダウンロード