Clash 設定ファイル完全リファレンス

1. YAML構造概要:設定ファイルを構成するブロック

Clash の設定ファイルは標準的な YAML ドキュメントで、既定のファイル名は config.yaml です。YAML には最初に覚えておくべき3つの鉄則があります。第一に、階層はすべてインデントで表現し、半角スペース2つを1階層とする慣習があり、タブは使用できません。第二に、コロンの後には必ず半角スペースを入れる必要があり、port:7890 は構文エラーで、port: 7890 が正しい書き方です。第三に、値にコロン・シャープ・波かっこなどの特殊文字が含まれる場合は引用符で囲む必要があり、特にパスワードや URL で注意が必要です。シャープ # から行末まではコメントとして扱われ、カーネル読み込み時に無視されます。

完全な設定ファイルは上から下へおおむね4層に分かれます。インバウンドと動作パラメータ(ポート、モード、ログ)、DNS セクション、アウトバウンドリソース(proxies ノードリスト、proxy-groups ポリシーグループ、2種類の provider)、そして最後に rules ルールリストです。カーネルは「ルール一致 → ポリシーグループの判断 → ノードへの出力」という順序で各接続を処理し、設定ファイルの構成順序はこのデータフローと対応しています。以下は主要なトップレベルフィールドの早見表です。

以下はそのまま動かせる最小構成の設定です。5つの要素がすべて含まれており、以降の各章はこの骨格を土台に拡張していきます。

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

proxies:
  - name: "ノードA"
    type: ss
    server: example.com
    port: 8388
    cipher: aes-128-gcm
    password: "your-password"

proxy-groups:
  - name: "PROXY"
    type: select
    proxies:
      - ノードA
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.com,PROXY
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

2. 共通フィールド:ポート・モード・コントロールAPI

インバウンドポート:mixed-port ひとつで3役

以前は port: 7890(HTTP)と socks-port: 7891(SOCKS5)を分けて書くのが一般的でしたが、現在は mixed-port: 7890 と直接書くことが推奨されています。同じポートで両方のプロトコルを自動判別し、システムプロキシや各種アプリのプロキシ設定はすべてこのポートを指せばよく、プロトコルを区別する手間が省けます。7890 はコミュニティの慣習であって予約値ではありません。起動ログに "address already in use" と出た場合は、そのポートが他のプロセスに使われているという意味なので、未使用のポートに変更してください。

allow-lan と bind-address

allow-lan: true にすると、インバウンドポートを同じ LAN 内の他デバイスにも公開します。テレビボックスやゲーム機がパソコン上の Clash を利用する、といった用途によく使われます。bind-address と組み合わせれば待ち受けアドレスを制限できます。既定値の "*" は全ネットワークインターフェースで待ち受けますが、具体的なローカル IP に変更すれば特定のセグメントだけに開放できます。有効化する前に、その場のネットワークが信頼できるか確認してください。会社や公共 Wi-Fi で allow-lan を開放するのは、同一セグメントの誰にでも出口回線を貸すのと同じことです。

mode:3つの動作モードの境界

mode: rule は日常的に使う形態で、接続ごとにルール表を1件ずつ照合します。global はルールをスキップし、すべてのトラフィックをグローバルポリシーグループが選んだノードに任せる方式で、「ルールの問題なのかノードの問題なのか」を一時的に切り分けたいときに向いています。direct はすべて直結で、プロキシのロジック自体を丸ごとバイパスします。3つのモードはクライアントの画面上でその場に切り替えられ、ファイルを変更する必要はありませんが、設定ファイルに書かれた値がカーネル起動時の初期モードを決めます。

log-level と external-controller

log-level は少ない方から silent / error / warning / info / debug の順です。「あるルールがなぜ効かないのか」を調べるときは debug に切り替えると、各接続がどのルールに一致し最終的にどこへ出たかがログに出力されます。原因が分かったら info に戻してください。debug レベルのログ量は長期運用には向きません。external-controller: 127.0.0.1:9090 は RESTful コントロール API を開き、クライアントパネルのノード切り替え、レイテンシテスト、接続リストはすべてこれを通じて動作します。secret フィールドは API にアクセストークンを設定するもので、例では secret: "xxxx" のように常にダミー値を使用してください。external-ui はローカルディレクトリを指し、Web パネルをマウントできます。コントロール API を 0.0.0.0 で待ち受けさせる場合は必ず secret も設定してください。そうしないと LAN 内の誰でもプロキシの状態を変更できてしまいます。

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

