Clash YAML設定ファイルの各セクションを徹底解説

port、mode、dnsからproxies、proxy-groups、rulesまで、設定ファイルの順番に沿って各項目の意味・値・入力ミスによるエラーを解説します。

Clashの設定ファイルは通常YAMLで記述します。リスニングポート、動作モード、DNS、プロキシノード、プロキシグループ、ルールを1つのドキュメントにまとめて管理できます。キーの並び順は通常カーネルの読み込みに影響しませんが、「基本設定 → DNS → ノード → プロキシグループ → ルール」の順に書くと、参照関係やインデントミスを見つけやすくなります。

本記事では、Clash for Windows 0.20.39で一般的な設定構造と、mihomo v1.19系の設定仕様を基準に解説します。対応プロトコル、TUNパラメータ、DNSの拡張項目はカーネルによって完全には一致しません。サブスクリプションで生成された設定を変更する前に、次回更新で手作業の内容が上書きされないよう、ローカルにコピーを保存しておくことをおすすめします。

YAMLの構文とトップレベル構造

インデント、リスト、キーと値

YAMLではスペースで階層を表し、インデントにTabは使えません。一般的には1階層あたりスペース2個で記述します。コロンの後にはスペースを1つ入れ、リスト項目はハイフンで始めます。ノード、プロキシグループ、ルールはそれぞれ異なるトップレベルキーの下にあります。階層が1段ずれるだけで、ファイル全体を読み込めなくなることがあります。

port: 7890
mode: rule

proxies:
  - name: "サンプルノード"
    type: ss
    server: 203.0.113.10
    port: 443

proxy-groups:
  - name: "ノード選択"
    type: select
    proxies:
      - "サンプルノード"
      - DIRECT

rules:
  - MATCH,ノード選択

port: 7890 はキーと値の組です。proxies: の後にはリストが続きます。- name: で始まる各項目はノードオブジェクトです。コロン、シャープ、アスタリスク、または真偽値として解釈されやすい名前は、引用符で囲むのがおすすめです。たとえばノード名を "HK: 01" と書けば、コロンがマッピングの区切りとして扱われるのを防げます。

よくある解析エラー

ポート、LAN、動作モードの設定

ファイルの先頭には通常、受信待ち受けと基本的な動作パラメータを記述します。次の例ではHTTP、SOCKS5、混合プロキシにそれぞれポートを設定しています。実際には3種類のポートを同時に有効にする必要はなく、デスクトップクライアントでは mixed-port が最もよく使われます。

port: 7890
socks-port: 7891
mixed-port: 7892
allow-lan: false
bind-address: "*"
mode: rule
log-level: info
ipv6: false
external-controller: 127.0.0.1:9090
secret: "change-this-controller-secret"

3種類のプロキシポートの違い

同じIPアドレスとポートを2つのプログラムが同時に待ち受けることはできません。ログに address already in usebind: Only one usage of each socket address が表示された場合は、古いClashプロセス、別のプロキシツール、ローカル開発サービスがポートを使用していないか確認してください。Windowsではターミナルで netstat -ano | findstr :7890 を実行すると、該当するPIDを確認できます。

allow-lan と bind-address

allow-lan: false は、LAN内のデバイスにプロキシの入口を公開しない設定です。true に変更すると、スマートフォンや別のPCで、現在のPCのLANアドレス(例:192.168.1.20:7890)をプロキシサーバーとして指定できます。この場合は、Windowsファイアウォールで該当ポートの通信も許可してください。

bind-address は待ち受けアドレスを指定します。本機だけで使う場合は 127.0.0.1 にバインドすると明確です。LANからアクセスする場合は、カーネルの対応状況に応じて * または特定のネットワークアダプターのアドレスを使用できます。allow-lan だけを変更しても、他のデバイスから必ず接続できるとは限りません。ファイアウォール、ゲストネットワークの分離、ルーターのAP隔離もアクセスを妨げます。

mode、log-level、制御ポート

DNSセクション:待ち受け、リゾルバー、拡張モード

DNSセクションでは、ドメイン名をどのように解決するかを指定します。ルールの照合だけでなく、TUNモードでのドメイン通信の取り込みにも影響します。基本的な構成例は次のとおりです。

dns:
  enable: true
  listen: 127.0.0.1:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "localhost.ptlogin2.qq.com"
    - "+.msftconnecttest.com"
  default-nameserver:
    - 223.5.5.5
    - 1.1.1.1
  nameserver:
    - https://dns.alidns.com/dns-query
    - tls://1.1.1.1:853
  fallback:
    - https://dns.google/dns-query
  fallback-filter:
    geoip: true
    geoip-code: CN

enable、listen、default-nameserver

enable は内蔵DNSモジュールを制御します。listen はDNSサービスの待ち受けアドレスです。例ではローカルのUDP/TCPポート 1053 を使用しています。別のローカルDNSプログラムがこのポートを使っている場合、ログに待ち受けの失敗が表示されます。

