Clash config.yamlの読み方｜ポート設定からrulesまで項目別に解説

まずカーネルと設定ファイルの入手元を確認

config.yamlは、プロキシカーネルが読み込む設定ファイルです。カーネルが接続の確立や通信の振り分けを担い、クライアントは設定のインポートや切り替え、ログ確認の画面を提供します。クライアントによっては読み込み前にポート設定を統合したり、ルールを上書きしたりするため、編集したファイルが最終的な設定のすべてとは限りません。

この記事では、mihomo（旧Clash Metaカーネル）で一般的に使われる設定項目を中心に解説します。従来のClashとmihomoには共通の構文がありますが、すべての機能に互換性があるわけではありません。特にTUN、DNS、新しいプロキシプロトコルには注意が必要です。クライアントの「バージョン情報」やカーネル情報で名称とバージョンを確認し、対応するドキュメントを参照してください。画面にClashと表示されているだけで互換性を判断しないようにしましょう。

読むときは3つの流れを押さえる

• 入口：ポートとTUNで、通信がどのようにカーネルへ入るかが決まります。
• 出口：proxiesで接続先を定義し、proxy-groupsで選択可能なプロキシグループにまとめます。
• 振り分け：rulesでドメインやIPなどの条件を指定し、通信をプロキシグループまたは組み込みアクションへ振り分けます。

ファイルの上から下への並びは、主に読みやすさのためです。トップレベルのrulesは、参照先のプロキシグループの直後に置く必要はありません。重要なのは名前が一致していること、項目の階層が正しいこと、そしてルールリスト内の順序です。

構成を確認できるconfig.yamlの全体例

以下は、読み方の確認とローカルテスト用のmihomo設定です。リモートプロキシノードはなく、許可される通信はすべて直接接続されます。リモートプロキシが利用できるかどうかの確認には使えません。接続できないデモ用サーバーを混ぜず、ポート、DNS、プロキシグループ、ルールの関係を把握することを目的としています。

# ローカルのプロキシ入口
mixed-port: 7890
allow-lan: false
bind-address: 127.0.0.1

# 動作モードとログ
mode: rule
log-level: info
ipv6: false

# ローカルDNSサービス
dns:
  enable: true
  listen: 127.0.0.1:1053
  ipv6: false
  enhanced-mode: redir-host
  nameserver:
    - 223.5.5.5
    - 1.1.1.1

# 仮想ネットワークインターフェースによる通信の取り込みは無効
tun:
  enable: false

# リモートプロキシノードなし
proxies: []

# プロキシグループで組み込みの直接接続アクションを使用
proxy-groups:
  - name: "出口の選択"
    type: select
    proxies:
      - DIRECT

# 上から順に照合し、最後のルールをフォールバックにする
rules:
  - DOMAIN-SUFFIX,example.com,出口の選択
  - IP-CIDR,127.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - MATCH,出口の選択

example.comは予約済みのサンプルドメインで、ここではドメインルールの例としてのみ使用しています。DNSサーバーは具体的なパブリックDNSサービスですが、すべてのネットワークからアクセスできるとは限りません。読み込む前に、ローカルの7890と1053ポートが他のプログラムに使われていないことも確認してください。

YAMLはまずインデント、次に項目を見る

YAMLではインデントで項目の親子関係を表します。例では半角スペース2つに統一し、Tabは使いません。dns:を左端に書き、enable:を1段深くインデントすると、DNS設定の項目になります。リストの-は各項目を表し、[]は空のリストを表します。

• コロンの後には通常、半角スペースを入れます。例：mode: rule。
• 同じ階層の項目はインデントをそろえます。トップレベルのrules:をプロキシグループの中に入れないでください。
• 文字列に#などの特殊文字が含まれる場合は、後半がコメントとして扱われないよう引用符で囲みます。
• 同じ階層でdnsやrulesを重複して定義しないでください。パーサーによっては重複キーを拒否したり、一方だけを残したりします。

ポートとモード：アプリの通信を正しい入口へつなぐ

mixed-port: 7890は、同じポートでHTTPプロキシとSOCKS5プロキシの接続を受け付ける設定です。アプリにプロキシを手動設定する場合、アドレスに127.0.0.1、ポートに7890を指定し、アプリの選択肢に応じてプロトコルを選びます。この数値は記事内の例であり、すべてのクライアント共通の既定値ではありません。

