上級設定 読了目安 13分

Clash設定ファイルの構造を分解：portからrulesまでYAMLを段階的に読み解く

完全な設定ファイルを、共通項目、dnsブロック、proxiesのノード定義、proxy-groupsのプロキシグループ、rulesのルール一覧まで順に解説。各セクションに例を添え、項目の意味とよくある記述ミスを紹介します。

まずYAMLの階層と解析ルールを確認

Clashの設定ファイルには通常YAMLを使います。これは独立したスイッチの集まりではなく、階層を持つ設定ツリーです。トップレベルの項目がコアの動作を制御し、インデントされた項目は上位オブジェクトに属します。ハイフンで始まる項目はリスト要素です。設定を読むときは、まずインデントを確認してから項目の意味を判断しましょう。項目名だけを見て階層を確認しないと、有効なパラメータを誤った位置に置いてしまいがちです。

インデント、コロン、リスト

  • インデントには半角スペースを使い、一般的には1階層あたり2スペースに統一します。Tabは混在させないでください。
  • キー名の後のコロンには半角スペースを1つ入れます。例：mode: rule。
  • dns:やprofile:の下に子項目が続く場合、子項目はさらにインデントします。
  • proxies:、proxy-groups:、rules:には通常リストが入り、各項目は-で始まります。
  • コロン、シャープ記号、波括弧などの特殊文字を含む名前は、シングルクォートまたはダブルクォートで囲むことをおすすめします。
mode: rule
log-level: info

profile:
  store-selected: true
  store-fake-ip: true

proxy-groups:
  - name: 'ノード選択'
    type: select
    proxies:
      - '自動選択'
      - DIRECT

上の例では、store-selectedはprofileに属し、name、type、proxiesが1つのプロキシグループオブジェクトを構成します。typeとnameのインデントがずれていると、YAMLを解析できたとしても、まったく別のデータ構造になる可能性があります。

共通項目：ポート、LAN、動作モード

設定ファイルの冒頭には、待受ポート、動作モード、ログレベル、コントロールポートを置くことが多いです。これらの項目によって、アプリがシステムの通信を受け取る方法や、GUIクライアントがClash Meta（mihomo）コアと通信する方法が決まります。

port: 7890
socks-port: 7891
mixed-port: 7893
redir-port: 7892
tproxy-port: 7895

allow-lan: false
bind-address: '*'
mode: rule
log-level: info
ipv6: false

external-controller: 127.0.0.1:9090
secret: 'change-this-controller-secret'

各ポートが受け取る通信

port
HTTPプロキシの待受ポートです。例では通常127.0.0.1:7890と記述します。
socks-port
SOCKS5プロキシのポートです。SOCKS5に対応するコマンドラインツールやアプリは、127.0.0.1:7891に接続できます。
mixed-port
同じポートでHTTPとSOCKS5のリクエストを受け付けます。クライアントがローカルプロキシの入口を1つだけ公開すればよい場合は、通常これを有効にします。
redir-port
Linuxのリダイレクト用途で使い、通常はiptablesまたは互換性のある通信転送ルールと組み合わせます。
tproxy-port
LinuxのTPROXY透過プロキシに使い、宛先アドレスを保持する必要がある転送通信を処理できます。

これらのポートをすべて有効にする必要はありません。デスクトップクライアントでシステムプロキシを使う場合、mixed-port: 7890だけを有効にするか、HTTPとSOCKSのポートを個別に有効にする構成が一般的です。ログにaddress already in useと表示されたら、ほかのプロキシソフト、古いコアプロセス、開発用サービスが同じポートを使用していないか確認し、設定を変更するか競合プロセスを終了してください。

mode、allow-lan、コントロールインターフェース

  • mode: ruleはrulesを上から順に照合します。日常的な通信分岐設定で最もよく使われるモードです。
  • mode: globalは通信をグローバルプロキシグループに渡し、通常のルールによる個別の振り分けを行いません。
  • mode: directは通信を直接接続します。問題の原因がプロキシ経路にあるか一時的に切り分けるときに便利です。
  • allow-lan: trueにすると、LAN内のデバイスが待受ポートへ接続できるようになります。有効にする際は、システムファイアウォール、待受アドレス、信頼できるネットワークの範囲も確認してください。
  • external-controllerはREST APIのコントロールインターフェースです。ローカルクライアントだけで使う場合は127.0.0.1にバインドし、リモートパネルが必要な場合は有効なsecretを設定してネットワークアクセスの範囲を制限してください。

