上級設定推定読了時間:9分

Clash 設定ファイル構造を逐条解説:port・proxiesからrulesまで全フィールドを理解

config.yamlを渡されても編集に踏み出せない?本文では読み込み順に沿って共通フィールド・プロキシ一覧・策略グループ・ルールの構文と代表的な書き方を解説する。設定変更前にまず読んでおきたい一本。

設定ファイルの読み込み順と全体構造

Clash と Clash Meta(コア名 mihomo)が読み込むのはいずれも YAML 形式のテキストファイルで、ファイル名は一般に config.yaml。クライアントの起動時やサブスクリプション切り替え時に、ファイル全体を一度に解析してメモリ上のオブジェクトに変換し、セクション名ごとに反映する。「読みながら順に反映される」といった依存関係は存在しないが、読解やトラブル対応の際は次の順序で理解すると分かりやすい。

  1. 共通フィールド:ポート、動作モード、ログレベル、外部コントローラーなど、クライアント自身の動き方を決める。
  2. dns セクション:ドメイン解決の挙動を決め、後続のルール判定がドメイン名ベースか解決済み IP ベースかに影響する。
  3. proxies セクション:ノード一覧。1 項目ごとに利用可能な 1 台のプロキシサーバーを記述する。
  4. proxy-groups セクション:ノード一覧を策略グループとして組織化し、「どのノードを選ぶか」をユーザーにどう提示するかを決める。
  5. rules セクション:通信のマッチングルール。「この接続をどの策略グループに流すか」を決める。

サブスクリプションリンクから配布される設定ファイルも本質的には同じフィールド構成で、配布側のサーバーで生成されているだけである。手動で編集する前には元ファイルのバックアップを取ることを推奨する。フィールドを誤ると軽ければクライアントが読み込みを拒否し、重ければルールが無効化されて全通信が直接接続、あるいは全通信が同一ノード経由になってしまう。

YAML はインデントに極めて敏感。半角スペース 2 つで統一し、タブと混在させないこと。コロンの後には必ず半角スペースを 1 つ入れ、リスト項目はハイフンとスペースで始める。これらを守らないことが初心者が設定ファイルを壊す最大の原因になる。

共通フィールド:port・mode・log-level と外部コントロール

ファイル最上部には通常インデントの要らないトップレベルのフィールド群があり、クライアント自身の動作を制御する。

port: 7890
socks-port: 7891
redir-port: 7892
mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
external-controller: 127.0.0.1:9090
secret: ""
  • port / socks-port:それぞれ HTTP プロキシポートと SOCKS5 プロキシポートを開く。OS やブラウザ側で必要な方を設定する。
  • mixed-port:1 つのポートで HTTP と SOCKS5 の両方のリクエストを受け付ける。現在のクライアント UI は多くがこの 1 ポートのみを既定で公開し、システムプロキシ設定を簡略化している。
  • allow-lan:同一 LAN 上の他デバイスが自機のプロキシを経由できるようにするかどうか。スマートフォンをテザリング的に接続させたい場合は有効化する。
  • mode:コアの動作モード。rule は rules セクションに従って振り分け、global は全通信を同一の策略グループへ流し、direct は全通信をプロキシを経由せず直接接続する。
  • log-level:ログの詳細度。トラブル対応時は一時的に debug に変更してもよいが、通常運用では info か warning にしてログファイルの肥大化を避ける。
  • external-controller:RESTful API のリスニングアドレスを開く。secret キーと組み合わせ、クライアント GUI やサードパーティ製パネルはこのインターフェース経由で状態取得やノード切り替えを行う。

これらのフィールドの多くは既定値を持ち、GUI では画面上のスイッチが YAML の記述を上書きすることが多い。ただしサブスクリプションから生成される設定ファイルは YAML フィールドが基準になるため、矛盾がある場合はクライアントの実際の読み込み結果を判断基準とする。

proxies セクション:各ノードの記述方法

proxies はリスト形式で、各項目が 1 台の利用可能ノードに対応する。フィールドはプロトコル種別によって異なるが、共通フィールドは以下の通り。

proxies:
  - name: "HK-01"
    type: ss
    server: 1.2.3.4
    port: 8443
    cipher: aes-256-gcm
    password: "your-password"
    udp: true

  - name: "SG-Trojan"
    type: trojan
    server: example.com
    port: 443
    password: "your-password"
    sni: example.com
    skip-cert-verify: false

主な共通フィールドの説明:

  • name:ノードの表示名。策略グループはこの名前でノードを参照するため、重複していると参照が曖昧になる。一意性を保つのが望ましい。
  • type:プロトコル種別。よく使われるのは ss(Shadowsocks)、ssr、vmess、trojan、hysteria2 など。プロトコルごとに専用フィールドが異なる。
  • server / port:ノードのサーバーアドレスとポート。接続先を直接左右する。
  • udp:そのノードで UDP 通信を中継できるかどうか。ゲームや一部のリアルタイム系アプリは UDP に依存しており、無効にすると失敗するか直接接続に切り替わってしまう。
  • skip-cert-verify:TLS 証明書の検証をスキップするかどうか。自己署名証明書を使う場合のみ有効化すべきで、通常のノードでは無効のままにする方が安全。

手書きでノードを追加する際に最も多いミスは、パスワードにコロンや特殊記号が含まれているのに引用符で囲んでいないケース。YAML パーサーはコロンを新しいキー・値の区切りとして解釈してしまうため、パスワードは常にダブルクオートで囲むことを推奨する。

