上級設定 2026-05-08 読了目安 9分

Clash 設定ファイル YAML 構造を逐条解説:ポート設定から rules 規則セクションまで

Clashの設定ファイルは全体設定・DNS・proxies・proxy-groups・rulesなどのセクションで構成されます。各項目の役割や値の指定方法、インデントの落とし穴を順に解説します。

設定ファイルの基本構造と読み込み方式

Clash 系クライアント(オリジナルの Clash、Clash Meta、その派生コアである mihomo を含む)が読み込む中核設定は YAML 形式のテキストで、通常 config.yaml という名前が付けられます。設定がサブスクリプションリンクから自動ダウンロードされたものであれ、手動でローカルファイルを読み込んだものであれ、クライアントは最終的にこのテキストを構造化データとして解析し、記載されているポート・プロキシノード・ポリシーグループ・規則の順に各モジュールを初期化します。このファイルのセクション構成を理解しておくことは、「規則が反映されない」「ノードのグループが空になる」といった問題を切り分けるための前提となります。

設定ファイルは慣例として上から下へ、全体の動作パラメータ・DNS 解析設定・proxies ノード一覧・proxy-groups ポリシーグループ・rules 規則表という5つの大きなセクションに分かれます。セクション同士の順序に厳密な規定はなく、コアはフィールド名で照合するため行番号順ではありませんが、大半のサブスクリプション生成ツールや主流のテンプレートはこの順序に従っており、本稿もこの順序に沿って解説します。実際のファイルと照らし合わせて確認する際の参考にしてください。

YAML はインデント(空白の階層)で構造を表現する形式であり、波括弧や終了タグを使いません。つまり同一セクション内では、子フィールドのインデントの空白数が完全に一致していなければならず、タブ文字を空白の代わりに使うこともできません。手作業で設定を編集する際に最もつまずきやすいポイントで、後段で節を設けて詳しく説明します。

全体設定フィールド:ポート・動作モード・ログレベル

ファイルの最上部には、通常どの階層にも属さない独立したキーと値のペアが並びます。よく見られるフィールドは次のとおりです。

port: 7890
socks-port: 7891
mixed-port: 7890
allow-lan: true
mode: rule
log-level: info
external-controller: 127.0.0.1:9090
secret: ""

各フィールドの役割は以下のとおりです。

  • port / socks-port:それぞれ HTTP プロキシポートと SOCKS5 プロキシポートを指定します。OS やアプリでプロキシを手動設定する際にこの数値が必要になります。
  • mixed-port:1つのポートで HTTP と SOCKS5 の両プロトコルを同時にリスニングできる設定で、これを使う場合は上の2項目は省略可能です。多くのGUIクライアントはデフォルトでこの項目のみを使用します。
  • allow-lan:同一LAN内の他端末が本機のプロキシポート経由で接続することを許可するかどうかの設定です。スマートフォンやタブレットで同じPCのプロキシを共有する場合に有効化が必要です。
  • mode:全体の動作モードで、代表的な値は rule(規則表に基づく振り分け)、global(全通信を同一プロキシ経由に)、direct(全通信を直接接続)です。通常は rule を選び、他の2つは切り分け検証のため一時的に切り替えるだけにしましょう。
  • log-level:ログの詳細度で、silent、error、warning、info、debug の値を取ります。接続失敗の調査時に一時的に debug にするとハンドシェイクの過程がより詳細に確認できます。
  • external-controller:外部管理パネル(内蔵ダッシュボードなど)から呼び出す API のアドレスとポートです。多くのGUIクライアントは管理画面を内蔵しているため、通常のユーザーが変更する必要はありません。
  • secret:上記 API にアクセスする際の認証パスワードです。空欄はパスワード未設定を意味し、ローカル利用のみなら未設定でも構いませんが、LAN内公開時は設定を推奨します。

また、TUN モード関連のフィールドもこのセクションに含まれます。

tun:
  enable: true
  stack: system
  dns-hijack:
    - "any:53"
  auto-route: true
  auto-detect-interface: true

TUN モードは Clash に仮想ネットワークアダプタを作成させ、システムのネットワーク層から全体の通信を引き受けさせる仕組みです。アプリごとに HTTP/SOCKS プロキシを個別設定する必要がなくなり、プロキシ設定に対応していないソフトウェアやシステムレベルの通信を処理する際によく利用されます。stack は仮想アダプタが使うプロトコルスタックの実装を決めるもので、system はOS標準機能に依存し互換性が高く、gvisor はユーザー空間での実装でプラットフォームによってはより安定した性能を発揮します。TUN モードの有効化には通常、クライアントを管理者権限または root 権限で実行する必要があり、プロキシポート設定とは独立した別の通信引き受け機構です。

