Clash 設定ファイルの構造を段階別に解説：port から rules まで YAML を読み解く

まず設定ファイルの処理の流れを把握する

Clash または mihomo の設定は、単なる「ノード一覧」ではありません。カーネルの起動時には、まず YAML を解析し、ローカルの待受ポート、DNS モジュール、プロキシノード、ポリシーグループを構築してから、rules を上から順に照合して接続先を決めます。あるセクションが構文チェックを通っても、他のセクションとの参照関係が正しいとは限りません。存在しないポリシーグループをルールが参照したり、名前を変更したノードをポリシーグループが参照したりする場合があります。

設定を理解するときは、ファイルを5つの層に分けて考えると分かりやすくなります。基本実行パラメータはポートと動作モードを管理し、DNS セクションはドメイン名の解決を担います。proxies は利用可能な個別のアウトバウンドを定義し、proxy-groups はそれらを選択式または自動テスト式のポリシーにまとめます。rules は接続ごとに最終的なポリシーを決めます。サブスクリプション設定では、外部ファイルからノードやルール集合を読み込む proxy-providers と rule-providers が加わることもあります。

YAML で特に間違えやすい3つの基本

階層はスペースでインデントし、Tab は使いません。一般的には1階層につきスペース2つで揃えます。
コロンの後には通常スペースを1つ入れます。たとえば mode: rule のように記述し、リスト項目はハイフンとスペースで始めます。
true、false、数値、文字列は意味が異なります。ポートは 7890 のように記述し、特殊文字を含む名前やパスワードは引用符で囲むのが安全です。

一般的なデスクトップクライアントでは、「設定」→現在の設定を選択→「編集」の順に進むと YAML を開けます。保存後は「設定」→「再読み込み」または「適用」を実行します。クライアントによってボタン名は多少異なりますが、確認手順は同じです。まず保存し、カーネルに解析エラーがないことを確認してからプロキシ接続をテストします。トラブル対応では「ログ」→「ログレベル」→「debug」に切り替え、調査が終わったら info に戻して、大量のデバッグ情報を長時間記録しないようにします。

共通項目：ポート、モード、制御インターフェース

設定ファイルの冒頭には通常、ローカルの待受設定とカーネルの実行パラメータを記述します。以下はデスクトップ環境で確認しやすい例です。HTTP プロキシは 7890、SOCKS5 プロキシは 7891 で待ち受け、外部制御インターフェースはローカルのループバックアドレスにのみバインドしています。

port: 7890
socks-port: 7891
allow-lan: false
bind-address: "*"
mode: rule
log-level: info
ipv6: false
external-controller: 127.0.0.1:9090
secret: "change-this-token"

項目	役割	確認ポイント
`port`	HTTP プロキシの待受ポートを提供	システムプロキシでは通常 `127.0.0.1:7890` を指定します
`socks-port`	SOCKS4・SOCKS5 プロキシの入口を提供	SOCKS5 対応アプリは `127.0.0.1:7891` に接続できます
`mixed-port`	1つのポートで HTTP と SOCKS 接続を同時に受け付ける	使用時は通常、同じ用途のポートを別途設定しません
`allow-lan`	LAN 内の端末が本機のプロキシポートへ接続できるかを決める	有効化後はバインドアドレス、OS のファイアウォール、アクセス制御も確認します
`mode`	`rule`、`global`、`direct` から選択	日常利用では通常 `rule` を使います
`external-controller`	GUI や管理パネルに制御 API を提供	本機だけで使う場合は `127.0.0.1` へのバインドが適しています

mode: rule は各接続をルール照合にかけます。global はすべての接続をグローバルポリシーに渡し、direct は直接接続します。ここでいうモードは特定のプロキシプロトコルではなく、ノード自体のパラメータも変更しません。「ノードの速度テストは成功するのに、特定のサイトだけプロキシ経由にならない」場合は、まず誤ってダイレクト接続モードになっていないかを確認し、その後どのポリシーにルールが一致したかを調べます。

LAN 共有はスイッチ1つの変更だけでは完了しない

