Clash 設定ファイル解説:YAML 各項目を port から rules まで逐条解析

設定ファイルの本質:1つの YAML テキスト

Clash と mihomo(Clash Meta)コアのすべての動作は、YAML 形式の1つの設定ファイルによって決まります。サブスクリプションリンクからダウンロードしたファイルは、実質的にはサーバー側が事前に用意した YAML です。クライアント画面上のモード切替やノード選択も、最終的にはすべてこのファイルの項目に反映されます。構造を理解すれば、ポート変更・ルール追加・DNS 調整も、対応する箇所を見つけて数行書き換えるだけの作業になります。

YAML の文法で押さえるべき点は3つだけです。インデントは半角スペースのみを使い、タブは禁止。階層は基本的に半角スペース2つで表現します。キーと値はコロン(:)で区切り、コロンの後には必ず半角スペースを入れます。ハイフンで始まる行はリスト項目、# 以降はコメントです。設定ファイル全体はいくつかのトップレベル項目で構成されており、主な項目と役割は以下の通りです。

この中で proxies、proxy-groups、rules の3項目が通信の振り分けを決定し、本稿の中心テーマです。dns 項目はドメイン名の解析方法を決め、その他の項目はポートや動作全般を制御します。以下、順に解説します。

ポートと全体設定項目:mixed-port から external-controller まで

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

mixed-port は混合ポートで、HTTP と SOCKS5 のリクエストがここからコアに入ります。ほとんどのクライアントやサブスクリプションではデフォルトで 7890 番が使われます。旧設定で分けて書かれていた port(HTTP 専用)や socks-port も引き続き有効ですが、新しい設定では mixed-port 1つにまとめれば十分です。

• allow-lan:true に設定すると、同一 LAN 内のスマホやタブレットからこの端末をプロキシゲートウェイとして利用できます。bind-address はどのネットワークカードでリスニングするかを制御します。公共のネットワーク環境では false のままにしてください。
• mode:rule は rules の内容に従って振り分け、global は選択中のプロキシグループをすべての通信で使用、direct はすべて直接接続します。クライアント画面上のモード切替は、この項目を書き換えているだけです。
• log-level:通常は info で十分です。接続の問題を調査する際は一時的に debug に変更し、silent にすると出力を完全に停止します。
• external-controller:コアの RESTful API のリスニングアドレスで、metacubexd や yacd などの Web パネルはここを通じて状態取得やノード切替を行います。別の行に secret を書いてアクセスキーを設定すれば、ポートが外部に公開されても不正操作を防げます。

mihomo の設定では unified-delay、tcp-concurrent、find-process-mode などの拡張項目もよく見られますが、これらは Meta コア専用です。原版 Clash はこれらの未知の項目を読み込むとエラーになるため、コアを混在させる場合は注意が必要です。

dns 項目:ドメイン名の解析方法

dns:
  enable: true
  listen: 0.0.0.0:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - 223.5.5.5
    - 119.29.29.29
  fallback:
    - tls://1.1.1.1
    - https://dns.google/dns-query
  fake-ip-filter:
    - "*.lan"
    - "*.local"

enable は総合スイッチで、TUN モードを使う場合は必ず有効にする必要があります。listen は内蔵 DNS サービスのリスニングアドレスで、システムからのドメイン名クエリはここに送られ、コアが設定に従って上流に転送します。

• enhanced-mode:fake-ip モードでは、コアが先に仮の IP を返し、接続が確立した後にドメイン名で振り分けを行うため、速度が速く判定も正確です。redir-host は旧方式で、新しいコアでは徐々に廃止されているため、fake-ip のままで問題ありません。
• fake-ip-range:仮 IP のアドレスプールで、デフォルトは 198.18.0.1/16 です。通常は変更する必要はありません。
• nameserver:デフォルトの上流リゾルバです。3種類の書き方があります――純粋な IP は UDP、tls:// で始まるものは DoT、https:// で始まるものは DoH を使用します。
• fallback:海外ドメインを解析する際の上流指定で、旧バージョンの書き方です。mihomo では nameserver-policy の使用が推奨されており、ドメインの末尾ごとに異なる上流を指定できます。
• fake-ip-filter:このリストに含まれるドメインには仮 IP を返しません。LAN 内のホスト名や、一部の QR コードログイン用ドメインをここに入れることが多いです。

proxies 項目:ハイフン1つが1つのノード

proxies:
  - name: "香港01"
    type: ss
    server: hk1.example.com
    port: 8388
    cipher: aes-128-gcm
    password: "example-password"
    udp: true
  - name: "日本01"
    type: vmess
    server: jp1.example.com
    port: 443
    uuid: 00000000-0000-0000-0000-000000000000
    alterId: 0
    cipher: auto
    tls: true
    network: ws