mode: ruleは、この記事で扱うルールモードです。グローバルモードでは通常、通信がグローバル用のポリシーへ送られ、directモードでは直接接続されます。どちらのモードでも、通常のルールを編集しただけでは期待どおりに動作しません。クライアントの画面でモードが上書きされる場合もあるため、実際の動作状態を確認してください。

log-level: infoは、普段の状態確認に適しています。問題の原因を調べるときは一時的にdebugへ変更し、再現できたら元に戻してください。詳細ログにはアクセス先のドメインなどが含まれることがあるため、共有前に機密情報を削除しましょう。

DNSとTUN：名前解決と通信の取り込みを分けて考える

DNSはドメイン名をIPアドレスに変換する仕組みです。この例ではカーネルのDNSサービスを有効にし、127.0.0.1:1053で待ち受けます。ただし、これだけですべてのOSのDNSリクエストが自動的に転送されるわけではありません。実際の経路は、OSの設定、クライアントとの連携方法、TUNによる通信の取り込みによって変わります。

nameserverと名前解決モード

nameserverは、名前解決に使う上流DNSサーバーのリストです。例にあるIPアドレスを直接指定する方法では、通常のDNSを使い、通信は暗号化されません。DoH（HTTPS経由のDNS問い合わせ）を使う場合は、利用中のカーネルが対応する形式でサーバーアドレスを設定し、接続経路と起動時の名前解決要件も確認してください。

enhanced-mode: redir-hostは、名前解決時に実際のアドレスを返します。もうひとつの一般的なモードfake-ipでは、アプリに対応付け用の仮想アドレスを返し、カーネルが元のドメインに関連付けます。どちらも「速度設定」ではありません。モードを切り替えた後は、古いDNSキャッシュや既存の接続が確認結果に影響することがあります。必要に応じてキャッシュを消去し、関連アプリを再起動してください。

TUNは別のプロキシノードではない

TUNは、システムのルーティングから転送された通信を受け取る仮想ネットワークインターフェースです。この例ではtun.enable: falseのみを指定しているため、この経路による通信の取り込みは有効になっていません。システムプロキシを有効にしてもTUNが有効になるわけではありません。前者は主にシステムプロキシ設定に従うアプリに作用し、後者は適切なルート設定と権限があれば、より多くの通信を受け取れます。

• まずアプリに127.0.0.1:7890を手動設定して確認し、次にシステムプロキシを試します。TUNを検討するのはその後です。
• TUNを使う場合は、クライアントとOSの要件に従って、管理者権限、仮想インターフェース、ルート設定を行ってください。
• dns-hijackは条件に一致するDNS通信を取り込む設定ですが、すべての暗号化DNSに有効とは限りません。アプリ内蔵のDoHは別の経路で通信することがあります。
• この例ではトラブルシューティングの範囲を絞るためIPv6を無効にしていますが、すべてのネットワークで恒久的に使うべき設定ではありません。

proxiesとプロキシグループ：名前をたどって出口を確認

proxiesは、個々のプロキシ接続を定義するリストです。実際のノードには通常、名前、プロトコルの種類、サーバー、ポート、認証情報が含まれ、必要な項目はプロトコルごとに異なります。サーバーアドレスとパスワードは実際のサービス設定を使ってください。異なるプロトコルの項目を寄せ集めてノードを作ることはできません。

この例のproxies: []は、リモートノードがないことを明示しています。プロキシグループ内のDIRECTはカーネルに組み込まれた直接接続アクションなので、ノードリストに追加する必要はありません。同様に、REJECTは接続を拒否する組み込みアクションです。

selectは選択用で、速度測定は行わない

proxy-groupsでは、1つ以上の出口をグループにまとめます。この例のtype: selectは手動選択を表し、グループ名は「出口の選択」です。実際のノードを追加する場合は、その正確な名前をグループのproxiesリストに追加すると、グループ内で選べるようになります。

rules内の「出口の選択」
        ↓ 名前を一致させる
proxy-groupsでnameが「出口の選択」のグループ
        ↓ 現在の選択項目
DIRECT（宛先へ直接接続）

url-testは、テスト結果に基づいて出口を選ぶプロキシグループです。適切なテスト用URLと間隔が必要です。測定された遅延は特定の宛先に対する値であり、ダウンロード速度を示すものではなく、すべてのサイトへの接続を保証するものでもありません。