default-nameserver は主に、DoHやDoTなど上流サーバー自身のドメイン名を解決するために使われます。ブートストラップDNSと呼ばれることもあります。循環依存を避けるため、ここには別の名前解決が必要なドメイン名ではなく、直接アクセスできるIPアドレスを指定するのが一般的です。

nameserver、fallback、ポリシー別名前解決

nameserver は主要なリゾルバーで、通常のDNSアドレス、DoH、DoTのいずれも指定できます。fallbackfallback-filter は、従来のClash設定でよく使われる予備の名前解決構成です。mihomoではさらに nameserver-policyproxy-server-nameserverdirect-nameserver などの項目にも対応しており、ドメインルールやプロキシノードの名前解決用途に応じて上流サーバーを使い分けられます。

「DNSを複数書いたから、すべてのリクエストが同時に全回答を使う」と考えないでください。カーネルは項目の意味、フィルター条件、応答結果に基づいて解決経路を選択します。ドメインは解決できるのにサイトが開けない場合は、DNSログ、ルールのヒット状況、ノード接続を同時に確認してください。ブラウザーのエラーだけで判断することはできません。

fake-ip と redir-host

proxies:個別プロキシノードの項目

proxies には手動で定義したノードを保存します。サブスクリプションでは通常、このセクションが自動生成されます。プロトコルによって項目は異なりますが、各ノードには少なくとも一意の名前、プロトコル種別、サーバーアドレス、ポートが必要です。

proxies:
  - name: "SS-HK-01"
    type: ss
    server: hk.example.net
    port: 443
    cipher: aes-128-gcm
    password: "example-password"
    udp: true

  - name: "VMess-JP-01"
    type: vmess
    server: jp.example.net
    port: 443
    uuid: 11111111-2222-3333-4444-555555555555
    alterId: 0
    cipher: auto
    tls: true
    servername: jp.example.net
    network: ws
    ws-opts:
      path: /gateway
      headers:
        Host: jp.example.net

共通項目とプロトコル固有の項目

ノードがリストに表示されることは、YAMLが解析されたことを示すだけで、接続パラメータが正しいとは限りません。認証情報の誤りはハンドシェイク失敗として現れることが多く、サーバーアドレスを解決できない場合はDNSエラーになります。WebSocketのパスやHostが一致しない場合は、接続確立直後に切断されることがあります。トラブルシューティングでは、クライアントの「ログ」を開いてレベルを一時的に debug に変更し、1つのノードを対象に遅延テストを実行してください。

proxy-providers と proxy-groups

ノードプロバイダー proxy-providers

proxy-providers では、ローカルファイルやリモートURLからノード群を読み込めます。すべてのノードを proxies に直接記述するよりも、ノードの取得元とプロキシグループの構成を分けて管理するのに適しています。

proxy-providers:
  provider-main:
    type: http
    url: "https://example.com/subscription"
    path: ./providers/provider-main.yaml
    interval: 3600
    health-check:
      enable: true
      interval: 600
      url: https://www.gstatic.com/generate_204

interval: 3600 は、3600秒ごとに更新を確認する設定です。ヘルスチェックの interval: 600 は、10分ごとにテストを実行することを示します。プロバイダーのダウンロードに失敗した場合は、サブスクリプションURLへのアクセス、システム時刻、プロキシ起動時の循環依存、保存先への書き込み権限を確認してください。

プロキシグループの種類と参照

proxy-groups:
  - name: "ノード選択"
    type: select
    proxies:
      - "自動選択"
      - "フェイルオーバー"
      - DIRECT
    use:
      - provider-main

  - name: "自動選択"
    type: url-test
    use:
      - provider-main
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 80

  - name: "フェイルオーバー"
    type: fallback
    use:
      - provider-main
    url: https://www.gstatic.com/generate_204
    interval: 300

tolerance: 80 は、遅延差が80ミリ秒以内なら自動選択グループが頻繁に切り替わらないようにする設定です。値が小さすぎると、軽微なネットワーク変動でノードが何度も切り替わります。大きすぎると、明らかに遅くなったノードを使い続けることがあります。家庭のブロードバンドでは、まず50~100ミリ秒から調整するとよいでしょう。

rules と rule-providers:分流ルールの照合順

rules は、接続をどのプロキシグループに渡すかを決めます。ルールは上から順に照合され、最初に一致した時点で処理が止まります。そのため、具体性の高いルールを前に置き、最後にデフォルトルールを配置するのが一般的です。

rules:
  - DOMAIN,api.example.com,ノード選択
  - DOMAIN-SUFFIX,example.net,ノード選択
  - DOMAIN-KEYWORD,stream,自動選択
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,ノード選択

よく使われるルール種別

no-resolve は、一部のIPルールで照合のために追加の名前解決が発生するのを防ぎます。すべてのルールに必要な汎用サフィックスではありません。MATCH を1行目に置くと、後続のルールは一度も照合されません。存在しないプロキシグループをルールから参照すると、読み込み時に直接エラーになる場合や、接続処理中にポリシーが見つからないと表示される場合があります。