allow-lan を true に変更した後、スマートフォンや別のパソコンでは Clash が動作する端末の LAN アドレス、たとえば 192.168.1.20:7890 を使います。接続元端末自身の 127.0.0.1 ではありません。同時に TCP 7890 ポートの通信も許可する必要があります。パソコンのアドレスが DHCP で自動割り当てされている場合、ルーターへの再接続後に変わる可能性があるため、ルーターでその端末に固定リースを設定すると便利です。

DNS セクション：名前解決経路と fake-ip モード

DNS 設定はドメイン名から IP アドレスを取得する方法を決め、ドメインルールが安定して一致するかどうかにも影響します。mihomo でよく使われる拡張モードには fake-ip と redir-host があります。前者はアプリに予約アドレスプール内のマッピングアドレスを返し、カーネルが接続を受け取った後でドメイン名を復元します。後者は従来の実アドレス解決に近い方式です。TUN モードで fake-ip を使うとドメイン情報を保持しやすい一方、LAN サービス、接続確認、実アドレスを必要とするアプリの一部ではフィルターへの追加が必要です。

dns:
  enable: true
  listen: 0.0.0.0:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  default-nameserver:
    - 223.5.5.5
    - 1.1.1.1
  nameserver:
    - https://dns.alidns.com/dns-query
    - https://1.1.1.1/dns-query
  proxy-server-nameserver:
    - https://dns.alidns.com/dns-query
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "time.*.com"
    - "+.msftconnecttest.com"

default-nameserver は主に初期名前解決を担うため、通常は IP アドレスだけで指定した DNS アドレスを記述します。暗号化 DNS サーバー自体をドメイン名で指定する場合、カーネルはまずそのドメインをどこで解決するか知る必要があります。nameserver は通常の問い合わせに使う上流 DNS です。mihomo の proxy-server-nameserver を使えば、プロキシサーバーのドメイン名専用に DNS を指定でき、「ノードのアドレスが未解決なのに DNS 問い合わせがプロキシノードを待つ」という依存問題を減らせます。

DNS は有効なのにサイトを開けない場合

ログに dns resolve failed、タイムアウト、証明書接続エラーが出ていないか確認します。
システムまたは TUN の DNS リクエストが実際にカーネルの待受へ届いており、古い LAN 内 DNS へ送られ続けていないことを確認します。
一時的に enhanced-mode を redir-host に変更して再テストし、問題が fake-ip との互換性に関係するかを切り分けます。
fake-ip-filter を確認し、互換性に問題があるドメインだけを追加します。範囲の広すぎるワイルドカードルールは避けてください。
ドメイン名と IP アドレスを分けてテストします。IP にはアクセスできるのにドメイン名では失敗する場合は、まず DNS を調べます。両方とも失敗するなら、ポリシーグループとノード接続を確認します。

例にある 198.18.0.1/16 は、よく使われる fake-ip のアドレスプールです。アプリにこのアドレスが見えても、サイトがそこに実際に配置されているわけではなく、カーネルが管理する一時的なマッピングです。パケットキャプチャで 198.18.x.x が繰り返し現れる場合は、Clash のログにある元のドメイン名と照合して判断し、遠隔サーバーのアドレスと直接みなさないでください。

proxies：個別ノードを YAML で記述する

proxies はノードオブジェクトのリストです。各オブジェクトには少なくとも一意の name、プロトコルを示す type、サーバーアドレスの server、ポートの port が必要で、その他の項目はプロトコルによって異なります。以下では Shadowsocks と SOCKS5 を使って構造を示します。サンプルのドメイン名と認証情報は形式の説明用です。

proxies:
  - name: "東京-SS"
    type: ss
    server: ss-node.example.com
    port: 443
    cipher: aes-128-gcm
    password: "demo-password"
    udp: true

  - name: "ローカル-SOCKS"
    type: socks5
    server: 192.168.1.30
    port: 1080
    username: "proxy-user"
    password: "demo-password"
    udp: false

