Clash 設定ファイル構造解説:YAML 各セクションの項目と書き方

設定ファイル概要:YAML 構文の基礎とトップレベル構造

Clash と Clash Meta(mihomo コア)の設定ファイルはいずれも一つの YAML テキストで、通常 config.yaml という名前で保存されます。サブスクリプションリンクの中身も実は同じ形式のファイルで、クライアントはダウンロード後にローカルディレクトリへ保存してから解析・読み込みを行います。ファイル全体はトップレベルのキーで構成され、よく見るキーには port、socks-port、mixed-port、allow-lan、mode、log-level、dns、proxies、proxy-groups、rules、そして Meta コア独自の tun があります。これらのキーは同じインデント階層にあり互いに従属関係はなく、理論上は順序が解析に影響しませんが、トラブル調査をしやすくするため、多くの設定では動作パラメータを先頭に、ルールを最後に置く習慣があります。

YAML は空白によって階層関係を表現し、Tab キーは認識せず半角スペースのみを使い、同じ階層のインデント量は完全に一致させる必要があります。文字列の多くは引用符が不要ですが、値にコロンやシャープが含まれる場合や、数字で始まるものの文字列として扱いたい場合は、半角の引用符を付けるべきです。リスト項目はハイフンとスペースで始まり、辞書項目はコロンとスペースでキーと値を区切ります。これらのルールは一見単純ですが、後述するエラーの大半の根本原因になるため、設定を編集する前にしっかり覚えておくことをおすすめします。

基本動作セクション:ポート、LAN、動作モード

設定ファイルの最上部には、通常クライアント自身の挙動を制御する項目群があり、待ち受けポート、LAN 内デバイスの接続許可、トラフィックの処理モードなどを決めます。

port: 7890
socks-port: 7891
mixed-port: 7893
allow-lan: true
bind-address: "*"
mode: rule
log-level: info
external-controller: 127.0.0.1:9090

• port:HTTP プロキシの待ち受けポート。システムのプロキシ設定で入力する値がこれです。
• socks-port:SOCKS5 プロキシのポート。一部のコマンドラインツールやゲームクライアントはこのプロトコルを個別に設定する必要があります。
• mixed-port:同一ポートで HTTP と SOCKS5 のリクエストを両方受け付けます。現在の GUI クライアントの多くはこのポートのみを使い、port/socks-port はどちらか一方だけ残しても構いません。
• allow-lan:同一 LAN 内の他のデバイスが自分のプロキシ経由でインターネットに出られるかどうか。既定値は false で、スマートフォンやタブレットにプロキシを共有する場合は true に変更します。
• mode:コアの動作モード。rule(ルールベースの振り分け)が最も一般的な選択で、global はすべての通信を同じノードに流し、direct はプロキシを一切使わず、一時的な検証にのみ使います。
• log-level:ログの詳細度。問題を調査する際は一時的に debug に変更でき、通常運用では info か warning を維持し、ログパネルの情報量が多すぎて見にくくなるのを避けます。

DNS セクション:項目の意味とよくある設定値

dns セクションは名前解決の方式を制御します。適切に設定すれば DNS リークや解決遅延を減らせますが、設定が不適切だとサイトが開けない、あるいは間違ったアドレスに解決されるといった問題が起きやすくなります。よくある書き方は次の通りです。

dns:
  enable: true
  ipv6: false
  default-nameserver:
    - 223.5.5.5
    - 119.29.29.29
  nameserver:
    - https://doh.example-provider.net/dns-query
    - tls://dot.example-provider.net:853
  fallback:
    - https://fallback-doh.example-provider.net/dns-query
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "localhost.ptlogin2.qq.com"

