上級設定 読了目安:9分

Clash 設定ファイル YAML 構造セクション別解説:ポート設定から rules ルール段まで

config.yaml を上から下へ順にたどりながら、共通のポート・モード設定、dns、proxies、proxy-groups、rules ——各セクションの役割を一つずつ解説し、よくあるインデントミスやフィールド名の誤字といった落とし穴も指摘する。

Clash と Clash Meta(mihomo)の核心となる設定ファイルは、いずれも1つの YAML ドキュメントであり、慣例的に config.yaml と名付けられている。いくつかのトップレベルのセクションが連なって構成され、各セクションがそれぞれ1つの役割を担う——ポートと動作モード、DNSの解決方式、ノードリスト、策略グループ、振り分けルール。これらのセクションの前後関係とフィールドの意味を理解することは、なんらかの「万能設定」を丸暗記するより実用的だ。というのも、サブスクリプションが提供するリモート設定は手動で照合したり、ローカル設定とマージしたりする必要がよくあり、構造を理解していないと、インデントを1つ間違えただけでファイル全体が無効になりかねない。本稿ではファイルの上から下への順序に沿ってセクションごとに解説し、各セクションで実際に遭遇しやすい落とし穴も挙げていく。

共通設定セクション:ポート、モード、LAN許可

ファイルの先頭には、クライアント自体の動作を定義するフラットなキーバリューのまとまりがあり、個々のノードとは関係ない。よく使われるフィールドは次の通り:

port: 7890
socks-port: 7891
redir-port: 7892
allow-lan: false
mode: rule
log-level: info
external-controller: 127.0.0.1:9090

port はHTTPプロキシポート、socks-port はSOCKS5プロキシポートで、両者は互いに影響せず、同時に有効にしても片方だけ残してもよい。redir-port は透過プロキシ用で、一般的なデスクトップ利用ではほとんど必要ない。allow-lan はLAN内の他デバイスが本機のIP経由でプロキシを使えるかを決めるもので、スマートフォンやルーターにネット共有する場合は true に変更する必要があり、同時にファイアウォールで該当ポートを許可しておく点にも注意する。

mode には3つの値がある:rule はルールセクションに従って振り分け、global はすべての通信を強制的に特定ノードへ流す(ノード自体の可用性を確認する際によく使う)、direct はすべて直接接続してプロキシを経由しない。通常は rule を維持し、ノードの接続テストをする時だけ一時的に global に切り替え、テスト後は必ず戻すこと。そうしないと「ルールを設定したのに全部プロキシ経由になっている」という誤解が生じる。external-controller を有効にすると、クライアントはローカルAPIポートを公開し、Dashboardパネルやサードパーティツールが動作状態を読み取れるようにする。この機能が不要であれば、この行を空欄にするか削除してよい。

dnsセクション:解析方式が振り分けの精度を左右する

dnsセクションはドメイン名の解析動作を制御し、設定が不適切だとルール振り分けの精度に直接影響する。特にTUNモードを有効にしている場合は要注意だ。よく見られる書き方は次の通り:

dns:
  enable: true
  ipv6: false
  default-nameserver:
    - 223.5.5.5
    - 119.29.29.29
  nameserver:
    - https://doh.pub/dns-query
    - tls://dns.rubyfish.cn:853
  fallback:
    - https://1.1.1.1/dns-query
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - localhost.ptlogin2.qq.com

default-nameserver は、下の nameserver にあるDoH/DoTアドレス自体のドメイン名を解決するためのサーバーで、必ず純粋なIPアドレスを指定しなければならず、ドメイン名を指定してはいけない。そうしないと「解決サーバーのドメイン名を解決する」という循環依存が生じ、起動時にエラーになる。nameserver は実際に名前解決を提供するサーバーの一覧で、fallback は nameserver の判定結果が汚染されている可能性がある場合に使う代替リストで、地理的位置や返されたIP範囲で判断する fallback-filter と組み合わせることが多い。