ルールプロバイダー rule-providers

rule-providers:
  private-network:
    type: http
    behavior: ipcidr
    format: yaml
    url: "https://example.com/rules/private-network.yaml"
    path: ./ruleset/private-network.yaml
    interval: 86400

rules:
  - RULE-SET,private-network,DIRECT
  - MATCH,ノード選択

behavior はルールセットの内容に合わせる必要があります。一般的な値には domainipcidrclassical があります。ドメインルールセットを ipcidr と宣言すると、内容を正しく解析できません。mihomoのルールセットでは format も関係します。リモートファイルがYAML、テキスト、バイナリ形式の場合は、対応する値を指定してください。

TUNセクションと透過プロキシの設定

TUNモードは仮想ネットワークインターフェースを作成し、個別のプロキシ設定を持たないアプリの通信を取り込みます。システムプロキシとは別の入口です。mihomoでよく使われる設定例は次のとおりです。

tun:
  enable: true
  stack: mixed
  dns-hijack:
    - any:53
    - tcp://any:53
  auto-route: true
  auto-detect-interface: true
  strict-route: false

TUNを有効にした後に「ブラウザーは開けるのにゲームがネットワークに接続できない」「LAN内のデバイスにアクセスできない」といった問題が起きた場合は、実行権限、ルーティングテーブル、DNSの取り込み、LANセグメント向けのダイレクトルール、他のVPNを順に確認してください。デフォルトルートを作成するネットワークツールを複数同時に有効にしないでください。Windowsでは route print を実行して、デフォルトルートとインターフェースの優先順位も確認できます。

読みやすい最小構成とトラブルシューティング手順

次の構成では実際の認証情報を省略していますが、入口からルールまでの参照関係は完全に残しています。設定を確認する際は、最後のプロキシグループから逆方向に追跡できます。ルールは「ノード選択」を参照し、「ノード選択」は「サンプルノード」を参照し、「サンプルノード」にはサーバーパラメータが含まれています。

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

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  default-nameserver:
    - 223.5.5.5
  nameserver:
    - https://dns.alidns.com/dns-query

proxies:
  - name: "サンプルノード"
    type: ss
    server: 203.0.113.10
    port: 443
    cipher: aes-128-gcm
    password: "replace-with-valid-password"
    udp: true

proxy-groups:
  - name: "ノード選択"
    type: select
    proxies:
      - "サンプルノード"
      - DIRECT

rules:
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,ノード選択

エラーの種類ごとに段階的に確認

  1. ファイルを読み込めない:まずTab、インデント、コロン、引用符、重複キーを確認します。この段階ではノードのテストを先に行わないでください。カーネルがまだ設定を正常に読み込めていないためです。
  2. 設定は読み込めるがプロキシグループが空:proxies にノードがあるか、use のプロバイダー名が正しいか、プロバイダーファイルのダウンロードに成功しているかを確認してください。
  3. ノードテストに失敗する:server、port、認証項目、TLS名、通信パラメータを確認し、その後でサーバーのドメイン名を解決できるか確認してください。
  4. 一部のサイトだけ開けない:接続ログでルールのヒット状況、対象ドメイン、プロキシグループ、実際に使用されたノードを確認し、ルールの順番によって通信が先にDIRECTやREJECTへ送られていないか確認してください。
  5. システムプロキシは有効なのに他のプログラムがプロキシを通らない:そのプログラムがシステムプロキシに従うか確認してください。従わない場合にTUNを検討し、入口の問題を広範なルールの追加で隠さないようにします。
  6. サブスクリプション更新後に変更が消える:ローカルDNS、TUN、ルールの変更を、クライアントが対応するオーバーライドまたは設定マージへ移行してください。

項目の互換性とメンテナンスのヒント

Clash for Windows 0.20.39で使用されるClashカーネルの設定と、継続的に更新されるmihomoの設定は完全に同じではありません。新しいサブスクリプションには、古いカーネルが認識できないプロトコル、ルールセット形式、DNS項目が含まれることがあります。field not foundunsupported proxy type などのエラーが出た場合は、画面上の名称だけで判断せず、クライアントが実際に使用しているカーネルとバージョンを確認してください。

日常のメンテナンスでは、設定を3種類に分けると管理しやすくなります。サブスクリプションはノード、ルールプロバイダーは更新可能なルールセット、ローカルオーバーライドはポート・DNS・TUNを担当させます。手作業でのマージを減らし、問題の範囲も明確にできます。変更する際は、まずDNSだけを変更して再読み込みし、名前解決が正常になったことを確認してからTUNを有効にするなど、テーマごとに1つずつ調整してください。

設定ファイルの基本的な関係は複雑ではありません。受信ポートが通信を受け取り、DNSがドメイン情報を提供し、ルールがプロキシグループを決め、プロキシグループがノードを選び、ノードがリモート接続を確立します。この流れに沿って確認するほうが、ノードを何度も切り替えたり、YAML全体を一度に置き換えたりするより、問題のある項目を見つけやすくなります。

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