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

YAML構造の全体像

設定ファイルはどこにあるか

GUIクライアントの多くは、ファイル本体を直接意識させない設計になっています。Clash Verge Revは「サブスクリプション / 設定」ページで複数の設定を管理し、Clash Plusはアプリ内でサブスクリプションとローカル設定を一元管理します。ファイル自体は各アプリのデータディレクトリに保存され、画面上には「設定フォルダを開く」といった導線が用意されています。一方 mihomo カーネル(および Clash for Windows のような旧クライアント)は1つのYAMLファイルを直接読み込みます。既定のファイル名は config.yaml で、起動時に -d パラメータで格納ディレクトリを指定します。どちらの方式でも、最終的に反映されるYAMLの構造は同じです。トップレベルにポート・モード・ログレベルなどのスカラー項目が並び、続いて dns、proxies、proxy-groups、rules という4つの機能セクション、さらに proxy-providers、rule-providers という2つの外部リソースセクションがあります。この骨格を理解すれば、Clash系クライアント全体に共通する設定ロジックが理解できます。

YAML構文の4大原則

YAMLの記法ルールは少ないものの、どれもファイルが正しく解析されるかどうかを直接左右します。

1. インデントはスペースのみで、タブは使えません。初心者が最初に遭遇するエラー原因はこれで、エディタでタブを自動的にスペース2つに変換する設定にしておくと安心です。
2. キーと値の間は「コロン+半角スペース1個」です。port:7890 や port : 7890 のように書くと解析エラーになったり、意図しない結果になります。
3. リスト項目は「- 」(ハイフン+半角スペース)で始めます。親キーと同じ列に書いても、さらに1段インデントしても構いませんが、どちらも意味は同じなので、ファイル全体で表記を統一してください。
4. 文字列にコロン・#・波かっこ・角かっこ・カンマなどの特殊文字が含まれる場合は、英数字の二重引用符で全体を囲みます。# 以降の文字列はコメントとして扱われ、解析対象になりません。

またYAMLはアンカーと参照(& でアンカー定義、* で参照、<< でマージ)に対応しており、複数のノードで共通パラメータを使う場合、重複行を減らせます。具体例は「プロキシノード項目」の節を参照してください。

トップレベル項目の全体像

1つの設定ファイルのトップレベルは大きく3グループに分けられます。ネットワーク監視(port、socks-port、mixed-port など)、動作設定(mode、log-level、ipv6、external-controller など)、機能セクション(dns、proxies、proxy-groups、rules)です。まず下表で全体像をつかみ、以降の節で1つずつ詳しく見ていきます。

# config.yaml の骨格:まずスカラー、続いてセクション
mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
external-controller: 127.0.0.1:9090

dns:
  enable: true
  # ...詳細は「DNS項目」の節を参照

proxies:
  - name: "node-a"
    # ...詳細は「プロキシノード項目」の節を参照

proxy-groups:
  - name: "PROXY"
    type: select
    proxies: ["node-a", DIRECT]

rules:
  - DOMAIN-SUFFIX,local,DIRECT
  - MATCH,PROXY

基本項目:ポート・モード・全体動作

ポート関連項目

Clashは4種類の受信リスニングを提供します。port は従来のHTTPプロキシポート、socks-port はSOCKS5ポートでUDP転送に対応、mixed-port は両プロトコルを1つのポートに統合し、カーネルがリクエストの特徴から自動判別します。現在ほとんどのGUIクライアントは既定でこの混合ポートのみを開きます。redir-port と tproxy-port はLinuxの透過プロキシ向けで、デスクトップ利用では通常不要です。起動時に「bind: address already in use」と出た場合はポートが使用中です。別のポートに変更するか、使用中のプロセスを見つけて終了してください。混合ポートとLAN共有の実践的な使い方については、技術ノートに専用の解説記事があります。

動作モード

mode はリクエストの出口の決め方を制御し、3つの値を取ります。rule は rules リストを上から順にマッチングする、日常使用における既定モードです。global は全トラフィックをGLOBALポリシーグループ(通常パネルで選択したノードと同じ)に任せます。「ルール設定が間違っているのか」を切り分けたいときはこれに切り替えるのが手っ取り早い方法です。direct は全て直接接続で、プロキシ自体が機能しているかを確認するのに使います。GUIクライアントのホーム画面にあるモード切り替えボタンは、この項目を変更しています。

LANアクセスと外部からのアクセス