proxy-groups セクション:策略グループの構文とよく使う種類

proxy-groups は proxies のノードをルールから参照可能なグループとして組織化する。代表的な種類は次の通り。

proxy-groups:
  - name: "自動選択"
    type: url-test
    proxies:
      - HK-01
      - SG-Trojan
    url: "http://www.gstatic.com/generate_204"
    interval: 300

  - name: "手動切替"
    type: select
    proxies:
      - 自動選択
      - HK-01
      - SG-Trojan
      - DIRECT

  - name: "フェイルオーバー"
    type: fallback
    proxies:
      - HK-01
      - SG-Trojan
    url: "http://www.gstatic.com/generate_204"
    interval: 300
  • select:手動切替グループ。UI 上にドロップダウンリストが表示され、ユーザーが選んだノードがそのまま使われる。ユーザーの最終的な保険として最上位に置くのに向いている。
  • url-test:自動速度計測グループ。interval 秒ごとにグループ内のノードを探測し、遅延が最も低いノードを自動選択する。
  • fallback:フェイルオーバーグループ。リストの順に接続を試し、最初に到達できたノードを優先的に使用し、それが失効したときのみ次に移る。
  • load-balance:負荷分散グループ。所定のポリシーで接続を複数ノードに分散させる。ノード数が多く性能が近い場合に向いている。

策略グループの proxies リストにはノード名以外に、他の策略グループの名前を記述することもできる。また内蔵ポリシーである DIRECT や REJECT(それぞれ直接接続と接続拒否を意味する)も指定できる。グループ同士は相互に入れ子参照できるが、循環参照は不可で、発生するとクライアントの読み込み時にエラーになる。

rules セクション:マッチング構文と優先順位

rules は上から順にマッチングするリストで、最初にヒットしたルールがそのまま適用され、以降は比較を続けない。したがってルールの並び順そのものが優先順位になる。

rules:
  - DOMAIN-SUFFIX,openai.com,自動選択
  - DOMAIN-KEYWORD,google,自動選択
  - DOMAIN,ads.example.com,REJECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,自動選択

よく使われるルール種別:

  • DOMAIN / DOMAIN-SUFFIX / DOMAIN-KEYWORD:完全なドメイン名、ドメインの末尾、キーワードでマッチングする。末尾マッチが最も多く使われ、サブドメインもまとめて対象にできる。
  • IP-CIDR / IP-CIDR6:IP レンジでマッチングする。no-resolve パラメータと組み合わせて DNS 解決をスキップし、接続先の字面上の IP をそのまま判定することが多い。
  • GEOIP:IP が属する国・地域でマッチングする。GEOIP,CN,DIRECT は中国本土向けの直接接続でよく使われる書き方。
  • PROCESS-NAME:接続を発生させたプロセス名でマッチングする。デスクトップ環境でアプリ単位の振り分けを行う際によく使う。
  • MATCH:兜底ルール。リストの最後に置き、それ以前のどのルールにもヒットしなかった通信をここで受ける。ほぼすべての設定ファイルに MATCH の最終行が必要で、これがないと未マッチの通信の行き先が不明確になる。

ルール内で参照する策略グループ名は proxy-groups の name と完全に一致していなければならず、大文字小文字や空白も揃える必要がある。一致しないとクライアントの読み込み時に「未定義の策略を参照している」といったエラーが出て、設定ファイル全体の適用が拒否されることが多い。

DNS の解決挙動は IP 系ルールが機能するかどうかに影響する。fake-ip モードを有効にしている場合、ルール判定の段階で接続先が取得するのは仮想 IP のため、IP-CIDR 系ルールが想定通りに動かないことがある。特定のドメインだけ DNS モードを実解決に切り替える必要があるケースが多く、具体的な判断ロジックは本サイトの DNS 関連記事で詳しく解説している。

よくあるエラーとトラブル対応の考え方

設定ファイルを手動編集した後にクライアントが反映されない、あるいはエラーになる場合は次の方向で確認するとよい。

  1. まずオンラインの YAML 検証ツールやテキストエディタのシンタックスハイライトでインデントとコロン後のスペースを確認する。多くの「読み込み失敗」はロジックではなく書式の問題である。
  2. proxy-groups で参照しているノード名と proxies の name が完全に一致しているか確認する。コピー&ペースト時に余分な空白や全角文字が混入しやすい。
  3. rules で参照している策略グループ名が proxy-groups に存在するか確認する。ルール追加時に策略グループ名を書き間違えるのはよくあるミス。
  4. log-level を一時的に debug に変更してクライアントを再起動し、ログ出力を確認する。接続失敗の具体的なエラーは、どの設定箇所に問題があるかを示していることが多い。
  5. 配布元が生成した設定自体に問題があると疑われる場合は、クライアント内で元のサブスクリプション内容を確認し、自分が理解しているフィールドと一つずつ照合する。クライアント本体をいきなり疑うのは避けたい。

この 5 つのセクション構成と読み込み順を理解すれば、以降サブスクリプション提供元が配布する複雑な設定ファイルに出会ったときや、自分でカスタムの振り分けルールを追加したいときも、該当セクションの構文に沿ってそのまま編集できる。ファイル全体を最初から書き直す必要はない。

NEXT STAGE

インストーラーを入手して、次のステップへ

Windows・macOS・Android・iOS・Linux のインストーラーと設定手順はすべてサイト内で揃っている。

▶Clash をダウンロード 攻略を見る
▶クライアントをダウンロード