bind-address: '*'は利用可能なアドレスで待ち受けることを示しますが、LANに実際に公開されるかどうかはallow-lanとファイアウォールにも左右されます。「待受アドレス」「LAN許可」「コントロールインターフェース」を同じ設定だと考えないでください。それぞれプロキシの入口、LANアクセスの許可、コア管理インターフェースを管理します。

DNSブロック：名前解決経路とFake-IP

DNS設定はドメインの解決方法を決めるだけでなく、接続時にドメインルールを引き続き照合できるかどうかにも影響します。Clash Meta（mihomo）でよく使われる拡張モードにはfake-ipとredir-hostがあります。前者は予約アドレス範囲からマッピング用アドレスを返し、コア内にドメインと接続の対応関係を保持します。後者は実際の名前解決結果を返す方式に近い動作です。

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'
    - '*.local'
    - 'time.*.com'
    - 'time.*.gov'
  default-nameserver:
    - 223.5.5.5
    - 119.29.29.29
  nameserver:
    - 'https://dns.alidns.com/dns-query'
    - 'https://doh.pub/dns-query'
  fallback:
    - 'https://1.1.1.1/dns-query'
    - 'https://dns.google/dns-query'
  fallback-filter:
    geoip: true
    geoip-code: CN

3種類のnameserverの役割

  • default-nameserverには通常、直接アクセスできるIPアドレスを指定します。DoHやDoTサーバー自体のドメインを解決し、起動時の循環依存を避けるために使います。
  • nameserverは主要なリゾルバーです。通常のUDP DNSのほか、DoHやDoTなどの暗号化DNSアドレスも指定できます。
  • fallbackは予備のリゾルバーです。その結果を採用するかどうかは、fallback-filterなどの条件に左右されます。

listen: 127.0.0.1:1053は、DNSの待受ポートへのアクセスをローカルホストだけに限定します。クライアントがシステムDNSを自動的に引き受けている場合、OSのDNSを手動でこのポートへ変更する必要は通常ありません。TUNモードでは、コアがDNSハイジャックによって53番ポートのリクエストを受け取ることもあります。具体的な動作はクライアントが生成するTUN設定によって決まります。

fake-ip-filterには何を入れるか

LAN内のドメイン、デバイス検出用ドメイン、一部の時刻同期用ドメイン、実際のアドレスを返す必要があるアプリのドメインは、fake-ip-filterに追加できます。広範囲のワイルドカードを安易にフィルターへ追加しないでください。多くのドメインがFake-IPのマッピングを回避し、ドメインルールのヒット方法や初回接続時の遅延が変わる可能性があります。

proxies：個々のノードを定義する

proxiesは静的なノード一覧です。各ノードには少なくとも名前、プロトコル種別、サーバーアドレス、ポートが必要で、その後にプロトコルに応じた認証や通信パラメータを指定します。ノードの項目はサーバー側の実際の設定と一致させてください。プロトコル名が同じでも、ポート、暗号化方式、TLSホスト名、WebSocketパスを相互に使えるとは限りません。

proxies:
  - name: 'サンプル-Trojan'
    type: trojan
    server: edge.example.com
    port: 443
    password: 'example-password'
    udp: true
    sni: edge.example.com
    skip-cert-verify: false

  - name: 'サンプル-VMess'
    type: vmess
    server: vm.example.com
    port: 443
    uuid: 00000000-0000-4000-8000-000000000001
    alterId: 0
    cipher: auto
    udp: true
    tls: true
    servername: vm.example.com
    network: ws
    ws-opts:
      path: /connect
      headers:
        Host: vm.example.com

ノード名は後で参照するキー

nameは画面に表示する文字列だけではありません。プロキシグループは完全に同じ文字列でノードを参照します。ノード名がサンプル-Trojanなら、プロキシグループにサンプル Trojanと書くと存在しない参照になります。ノード名を変更するときは、すべてのproxy-groups、ルールの宛先、チェーンプロキシの設定も確認してください。