allow-lan を有効にすると、同じLAN内のスマートフォンやタブレットがこのPCのIPアドレスとポートをプロキシ先に指定して、同じプロキシ出口を共有できます。bind-address は監視するネットワークインターフェースを制御し、既定の "*" は全インターフェースを意味しますが、これは allow-lan と組み合わせてこそ意味を持ちます。external-controller はカーネルのRESTful管理APIで、GUIパネルはこれを通じて状態取得・ノード切り替え・ログ取得を行います。secret はこのAPIへのアクセストークンです。このAPIの監視アドレスを 0.0.0.0 に変更して外部公開する場合は、必ず secret を設定してください。設定しないと、プロキシの制御権をネットワーク全体に開放することになります。external-ui は静的パネルのディレクトリを指し、ブラウザから管理画面に直接アクセスできるようにします。

ログ・遅延・その他の動作項目

log-level は silent から debug まで5段階あり、トラブルシューティング時は一時的に debug に、通常は info に設定します。ipv6 はAAAAレコードを処理するかを制御し、IPv6の出口がないネットワークでは無効化を推奨します。unified-delay は速度測定にTCP/TLSハンドシェイク時間を含めることで、ノード間の数値を比較可能にします。tcp-concurrent は候補ノードへの並行接続を可能にし、初回接続を高速化します。find-process-mode はローカルのプロセス名を解析するかを制御し、PROCESS-NAMEルールがこれに依存します。global-client-fingerprint はTLSクライアントフィンガープリントの偽装方式を指定します(よく使われる値は chrome)。uTLSに依存するプロトコルで意味を持ちます。profile セクションの store-selected はパネルで選んだ手動選択を記憶し、設定の再読み込み後も選択が保持されます。他に tun セクションは仮想NICレベルでのトラフィック引き取りに使う進階機能で、一般的なデスクトップ利用では有効化不要です。

port: 7890
socks-port: 7891
mixed-port: 7897
allow-lan: false
bind-address: "*"
mode: rule
log-level: info
ipv6: false
external-controller: 127.0.0.1:9090
secret: ""
unified-delay: true
tcp-concurrent: true
find-process-mode: strict
global-client-fingerprint: chrome
profile:
  store-selected: true
  store-fake-ip: true

DNS項目:改ざん対策とリーク対策

なぜDNSを別セクションにするのか

プロキシが解決するのは「トラフィックをどう通すか」だけで、DNSは「ドメイン名を何に解決するか」を決めます。システム標準のDNSは通信事業者のUDP 53番ポートを経由し、平文かつ改ざんされやすく、アクセス先をローカルネットワークに露出させてしまいます。これがいわゆるDNSリークです。Clashの dns セクションはカーネル内にDNSサーバーを内蔵し、クエリを引き取ってドメインごとに異なる上位サーバーへ振り分けます。fake-ipモードと組み合わせれば「まずドメイン名でルールをマッチングし、その後プロキシするかを決める」という流れが実現でき、「改ざんされたIPをまず解決してしまい、ルールはドメイン名で書いてあるのに使えない」という矛盾を回避できます。

基本項目

enable は全体のオン/オフスイッチです。listen は内蔵DNSの監視アドレスで、GUIクライアントがシステムレベルの引き取りを行わない場合は設定不要です。enhanced-mode には2つの値があります。redir-host は実際の解決結果を返し、カーネルがドメイン名とIPの対応を記録します。fake-ip は 198.18.0.0/16 帯の仮想アドレスを即座に返し、接続が来た時点でドメイン名を逆引きしてルールにマッチングします。速度が速く改ざんの影響を受けないため、現在の主流です。fake-ip-filter は fake-ip を使わないドメインを列挙するもので、LAN内のデバイス名、NTP時刻同期、実際のIPが必要な一部サービスなどが対象になり、これらは実際の解決結果で処理されます。default-nameserver は「上位DNSサーバー自体のドメイン名」の解決専用で、必ずIPアドレス直指定の従来型UDPサーバーを設定してください。そうしないと「DoHのドメインを解決するにはDoHに問い合わせる必要がある」という循環に陥ります。

上位サーバー