サブスクリプションにはproxy-providersが含まれる場合もあります。これはファイルまたはリモートの取得元からノードの一覧を読み込む設定です。プロキシグループでは通常、useでプロバイダー名を参照します。プロバイダー名を個別のノードとしてproxiesに入れるわけではありません。この形式を見つけたら、取得元、更新方法、ヘルスチェックの設定も確認してください。

rules：先頭からMATCHまで順に確認

ルールは通常、リストの順に照合され、最初に一致したルールで通信の行き先が決まります。具体的な条件を前に、範囲の広い条件を後ろに置き、最後にフォールバックを配置してください。MATCHを先頭に置くと、その後の通常ルールは新しい接続を処理できません。

ドメインルールとIPルールを混同しない

DOMAINはドメインの完全一致、DOMAIN-SUFFIXはドメインとそのサブドメインに使います。ルールにはドメイン名を指定し、URL全体は指定しません。たとえばhttps://example.com/pathにはプロトコルとパスが含まれるため、ドメイン条件としてそのまま使うことはできません。

IP-CIDRのCIDRは、プレフィックス長でIPアドレスの範囲を表す形式です。末尾のno-resolveは、このIPルールの確認のためにドメイン名の解決を新たに行わない設定です。接続情報に宛先IPがすでに含まれている場合は、そのIPを使って照合できます。DNS全体を無効にする設定ではありません。

この例では、よく使われるローカルネットワークの一部のみを記載しており、特殊なIPアドレスに対する完全なルールではありません。プリンター、ルーター、社内ネットワークに接続できない場合は、実際の宛先アドレスとルールの照合記録を確認してください。すべてのプライベートネットワークが192.168.0.0/16に含まれるとは限りません。

RULE-SETを見つけたらルールプロバイダーを確認

RULE-SETが参照するのは、rule-providersで定義されたルールセットであり、プロキシノードの一覧ではありません。プロバイダー名、取得元、形式、behaviorの種類をあわせて確認してください。ダウンロードに成功しても、取得した内容が現在の設定に適した形式とは限りません。

読み込み前の確認と動作検証

構文チェックに通っても、ネットワークが想定どおり動作するとは限りません。「読み込める」「待ち受ける」「ルールに一致する」「接続できる」の4段階に分けて確認しましょう。一度に変更する項目を1つにすれば、問題が起きても直前の動作状態に戻しやすくなります。

1. ファイルを確認します。テスト用コピーをUTF-8形式のconfig.yamlとして保存し、拡張子が.yaml.txtになっていないか確認します。インデント、重複キー、プロキシグループ名も確認してください。
2. カーネル設定を検証します。クライアントに用意された設定チェック機能を使ってください。mihomoのコマンドライン版がインストールされた環境では、下のテストコマンドも実行できます。Windowsでは、カレントディレクトリにあるプログラムを.\mihomo.exeのように指定します。
3. 読み込んでログを確認します。構文エラー、プロキシグループが見つからないという警告、ポートの競合がないことを確認してください。クライアントが設定を書き換える場合は、実際に生成された設定内容も確認します。
4. 入口を明示してリクエストを送信します。まずプロキシポートを明示的に指定し、システムプロキシの設定やブラウザーの設定による影響を除外してください。
5. 接続記録を確認します。テスト接続に一致したルール、プロキシグループ、最終的な出口を確認してから、元のDNS設定やTUN設定を段階的に有効にします。

# 設定を検証するコマンド。通常の長時間稼働するプロキシサービスは起動しません
mihomo -t -f ./config.yaml

# 設定を読み込み、カーネルを起動した後にローカルHTTPプロキシの入口をテスト
curl --proxy http://127.0.0.1:7890 --head https://example.com

2つ目のコマンドでは、ローカルのプロキシ入口からサンプルサイトまでの接続をテストします。この例の最終的な接続先はDIRECTです。リクエストに成功しても、リモートプロキシノードが有効だとは確認できません。Windowsでcurlが別のコマンドとして解釈される場合は、インストール済みのcurl.exeを明示して実行してください。

以降の設定変更も、入口のパラメーター、動作モード、DNS、通信の取り込み、ノード、プロキシグループ、ルールの順に確認すると整理しやすくなります。各項目の詳しい説明は、サイト内のYAMLマニュアルを参照してください。設定のインポートから有効化までの手順は使い方ガイドで紹介しています。毎回一から書き直すより、動作確認済みの設定を残しておくと便利です。