Clash config.yamlの構成を解説：ポート・DNS・proxy-groups・rulesの読み方

1. 設定ファイルの出所・コア・YAMLの階層を確認する

config.yamlはよく使われる設定ファイル名ですが、すべてのクライアントがこのファイルを使うわけではありません。サブスクリプションから取得した設定、ローカル設定、クライアントが生成した実行用設定は、それぞれ別の場所に保存されることがあります。編集前にクライアントの設定一覧で現在有効な項目を確認し、実際に読み込まれている設定を調べましょう。有効でないファイルを編集しても、現在の接続には反映されません。

Clashはプロキシ設定の仕組みで、Clash Metaは後にmihomoという名称になりました。多くの基本項目は共通ですが、対応プロトコルやDNSオプション、TUNの設定はコアやバージョンによって異なります。この記事では共通の構成を説明したうえで、mihomo固有の拡張項目を取り上げます。クライアントによって画面上の名称は異なるため、アイコンだけで使用中のコアを判断しないでください。

YAMLを読むときに確認する3つのポイント

インデントで階層を表します。この記事では半角スペース2つに統一し、Tabは使いません。トップレベルのdns、proxies、rulesは左端をそろえます。
コロンでキーと値を区切ります。mode: ruleのように書き、全角コロンは使いません。行頭の-はリスト項目を表します。
名前は参照先と一致させます。ルールで指定したポリシーグループが存在し、そのグループが参照するノードや別のグループも見つかる必要があります。

2. ポートとモード：通信をコアにどう取り込むか

設定ファイルの先頭付近には通常、待ち受けポート、動作モード、ログレベルを記述します。ポートはリクエストを受け付け、モードは取り込んだ通信の出口を決めます。この2つは別の要素です。ルールが正しくても、アプリからクライアントに通信が渡っていなければ、意図したプロキシ接続にはなりません。

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

項目	設定例の意味	確認ポイント
`mixed-port`	7890でHTTPとSOCKSのプロキシリクエストを受け付ける	アプリに設定したポートと一致し、ほかのプロセスが使用していないこと
`allow-lan`	falseは、ほかのLAN機器からの接続を許可しない設定	共有する場合は待ち受けアドレスとファイアウォールも確認
`mode`	ruleはルール一覧に従って接続を振り分ける	rulesの適用順を確認するときは、グローバルモードを使わない
`log-level`	infoは通常の実行情報を出力する	一時的なトラブルシューティングにはdebugを使い、終わったら元に戻す
`ipv6`	falseはコアの該当するIPv6機能を無効にする	OS全体のIPv6通信を無効にする設定ではない

mixed-port、port、socks-portの使い分け

portはHTTPプロキシ用、socks-portはSOCKSプロキシ用のポートです。共通の入口を使う場合はmixed-portを設定できます。たとえばアプリのHTTPプロキシに127.0.0.1:7890を指定するなら、コアも7890番ポートで該当するリクエストを受け付ける必要があります。異なる待ち受け設定に同じアドレスとポートを割り当てないでください。

mode: ruleはルールに基づく振り分け、globalはグローバルポリシー、directは直接接続です。モードを切り替えても、ブラウザーのシステムプロキシ設定は自動で変更されません。初回の動作確認では、まずシステムプロキシを使い、基本的な接続を確認してからTUNを有効にしましょう。入口を同時に複数調べる手間を減らせます。

external-controller: 127.0.0.1:9090は通常、コントロールAPIの待ち受けアドレスです。インターネット接続用のプロキシポートではありません。ブラウザーのプロキシ設定に9090を指定しないでください。また、利便性のためにコントロールインターフェースをインターネットへ公開するのも避けましょう。

3. dns：DNSサーバー・待ち受けアドレス・fake-ipを理解する

dnsでは、コアに渡されたドメイン名の名前解決方法を設定します。以下では基本構成をredir-hostで説明します。2つのIPアドレスはDNSサーバーの例であり、すべてのネットワークで利用できるとは限りません。使用前に接続可能か確認し、DNSリクエストのプライバシーについても検討してください。

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

enable: trueはコアのDNS機能を有効にしますが、システム全体のDNSリクエストが自動的にコアへ転送されるわけではありません。
listenはローカルDNSの待ち受けアドレスを指定します。例では1053番を使っています。システムで一般的な53番とは異なり、別途転送設定を行わない限り、システムがこのポートを自動で参照することはありません。
nameserverは上流DNSサーバーの一覧です。従来のDNSは通常53番ポートを使い、DoHやDoTではそれぞれのプロトコルに対応したアドレスを指定します。
dns.ipv6: falseは、このDNSモジュールでのAAAAクエリの処理を制御します。OSレベルのIPv6ファイアウォールではありません。

fake-ipで198.18から始まるアドレスが返るのはなぜ？

enhanced-mode: fake-ipはドメイン名に対応するマッピング用アドレスを割り当て、コアが接続先と元のドメイン名を対応付けます。設定でよく使われるfake-ip-range: 198.18.0.1/16はこのマッピング用で、Webサイトの実際のグローバルIPアドレスではありません。そのため、この範囲のアドレスが返っても、DNSが汚染されているとは限りません。