proxies はノードの一覧で、各ハイフンの項目が1つのノードを表します。name は表示名、type はプロトコル、server と port はサーバーアドレスです。その他の項目はプロトコルによって異なります。ss は cipher と password が必要、vmess は uuid、alterId、cipher が必要、vless は uuid が必要、trojan は password と sni が必要、hysteria2 は password が必要です。udp: true は UDP 通信の転送を許可することを意味します。

mihomo が対応するプロトコルは原版 Clash より豊富です。原版は ss、ssr、vmess、trojan、snell などに対応しますが、Meta コアはさらに vless、hysteria、hysteria2、tuic などに対応しています。この項目はほぼ常にサブスクリプションによって自動生成されるため、手動で編集する前に、次回サブスクリプションを更新すると手動編集の内容は上書きされる点を確認してください。

proxy-groups 項目:画面上で切り替える対象

proxy-groups:
  - name: "自動選択"
    type: url-test
    proxies:
      - "香港01"
      - "日本01"
    url: "http://www.gstatic.com/generate_204"
    interval: 300
    tolerance: 50
  - name: "手動選択"
    type: select
    proxies:
      - "自動選択"
      - "香港01"
      - "日本01"
      - DIRECT

クライアント画面で選ぶのは、実は単一のノードではなくプロキシグループです。type には4種類あります。select は手動選択、url-test は遅延に基づいて自動で最速ノードを選択、fallback は可用性に応じて順番に切り替え、load-balance は複数ノードに接続を分散します。

• url:遅延テストの対象アドレスで、よく使われるのは http://www.gstatic.com/generate_204 です。
• interval:自動速度テストの間隔で、単位は秒。300 なら5分ごとに1回テストします。
• tolerance:許容値で単位はミリ秒。新たに測定したノードの遅延が現在のノードよりこの数値以上低くならないと切り替わらないため、頻繁な切り替えを防ぎます。

グループの proxies リストには、ノード名だけでなく別のグループ名も書くことができ、「手動選択 → 自動選択 → 複数ノード」のような入れ子構造を作れます。DIRECT と REJECT という2つの内蔵ポリシーも指定可能です。rules 項目が参照するのはグループ名であり、ノードはサブスクリプションの更新に伴い変わっても、グループの構造自体は変わりません。

rules 項目:上から順に、一致した時点で停止

rules:
  - DOMAIN-SUFFIX,ads.example.com,REJECT
  - DOMAIN-KEYWORD,bilibili,DIRECT
  - GEOSITE,cn,DIRECT
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - GEOIP,CN,DIRECT,no-resolve
  - MATCH,手動選択

ルールは上から下へ順に照合され、一致した時点で処理を停止します。つまり記載順序がそのまま優先順位です。最後に書かれた MATCH は受け皿ルールで、それまでのどのルールにも一致しなかった通信をすべて受け止めます。各ルールは「種類・照合値・振り分け先」の3要素で構成されます。振り分け先にはプロキシグループ名、ノード名のほか、DIRECT(直接接続)や REJECT(拒否)も指定できます。

誤りやすい点が2つあります。1つ目は、IP-CIDR や GEOIP のように IP で判定するルールは、ドメインへのリクエストに対して DNS 解析を1回発生させてしまう点です。no-resolve パラメータを付けることで事前解析を回避し、判定を後続のドメインルールに委ねられます。2つ目は、GEOSITE は mihomo のみが対応しており geosite データファイルに依存するため、原版 Clash が読み込むとエラーになる点です。GEOIP は両方のコアが対応していますが、データファイルの形式はコアによって異なります。

変更後の反映方法とよくあるエラー

デスクトップクライアントで設定を変更した後は、設定ページで再読み込みをクリックするだけです。mihomo はホットリロードに対応しているため、プログラムを再起動する必要はありません。コマンドラインで動かしている mihomo は、API 経由で新しい設定を送信すれば更新が完了します。

その他よくある問題として、次の2つがあります。1つはポートの競合で、7890 番が他のプログラムに使われているとコアが起動に失敗するため、mixed-port を変更するか、占有しているプロセスを終了させます。もう1つは rules を変更しても反映されない場合で、多くは前方に書かれたより広範なルールが先に一致してしまっているケースです。log-level を debug に変更すると、ログにルールの一致記録が表示され、各通信が実際にどのルールに一致したかを確認できます。

設定ファイルの構造はこれだけです。ポート関連の項目が入口を決め、dns が解析方法を決め、proxies がノード一覧、proxy-groups が切替スイッチ、rules が振り分け表です。この順序で自分のサブスクリプション設定を読み返せば、すべての行の意味が理解できるはずです。