DNS セクションの詳細

DNS セクションはドメイン名の解決要求をどう処理するかを決定し、振り分けの正確性や解決速度に直接影響します。見落とされがちですが問題が起きやすい部分です。

dns:
  enable: true
  ipv6: false
  default-nameserver:
    - 223.5.5.5
    - 119.29.29.29
  nameserver:
    - https://dns.alidns.com/dns-query
    - tls://dns.google
  fallback:
    - https://1.1.1.1/dns-query
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "localhost.ptlogin2.qq.com"
  • default-nameserver:下の nameserver、fallback に記載された DoH/DoT サーバーのドメイン名自体を解決するために使われます。純粋な IP アドレスである必要があり、さらにドメイン解決を挟むと循環参照になってしまいます。
  • nameserver:通常のドメイン名を実際に解決するサーバー一覧です。従来の UDP、DoH(https://)、DoT(tls://)など複数のプロトコルプレフィックスに対応します。
  • fallback:規則判定によりあるドメインがプロキシ経由になるべきと判断された場合に使う予備の解決サーバーです。通常は海外や暗号化された解決サービスを設定し、汚染を避けます。
  • fake-ip-range:fake-ip モードを有効にした場合、ドメイン名に一時的に割り当てられる仮想 IP のレンジです。クライアントはこの仮想 IP を受け取り、コアが接続確立時に実際の宛先へ復元します。これはドメイン名でマッチングしつつ IP レイヤーで転送するための橋渡し機構です。
  • fake-ip-filter:fake-ip を使わず実際の IP をそのまま返すドメインを指定します。LAN内デバイスの検出や配信のコメント機能など、実際の IP に依存する場面でよく必要になり、設定漏れがあるとこうした機能が正常に動作しません。

DNS 設定の誤りによる典型的な症状は、規則表自体は正しく見えるにもかかわらず一部のサイトが誤った出口を通ってしまう、あるいは接続できても頻繁にタイムアウトするといったものです。この種の問題は規則の記述ミスではなく、ドメイン解決の段階で既に想定外の結果を得ていることが多いため、まず DNS セクションを確認し、その後 rules セクションを見るという順序で切り分けることを推奨します。

proxies と proxy-groups セクション:ノードとポリシーグループの関係

proxies はリスト形式で、各項目が1つのプロキシノードを表し、プロトコル種別・サーバーアドレス・ポート・暗号方式など接続に必要なパラメータが含まれます。例:

proxies:
  - name: "HK-01"
    type: ss
    server: example-hk.example.com
    port: 8443
    cipher: aes-256-gcm
    password: "your-password"
  - name: "SG-02"
    type: vmess
    server: example-sg.example.com
    port: 443
    uuid: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
    alterId: 0
    cipher: auto

よく使われる type の値には ss(Shadowsocks)、vmess、trojan、socks5、http などがあります。プロトコルごとに必須フィールドが異なり、必須項目が欠けているとそのノードはクライアント上で利用不可と表示されるか、読み込み時にスキップされます。この部分はサブスクリプションリンクから取得している場合は手書きの必要がなく提供元が生成しますが、手動でノードを追加する場合はプロトコルに合ったフィールド名かどうか1つずつ確認する必要があります。

proxy-groups セクションは上で列挙したノードを規則から呼び出せる「ポリシーグループ」として整理するもので、規則表が参照するのはポリシーグループの名前であり、個々のノード名ではありません。そのため出口を切り替える際はポリシーグループの内部を調整するだけで済み、規則表を変更する必要がありません。代表的なポリシーグループの種類は次のとおりです。

type の値動作の説明典型的な用途
select複数のノード/サブグループ間を手動で切り替える。自動判定なし日常的な手動選択
url-test指定 URL へ定期的に速度測定を行い、遅延が最も低いノードを自動選択自動最適化
fallbackリスト順に可用性を確認し、先頭のノードが失効したときのみ次に切り替える主系・待機系のフェイルオーバー
load-balanceハッシュまたはラウンドロビンで複数ノードに接続を分散複数ノードへの負荷分散
 
proxy-groups:
  - name: "自動選択"
    type: url-test
    proxies:
      - HK-01
      - SG-02
    url: "http://www.gstatic.com/generate_204"
    interval: 300
  - name: "手動選択"
    type: select
    proxies:
      - 自動選択
      - HK-01
      - SG-02
      - DIRECT

ポリシーグループ同士は入れ子で参照し合うことも可能です(上の例では「手動選択」が「自動選択」を選択肢の1つとして含んでいます)。ただし循環参照は不可で、発生するとコアは設定読み込み時にエラーとなり起動を拒否します。

rules 規則セクション:記述順序とマッチングロジック

rules セクションは上から下へ順に照合されるリストで、コアは各通信要求をこの順序で1行ずつ照合し、最初にマッチした規則の対応するポリシーを実行した時点でそれ以降の照合を止めます。つまり規則の並び順そのものがロジックの一部であり、順序を誤ると後段の精密な規則が永久に呼び出されなくなります。

rules:
  - DOMAIN-SUFFIX,google.com,自動選択
  - DOMAIN-KEYWORD,github,自動選択
  - DOMAIN,ad.example.com,REJECT
  - GEOIP,CN,DIRECT
  - MATCH,手動選択

よく使われるマッチングタイプには DOMAIN(完全一致のドメイン名)、DOMAIN-SUFFIX(ドメインサフィックス、サブドメインも合わせてマッチ)、DOMAIN-KEYWORD(ドメイン名にキーワードを含めばマッチ)、IP-CIDR(IP レンジでのマッチ)、GEOIP(IP が属する国・地域データベースでのマッチ)、MATCH(最終行に置く受け皿規則で、それまでのどの規則にもマッチしなかった要求すべてにマッチ)があります。MATCH の受け皿行が欠けているのは設定ファイルでよく見られる不備で、一部の要求が対応するポリシーを見つけられず予期しない挙動になる原因になります。

規則の右側に記述する対象は、proxy-groups で定義済みのポリシーグループ名、または組み込みの DIRECT(直接接続)や REJECT(接続拒否、広告ドメインのブロックによく使われる)である必要があります。ポリシーグループ名は大文字小文字を区別し、規則表内で定義されていない空のポリシーグループを含めることもできません。含めると同様に読み込み時にエラーになります。

注意 NOTICE 規則セット(rule-provider)が参照する外部の規則ファイルも、実質的には上記のマッチングタイプが1行ずつ並んだものです。ただし単独のファイルとして保存され、定期的に更新できる点が異なります。RULE-SET タイプの規則を使う前には、rule-providers セクションで対応する規則セットの取得元アドレスとローカルキャッシュのパスを先に定義しておく必要があります。定義していないと、存在しない規則セットを参照したとして規則表の読み込み時に失敗します。

よくあるインデントエラーとその対処法

YAML はインデントに対して他の多くの設定形式より厳しい要件があり、手動編集時に特に多いのは次のような問題です。

  1. 同じ階層のフィールドでインデントの空白数が揃っていない

    同一リスト内の複数項目では、先頭の空白数が完全に同一でなければなりません。1つでも空白がずれると、コアはそこだけをスキップするのではなく階層エラーと判断してファイル全体の読み込みを拒否します。

  2. タブと空白の混在

    多くのテキストエディタはデフォルトでタブインデントですが、YAML の規格はタブ文字を受け付けません。「タブをスペースに変換」する機能を持つエディタを使い、統一して半角スペース2文字を1レベルのインデントとすることを推奨します。

  3. コロンの後ろにスペースがない

    YAML のキーと値のペアはコロンの後に半角スペースを1つ入れて値を書く必要があります。例えば name:HK-01 のようにスペースがないと、不正なキー名として解析されてしまいます。name: HK-01 のように書きましょう。

  4. 文字列にクオートを付けず型が誤判定される

    パスワードや UUID などのフィールドが数字で始まったり特殊記号を含む場合は、明示的にダブルクオートで囲むことを推奨します。そうしないと数値やブール値として解釈され、接続時の認証に失敗する可能性があります。

この種の問題を切り分ける最も直接的な方法は、変更後の設定ファイルをオンラインの YAML 構文検証ツールに通してインデントをチェックし、構文上問題がないことを確認したうえでクライアントに読み込ませることです。クライアントの起動ログ(または log-level を debug に変更した際の出力)も、多くの場合読み込み失敗の具体的な行番号を示してくれるため、行番号を手掛かりに調べるほうが目視での逐条チェックより効率的です。設定ファイルを編集する前には必ず元のファイルをバックアップしておき、変更後にクライアントが正常に読み込めない場合はすぐバックアップ版に戻せるようにしておくと、切り分けに時間がかかって長時間ネットに繋がらない事態を避けられます。

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