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

図版 B-01本ページの位置づけと読み方

本サイトのコンテンツは2つの系統に分かれています。入門ガイドはすぐに使い始めるための手順で、「クライアントをインストール → サブスクリプションを導入 → モードを選択 → 接続を確認」の順に進めれば通常利用に入れます。設定ファイルを読む必要は一切ありません。本ページはもう一つの系統で、config.yaml を開いて確認・変更する場面向けのリファレンスです。たとえば、あるルールがなぜ効かないのか調べたい、サブスクリプションとは別に自分でルールを追加したい、あるいは最小構成の設定をゼロから書きたい、といった場合に使います。両者は相互に参照する関係にあり、初めて Clash に触れる方はまず入門ガイドの手順を完了させ、設定が動くようになってから本ページをフィールド番号ごとに参照してください。

フィールドの記述基準について先に説明します。現在主流のグラフィカルクライアント——Clash Plus、Clash Verge Rev、FlClash など、一覧はインストールガイドとクライアント比較ページを参照——は、いずれも mihomo コアまたは互換コアを内部で動かし、同じ YAML 設定形式を読み込んでいます。本ページは各コアで共通して使えるフィールドを主体に解説し、新しいコアのみが対応する拡張機能については各段落で個別に注記します。旧コアにそのまま流用して「フィールドを認識できない」というエラーが出ないようにするための配慮です。

読み方の目安は次の通りです。分流ルールを変更したい場合は図版 B-07 と B-08 を、サブスクリプション更新で手動修正が消えてしまう場合は図版 B-09 を、あるノードに接続できない場合はまずノードタイムアウトの対処記事を確認してから設定変更を検討してください。ネットワークに全く接続できない場合は、まずよくある質問と入門ガイドでクライアントとシステムプロキシの状態を確認し、不具合が出ている状態のまま設定ファイルをやみくもに書き換えないでください。

図版 B-02YAML 構造の全体像

書き方の3つの鉄則

config.yaml は標準的な YAML 文書で、いくつかのトップレベルキーで構成され、各キーが一つの機能ブロックを担当します。YAML の記述には3つの鉄則があり、「設定の読み込みに失敗する」ケースの大半はこのいずれかが崩れています。第一に、インデントは半角スペースのみを使い、慣例として2スペースを1階層とし、タブは使用しません。第二に、「キー: 値」のコロンの後には必ず半角スペースを入れます。port:7890 のように書くと、キーと値のペアではなく単一の文字列として扱われてしまいます。第三に、リスト項目は「- 」で始め、同じ階層のハイフンは同じ列に揃えます。

文字列の引用符も見落としがちなポイントです。値に #、コロン、波カッコなどの特殊文字が含まれる場合、または特殊記号で始まる場合は必ず引用符で囲む必要があります。囲まないと # 以降がコメントとして切り捨てられてしまいます。ノード名に emoji、スペース、全角文字が含まれる場合は、解析のあいまいさを避けるため常に二重引用符で囲むことを推奨します。プロキシグループから参照する際も、この引用符付きの表記のまま記述してください。

トップレベルキー一覧

最小構成のひな形

以下は構造として完結した最小構成のひな形です。5つのブロックが揃っていればコアに読み込ませることができます。以降の各図版で1ブロックずつ拡大して解説していきます。

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

dns:
  enable: true
  enhanced-mode: fake-ip
  nameserver:
    - https://doh.pub/dns-query

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

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

rules:
  - GEOIP,CN,DIRECT
  - MATCH,ノード選択

見慣れない設定ファイルを読む際の推奨順序:まず mode とポート部分を見て動作方式を確認し、次に proxy-groups を見て出口の構成を把握し、最後に rules でトラフィックの振り分けを確認します。proxies ブロックは通常サブスクリプションが自動生成するため、単一ノードの問題を調べるとき以外はフィールドを1つずつ細かく見る必要はありません。

図版 B-03共通フィールド:ポート、動作モード、コントロールインターフェース

3種類のポート

port は HTTP プロキシ専用ポート、socks-port は SOCKS5 ポートで、mixed-port は同一ポートで両方のプロトコルを受け付けます。現行のクライアントはデフォルトで mixed-port: 7890 を使用し、システムプロキシ、ブラウザの手動プロキシ設定、ターミナルの環境変数もこの1つのポートを指すだけでよく、個別に設定する必要はありません。3つのキーは 0 を指定するか省略すると該当ポートを待ち受けません。注意点として、ポート番号を変更したらシステムプロキシの設定も必ず同期させてください。そうしないと「クライアントは動いているのにトラフィックが流れない」という見かけ上の不具合が起きます。この種の問題の詳しい対処法はシステムプロキシが効かない場合の対処記事を参照してください。