項目名はプロトコルの定義に合わせる必要があります。Shadowsocks では cipher と password を使い、SOCKS5 では username と password を指定できます。その他のプロトコルでは TLS、トランスポート層、サーバー名などのパラメータも関係します。GUI 上でどちらも1行に表示されるからといって、一方のプロトコルの項目を別のプロトコルへそのままコピーしてはいけません。

ノード名は実質的に参照キー

name は表示用だけでなく、ポリシーグループから文字列として参照されます。ノード定義が「東京-SS」なら、ポリシーグループに「東京 SS」と書いた場合、途中の文字が異なるため無効な参照になります。ノード名をポリシーグループと同じにするのも避けましょう。ログやルールの転送先を確認するとき、どの階層を指しているか判断しにくくなります。

同じリスト内では名前を一意に保ち、「地域-プロトコル-番号」のような固定形式を使うと管理しやすくなります。
コロン、シャープ、アスタリスク、または前後のスペースを含む名前は、YAML が文字を構文として解釈しないよう引用符で囲みます。
udp: true は、そのノード設定で UDP が許可されていることを示すだけです。実際に利用できるかどうかは、プロトコル、サーバー側、通信の取り込み方式にも左右されます。
サーバーアドレスにドメイン名を指定する場合は、ノードのドメイン名を解決する DNS 経路もあわせて確認します。

proxy-groups：ノードを操作可能なポリシーにまとめる

ルールは通常、固定のノードを直接指定せず、ポリシーグループを参照します。これにより、「仕事用サービス」「ストリーミング」「デフォルトプロキシ」など用途ごとにアウトバウンドを独立して選べます。ポリシーグループはクライアントのプロキシ画面で主に操作する対象でもあり、ユーザーが切り替えるのはルールではなく、ある select グループで現在選択されているメンバーです。

proxy-groups:
  - name: "手動選択"
    type: select
    proxies:
      - "自動速度テスト"
      - "東京-SS"
      - "ローカル-SOCKS"
      - DIRECT

  - name: "自動速度テスト"
    type: url-test
    proxies:
      - "東京-SS"
      - "ローカル-SOCKS"
    url: "https://www.gstatic.com/generate_204"
    interval: 300
    tolerance: 50
    lazy: true

  - name: "デフォルトプロキシ"
    type: select
    proxies:
      - "手動選択"
      - "自動速度テスト"
      - DIRECT

グループタイプ	選択ロジック	適した用途
`select`	ユーザーがメンバーを手動で選択	地域、回線、ダイレクト接続を明確に指定したい場合
`url-test`	テスト先へ定期的にリクエストし、遅延の少ないメンバーを選択	ノードが多く、自動で最適なものを選びたい場合
`fallback`	利用可能なメンバーを順番に使い、現在のメンバーが失敗すると切り替え	固定の優先順位とフェイルオーバーを重視する場合
`load-balance`	指定したポリシーに従って異なる接続を複数のメンバーへ振り分け	接続を分散したい場合で、上流側の条件も対応している場合

例の interval: 300 は300秒ごとに定期テストを行う設定で、tolerance: 50 は遅延差が小さいときに頻繁な切り替えを避ける設定です。速度テストの値はテスト URL へのリクエスト時間だけを示し、ダウンロード帯域幅とは一致しません。ある実測でノード A の遅延が86ミリ秒、ノード B が112ミリ秒だった場合、A がそのテスト先により速く応答したことしか分かりません。別地域のサービスへアクセスすると結果が逆になる可能性があります。

ポリシーグループの循環参照を確認する

ポリシーグループは他のポリシーグループを参照できますが、ループを作ることはできません。たとえば「デフォルトプロキシ」が「手動選択」を含み、「手動選択」も「デフォルトプロキシ」を含むと、カーネルは最終的なアウトバウンドを決定できません。複雑な設定を読むときは、ルールの転送先から下へ追跡します。ルールがどのグループを指し、そのグループに何が含まれ、最終的にノードまたは DIRECT、REJECT に到達できるかを確認してください。

rules：順番に各接続の行き先を決める