nameserver は主要な上位サーバーのリストで、複数行書くと並行クエリを行い最速の結果を採用します。fallback は代替グループで、fallback-filter と組み合わせてGEOIPで判定します。解決結果が海外のIP帯に属する場合、fallback で再クエリします。mihomoでは nameserver-policy がより推奨されます。ドメインセットごとに直接上位サーバーを指定する方式で、例えば geosite:cn は中国国内向けDoHへ、それ以外は信頼できる海外DoHへ振り分けるなど、fallbackの「先に解決してから判定する」方式より確実です。proxy-server-nameserver はプロキシノードのドメイン名解決専用で、ノードのドメインが改ざんされて接続できなくなることを防ぎます。respect-rules を有効にすると、DNSリクエスト自体もルールに従って出口を選択します(プロキシ経由で海外DNSに問い合わせるなど)が、設定は複雑になります。他に sniffer セクションはTLS/HTTPハンドシェイクからドメイン名を復元し、「アプリがIPに直接接続する」場合のルールマッチングを補正します。

dns:
  enable: true
  listen: 0.0.0.0:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - time.*.com
    - ntp.*.com
  default-nameserver:
    - 223.5.5.5
    - 119.29.29.29
  nameserver:
    - https://doh.pub/dns-query
    - https://dns.alidns.com/dns-query
  proxy-server-nameserver:
    - https://doh.pub/dns-query
  nameserver-policy:
    "geosite:geolocation-!cn":
      - https://dns.cloudflare.com/dns-query
      - https://dns.google/dns-query

プロキシノード項目:proxies 一覧

共通項目

proxies はリストで、各要素が1つのノードに対応します。全プロトコルで共通する項目は5つだけです。name(表示名。ルールやポリシーグループから参照されるため、ファイル内で一意である必要があります)、type(プロトコル種別)、server、port、udp(UDP転送の有無。ノードが対応していれば有効化します)。それ以外の項目はプロトコルによって異なります。同じプロトコルのノードを手動で複数管理する場合、YAMLアンカーで共通部分を切り出し、以降のノードはマージキーで参照して差分だけを書くことができます。

proxies:
  - &ss-base
    name: "ss-a"
    type: ss
    server: 203.0.113.10
    port: 8388
    cipher: aes-128-gcm
    password: "your-password"
    udp: true
  - <<: *ss-base
    name: "ss-b"
    server: 203.0.113.11
    port: 8389

各プロトコルの例

以下の例は mihomo で一般的な5種類のプロトコルを網羅しています。アドレスはすべて文書用の予約アドレスを使用しているので、実際のサーバー情報に置き換えて使用してください。

proxies:
  - name: "ss-example"
    type: ss
    server: 203.0.113.10
    port: 8388
    cipher: aes-128-gcm
    password: "your-password"
    udp: true

  - name: "vmess-example"
    type: vmess
    server: 198.51.100.20
    port: 443
    uuid: 11111111-2222-3333-4444-555555555555
    alterId: 0
    cipher: auto
    tls: true
    servername: example.com
    network: ws
    ws-opts:
      path: /ray
      headers:
        Host: example.com

  - name: "trojan-example"
    type: trojan
    server: 192.0.2.30
    port: 443
    password: "your-password"
    sni: example.com
    skip-cert-verify: false
    udp: true

  - name: "hy2-example"
    type: hysteria2
    server: 203.0.113.40
    port: 443
    password: "your-password"
    sni: example.com
    skip-cert-verify: false

  - name: "vless-example"
    type: vless
    server: 198.51.100.50
    port: 443
    uuid: 11111111-2222-3333-4444-555555555555
    network: tcp
    tls: true
    udp: true
    flow: xtls-rprx-vision
    servername: www.microsoft.com
    reality-opts:
      public-key: "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
      short-id: "0123456789abcdef"
    client-fingerprint: chrome

skip-cert-verify は証明書チェーンに特別な事情があると確認できた場合のみ一時的に有効にしてください。長期間有効にしておくのは、TLSの証明書検証を放棄することと同義です。sni / servername はTLSハンドシェイクで宣言するドメイン名を決めるもので、誤って設定すると接続できなくなります。

プロトコル対応の差異

オリジナル版のClashは開発が終了しており、新しいプロトコルは mihomo カーネルにのみ追加されます。これが本サイトのダウンロードページで mihomo 系クライアントを一貫して推奨している理由です。

ポリシーグループ項目:proxy-groups

5つのタイプ

ポリシーグループは「ノードの集合+選択方式」です。select は手動選択で、パネルでクリックしたノードがそのまま使われます。ほぼすべての設定に総合入口となるグループが1つあります。url-test は一定間隔でグループ内のノードの速度を測定し、最も遅延の低いものを自動選択します。fallback も同様に速度測定を行いますが、意味は「現在のノードが落ちたら次に切り替える」で、リストの順序がそのまま優先順位になります。load-balance は接続を複数ノードに分散させます(strategy は consistent-hashing または round-robin)。複数回線で帯域を合算したい場合に向いています。relay は複数ノードをチェーン状に連結し、トラフィックが順に通過して最後のノードが出口になります。mihomo ではポリシーグループに icon 項目を追加でき、パネルにカスタムアイコンを表示できます。