LAN 共有

allow-lan: true にすると、同一 LAN 内の他のデバイスがこの端末をプロキシサーバーとして利用できるようになります。クライアントを入れにくいテレビや家庭用ゲーム機にプロキシの出口を指定するのが典型的な用途です。bind-address と組み合わせれば、特定のネットワークインターフェースのみで待ち受けるよう制限できます。カフェや空港などの公衆ネットワークでは false のままにしてください。そうしないと同一ネットワーク内の誰でもこの出口を使えてしまいます。

動作モード mode

ログとコントロールインターフェース

log-level の値は簡素なものから詳細なものへ silent / error / warning / info / debug の順です。通常時は info で問題ありません。あるルールが命中しているかを調べたいときだけ debug に切り替えると、コアが接続ごとの照合結果を1件ずつ出力します。確認後は元に戻してください。debug のままにしておくと大量のログが生成されます。external-controller は RESTful コントロールインターフェースの待受アドレスを定義します(よく使われるのは 127.0.0.1:9090)。グラフィカルクライアントの接続パネル、ノード切り替え、レイテンシテストはすべてこのインターフェース経由でコアの状態を読み書きします。secret はこのインターフェースへのアクセスキーです。ipv6: false の場合、コアは IPv6 アドレスの解決も接続も行いません。利用中のネットワークで IPv6 経路が不安定な場合は、いったん無効にしておくとよいでしょう。

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

また、比較的分量の多いトップレベルキーとして tun があります。これは仮想ネットワークアダプタとしてシステム全体のトラフィックを引き受ける方式で、一部のアプリがシステムプロキシを参照しない問題を解決できます。サブフィールドはコアのバージョンによってかなり差があり、システム権限も関わるため、クライアントの UI にある「TUN モード」のスイッチを使い、クライアント側に正しいフィールドを生成させることを推奨します。手動で書くのは避けてください。有効化前の注意点はよくある質問の該当項目を参照してください。

図版 B-04DNS 設定:解決レイヤーが分流の土台になる

プロキシ利用時に DNS を別途設定する理由

ルールの照合は多くの場合ドメイン名レイヤーで行われます。ドメイン名がコアに渡る前にローカルネットワーク側で汚染され、誤った IP に解決されてしまうと、GEOIP のように IP の帰属で判定するルールも連動して誤判定を起こし、「ルールの記述自体は正しいのにトラフィックが間違った出口に流れる」という現象が発生します。dns セクションの役割は、この解決処理をコアに引き受けさせ、ルール照合の根拠となる解決結果を信頼できるものにすることです。enable: true がこのセクション全体を有効にする前提条件です。

enhanced-mode の2つの動作方式

fake-ip モードでは、コアは各ドメイン名に対して予約済みのネットワーク帯(デフォルトは 198.18.0.1/16)内の仮アドレスを返し、実際に接続を確立する段階でドメイン名に基づきルールを照合して解決を行います。利点は事前解決を1回省ける分レイテンシが低く、根本的にローカルネットワークによる解決結果の妨害を避けられることで、現在の推奨設定です。redir-host モードは実際の IP を返すため互換性は高いものの、接続ごとに解決処理が1回余分に発生します。fake-ip を使う場合、fake-ip-filter には実際の IP が必要なドメインを必ず列挙してください——LAN 内デバイスの管理用ドメイン、NTP 時刻同期、一部の対戦型ゲームプラットフォームなどが該当し、これを忘れるとこれらのサービスは仮アドレスのまま動作しなくなります。

3種類のサーバーが担う役割の切り分け

default-nameserver が担うのはただ一つの役目です。nameserver に設定した DoH/DoT サーバー自身のドメイン名を解決することで、そのため必ず純粋な IP アドレスを指定する必要があり、ドメイン名を指定すると「鶏が先か卵が先か」のような循環に陥ります。nameserver はメインの解決グループで、日常的な問い合わせをすべて担当します。暗号化された DNS アドレスの指定を推奨します。一部のコアでは fallback グループにも対応しており、メイングループの結果が汚染の特徴に合致した場合に、こちらのグループ(通常は海外の解決サービスを指定)の結果を採用します。これは任意の追加機能です。

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"
    - "time.windows.com"
  default-nameserver:
    - 223.5.5.5
  nameserver:
    - https://doh.pub/dns-query
    - https://dns.alidns.com/dns-query