• enable:内蔵 DNS サーバーによる名前解決を有効にするかどうか。無効にするとシステム自体の DNS 設定にフォールバックします。
• default-nameserver:nameserver に記載した DoH/DoT アドレス自体のドメイン名を解決するために使われます。純粋な IP のみを記入し、ドメイン名を指定してはいけません。指定すると「解決サーバーのドメインをどう解決するか」という循環問題が発生します。
• nameserver:実際に日常のドメイン名解決に使うサーバー一覧です。従来の UDP アドレスに加え、https:// で始まる DoH や tls:// で始まる DoT にも対応しており、暗号化された解決を使うと通信事業者によるハイジャックの可能性を減らせます。
• fallback:nameserver による解決結果が汚染されている可能性があると判断された場合に使われる代替の解決先リストで、通常は fallback-filter と併用します。
• enhanced-mode:拡張モード。fake-ip はドメイン名に仮の内部アドレスを割り当て、出口で実際のドメインへ復元する方式で、互換性が高く多くのクライアントの既定値です。redir-host はより古い互換方式で、現在は推奨されません。
• fake-ip-filter:fake-ip の対象から除外するドメインのリストです。LAN 内のデバイス名や社内ネットワークのドメインなどはこのリストに追加しておくべきで、追加しないと社内サービスにアクセスできなくなることがあります。

proxies セクション:ノード項目の書き方

proxies はリストで、各項目が利用可能な一つのプロキシノードを表します。よく使われるプロトコルには ss(Shadowsocks)、vmess、trojan、そして Meta コアが追加で対応する hysteria2 などがあります。プロトコルによって項目は多少異なりますが、いずれも名前・サーバーアドレス・ポートという基本の 3 項目を含みます。

proxies:
  - name: "サンプル-香港-01"
    type: ss
    server: node1.example-relay.net
    port: 8388
    cipher: aes-256-gcm
    password: "your-password"
    udp: true

  - name: "サンプル-日本-01"
    type: vmess
    server: node2.example-relay.net
    port: 443
    uuid: 11111111-2222-3333-4444-555555555555
    alterId: 0
    cipher: auto
    tls: true
    network: ws
    ws-opts:
      path: /path
      headers:
        Host: node2.example-relay.net

• name:クライアント画面に表示されるノード名です。後述の proxy-groups でノードを参照する際はこの名前で照合されるため、名前を変更したらグループ側の参照が食い違っていないか合わせて確認してください。
• type:プロトコルの種類で、後続でどの追加項目が必要かを決定します。
• server / port:ノードのサーバーアドレスとポートで、サブスクリプション提供元から得た情報をそのまま使います。
• udp:そのノードで UDP 転送を有効にするかどうか。オンラインゲームや一部の音声通話は UDP に依存するため、クライアントが対応していれば有効にしておくことをおすすめします。
• tls / network / ws-opts:トランスポート層と TLS 関連の設定で、WebSocket のパスや偽装ドメインなどに関わります。通常はサブスクリプション提供元が示すパラメータをそのまま使い、手動で変更する前に元のファイルをバックアップしておくとよいでしょう。

ほとんどのユーザーはこのセクション全体を手書きする必要はありません。サブスクリプションリンクが更新されるとクライアントが自動的にこの部分を再生成するため、手動編集は主にローカルの自前ノードを個別に調整したり、特定の項目の誤りを一時的に修正したりする用途に使われます。

proxy-groups セクション:グループの種類と書き方

proxy-groups はノードがどう分類・表示され、切り替えや測速がどのように動作するかを決めます。各グループには少なくとも name、type、proxies の 3 項目が必要です。

proxy-groups:
  - name: "自動選択"
    type: url-test
    url: "https://www.gstatic.com/generate_204"
    interval: 300
    tolerance: 50
    proxies:
      - "サンプル-香港-01"
      - "サンプル-日本-01"

  - name: "ノード選択"
    type: select
    proxies:
      - "自動選択"
      - "サンプル-香港-01"
      - "サンプル-日本-01"
      - DIRECT

  - name: "フェイルオーバー"
    type: fallback
    url: "https://www.gstatic.com/generate_204"
    interval: 300
    proxies:
      - "サンプル-香港-01"
      - "サンプル-日本-01"

• select:手動選択型のグループで、画面上はドロップダウンリストとして表示され、最外層に置いてユーザーに手動で切り替えてもらうのに向いています。
• url-test:自動測速型のグループで、interval で指定した周期(単位は秒)ごとに url へアクセスして遅延を測定し、遅延が最も低く tolerance の許容範囲内で優れているノードを自動的に選択します。
• fallback:フェイルオーバー型のグループで、リストの順に試行し、現在のノードが使えなくなると自動的に次のノードへ切り替わります。速度よりも安定性を重視する場面に向いています。
• load-balance:負荷分散型のグループで、戦略に応じてリクエストを複数のノードへ振り分けます。複数ノードで帯域を合算したい場面に向いています。