ipv6: false はカーネルが IPv6 アドレスを解決・使用しないことを意味します。利用しているネットワークの IPv6 接続性が良くない場合、これをオフにすることで「v6 アドレスは解決できたのに接続できない」というタイムアウトの一部を避けられます。ネットワークとノードの両方が v6 に対応している場合にオンにしてください。このスイッチは DNS セクションの解決動作と連動しているため、変更後はホットリロードではなくカーネルの再起動を推奨します。

3. DNS設定:fake-ip、分割解決とDNS汚染対策

DNS セクションは「ドメイン名がどう IP になるか」を決め、分流の精度と接続の成否に直接影響します。enable: true で内蔵 DNS モジュールを有効化し、listen はモジュール自身の待ち受けアドレスを指定します。TUN モードでは dns-hijack と組み合わせて使います。本当に理解が必要なのは enhanced-mode の2つの値です。

fake-ip と redir-host のどちらを選ぶか

fake-ip モードでは、カーネルは各ドメイン名に対してまず fake-ip-range(既定値 198.18.0.1/16)内の偽アドレスを返し、アプリはその偽アドレスで接続を開始します。カーネルは「偽IP ↔ ドメイン名」の対応表から元のドメイン名を復元してルール照合を行います。利点はドメインルールが100%一致し、ローカル解決の待ち時間が1回省けることですが、実IPに依存する一部のプログラム(LAN内発見、一部のゲームのオンライン対戦)は偽アドレスに干渉されるため、そうしたドメインは fake-ip-filter のホワイトリストに追加して実際の解決結果を得られるようにする必要があります。redir-host は素直に先に解決してから照合する方式で動作は直感的ですが、ドメイン系ルールは「先にIPを取得してしまう」ことで判定漏れが起きる場合があります。デスクトップとモバイルでは日常的に fake-ip を使い、互換性の問題が多い環境では redir-host に戻してください。

nameserver、fallback、fallback-filter

nameserver はメインの解決グループで、契約している通信事業者から到達しやすく低遅延なサービスを設定するのがおすすめです。udp、tls://(DoT)、https://(DoH)の3種類の書き方に対応しています。fallback は代替グループで、信頼できる海外の DoH を設定します。両グループへ並行して問い合わせたあと、どちらの結果を採用するかを fallback-filter が決定します。geoip: true かつ geoip-code: CN の意味は——メイングループの解決結果が中国本土の IP であれば採用し、そうでなければ fallback の結果に切り替えて汚染された応答を回避する、というものです。mihomo カーネルはさらに nameserver-policy に対応しており、ドメインの末尾ごとに特定の DNS を割り当てられるため、より細かい粒度の制御ができます。

dns:
  enable: true
  listen: 0.0.0.0:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "+.local"
    - "+.msftconnecttest.com"
  nameserver:
    - https://223.5.5.5/dns-query
    - 119.29.29.29
  fallback:
    - https://1.1.1.1/dns-query
  fallback-filter:
    geoip: true
    geoip-code: CN

4. ノードフィールド:proxiesをプロトコル別に解説

proxies は配列で、各要素が1つのアウトバウンドノードを表します。すべてのプロトコルに共通する4つのフィールドがあります。name(ノード名。ファイル全体で一意で、ポリシーグループはこれで参照する)、type(プロトコル種別)、server(サーバーアドレス。ドメイン名または IP)、port(ポート番号)です。udp: true はそのノードが UDP トラフィックを転送することを示し、音声通話やゲームがこれに依存します。名前に日本語や中国語、スペース、特殊記号が含まれる場合は引用符で囲み、解析時の誤解を避けてください。

Shadowsocks(ss)

最もフィールドが少ないプロトコルです。cipher は暗号方式を指定し(よく使われるのは aes-128-gcm、chacha20-ietf-poly1305)、password は事前共有鍵です。cipher の表記はサーバー側と完全に一致させる必要があります。間違えた場合、エラーは出ずに「接続はできるがデータが完全に破損している」状態になり、レイテンシテストは永遠にタイムアウトします。