図版 B-05プロキシノードのフィールド:proxies 配列

proxies はノード定義の配列です。サブスクリプションを利用している場合、このセクションはサブスクリプション変換サービスが自動生成するため、通常は手書きの必要はありません。手書きが必要になる典型的な場面は、自前のサーバーを立てる場合や単一ノードのデバッグを行う場合です。すべてのプロトコルで共通する4つのフィールドがあります:name(ノード名。ファイル全体で一意であり、プロキシグループが名前で参照します)、type(プロトコルの種類)、server(サーバーアドレス。ドメイン名または IP)、port(サーバー側のポート)。それ以外のフィールドはプロトコルによって異なり、以下ではインストールガイドでカバーしている主要なプロトコルを順に紹介します。

Shadowsocks(type: ss)

重要なフィールドは2つで、cipher(暗号化方式)と password(パスワード)です。いずれもサーバー側と完全に一致させる必要があり、どちらか一方でも一致しないと、接続確立後すぐに切断されるか無応答になる現象が起こります。

- name: "ss-サンプル"
  type: ss
  server: example.com
  port: 8388
  cipher: aes-128-gcm
  password: "your-password"

VMess(type: vmess)

認証情報は uuid で、サーバー側と1文字も違わず一致させる必要があります。alterId は現行の構成では常に 0 です。cipher は通常 auto を指定します。WebSocket + TLS 経由のノードでは network: ws と ws-opts サブセクションが必要で、path と headers.Host はサーバー側の設定と一致させる必要があります。この2箇所の記述ミスは VMess ノードがタイムアウトする原因として非常に多いです。

- name: "vmess-サンプル"
  type: vmess
  server: example.com
  port: 443
  uuid: 00000000-0000-0000-0000-000000000000
  alterId: 0
  cipher: auto
  tls: true
  network: ws
  ws-opts:
    path: /your-path
    headers:
      Host: example.com

Trojan と Hysteria2

Trojan は password を認証情報とし、実際の TLS 証明書に依存します。sni は証明書に対応するドメイン名を指定する必要があります。Hysteria2 は QUIC(UDP 通信)を基盤とし、password に加えて up / down で帯域を宣言することで輻輳制御を有効化できます。利用中のネットワークで UDP が遮断されている場合、このプロトコルはそもそも使えないため、切り分けの際はまずここを確認してください。

- name: "trojan-サンプル"
  type: trojan
  server: example.com
  port: 443
  password: "your-password"
  sni: example.com

- name: "hy2-サンプル"
  type: hysteria2
  server: example.com
  port: 443
  password: "your-password"

フィールドを確認しても接続できない場合、問題の多くは設定ファイル自体にはありません。ノードタイムアウト対処チェックリストの順に、サブスクリプションの有効性、システム時刻、ファイアウォールを確認してください。

図版 B-06プロキシグループのフィールド:proxy-groups 配列

プロキシグループはルールとノードの間に置かれる中間層です。ルールの出口はグループ名を指し、そのグループが実際に使うノードを決定します。この層を分離しておく利点は、サブスクリプションのノード名変更や増減があってもグループのメンバーリストを保守するだけで済み(サブスクリプション変換で通常自動的に反映されます)、ルールを1行も変更する必要がない点です。よく使われる4種類のタイプは以下の通りです。

自動速度測定のパラメータ