グループの proxies リストには具体的なノード名だけでなく、別のグループ名を書くこともでき、さらに組み込みの DIRECT(直接接続)や REJECT(拒否)という戦略名を書くこともできます。これは「ノード選択」グループの中に「自動選択」グループを入れ子にする、よくある書き方です。

rules セクション:ルールの構文とマッチング順序

rules セクションは振り分けが実際に機能する部分で、各行は「ルールタイプ,マッチ内容,対象ポリシー」という固定形式です。上から下へ順に照合し、最初に一致した行で処理を止めて以降のルールは適用されません。そのため順序が非常に重要です。

rules:
  - DOMAIN-SUFFIX,example-streaming.com,ノード選択
  - DOMAIN-KEYWORD,example-ads,REJECT
  - DOMAIN,api.example-tool.dev,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,ノード選択

• DOMAIN / DOMAIN-SUFFIX / DOMAIN-KEYWORD:それぞれ完全一致、ドメインサフィックス一致、ドメインに含まれるキーワード一致を表します。サフィックス一致が最もよく使われ、1 行で一つのドメイン配下のすべてのサブドメインをカバーできます。
• IP-CIDR / IP-CIDR6:IP レンジで一致させます。LAN アドレスや内部ネットワークアドレスを直接直結させる用途によく使われ、no-resolve はドメインの追加解決を行わず対象 IP だけで判定することを表し、不要な DNS クエリを減らせます。
• GEOIP:対象 IP が属する国や地域で一致させます。GEOIP,CN,DIRECT はほぼすべての設定に残されている一行で、中国本土のアドレスを直結させ、プロキシによる不要な迂回を減らします。
• MATCH:デフォルトルールで、必ず最後の行に置き、それまでのルールに一致しなかった通信をどう処理するかを表します。この行を書き忘れると、一致しなかった通信の挙動が不定になります。

ルール内に出てくるポリシー名は proxy-groups の name と完全に一致していなければならず、大文字小文字や全角・半角文字の違いも含みます。これは初心者が最も見落としやすい点の一つで、グループは確かに存在するのにルールが「ポリシーが存在しない」と表示される場合、多くは名前の一文字を打ち間違えていることが原因です。

よくあるインデント・構文エラーの確認方法

設定ファイルを手動編集してエラーになる場合、9 割以上はインデントか記号の問題です。次の順序で確認するとよいでしょう。

1. Tab とスペースが混在していないか確認し、テキストエディタで Tab をスペース 2 個または 4 個に統一置換し、全体で揃えることをおすすめします。
2. 同じ階層のリスト項目が揃っているか確認します。例えば proxies 配下の各 - name: の前のスペース数は同じでなければなりません。
3. 文字列に引用符が必要かどうか確認します。UUID やパスワードにコロンが含まれる場合、数字で始まる文字列の場合は、統一して半角のダブルクォートを付け、YAML に文字列以外の型として解釈されるのを避けます。
4. ルール行のコンマが全角コンマになっていないか確認します。全角コンマは YAML では区切り文字として認識されず、ルール全体が無効になったりエラーになったりします。
5. どの行でエラーが出ているのか特定できない場合は、設定を段落ごとにコメントアウトしてから一段ずつ戻していくと、問題の範囲を早く絞り込めます。

変更後の確認方法

設定を保存したら、多くのクライアントは画面上で直接「設定を再読み込み」でき、プログラム全体を再起動する必要はありません。読み込みに失敗した場合、クライアントは通常ログパネルやポップアップに具体的なエラー行番号を表示するので、上記の確認順序に沿って対応すればほぼ特定できます。読み込みに成功したら、次の点で修正が実際に反映されているか確認することをおすすめします。

• プロキシページで対象グループ配下のノード一覧が、いま編集した内容と一致しているか確認する。
• ログページに切り替えてログレベルを debug にし、テスト用のドメインにアクセスして、想定したルールとポリシーに一致しているか観察する。
• コマンドラインツールで既知の検出用アドレスにアクセスし、返された出口情報が想定したノードと一致することを確認したら、ログレベルを日常利用の info に戻す。