速度測定パラメータ

url は速度測定の対象で、慣例的に http://www.gstatic.com/generate_204 が使われます。204で内容なしのレスポンスとなり、負荷が最小です。interval は速度測定の間隔(秒)で、短すぎるとトラフィックとバッテリーを消費するだけなので、300が一般的な値です。tolerance は切り替えのしきい値(ミリ秒)で、新しいノードが現在のノードよりこの数値以上速くならないと切り替えません。近い性能の回線間で頻繁に切り替わることを防ぎます。lazy を true にすると、グループが実際に使われているときだけ速度測定を行い、使われない待機用グループで無駄なトラフィックを消費しません。timeout は1回の速度測定のタイムアウト上限です。

入れ子と参照

ポリシーグループの proxies リストには、他のポリシーグループの名前を書くこともできます。これが入れ子です。総合入口の PROXY に「香港」「日本」「アメリカ」の3つの地域グループを入れ、各地域グループを url-test にすることで、手動で地域を選び、グループ内は自動でノードを選ぶという二層構造が実現できます。use 項目は proxy-providers で定義したサブスクリプション元を参照し、そのノード群をまとめてグループに取り込みます。filter は正規表現でノード名を絞り込みます。例えば filter: "香港|HK" は名前に「香港」を含むノードだけを残します。DIRECT(直接接続)と REJECT(拒否)は組み込みの2つの出口で、どの proxies リストにも直接記載でき、select グループと組み合わせれば「広告ブロックのオン/オフ」のような機能グループが作れます。

proxy-groups:
  - name: "PROXY"
    type: select
    proxies: ["HK-AUTO", "JP-AUTO", "US-AUTO", DIRECT]

  - name: "HK-AUTO"
    type: url-test
    use: ["provider-main"]
    filter: "香港|HK|Hong Kong"
    url: http://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    lazy: true

  - name: "JP-AUTO"
    type: url-test
    use: ["provider-main"]
    filter: "日本|JP|Japan"
    url: http://www.gstatic.com/generate_204
    interval: 300

  - name: "US-AUTO"
    type: fallback
    use: ["provider-main"]
    filter: "アメリカ|US|United States"
    url: http://www.gstatic.com/generate_204
    interval: 300

  - name: "AD-BLOCK"
    type: select
    proxies: [REJECT, DIRECT]

ルール構文:rules は上から順に評価

マッチング順序

rules は順序付きリストです。カーネルは上から下へ1件ずつ照合し、最初にマッチしたところで停止し、それ以降は評価しません。書き方の原則は「厳密なルールを先に、緩いルールを後に、MATCH は必ず最後に置く」です。ルールは2種類に分かれます。ドメイン系(DOMAIN / DOMAIN-SUFFIX / DOMAIN-KEYWORD / GEOSITE)は解決前に判定可能で、IP系(IP-CIDR / GEOIP)は解決結果が必要です。IP系ルールに no-resolve パラメータを付けると、「リクエストがもともとドメイン名の場合、このルールをマッチさせるためだけにDNS解決を発生させない」という意味になります。純粋なドメイン名リクエストはこの行をスキップして次へ進み、無駄なクエリを大幅に減らせます。GEOSITE と GEOIP は地理データファイルに依存し、GUIクライアントは自動で管理しますが、カーネル単体で動かす場合はデータファイルが設定ディレクトリ内にあること、または自動更新を有効にしておく必要があります。

ルールタイプ一覧

rule-providers ルールセット

ルールセットは何百・何千行にもなるルールを外部ファイルに切り出し、メイン設定には参照行だけを残す仕組みです。type が http の場合、url から定期的に取得し(interval 秒間隔)、path にキャッシュします。file の場合はローカルファイルを読み込みます。behavior は3種類あります。domain(純粋なドメイン接尾辞の集合。ドメインツリーとして読み込まれ、マッチングが最速)、ipcidr(純粋なIPセグメント)、classical(従来型のルール行で、各種タイプを混在させられる)。ルールセットファイル自体は yaml(payload のリスト)またはプレーンテキスト(1行1ルール)のどちらでも構いません。