url-test と fallback は3つのパラメータに依存します。url には軽量な生存確認用アドレスを指定します(よく使われるのは https://www.gstatic.com/generate_204 で、空のレスポンスを返すため負荷が非常に小さいです)。interval は測定周期で単位は秒、300 がよく使われます。tolerance は単位がミリ秒で、新しいノードのレイテンシが現在のノードよりこの値以上低くならないと切り替えないという設定です。レイテンシが近い2つのノード間で頻繁に切り替わってしまうのを防ぐためのものです。任意の lazy: true を設定すると、そのグループが実際に使われたときにのみ速度測定を行うようになり、バックグラウンドでのリクエストを減らせます。

入れ子構造と組み込みの出口

グループは入れ子にできます。よく使われるやり方は、select の総合出口グループを1つ作り、url-test の自動選択グループと複数の手動ノードをまとめてメンバーにする方法です。通常時は自動グループにしておき、必要なときだけワンクリックで特定のノードに切り替えます。DIRECT(直接接続)と REJECT(拒否)はコアに組み込まれた2つの出口で、定義せずにそのままどのグループのメンバーやルールの出口としても使えます。

proxy-groups:
  - name: "ノード選択"
    type: select
    proxies:
      - "自動速度測定"
      - "香港-01"
      - "日本-01"
      - DIRECT

  - name: "自動速度測定"
    type: url-test
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    proxies:
      - "香港-01"
      - "日本-01"

命名の規律:グループ名はノード名と重複させないでください。ルールやグループメンバーで参照する名前は、定義箇所と1文字も違わず一致させる必要があります。emoji、スペース、全角・半角の違いも含みます。1箇所でも不一致があると、コアは「proxy not found」のようなエラーで設定全体の読み込みを拒否します。これはサブスクリプションのノード名が変わった直後に設定が突然エラーになる典型的な原因でもあります。

図版 B-07ルール構文と照合順序

rules 配列は上から順に1件ずつ照合され、最初に命中した時点で評価が止まり、それ以降のルールは見られません。つまり記述順序がそのまま優先度になります。これはルール分流の挙動を理解するうえでの第一原理です。各ルールの基本形式は「タイプ,照合値,出口」で、一部のタイプは追加パラメータに対応します。出口にはプロキシグループ名、ノード名、または組み込みの DIRECT / REJECT を指定できます。

並び順の原則と no-resolve

推奨される並び順は、完全一致系(DOMAIN)を先頭に、範囲系(DOMAIN-SUFFIX / DOMAIN-KEYWORD)を中間に、IP 系(GEOIP / IP-CIDR)を後方に置き、MATCH は必ず最後の1行だけにします。IP 系のルールは照合前にドメイン名を IP に解決する必要があり、余分な解決処理が発生します。プライベートネットワーク帯や予約帯のような「もともと IP が対象」のルールでは、行末に no-resolve パラメータを付けて「対象が IP でなければこの行はスキップする」と宣言し、不要な解決を避けてください。

rules:
  - DOMAIN,dl.google.com,ノード選択
  - DOMAIN-SUFFIX,github.com,ノード選択
  - DOMAIN-KEYWORD,google,ノード選択
  - DOMAIN-SUFFIX,cn,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,ノード選択

よくある3つの記述ミス

1つ目は、MATCH の後にもルールを書いてしまうケースです。命中した時点で評価が止まるため、それらのルールは永久に実行されず無効な行になります。2つ目は、DOMAIN-SUFFIX,cn で中国本土のサイトをすべて網羅できると思い込むケースです。これは .cn の末尾にしか一致せず、中国本土の多くのサービスは .com ドメインを使っているため、中国本土向けトラフィックの兜底は GEOIP,CN に任せるべきです。3つ目は、出口名がプロキシグループの定義と一致していない(スペースや emoji が1つ違う)ケースで、設定全体が読み込みを拒否されます。国内・海外の分流の完全な記述方法と照合の考え方はルール分流設定の実践記事を参照してください。すぐに使いたいだけの場合は、入門ガイドに掲載されている完成済みのルールをそのまま利用してください。

図版 B-08ルールセット:rule-providers による外部ルール

数千行のルールを手動で保守するのは現実的ではありません。ルールセットの仕組みは、大量のルールを外部ファイルとして分離し、設定ファイル側には取得元の宣言と1行の参照だけを残し、コアが周期的に自動で更新を取得する仕組みです。これはトップレベルキーの rule-providers(取得元を定義)と、rules 内の RULE-SET 項目(それを利用する側)の2つが連携して機能します。

フィールドの説明

type は http(リモート取得)または file(ローカルファイル)のいずれかです。behavior はファイルの内容形式を宣言し、3種類あります:domain はファイルにドメイン名のリストのみが含まれることを示し、ipcidr はネットワーク帯のリストのみを示し、classical は各行が「タイプ,照合値」の完全なルールであることを示します。behavior はファイルの実際の内容と一致させる必要があります。一致していなくてもエラーにはならず、静かに機能しなくなるだけです。これがルールセットが「読み込まれているように見えるのに効かない」原因の第一位です。format はファイル形式を宣言します(yaml または text)。url はリモートアドレス、path はローカルのキャッシュパスです。異なるルールセットで同じ path を共用すると互いに上書きされてしまうため注意してください。interval は更新周期で単位は秒、86400 で1日1回になります。

rule-providers:
  reject-list:
    type: http
    behavior: domain
    format: yaml
    url: https://example.com/rules/reject.yaml
    path: ./ruleset/reject.yaml
    interval: 86400

  cn-cidr:
    type: http
    behavior: ipcidr
    format: yaml
    url: https://example.com/rules/cn-cidr.yaml
    path: ./ruleset/cn-cidr.yaml
    interval: 86400

rules:
  - RULE-SET,reject-list,REJECT
  - RULE-SET,cn-cidr,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,ノード選択

補足2点。RULE-SET 項目が rules 内にある位置も「上から順に、命中したら止まる」という全体の順序に従います。ルールセットだからといって優先的に評価されるわけではありません。また、ipcidr 型のルールセットを参照する場合は IP-CIDR ルールと同様に、参照行の末尾に no-resolve を付けることを推奨します。リモートのルールセットは初回取得時にネットワーク接続が必要なため、初期セットアップ時にまだ接続できていない場合は、type: file でクライアントに同梱されているローカルファイルを一時的に指定して乗り切ることができます。

図版 B-09上書きとマージ:サブスクリプション更新後も手動修正を残す方法

問題と原則

サブスクリプションが生成した設定ファイルを直接編集するのは、初心者が最もよく陥る保守上の落とし穴です。次にサブスクリプションが更新されると、ファイル全体が再生成され、手動での修正はすべて失われてしまいます。正しい方法は1つの規律を守ることです——サブスクリプションの原文には手を加えず、修正はすべて「オーバーライド層」に記述する。クライアントは設定を読み込むたびにオーバーライドの内容とサブスクリプションの原文をマージしてからコアに渡すため、サブスクリプションがどのように更新されても、あなたのカスタマイズには影響しません。

各クライアントのオーバーライド機能

主流のクライアントはいずれもこの仕組みを提供しています。呼び方は異なりますが考え方は同じです:Clash Verge Rev は「グローバル拡張設定」を提供し、Merge(宣言的マージ)と Script(スクリプトによる書き換え)の2種類があります。Clash Plus には設定オーバーライドの入口があります。FlClash は設定の重ね合わせに対応しています。入口の位置やフィールド名はクライアントの更新に応じて変わるため、クライアント内の説明を最終的な基準としてください。以下は Merge 方式の例で、サブスクリプションのルールの先頭にカスタムルールを2件挿入しつつ、同時に DNS セクションを上書きしています。

prepend-rules:
  - DOMAIN-SUFFIX,intra.example.com,DIRECT
  - PROCESS-NAME,Steam.exe,DIRECT

dns:
  enable: true
  enhanced-mode: fake-ip

prepend- 接頭辞は、サブスクリプション側の同名配列の前に挿入する(優先度が最も高い)ことを示し、append- は末尾に追加することを示します。トップレベルキーを直接書く(上記例の dns など)場合は、サブスクリプション側の該当セクション全体を置き換えます。カスタムルールはほとんどの場面で prepend を使います——ルール照合は命中した時点で止まるため、先頭に挿入してこそ優先的に効くことが保証されます。

修正後の確認手順

オーバーライドの内容を変更するたびに、決まった手順で確認してください:オーバーライドを保存 → クライアントで設定をリロード → ログにエラーがないことを確認 → 以下のコマンドでプロキシポートが正常に転送していることを確認 → 接続パネルで実際に対象サイトへアクセスし、命中したルールと出口が想定どおりであることを確認します。コマンドが HTTP/2 204 または 204 No Content を返せば経路は正常です。

curl -x http://127.0.0.1:7890 https://www.gstatic.com/generate_204 -I

図版 B-10読み込みエラー対処表:エラー文言から該当行を特定する

設定を間違えて書き換えると、コアは読み込みを拒否し、ログに1行のメッセージを残します。この文言はクライアントによって表現が少し異なりますが、種類は決まっており、種類を理解すればエラーの出ているフィールドを直接特定できるため、ファイル全体を1行ずつ読む必要はありません。以下の表は、よく見られるメッセージの種類と実際の原因を対応させたものです。トラブル対応の際はまずメッセージを分類し、対応する図版に戻って記述を確認してください。

汎用的な二分探索式の特定方法

エラーが示す行番号が曖昧で、その行を見ても問題が見つからない場合、多くは前のブロックの構造が正しく閉じられておらず、エラーが次の行に「押し出されて」いる状態です。この場合は二分探索が最も時間を節約できます。まず rules ブロック全体をコメントアウトしてリロードし、読み込めれば問題はルール側にあります。読み込めなければ次に proxy-groups をコメントアウトし、順に上へ範囲を絞っていき、具体的なブロックを特定したら、そのブロック内でさらに半分ずつコメントアウトしていきます。YAML のコメントは行頭に # を付けるだけで、一括コメントアウトはどのテキストエディタでも一度に行えるため、数回の絞り込みで必ずエラーの行に収束します。

また、「エラーは出ないのに効かない」というケースはさらに時間を取られがちです。コアの読み込みは成功し、ログもきれいなのに、動作だけが期待と違うというものです。この種の問題の根本原因は構文ではなく意味の側にあることが多く、上にあるより広い範囲のルールに先に命中してしまっている、ルールセットの behavior がファイルの内容と一致していない、あるいはオーバーライド層の解析に失敗して静かにフォールバックしている、といったケースです。判断方法は共通していて、log-level を debug に切り替えて対象サイトに一度アクセスし、ログでその接続が実際にどのルールに命中し、どの出口を通ったのかを確認します。これだけで「推測」を「確認」に変えられます。ログにそのドメインの記録すら見当たらない場合は、トラフィックがそもそもコアに入っていないことを意味するため、まずシステムプロキシが効かない場合の対処記事で入口側の問題を解決してください。

図版 B-11バックアップ、バージョン管理、長期的な保守の心得

バックアップすべきもの

長期的に保存しておくべきものは実質3つだけです。1つはサブスクリプションのリンク自体(失うとサービス提供元の管理画面から再取得する必要があります)、2つ目は自分で書いたオーバーライド層の内容(これは自動では復元できない唯一の手作りの資産です)、3つ目はカスタムルールセットのローカルファイル(type: file を使っている場合)です。サブスクリプションが生成する config.yaml 本体はバックアップ不要です——いつでも再取得できますし、バックアップするとむしろ「バックアップファイルを編集したのに反映されない理由が分からない」という混乱を招きます。この3つを1つのプレーンテキストのフォルダにまとめておけば、システムの再インストールやマシンの入れ替え時に、クライアントを新しくインストール → サブスクリプションを入れ直す → オーバーライド層を貼り直す、という手順で数分で完全に復元できます。

記憶に頼らずコメントに頼る

オーバーライド層にカスタムルールを1件追加するたびに、その上の行に「なぜ追加したのか」「いつ削除してよいのか」を一言コメントしておいてください。半年後に見返すと、コメントのないルールは削除する勇気も持てず、用途も思い出せず、ずっと残しておくしかなくなります。コメントがあるルールは定期的に整理できます。コメントのコストは1行分の文字ですが、その見返りとして設定ファイルが時間とともに肥大化して保守不能な負債になることを防げます。

prepend-rules:
  # 会社の社内システム、必ず直接接続。退職後は削除可
  - DOMAIN-SUFFIX,intra.example.com,DIRECT
  # Steam のダウンロードは帯域をフルに使うため直接接続。2026-07 追加
  - PROCESS-NAME,Steam.exe,DIRECT

定期的に見直すべき3つのポイント

1つ目は、ルールセットの interval と path です。複数のルールセットで同じ path を共用すると互いに上書きしてしまい、新しくルールセットを追加する際にコピー&ペーストで誤りが起きやすいため、追加するたびに確認する価値があります。2つ目は、プロキシグループのメンバーです。サブスクリプションのノード名が変わった後、オーバーライド層に手書きしたノード名が無効になっていることがあり、グループのメンバーが減っていたり、proxy not found のエラーが出たりします。3つ目は、コアとクライアントのバージョンです。新しいフィールドは古いコアでは認識されないため、クライアントを更新した後に新しいフィールドを使う方が安全です。各クライアントの更新頻度や違いはクライアント比較ページを、インストーラーの入手はインストールガイドを参照してください。

修正を続けるより作り直すべきタイミング

何度も手動修正を重ねて、自分でもどのフィールドがまだ有効なのか分からなくなった設定は、修正を続けるより作り直す方が速いです。古い設定を削除し、サブスクリプションを再取得してきれいな原文を手に入れ、オーバーライド層の中から本当に必要だと確認できたルールだけを選び出して貼り直し、残りはすべて捨てます。図版 B-02 の最小構成のひな形を目安にすれば、5つのブロックが揃うだけで動きます。そこから必要に応じて1ブロックずつ追加し、追加するたびにリロードすれば、どこかで問題が起きてもすぐに特定できます。この方法は遠回りに見えますが、混乱したファイルを1つずつ調査するより実際には時間を節約できます。

図版 B-12よくあるシーン別のフィールド組み合わせ

本セクションでは、これまでの各項目のフィールドを組み合わせて、日常でよく使う4種類のニーズに対応する完成した書き方を紹介します。いずれもオーバーライド層に記述するため、サブスクリプションの更新には影響されません。コピーした後、コメントに従って自分のドメイン名やプロセス名に置き換えるだけで使えます。

シーン1:特定のサイトを必ず直接接続にする

社内システム、銀行、行政機関のサイトなど、国内の出口しか認めないサービスは、プロキシ経由だと拒否されたり、何度も本人確認を求められたりします。DOMAIN-SUFFIX で DIRECT を指定し、prepend セクションに置くことで、サブスクリプションに含まれるどのルールよりも優先されるようにします。

prepend-rules:
  - DOMAIN-SUFFIX,intra.example.com,DIRECT
  - DOMAIN-SUFFIX,example-bank.com,DIRECT

シーン2:特定のアプリを丸ごと直接接続またはプロキシ経由にする

デスクトップ環境ではプロセス名で分流できます。ゲームのダウンローダーや大容量ファイルの同期ツールのように、プロキシを必要とせず帯域をフルに使ってしまうアプリに向いています。プロセス名はシステム上の実際の実行ファイル名を書く必要があり、Windows では .exe 拡張子を含みますが、macOS や Linux では通常含みません。名前はクライアントの接続パネルで直接確認できます。

prepend-rules:
  - PROCESS-NAME,Steam.exe,DIRECT
  - PROCESS-NAME,Docker Desktop.exe,ノード選択

シーン3:広告やトラッキング用ドメインを遮断する

接続したくないドメインを REJECT に向けると、コアはその接続を直接拒否します。少数のドメインなら手書きでも構いませんが、規模が大きくなる場合はルールセットに任せ、rule-providers で自動更新させることで、数千行を手動で保守する事態を避けられます。

prepend-rules:
  - DOMAIN-KEYWORD,doubleclick,REJECT
  - DOMAIN-SUFFIX,ads.example.com,REJECT

シーン4:地域別に出口を分ける

動画配信サービスや AI サービスなど、地域によって提供内容が異なるサイトは、特定の地域のノードを固定して使う必要があります。やり方は、まずその地域のノードだけを含む select または url-test グループを1つ作り、対応するドメインをこのグループに向けます。こうすればノードの増減時にグループのメンバーを保守するだけで済み、ルールには手を加える必要がありません。

prepend-proxy-groups:
  - name: "日本出口"
    type: url-test
    url: https://www.gstatic.com/generate_204
    interval: 300
    proxies:
      - "日本-01"
      - "日本-02"

prepend-rules:
  - DOMAIN-SUFFIX,example-stream.jp,日本出口

4つの組み合わせはいずれも同じ考え方に従っています:「どのトラフィックか」(ドメイン、プロセス、IP 帯)を特定し、「どの出口に送るか」(組み込みの出口かプロキシグループ)を決め、優先度を確保するために prepend セクションに置く、という3ステップです。この3ステップを理解すれば、新しいニーズが出てきても自分で組み立てられるようになり、既製の設定を待つ必要はありません。ルール間の照合の考え方やより複雑な国内・海外の分流方法については、ルール分流設定の実践記事を参照してください。

以上で config.yaml の主要なフィールドを網羅しました。本ページで扱っていない具体的な不具合についてはよくある質問で分類から検索してください。どのクライアントでこの設定を使うか迷う場合はクライアント比較ページの選定結論を参照してください。まだクライアントをインストールしていない方はインストールガイドからプラットフォームに応じて入手してください。いずれのプラットフォームでも Clash Plus を第一候補として推奨しています。