TLSとトランスポート層の項目を対応させる

  • serverは接続確立時に使用するサーバーアドレスです。
  • sniまたはservernameはTLSハンドシェイクで使用するサーバー名です。ノード提供元が指定した値を入力してください。
  • skip-cert-verify: falseは、サーバー証明書を通常どおり検証することを示します。
  • network: wsはWebSocket通信を使用することを示し、対応するパラメータはws-optsに記述します。
  • udp: trueは、そのノードでUDPを処理できることを示します。実際に通信できるかどうかは、プロトコル、サーバー側の設定、ネットワーク環境にも左右されます。

サブスクリプションからインポートすると、ノードはproxiesに直接記述されず、クライアントが変換して生成するか、proxy-providersから読み込むことがよくあります。両方の方式は併用できますが、同名ノードがあるとプロキシグループの参照やトラブルシューティングが難しくなります。

proxy-providersとproxy-groups：ノードからプロキシグループへ

proxy-providersはローカルファイルやリモートURLから複数のノードを読み込み、proxy-groupsはノードを手動選択、速度テスト、障害切り替えが可能なプロキシグループにまとめます。ルールは通常、個別ノードではなくプロキシグループを参照します。

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

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

よく使われるプロキシグループの種類

  • select：ノードまたは別のプロキシグループを手動で選択します。ルールが最終的に参照するプロキシグループに適しています。
  • url-test：テストURLへ定期的にリクエストを送り、候補ノードから遅延の低いものを選びます。例では300秒ごとに検査し、tolerance: 80で遅延が近い場合の頻繁な切り替えを抑えます。
  • fallback：利用可能性に基づいて候補を選び、現在の接続経路が使えなくなったときに、後続の利用可能なノードへ切り替えます。
  • load-balance：設定した方式に従って複数のノードへ接続を振り分けます。1つのダウンロードに複数ノードの帯域を単純に合算する機能ではありません。

proxiesはノード名やプロキシグループ名を明示的に列挙し、useはproviderを参照します。プロキシグループは入れ子にでき、たとえば「ノード選択」に「自動選択」を含め、「自動選択」がproviderからノードを取得する構成も可能です。設定を確認するときは参照関係をたどり、各名称が存在することを順に確認して、自分自身を参照する循環を避けてください。

rules：順番に実行される通信分岐ルール一覧

rulesは設定の末尾にある最も重要なリストの1つです。Clashは上から順に照合し、通常は1つのルールに一致すると後続の確認を続けません。そのため、より具体的なドメイン、プロセス、ネットワーク範囲のルールを先に置き、範囲の広いGeoIP、GeoSite、フォールバックルールを後ろに配置します。

rules:
  - DOMAIN-SUFFIX,example.org,ノード選択
  - DOMAIN,api.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
  - GEOSITE,CN,DIRECT
  - GEOIP,CN,DIRECT,no-resolve
  - MATCH,ノード選択

ルールはマッチャー、値、宛先で構成される

DOMAIN-SUFFIX,example.org,ノード選択を例にすると、1番目はルール種別、2番目は照合対象の値、3番目は一致したときに使うプロキシグループです。プロキシグループ名はproxy-groups内の名称と完全に一致させる必要があります。DIRECTやREJECTなどの組み込み宛先も使用できます。

  • DOMAINは完全なドメイン名を1つに対して完全一致します。
  • DOMAIN-SUFFIXは指定したドメインとそのサブドメインに一致し、サイト単位の通信分岐に適しています。
  • DOMAIN-KEYWORDはドメイン内のキーワードで照合します。範囲が広いため、短すぎるキーワードは避けてください。
  • IP-CIDRとIP-CIDR6は、それぞれIPv4とIPv6のアドレス範囲に一致します。
  • GEOIPは地理IPデータベースを使い、宛先アドレスの地域を判定します。
  • GEOSITEはドメイン分類データベースに依存します。利用できるカテゴリは、使用中のmihomoのバージョンとデータファイルによって異なります。
  • MATCHはそれまでのルールに一致しなかった通信に一致するため、ルール一覧の末尾に置きます。

no-resolveは、このIP系ルールが照合のために追加のドメイン解決を行わないことを示します。LANのアドレス範囲やGEOIPルールで使われることがありますが、追加するかどうかは前段のDNSモードとルールの要件を踏まえて判断してください。ドメインルールに付けても意味はありません。