VMess

核心となるのは uuid(ユーザー識別子)と alterId(現在のデプロイでは一律 0)です。cipher: auto は両端で暗号方式をネゴシエーションさせます。トランスポート層は network で選択し、生の TCP 以外で最も一般的なのは ws(WebSocket)で、この場合 ws-opts でパスと Host ヘッダーを補い、さらに tls: true で HTTPS に偽装します。ws のパス、Host、TLS のいずれか1つでもサーバー側と食い違えばハンドシェイクは失敗します。

Trojan

設計上 HTTPS に似せてあります。password で認証し、sni は TLS ハンドシェイク時に示すドメイン名を指定します(省略時は server の値が使われます)。skip-cert-verify: true は証明書検証をスキップします。サーバー側が自己署名証明書を使っていると分かっている場合に限り一時的に使うべきで、長期的に有効にすると中間者攻撃への防御を放棄することになります。

mihomo 拡張プロトコル

mihomo(Clash Meta)カーネルはオリジナル版に加えて vless(reality トランスポートを含む)、hysteria2、tuic といった種類を追加しており、フィールド構成も同じく「共通4点セット + プロトコル専用セクション」です。サブスクにこれらのノードが含まれる場合は、mihomo カーネルを採用したクライアント(ダウンロードページに掲載されている Clash Plus、Clash Verge Rev、FlClash はいずれも該当)を使う必要があります。オリジナル版カーネルは type を認識できずファイル全体の読み込みを拒否します。両世代のカーネルの詳細な違いは「mihomo カーネルとオリジナル版 Clash の違い比較」を参照してください。

proxies:
  - name: "SS-香港"
    type: ss
    server: hk.example.com
    port: 8388
    cipher: aes-128-gcm
    password: "your-password"
    udp: true

  - name: "VMess-日本"
    type: vmess
    server: jp.example.com
    port: 443
    uuid: 00000000-0000-0000-0000-000000000000
    alterId: 0
    cipher: auto
    tls: true
    network: ws
    ws-opts:
      path: /ws
      headers:
        Host: jp.example.com

  - name: "Trojan-シンガポール"
    type: trojan
    server: sg.example.com
    port: 443
    password: "your-password"
    sni: sg.example.com
    udp: true

5. ポリシーグループフィールド:proxy-groups の5種類

ポリシーグループはノードの上位に位置するスケジューリング層です。ルールはノードを直接指すのではなくグループを指し、グループは自身の種別に応じてどのノードを使うかを決めます。グループのメンバーは proxies 配列に記述し、ノード名、他のグループ名、または2つの組み込みポリシー——DIRECT(直結)と REJECT(接続拒否。ドメインのブロックによく使う)——を指定できます。グループの中に別のグループを入れ子にするのは一般的な手法で、例えば「手動選択」グループの中に「自動測速」グループを入れておくと、手動と自動の両方のメリットを得られます。

自動判定タイプのグループは3つのパラメータに依存します。url は死活確認用のアドレスで、204 を返す軽量なエンドポイントを使うのが定番です。interval はテスト周期(秒)で、300 がよく使われる値です。小さすぎるとプローブトラフィックが大量に発生します。tolerance(url-test のみ)は切り替えの許容差(ミリ秒)で、新旧ノードのレイテンシ差がこの値を超えた場合にのみ切り替えることで、レイテンシが近い2つのノード間で頻繁に切り替わるのを防ぎます。lazy: true にすると、そのグループが実際にルールから使われるまでテストを開始しないため、ノードが多い場合にバックグラウンドのリクエストを大幅に減らせます。load-balance は strategy で分配方式を選び、consistent-hashing は同じ宛先サイトを常に同じノードへ振り分けるためログイン状態と相性が良く、round-robin は順番に振り分けます。

proxy-groups:
  - name: "手動選択"
    type: select
    proxies:
      - 自動測速
      - SS-香港
      - VMess-日本
      - Trojan-シンガポール
      - DIRECT

  - name: "自動測速"
    type: url-test
    url: http://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    lazy: true
    proxies:
      - SS-香港
      - VMess-日本
      - Trojan-シンガポール

  - name: "フェールオーバー"
    type: fallback
    url: http://www.gstatic.com/generate_204
    interval: 300
    proxies:
      - SS-香港
      - VMess-日本