fake-ip-range はTUNモードと組み合わせて使う。クライアントはドメイン名に対して、指定した仮IP範囲内のアドレスを割り当て、通信レイヤーで実際のドメイン名に戻してルールとマッチングする。これにより、グローバルプロキシモードでもドメイン名ベースの振り分けルールを有効に機能させられる。fake-ip-filter に列挙されたドメイン(社内ドメインやLAN内デバイス名など)には仮IPが割り当てられず、実際のDNS解決が使われる。この項目を誤って設定すると、LAN内のデバイス(NAS、プリンター、ルーターの管理画面など)に突然アクセスできなくなることが多い。

注意:TUNモードを使う予定がなく、fake-ip の影響範囲もはっきりしない場合は、dnsセクション全体をデフォルトのままにするか、サブスクリプション提供元の設定をそのまま使うのがよい。フィールドを勝手に省略しないこと。DNS設定の誤りは「一部のサイトは開けるが一部は開けない」という形で現れることが多く、原因調査のコストが高い。

proxiesセクション:ノードリストのフィールド仕様

proxies は配列で、各要素が1つのノードを表し、フィールドはプロトコルの種類によって異なる。最も一般的な ss(Shadowsocks)と vmess を例に挙げる:

proxies:
  - name: "HK-01"
    type: ss
    server: hk01.example-node.invalid
    port: 8443
    cipher: aes-256-gcm
    password: "your-password-here"

  - name: "SG-02"
    type: vmess
    server: sg02.example-node.invalid
    port: 443
    uuid: 00000000-0000-0000-0000-000000000000
    alterId: 0
    cipher: auto
    tls: true
    network: ws
    ws-opts:
      path: /ws

頻出する落とし穴がいくつかある:name は人間が識別するための名前で、proxy-groups がノードを参照する際にこの名前で厳密にマッチングする。名前を変更した際に proxy-groups 側の参照を同期して変更しないと、そのノードは策略グループの中から「消える」。type はその項目の以降のフィールドの解析方式を決める。誤字(例えば vmess を vmes と書いてしまう)があると、そのノードは丸ごと無視される。多くの場合クライアントはエラーを出さず、ただノードリストが1つ少なくなるだけなので、見落とされやすい。password、uuid は英数字の引用符で囲むことを推奨する。特にパスワードに : や # などYAMLの特殊文字が含まれる場合、引用符を付けないと別の構造として解析されてしまい、ノード全体が無効になる。

ノードがサブスクリプションリンクから自動生成される場合、proxies セクションは通常手動で編集する必要はなく、クライアントがサブスクリプション取り込み時に自動的に埋め込む。自前で構築したノードや、単体のノードを手作業で追加する場合にのみ、このセクションを直接編集することになる。

proxy-groupsセクション:ノードを選択可能な策略グループに整理する

proxy-groups は、ユーザーがクライアント画面で見て切り替えられる選択肢と、rules セクションが最終的に参照する振り分け出口を決める。最も一般的な3種類のタイプは次の通り:

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

  - name: "フェイルオーバー"
    type: fallback
    proxies:
      - HK-01
      - SG-02
    url: "http://www.gstatic.com/generate_204"
    interval: 300

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

url-test はレイテンシに基づいて現在最速のノードを自動選択し、fallback はリスト順に最初に使用可能なノードを優先的に使い、select は手動選択で、ユーザーがクライアント画面上でクリックして選べる。注意すべきは、select タイプの proxies リストの中に別の策略グループの名前(上の例の「自動選択」など)を直接参照できることで、これは策略グループを入れ子にする一般的な書き方であり、「自動速度計測」を「ノード選択」の中の1つの選択肢として組み込むのに便利だ。proxies リストに書く名前は、proxies セクションの name または別の策略グループの name と完全に一致していなければならず、大文字小文字や全角半角文字も揃える必要がある。1文字でも間違えると、その策略グループの起動時にエラーになるか、その選択肢が静かに除外される。

interval は速度計測の間隔で単位は秒。値を小さくしすぎると計測頻度が増え、余分な通信量とバッテリー消費を招く。url には接続確認専用の検出用アドレスを使うことを推奨し、一般的なウェブサイトのアドレスは避けるべきだ。そうしないと計測結果がそのサイト自体の応答速度に影響されてしまう。

rulesセクション:振り分けルールのマッチング順序と書き方