LAN内のサービスやデバイス検出、実際の名前解決結果を必要とするアプリでは、例外設定が必要になることがあります。問題に応じてfake-ip-filterを設定し、対象をむやみに広げないでください。redir-hostとfake-ipでは動作が異なるため、切り替え後は新しい接続でテストしましょう。

mihomoではプロキシノードのドメイン名解決にも注意

プロキシサーバー自体がドメイン名で指定されている場合もあります。mihomoのproxy-server-nameserverなどを使うと、ノードのドメイン名をどのDNSサーバーで解決するか設定できます。上流DoHのアドレス自体がドメイン名の場合は、default-nameserverによる初期の名前解決が必要になることもあります。ノードの名前解決にプロキシが必要なのに、そのプロキシの接続にも同じドメイン名の解決が必要だと、依存関係が循環します。起動後にすべてのノードがタイムアウトする場合は、ルールだけを変更するのではなく、まずログのドメイン名解決エラーを確認してください。

4. proxies：ノード設定とサブスクリプションURLは別物

proxiesはノード定義の一覧です。ノードには通常、name、type、server、portを指定し、認証や通信方式に関する項目はプロトコルによって異なります。ノード名はポリシーグループから参照されます。サーバー側のポートはリモートサービスのポートなので、ローカルの7890番と混同しないでください。

この記事では、サーバーアドレスやパスワードを作り上げて掲載しません。構造の確認にはproxies: []でノード一覧を空にし、ポリシーグループから組み込みのDIRECTを一時的に参照できます。この設定では直接接続の振り分けを確認できますが、プロキシ接続が使えるようになるわけではありません。実際にプロキシを使うには、サービス提供元から受け取った、現在のコアが対応するノード設定を追加してください。

サブスクリプションURLはどこに登録する？

完全な設定ファイルのサブスクリプション：クライアントのサブスクリプションまたは設定画面からインポートします。取得した内容に、ノード、ポリシーグループ、ルールが含まれている場合があります。
ノード一覧のサブスクリプション：対応するproxy-providers機能で読み込み、ポリシーグループからuseで参照できます。
単一ノードの共有リンク：クライアントでの読み込みや変換が必要です。YAMLのノード定義としてproxiesにそのまま貼り付けることはできません。

通常のWebページ、ログインページ、期限切れの案内ページはノード一覧ではありません。インポート時に解析エラーが出たら、インデントを何度も調整するのではなく、まず応答内容を確認してください。また、完全な設定ファイルとprovider用のノード一覧では必要な形式が異なります。どちらも拡張子がYAMLだからといって、内容を相互に使えるわけではありません。

proxy-providersでよく使われるinterval: 3600は、リソースを3600秒ごとに更新する設定です。ポリシーグループのヘルスチェックにあるinterval: 300は、300秒ごとに接続を確認します。用途は異なり、どちらも遅延のしきい値ではありません。また、完全なサブスクリプションの更新設定を置き換えるものでもありません。

5. proxy-groups：ノードをまとめて出口を選ぶ

ルールからポリシーグループを指定し、そのグループでノードなどの出口を選ぶのが一般的です。これならノードを変更するときにルールを一つずつ書き換える必要がありません。以下のグループ名は「出口選択」で、組み込みの直接接続だけを含みます。参照関係の確認に使える例です。

proxies: []

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

よく使われる3種類のポリシーグループ

種類	選択方法	使用上の注意
`select`	グループ内の出口を手動で選択する	まずノードを固定してルールや接続状態を調べるのに適している
`url-test`	テスト結果に基づいて低遅延の出口を自動選択する	テストURLの応答時間はダウンロード速度と同じではない
`fallback`	リスト順に利用可能な出口を選ぶ	選択順はリスト順であり、遅延の低い順ではない

url-testとfallbackには通常、テスト用URLやチェック間隔などの設定も必要です。テスト用URLに現在の環境からアクセスできることを確認してください。テスト先に障害があると、複数の正常なノードが同時に利用不可と表示されることがあります。1回の遅延テストだけでノードを削除しないでください。

グループ名とノード名は重複しない、分かりやすいものにしましょう。ルールが「出口選択」を参照している場合、「プロキシ出口」に改名したらルール側も変更が必要です。グループを階層化することはできますが、AがBを参照し、BがAを参照するような設定はできません。参照が循環すると出口を正しく選べなくなります。

6. rules：上から順に照合し、MATCHは最後に置く

ルールモードでは通常、接続は一覧の上から順に照合され、最初に一致したルールのポリシーが適用されます。「具体的なルールが自動的に優先される」わけではありません。範囲の広いルールを先に書くと、後ろの詳細なルールが実行されないことがあります。明確な例外、範囲の広いルール、最後にフォールバックの順に並べると確認しやすくなります。

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