よく見る "proxy not found" エラーは、ほとんどが参照の不一致が原因です。グループに書いた名前と proxies セクションの name が、スペース1つ、引用符の有無、全角・半角の違いなどでずれていると読み込みに失敗します。名前を変更する際は、ファイル全体を検索して旧名の参照箇所をすべて一緒に直すことを忘れないでください。

6. providers:サブスクノードと外部ルール集合

proxy-providers:ノードの取得元を外部化する

ノードを proxies に直接書き込む方式の問題点は、サブスクが更新されるたびにファイル全体が上書きされ、ローカルの変更が消えてしまうことです。proxy-providers は「ノードの取得元」を外部に切り出します。type: http は interval(秒)ごとに url の指すサブスクを取得し、path にキャッシュします。type: file はローカルファイルを読み込みます。health-check サブセクションはこれらのノードに専用の死活確認を設定します。ポリシーグループは use フィールドで provider を参照し、provider 内の全ノードが自動的にそのグループへ注入されます。proxies 配列と併用することも可能です。

rule-providers:ルール集合の3種類の behavior

rule-providers はルール版の同じ発想で、rules セクションを短く保ち、大量のドメイン/IP は外部集合に管理を任せます。重要なフィールド behavior には集合内容の解釈方式を決める3つの値があります。domain(純粋なドメインリスト)、ipcidr(純粋な CIDR リスト)、classical(各行が完全な Clash ルール)です。format はファイル形式(yaml または text)を示し、behavior が集合の実際の内容と一致しない場合、そのルール群は静かに丸ごと無効化されます。これは「RULE-SET を書いたのに効かない」という不具合の最大の原因です。

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

rule-providers:
  cn-domains:
    type: http
    behavior: domain
    format: yaml
    url: "https://example.com/cn-domains.yaml"
    path: ./rules/cn-domains.yaml
    interval: 86400

proxy-groups:
  - name: "サブスクノード"
    type: select
    use:
      - main

サブスク自体には複数の配布形態があります——完全な YAML、Base64 ノードリスト、汎用共有リンクなど、すべてがそのまま provider に渡せるわけではありません。各形式の構造の違いと相互変換方法は「Clash サブスク形式を詳しく解説」を、クライアントでサブスクを導入する手順は使用ガイドを参照してください。更新に失敗したときは、まず path のキャッシュファイルが生成されているか、タイムスタンプが変化しているかを確認し、その後ログに出る provider 取得時の HTTP ステータスコードを見てください。当てずっぽうに再試行するより特定が早く済みます。

7. ルール文法:上から順に、最初に一致した条件が適用

各ルールはカンマ区切りの3要素形式です。種別,一致値,ポリシー で、ポリシーにはノード名、グループ名、DIRECT、REJECT のいずれかを指定できます。照合エンジンは上から下へ走査し、最初に一致した時点で確定し、以降のルールは見ません。つまり順序=優先度です。厳密なルール(DOMAIN、PROCESS-NAME)を先頭に、広範囲なルール(GEOIP)を後方に置き、MATCH による兜底は必ず最後の1行とし、一致値は空にします。

no-resolve は IP 系ルールの省略可能な4番目の要素で、「宛先がまだドメイン名のままで解決されていない場合、このルールをスキップし、照合のためだけに DNS 解決を発生させない」という意味です。LAN セグメントや予約アドレスのセグメント向けルールには一律 no-resolve を付けておくと、無意味な解決リクエストを大量に避けられます。mihomo カーネルはさらに GEOSITE 種別を提供し、サイト分類ごとに管理されたドメインデータベースを直接参照できます(例:GEOSITE,category-ads-all,REJECT)。手書きルールと RULE-SET の間ぐらいの粒度です。

rules:
  - PROCESS-NAME,Telegram.exe,手動選択
  - DOMAIN,ad.example.com,REJECT
  - DOMAIN-SUFFIX,github.com,手動選択
  - RULE-SET,cn-domains,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,手動選択