ルール順序を間違えたときの典型例

  1. MATCHを途中に置くと、その後のルールは実行されません。
  2. 広範囲に一致するDOMAIN-KEYWORDを先に書くと、後続の完全一致ドメインルールに到達できません。
  3. LANのアドレス範囲を先に直接接続へ振り分けないと、ルーター、NAS、開発サーバーへのアクセスまでプロキシに送られます。
  4. ルールの宛先名を変更したのにルール一覧が古いプロキシグループを参照していると、読み込み時にプロキシまたはプロキシグループが見つからないというエラーが表示されます。
  5. GEOSITEやGEOIPを使っているのに対応するデータベースを用意していないと、ルールの読み込みや照合に異常が生じます。

TUNとprofile：末尾に置かれることが多い設定

TUNモードは仮想ネットワークインターフェースでより多くのシステム通信を引き受けます。システムプロキシ設定を自動的に読み取れないアプリに適しています。mixed-portと競合するものではありません。前者はネットワーク層で通信を引き受け、後者はHTTPまたはSOCKS5に対応するアプリから引き続き利用できます。

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

profile:
  store-selected: true
  store-fake-ip: true

auto-routeはコアがルーティングを自動設定するための項目で、auto-detect-interfaceは現在の出口ネットワークインターフェースを検出します。TUNドライバー、管理者権限、ルーティング設定に必要な条件はOSによって異なります。GUIクライアントでは通常、「設定」→「ネットワーク」または「設定」→「TUNモード」でこれらの項目を生成・管理します。クライアントがTUN設定を管理している場合、複数のオーバーライド層で同名の項目を重複して宣言しないでください。

store-selected: trueはプロキシグループの選択を保存し、再起動後も前回選んだ項目を使うための設定です。store-fake-ip: trueはFake-IPのマッピングを保存し、再起動後のマッピング変更による接続中断を減らします。これら2つの項目はprofileに属し、dnsの子項目ではありません。

読み込みからルール一致までの確認手順

設定がYAML構文チェックを通ったからといって、ノードに接続できるとは限りません。ノードに接続できても、ルールやDNSが想定どおり動作するとは限りません。トラブル対応では、複数のセクションを同時に変更するより、決めた順番で1つずつ確認するほうが原因を特定しやすくなります。

  1. YAMLの解析を確認。まずクライアントの設定画面やコアのログを確認し、インデント、重複キー、未知の項目、型の誤りがないことを確認します。
  2. ローカルの待受を確認。7890、7891、7893、9090、1053など、実際に有効にしたポートがほかのプロセスに使用されていないことを確認します。
  3. ノードのハンドシェイクを確認。プロキシ画面でノードを1つ選んで遅延テストを行い、TLS、認証、タイムアウト、ネットワーク到達不能に関するログを確認します。
  4. プロキシグループの参照を確認。ルールの宛先、プロキシグループのメンバー、provider名が完全に一致していることを確認します。
  5. DNSを確認。ドメインクエリがタイムアウトしていないか、DoHサーバーのドメインをdefault-nameserverで初回解決できるかを確認します。
  6. ルールの一致を確認。接続画面やログ画面を開き、対象ドメインがどのルールに一致し、最終的にどのプロキシグループとノードが選ばれたかを確認します。
  7. 最後にTUNを有効化。まず通常のシステムプロキシが正常に動作することを確認してからTUNを有効にすると、ノードの問題とルーティング引き受けの問題を切り分けやすくなります。

設定ファイルを読む順番

見慣れない設定を読むときは、トップレベルのポートから始め、dns、proxiesまたはproxy-providers、proxy-groups、rulesの順に確認し、最後にtunとprofileを確認します。この順番は通信処理の流れに対応しています。アプリがローカルポートまたはTUNに入り、DNSでドメインを解決し、ルールがプロキシグループを選び、プロキシグループが具体的なノードを選択します。

設定の保守性を左右するのは項目数ではなく、参照関係が明確かどうかです。ノード名、provider名、プロキシグループ名、ルールの宛先が1本の連続したつながりを形成します。いずれかの名前を変更したら、そのつながりをたどって後続の参照を確認してください。変更後はクライアントの設定検証機能で再読み込みし、接続ログで実際の一致結果を確認します。

クライアントをダウンロード Windows、macOS、Android、iOS、Linux