DOMAINはドメイン名を完全一致で照合します。この例で一致するのはexample.comだけで、サブドメインすべてが対象になるわけではありません。
DOMAIN-SUFFIXは指定したドメインとそのサブドメインに一致します。この例ではexample.orgとwww.example.orgが対象です。
IP-CIDRは宛先IPの範囲に一致します。例ではよく使われるプライベートIPv4アドレスの範囲を3つ示していますが、特殊用途アドレスをすべて網羅した一覧ではありません。
no-resolveは、このIPルールへの一致判定だけを目的としたドメイン名の名前解決を行わない指定です。接続全体のDNSを無効にするものではありません。
MATCHは、それまでのルールに一致しなかった接続を受けるフォールバックです。リストの最後に配置してください。

GEOIP、RULE-SET、ルールプロバイダー

GEOIP,CN,DIRECTはIPジオロケーションデータベースに基づいて照合します。ドメイン名の文字列から地域を判断するものではありません。データベースがない、更新に失敗する、名前解決で別地域のIPが返るといった状況により、結果が変わることがあります。データベースのエラーが出た場合は、トラブルシューティングガイドのGEOIP確認項目を参照してください。

RULE-SETはrule-providersで定義したルールセットを参照します。ノードを格納するproxy-providersとは別の機能です。使用前にルールセットの形式や動作タイプ、現在のコアでの対応状況を確認してください。ルールセットを追加しただけでは照合に使われません。rulesにも参照ルールを追加する必要があります。

7. 最小構成を作り、TUNとサブスクリプションのノードを段階的に追加

以下では、これまでの基本項目を組み合わせた学習用のローカル設定を作成します。プロキシサーバーは含まれておらず、すべての出口は最終的に直接接続します。YAMLの階層、ポートの待ち受け、ポリシーの参照関係を確認するための例です。クライアントがポートやDNSを自動で上書きする場合は、実行中の設定とログを確認してください。

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

dns:
  enable: true
  listen: 127.0.0.1:1053
  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,出口選択
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - MATCH,出口選択

TUNを最初から追加していない理由

TUNは別の通信入口であり、プロキシノードでも、ルールを自動的に正しくする機能でもありません。mihomoでよく使われる設定項目にはtun.enable、stack、auto-route、dns-hijackなどがありますが、動作はOS、権限、ネットワークアダプター、ルーティング環境にも左右されます。利用環境が不明なTUN設定を、すべてのデバイスにそのまま適用しないでください。

まず「アプリのプロキシ設定 → 7890 → ルール → 出口」の順に動作を確認し、その後クライアントが対応する方法でTUNを有効にすることをおすすめします。有効化後にインターネットへ接続できなくなった場合は、すぐにproxiesを書き換えるのではなく、ルート、DNSの取り込み、ほかのVPNとの競合を優先して確認してください。基本的な設定手順は入門ガイドのTUNモードの説明を参照してください。

8. 保存した設定が反映されないとき：構文・参照先・実行状態を確認

編集した設定が有効か確認する。設定一覧で現在有効な項目と更新日時を確認してから、再読み込みしてください。同じ名前のファイルが複数保存されている場合もあります。
構文エラーの行を確認する。yaml: lineを含むエラーが出たら、該当行だけでなく、その直前の行にあるコロン、引用符、リスト記号、インデントも確認してください。特殊文字を含むパスワードは、YAMLの文字列ルールに従って引用符で囲みます。
同名のトップレベルキーがないか確認する。ファイル末尾に2つ目のdns:やrules:を追加しないでください。重複キーは解析時に拒否されることも、解析方法によっては上書きされることもあります。
出口の参照先を確認する。プロキシやポリシーが見つからないというエラーが出たら、グループ名、ノード名、大文字・小文字を一字ずつ照合してください。YAMLを解析できても、参照関係が正しいとは限りません。
待ち受けポートと通信入口を確認する。address already in useが表示されたら、7890番やDNSの待ち受けポートをほかのプロセスが使っていないか調べてください。システムプロキシのアドレスを変えても、ポートの競合は解消しません。
実際に適用されたルールを確認する。ruleモードで動作していることを確認し、新しい接続の詳細でルールを調べてください。アプリがシステムプロキシを使わない場合は、通信入口を設定するか、必要に応じてTUNを使用します。

コア内蔵の設定テストを実行する

mihomoをコマンドラインから実行できる場合は、設定ファイルのあるディレクトリで次のコマンドを実行します。設定のテストでは外部リソースやデータベースの読み込みが必要な場合があります。実行時と同じ作業ディレクトリとリソース環境を使ってください。

mihomo -t -f config.yaml

テストに成功したということは、コアが設定を受け付けたことを示すだけです。ノードの認証情報が有効か、すべての上流サーバーへ接続できるか、Webサイトが意図した出口を通るかまでは保証されません。引き続き接続ログを確認してください。トラブルシューティングでは一度に一つの要素だけを変更し、変更前後のエラーを記録しましょう。DNS、ルール、TUNを同時に切り替えるより原因を特定しやすくなります。

設定を読み解くには、「入口のポート → ドメイン名の解決 → ルールの照合 → ポリシーグループ → 最終的な出口」の順に確認するのがポイントです。ルールのトラブルシューティングを詳しく知りたい場合は、config.yamlの設定チェックを参照してください。クライアントを乗り換える際は、新しいクライアントのコアと対応する設定項目を確認してから設定を移行しましょう。