rules は順序を持つ照合リストです。接続は先頭から確認され、一致した時点でそのルールのポリシーを直ちに採用し、以降のルールは確認しません。具体的なルールを広範なルールより前に置き、最後は通常 MATCH で未一致の通信を受けます。

rules:
  - DOMAIN,api.example.com,デフォルトプロキシ
  - DOMAIN-SUFFIX,example.net,デフォルトプロキシ
  - DOMAIN-KEYWORD,video,手動選択
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,デフォルトプロキシ

DOMAIN は完全なドメイン名に一致し、DOMAIN-SUFFIX は指定ドメインとそのサブドメインに一致します。DOMAIN-KEYWORD はドメイン名にキーワードが含まれていれば一致する可能性があり、範囲が広いぶん誤一致もしやすくなります。IP-CIDR はアドレス範囲で判定し、GEOIP はカーネルが読み込んだ地理データベースに依存します。MATCH は最後の受け皿となるルールです。

no-resolve は IP 系ルールでよく使われ、照合時に IP を得るための追加のドメイン解決を行わないことを示します。すべてのルールに必ず付ける固定サフィックスではありません。ドメインルールはもともとドメイン名で判定し、アドレス結果が必要な場面では通常どおり解決が必要です。

ルールは正しそうなのに一致しない理由

前に、より広いルールがある：たとえば先に DOMAIN-SUFFIX,example.com,DIRECT を書くと、後続の DOMAIN,api.example.com,デフォルトプロキシ は実行されません。
アプリが IP に直接アクセスしている：ログに宛先アドレスしかなくドメイン名の情報がない場合、ドメインルールは照合できません。IP ルールを追加するか、DNS の取り込み方式を見直します。
ポリシー名の表記が異なる：ルールの転送先は proxy-groups 内の名前と完全に一致していなければなりません。
設定を再読み込みしていない：ローカルファイルを編集しても、クライアントが古い設定で動作し続けている場合があります。保存後に「設定」→「再読み込み」を実行し、ログを確認してください。
接続が再確立されていない：既存の TCP または QUIC セッションが古い経路を使い続けることがあります。アプリの接続を閉じて数秒待ってからテストすると、結果を確認しやすくなります。

provider セクション：ノードとルールを外部ファイルに分離する

ノードがサブスクリプションから提供される場合や、ルール集合が大きい場合は provider を利用できます。proxy-providers は外部ノード集合を管理し、rule-providers はルール集合を管理します。provider が通信の行き先を自動的に決めるわけではありません。ノード provider はポリシーグループから参照し、ルール provider は RULE-SET を使って rules に組み込む必要があります。

proxy-providers:
  airport:
    type: http
    url: "https://subscription.example.com/clash.yaml"
    path: ./providers/airport.yaml
    interval: 3600
    health-check:
      enable: true
      url: "https://www.gstatic.com/generate_204"
      interval: 600

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

ノード provider はポリシーグループ内の use で取り込めます。ルール provider は RULE-SET,private-sites,DIRECT のように記述します。behavior はルールファイルの内容に合わせます。domain はドメインルール、ipcidr はアドレス範囲、classical は従来型のルール表現に対応します。形式の指定とファイル内容が一致しない場合、provider のダウンロードは成功しても解析に失敗することがあります。

proxy-groups:
  - name: "サブスクリプション自動選択"
    type: url-test
    use:
      - airport
    url: "https://www.gstatic.com/generate_204"
    interval: 300

rules:
  - RULE-SET,private-sites,DIRECT
  - MATCH,サブスクリプション自動選択

interval: 3600 はノード provider が3600秒ごとに更新を試みる設定で、ルール例の 86400 は24時間を表します。更新間隔は提供元の変更頻度に合わせて設定します。短すぎると不要な通信が増え、長すぎると変更済みのノードやルールがなかなか反映されません。

読みやすい最小構成を組み立てる

ここまでの構造をまとめると、学習しやすい最小構成を作れます。これは汎用の完成品ではありません。ノードのプロトコル、DNS の上流、振り分け先は実際の環境に合わせて設定する必要がありますが、項目同士の参照関係を確認するには十分です。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
ipv6: false
external-controller: 127.0.0.1:9090