rules はファイルの最後のセクションであり、上から下へ1行ずつマッチングを行い、最初にマッチした行で処理を停止するセクションでもある。順序の誤りは最もよくあり、かつ自分で気づきにくい問題だ。基本的な文法は次の通り:

rules:
  - DOMAIN-SUFFIX,google.com,ノード選択
  - DOMAIN-KEYWORD,github,ノード選択
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,ノード選択

各行は「マッチタイプ、マッチ内容、出口策略グループ」の3つの部分から構成され、一部のタイプにはさらに4番目の任意パラメータが付く(例えば no-resolve はそのルールに対してDNS解析を行わないことを示し、効率を上げるためIPセグメントのルールでよく使われる)。DOMAIN-SUFFIX はドメイン名とそのサブドメインにマッチし、DOMAIN-KEYWORD はドメイン名に含まれるキーワードにマッチし、IP-CIDR はIPセグメントにマッチし、GEOIP はIPが属する国/地域にマッチし、MATCH は兜底(フォールバック)ルールで、rules セクション全体の最後の行に置かなければならず、「上のどれにもマッチしない場合はここへ」を表す。

順序マッチングであるため、範囲の広いルール(例えば GEOIP,CN,DIRECT)を具体的なルールより前に書いてしまうと、後に続く特定ドメイン向けのルールは決して発動しなくなり、「あるサイトをプロキシ経由に設定したはずなのに実際には効いていない」という現象が起きる。正しい並べ方は、まず具体的なドメイン/アプリのルールを書き、その後に範囲の広い地域/IPセグメントのルールを書き、最後に MATCH で締めることだ。

おすすめ:ルールの数が多い場合は、ルールセットをリモートルールセット(rule-providers)として分割・参照することで、手書きの行数を減らしつつ一括更新もしやすくなる。具体的な書き方はクライアント付属のサンプル設定や、公式ドキュメントの rule-providers セクションの説明を参照してほしい。

よくあるインデントミスとフィールド名の誤字の落とし穴

YAMLはインデントに極めて敏感で、実際の利用では以下のような誤りが繰り返し発生している:

  • スペースとTabの混在:YAML仕様ではTabによるインデントは許可されておらず、テキストエディタがインデントを自動的にTabへ変換してしまうと、クライアントは起動時に構文エラーを出す。「Tabをスペースに置き換える」機能をサポートするエディタで設定ファイルを開くことを推奨する。
  • 同階層フィールドのインデント不一致:同じ配列要素内のフィールドは厳密に同じ列に揃えなければならず、スペースが1つ多いだけでも下位階層として解釈され、そのフィールドが無視されたり、ノード全体の解析が失敗したりする。
  • 引用符なしの文字列による型の誤判定:パスワードやUUIDにYAMLが特殊記号として扱う文字(コロン、シャープ、角括弧)が含まれる場合は必ず引用符を付ける必要があり、付けないと解析結果が想定と異なってしまう。
  • フィールド名の誤字はエラーにならない:多くのクライアントは未知のフィールドに対して「無視」する方針を取り、「エラーを出す」わけではない。例えば allow-lan を allow_lan と書いてしまっても、設定ファイルは正常に読み込まれ、その設定だけがひっそりと無効になる。原因調査の際に見落とされやすいので、重要なフィールドを変更した後はクライアントのログを再確認するか、公式のサンプルでフィールド名を照合することを推奨する。
  • proxy-groups が参照するノード名が存在しない:ノードの名前変更や削除後に参照を同期して更新しないと、策略グループの選択肢が1つ欠けるか、読み込み自体が失敗することもある。proxies セクションを変更した後は、全文検索でそのノード名が proxy-groups 内の参照でも同期更新されているか確認することを推奨する。

これらのセクション構造とよくある落とし穴を1つずつ照らし合わせながら設定ファイルを見直せば、「サブスクリプションは取り込めるのにルールが効かない」「ポートを変更したのに反映されない」といった問題の多くを特定できる。手動で変更した後にクライアントが起動しなくなった場合は、まず最近変更した部分のインデントを確認し、続いてフィールド名のスペルが公式ドキュメントと一致しているか確認するとよい。原因はほぼこの2種類のどちらかにある。

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