rule-providers:
  reject-ads:
    type: http
    behavior: domain
    url: "https://example.org/rules/ads.yaml"
    path: ./ruleset/ads.yaml
    interval: 86400
  local-direct:
    type: file
    behavior: classical
    path: ./ruleset/direct.yaml

rules:
  - RULE-SET,reject-ads,AD-BLOCK
  - RULE-SET,local-direct,DIRECT
  - DOMAIN-SUFFIX,lan,DIRECT
  - GEOSITE,private,DIRECT
  - GEOSITE,cn,DIRECT
  - GEOIP,CN,DIRECT,no-resolve
  - GEOSITE,geolocation-!cn,PROXY
  - MATCH,PROXY

上書きと統合:サブスクリプションと独自設定の共存

サブスクリプションファイルを直接編集してはいけない理由

サブスクリプションの本質は「配布元から提供される設定ファイル全体」であり、クライアントは一定間隔でこれを再取得してファイル全体を上書きします。サブスクリプションファイルに追加した独自ルールやポリシーグループの変更は、次回の更新ですべて消えてしまいます。正しい考え方は「サブスクリプションの内容」と「ローカルの独自設定」を2層に分けることです。サブスクリプションはノードを担当し、上書き(オーバーライド)はルールや項目を担当し、両者はクライアントの動作時に統合されて最終的な設定になります。これにより、サブスクリプションを何度更新してもローカル層は変わりません。

クライアントの上書き機能

Clash Verge Rev を例にすると、サブスクリプション一覧を右クリックして編集に入ると、すべてのサブスクリプションに適用されるグローバル拡張設定(Merge)を管理できます。Merge は2種類のキーに対応しています。1つは prepend- / append- 接頭辞を持つ追加キーで、対応するリストの先頭または末尾に内容を挿入します。もう1つはトップレベルと同名の上書きキーで、サブスクリプション内の値を直接置き換えます。Clash Plus もサブスクリプション以外に独自設定を追加する入口を提供しており、考え方は同じです。まだ Clash for Windows を使っている方は注意してください。このプロジェクトは開発が終了しており、Mixin機構は長年更新されていません。《Clash Verge Rev と Clash Plus への移行ガイド》を参考に、現在も活発にメンテナンスされているクライアントへの切り替えを推奨します。

# グローバル拡張設定(Merge)の例
prepend-rules:
  - DOMAIN-SUFFIX,internal.example.com,DIRECT
append-proxy-groups:
  - name: "MY-SELECT"
    type: select
    use: ["provider-main"]
mixed-port: 7897

3つの方式の比較

検証・デバッグと典型的なエラー

カーネルによる静的チェック

mihomo には設定チェック機能が組み込まれています。config.yaml を1つのディレクトリに置き、./mihomo -t -d ./ディレクトリ を実行すると、成功時にはチェック成功のメッセージが、失敗時には項目名と行番号が表示されます。大きな変更を行った際は、まずコマンドラインで -t を通し、それから GUI に読み込ませると、クライアントを何度も再起動して試行錯誤するより格段に速く済みます。Windowsユーザーはカーネルの実行ファイルと設定ファイルを同じディレクトリに置き、PowerShellで同じコマンドを実行してください。

ホットリロードとログ

external-controller が有効になっている場合、カーネルを再起動せずに設定を再読み込みできます。

curl -X PUT "http://127.0.0.1:9090/configs?force=true" \
  -H "Content-Type: application/json" \
  -d '{"path": "/絶対パス/config.yaml"}'

force=true は既存の接続を強制的に切断・再接続します。日常的な再読み込みでは付けなくても構いません。ログについては、log-level を debug にすると、各接続のマッチング過程(ドメイン名、マッチしたルール、出口ノード)がすべて出力され、「このトラフィックがなぜプロキシを通らないのか」を特定する最初の手段になります。GUIクライアントのログ/コネクションパネルは、本質的にこのデータをグラフィカルに表示しているだけです。

頻発するエラーの対照表

ここまでで、骨格から項目、ルールから上書きまで、設定ファイルの一連の流れがひととおり揃いました。日常利用でよくある具体的な問題(つながらない、遅い、特定のアプリだけプロキシを通らない)については、よくある質問ページが症状別に対処法を整理しています。まだクライアントを導入していない方は、ダウンロードページでプラットフォームごとに現在メンテナンスされている選択肢を確認できます。まずは最小構成で素早く動かしてから、このページで項目を調べたい方は、導入ガイドから始めてください。