Clash 設定ファイル構造の全解説:port、dns から rules まで各セクションの役割

設定ファイル全体の構造概要

Clash の設定ファイルは本質的に1つの YAML ドキュメントで、上から下へおおよそ4つの内容に分かれます。グローバル動作パラメータ、ノード定義、ポリシーグループ定義、振り分けルールです。これら4つは互いに独立しつつ参照関係を持ちます——ノードはポリシーグループから参照され、ポリシーグループはルールから参照され、ルールが最終的にどの経路を通るかを決定します。この参照チェーンを理解することは、あるフィールドの取り得る値を丸暗記するより実用的です。設定エラーや振り分けが機能しない場合、調査の道筋は常にこのチェーンを逆にたどることになります。

Clash Meta(すなわち mihomo)は元の Clash のフィールドを拡張し、TUN モード、DNS スニッフィング、地理位置データベースのパスなどの設定項目を追加していますが、コアとなる4段構成は変わりません。本稿は Meta カーネルのフィールド範囲を基準としますが、無印 Clash のフィールドはその部分集合であり、そのまま読んでも理解に支障はありません。

共通フィールド:port、mode、log-level、dns

ファイルの最上部には通常、独立したキーと値のペアが並び、クライアント自体の動作方式を担います。具体的なノードは一切関与しません。

• port / socks-port:それぞれ HTTP プロキシポートと SOCKS5 プロキシポートを開き、OS やアプリが必要に応じてどちらかに接続します。
• mixed-port:1つのポートで HTTP と SOCKS5 の両方のリクエストを受け付けます。多くのクライアントはデフォルトでこのポートのみを公開し、設定項目を減らしています。
• allow-lan:同一 LAN 内の他デバイスがこのマシンのプロキシを経由することを許可するかどうか。bind-address と組み合わせてリスニング範囲を制御します。
• mode:値は rule(ルールに基づく振り分け、通常の使い方)、global(すべて同一ノード経由、トラブルシュート時に使用)、direct(すべて直接接続、一時的にプロキシを無効化する際に使用)。
• log-level:ログの詳細度を制御します。問題調査時に一時的に debug にすることが多く、日常使用では info または warning を推奨します。ログファイルが無限に肥大化するのを避けられます。

dns ブロックは独立したセクションで、ドメイン名解決がどの経路を通るかを決めます。これは「振り分けが効いているように見えて実際は効いていない」という問題の根本原因の1つです——DNS 解決の段階で間違った IP に解決されてしまえば、後段のルールをどう書いても取り返しがつきません。基本的に動作する dns セクションはおおよそ次のようになります。

dns:
  enable: true
  ipv6: false
  default-nameserver:
    - 223.5.5.5
  nameserver:
    - https://doh.pub/dns-query
  fake-ip-range: 198.18.0.1/16
  use-hosts: true

fake-ip-range は Meta カーネルでよく使われる設定で、TUN モードと組み合わせて使用します。ドメイン名に仮の(フェイク)ローカル IP セグメントを割り当て、カーネルがトラフィック層で実際の解決と転送を完了させることで、OS の DNS に直接依存することによる汚染問題を回避します。この部分を詳しく説明すると TUN モードの全体の流れに踏み込むことになり本稿の主題からは外れますが、ここでは dns セクションと rules セクションが独立しつつ互いに影響し合う2本のパイプラインであることを知っておけば十分です。

proxies:ノード定義

proxies はリストで、各項目が具体的な1つのプロキシノードを記述します。プロトコルによってフィールドは多少異なりますが、いずれも同じ構造に従います。name は後段の参照で使用する一意の識別子、type はプロトコル(ss、vmess、trojan、hysteria2 など)を決定し、その他のフィールドはそのプロトコル固有の接続パラメータです。

proxies:
  - name: "HK-01"
    type: ss
    server: hk01.example.com
    port: 443
    cipher: aes-256-gcm
    password: "your-password"
  - name: "SG-01"
    type: vmess
    server: sg01.example.com
    port: 443
    uuid: 0000-uuid-example
    alterId: 0
    cipher: auto

ここで最も見落とされやすいのは、name は単なる文字列識別子であり、クライアントはそれと実際のノードの地理的位置が一致しているかをチェックしないという点です。ラベルを間違って書いてもエラーにはならず、後でポリシーグループでノードを選ぶ際に誤解を招くだけです。プロバイダが提供するサブスクリプションリンクは本質的に完全な proxies リストを生成するものであり、サブスクリプション変換サービスが行っているのは、異なる形式のノード情報をこの構造に統一変換することです。

proxy-groups:ポリシーグループ

proxy-groups もリストですが、各項目が定義するのはノードそのものではなく「複数のノードやポリシーグループの中からどのように1つを選ぶか」です。ポリシーグループの proxies フィールドにはノード名だけでなく別のポリシーグループの名前も記述でき、この入れ子構造が多層振り分け(例えば「自動選択」の中にさらに「手動選択」を組み込む)を構築する基礎になります。

• select:手動選択。クライアントの画面上では切り替え可能なリストとして表示され、手動でノードを選びたい場面に適します。
• url-test:レイテンシに基づく自動選択。クライアントが指定した URL で定期的に速度を測り、最も低遅延のノードに自動的に切り替えます。
• fallback:フェイルオーバー。リストの順に順番に試し、現在のノードが使えなくなると自動的に次に切り替えます。
• load-balance:複数ノードによる負荷分散。ポリシー(例:コンシステントハッシュ)に基づき異なる接続を複数ノードに分散させます。