dns:
  enable: true
  listen: 0.0.0.0:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  default-nameserver:
    - 223.5.5.5
  nameserver:
    - https://dns.alidns.com/dns-query
  fake-ip-filter:
    - "*.lan"
    - "*.local"

proxies:
  - name: "東京-SS"
    type: ss
    server: ss-node.example.com
    port: 443
    cipher: aes-128-gcm
    password: "demo-password"
    udp: true

proxy-groups:
  - name: "プロキシ"
    type: select
    proxies:
      - "東京-SS"
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.net,プロキシ
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,プロキシ

api.example.net へ接続すると、カーネルはまず DNS セクションでドメイン名を解決し、次に DOMAIN-SUFFIX,example.net,プロキシ が「プロキシ」グループに一致します。グループで現在「東京-SS」が選択されていれば、そのノードへ接続が渡されます。プロキシ画面でグループを DIRECT に切り替えた場合も同じルールに一致しますが、最終的には直接接続になります。これが「ルール」と「ポリシーの選択」を分けて考える理由です。

保存後の確認手順

まず YAML のインデント、リスト記号、コロン後のスペースを確認します。
各ルールの転送先がポリシーグループ内に存在し、各グループのメンバーがノードまたは組み込みポリシーに到達できることを確認します。
設定を再読み込みし、起動ログに項目エラー、参照失敗、ポート競合がないか確認します。
7890、9090、1053 などのポートが他のプログラムに使用されていないことを確認します。
ダイレクト接続の対象とプロキシ対象を1つずつテストし、ログで実際に一致したルールを確認します。
最後にシステムプロキシまたは TUN を有効にします。複数の変数を同時に変更すると原因を特定しにくくなるためです。

カーネルが起動直後に終了する場合、設定を大幅に削除するより、セクションごとに範囲を絞る方法が効果的です。まず共通項目と利用可能なノード1つだけを残し、次にポリシーグループ、DNS、最後にルールと provider を順に戻します。各セクションを追加するたびに再読み込みすれば、エラーを具体的な項目まで絞り込めます。200行の設定なら、5つの段階に分けた復元は通常5〜8回の読み込みで済み、1行ずつ推測するより速く解決できます。

よくある誤解とメンテナンスのポイント

サブスクリプション URL をそのままノードアドレスにする

サブスクリプション URL が返すのはノード集合または完全な設定であり、個別ノードの server ではありません。完全なサブスクリプションはクライアントのサブスクリプション管理または proxy-providers に渡し、個別ノードはプロトコルの項目に従って proxies に記述します。データの階層が異なるため、相互に置き換えることはできません。

速度テストの数値だけを見て、ルールの一致を確認しない

ノードの速度テストに成功したということは、カーネルがそのノード経由でテスト先へアクセスできたという意味です。しかし実際の通信はルールによって DIRECT、別のポリシーグループ、または別のノードへ送られる可能性があります。トラブル対応では、まずログでルールの転送先を確認し、次にポリシーグループの現在の選択を確認し、最後にノード接続の結果を調べます。

すべての問題を DNS のせいにする

DNS が担うのは名前解決経路の一部だけです。ポート競合、システムプロキシの未有効化、TUN ルートの未接管、ルール順序の誤り、ポリシーグループが空であること、ノードのプロトコル項目の不一致なども、「ウェブページが開けない」原因になります。DNS アドレスを何度も変更するより、階層ごとに確認する方法のほうが確実です。

自動更新される設定を長期的に直接編集する

サブスクリプションを更新すると、手動で追加したルール、ポリシーグループ、DNS 項目が再生成された内容に置き換わることがあります。長期運用では役割を明確に分けます。サブスクリプションはノード更新、ローカル上書きは固定パラメータ、ルール provider は大規模なルール集合、少数の個人ルールは順序を管理できる先頭ルール領域に担当させます。これならノード更新のたびに YAML 全体を再統合する必要がありません。