proxy-groups:
  - name: "自動選択"
    type: url-test
    proxies:
      - HK-01
      - SG-01
    url: "https://www.gstatic.com/generate_204"
    interval: 300

  - name: "ノード選択"
    type: select
    proxies:
      - 自動選択
      - HK-01
      - SG-01
      - DIRECT

最後のポリシーグループに登場する DIRECT と REJECT に注目してください。これは2つの組み込み特殊識別子で、proxies の中で定義する必要はありません。DIRECT はプロキシを経由せず直接接続することを表し、REJECT は接続を直接拒否することを表します。これらはどのポリシーグループの候補リストにも登場でき、rules セクションで直接ターゲットポリシーとして使うこともできます。これは多くの人が見落としがちな細部です。

rules:振り分けルール

rules セクションは、各ネットワークリクエストを最終的にどのポリシーグループに処理させるかを決める部分であり、設定全体の中で1行ずつマッチングされ、順番に有効になる部分です——先に書かれたルールほど優先度が高く、あるルールがヒットすると、それ以降のルールはチェックされません。ルールの基本形式は「マッチ種別,マッチ内容,ターゲットポリシー」で、よく使われるマッチ種別は次のとおりです。

• DOMAIN-SUFFIX:ドメイン名の末尾でマッチし、あるドメインとそのすべてのサブドメインをカバーします。
• DOMAIN-KEYWORD:ドメイン名に指定キーワードが含まれていればマッチします。サフィックスよりマッチ範囲が広く、誤爆しやすい点に注意が必要です。
• IP-CIDR / IP-CIDR6:IP セグメントでマッチします。日本国内の IP セグメントを直接接続にする場合などによく使われます。
• GEOIP:IP の所属する地理的位置でマッチします。ローカルの GeoIP データベースに依存します。
• MATCH:デフォルトルール。最後の1行に置き、それまでのルールにヒットしなかったすべてのトラフィックにマッチします。

rules:
  - DOMAIN-SUFFIX,cn,DIRECT
  - DOMAIN-KEYWORD,google,ノード選択
  - GEOIP,CN,DIRECT
  - MATCH,ノード選択

ルールの3番目の項目に書くのはポリシーグループの名前(または DIRECT/REJECT)であり、ノード名を直接書くことはできません——これは初心者が最もよく踏む落とし穴の1つです。proxies にしか存在せず、どのポリシーグループにも登場していない名前を rules に書くと、クライアントは設定読み込み時にエラーを出します。あるルールが実際に有効になっているかを素早く特定したい場合は、log-level を一時的に debug に変更すると、各リクエストがどのルールにマッチしたかがログに出力されます。

最小構成のサンプル:4つのセクションをつなぎ合わせる

前述の4つのセクションを順につなぎ合わせると、そのまま動作させられる最小構成の設定になります。すべてのシナリオを網羅しているわけではありませんが、各セクションの連携関係を説明するには十分です——dns がドメイン名の解決方法を決め、proxies が利用可能なノードを提供し、proxy-groups がノードを切り替え可能なポリシーとして組み立て、rules が具体的なトラフィックをあるポリシーグループに振り分けます。

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

dns:
  enable: true
  nameserver:
    - https://doh.pub/dns-query

proxies:
  - name: "HK-01"
    type: ss
    server: hk01.example.com
    port: 443
    cipher: aes-256-gcm
    password: "your-password"

proxy-groups:
  - name: "ノード選択"
    type: select
    proxies:
      - HK-01
      - DIRECT

rules:
  - DOMAIN-SUFFIX,cn,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,ノード選択

この設定をどの Clash Meta カーネルクライアントに入れても、サーバーアドレスとパスワードを差し替えればそのまま動作します。多くのプロバイダが提供する完全な設定やサブスクリプションリンクは、展開してみれば本質的にこの4セクションの拡張版です——ポリシーグループの数が増え、ルールの行数が長くなり、追加でルールセットやグループ速度テストの URL が組み込まれているだけで、骨格は変わりません。

よくあるトラブルシュートの流れ

設定ファイルのエラーや振り分けの異常は、基本的に以下の順序でチェックできます。

1. YAML の文法レベル

   インデントが統一されているか(タブとスペースの混在は禁止)、コロンの後にスペースがあるか、特殊文字を含むパスワードが引用符で囲まれているか。ほとんどのクライアントは読み込み失敗時にログで具体的な行番号を示します。

2. 参照が存在しているか

   rules のターゲットポリシーグループ名、proxy-groups で参照しているノード名が、対応するセクションに実際に存在しているかを確認します。大文字・小文字を含め完全に一致している必要があります。

3. ルールの順序が適切か

   広範囲にマッチするルール(ある DOMAIN-KEYWORD など)を精密なルールより前に置いておらず、それによって後段のより具体的なルールが永久にマッチしない状態になっていないかを確認します。

4. DNS を単独でテストしたか

   mode を一時的に global に切り替え、振り分けルールの問題なのか DNS 解決段階の問題なのかを区別し、そのうえで段階的に調査範囲を絞ります。