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

01 / DOCUMENT MAP

YAML構造の全体像と読み込み順序

トップレベルフィールドで設定を構成する方法

Clashの設定ファイルは通常 config.yaml という名前で、マッピング、リスト、スカラーからなるデータツリーです。トップレベルのマッピングで機能領域を分けます。ポートと動作モードはトラフィックの入口を決め、dns は名前解決、proxies は個々のプロキシ、proxy-groups は選択や自動テストを行うポリシーにノードをまとめ、rules は接続を順番にプロキシグループへ振り分けます。mihomoでは proxy-providers、rule-providers、tun、sniffer などの拡張領域も利用できます。

設定を解析するとき、インデントが親子関係を示します。同じ階層のフィールドではスペース数を統一し、一般的には1階層2スペースにします。リスト項目はハイフンで始まり、ハイフンの後のオブジェクトにも子フィールドを記述できます。YAMLでは文字列を引用符なしで書けますが、ノード名、パスワード、正規表現、コロンや特殊記号を含む値は誤解釈されやすいため、引用符で囲むのが安全です。ブール値には true と false を使い、ポート番号は数値のまま記述してください。

mixed-port: 7890
mode: rule
log-level: info
ipv6: false

dns:
  enable: true
  listen: 0.0.0.0:1053
  enhanced-mode: fake-ip
  nameserver:
    - 223.5.5.5
    - 1.1.1.1

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

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

rules:
  - DOMAIN-SUFFIX,example.org,ノード選択
  - GEOIP,CN,DIRECT
  - MATCH,ノード選択

マッピング、リスト、名前の参照

dns: の後にはマッピング形式のフィールドが続き、proxies: の後にはオブジェクトのリストが続きます。プロキシグループ内の proxies もリストですが、ノードを再定義するのではなく名前を参照します。名前は大文字・小文字、スペース、記号を含めて完全に一致させる必要があります。ノード名が「香港 01」なら、プロキシグループで「香港01」と書くと存在しない参照になります。ルールの最後の項目も、プロキシグループ名や DIRECT、REJECT などの組み込みポリシーを参照します。名前を変更するときは、プロキシグループ、ルール、画面上のオーバーライドにあるすべての参照を確認してください。

YAMLのアンカーとエイリアスは重複を減らせますが、すべてのGUIクライアントが保存、変換、オーバーライドの過程でアンカーを完全に保持できるとは限りません。長期運用する公開設定では、明示的で分かりやすいフィールドを優先してください。設定が大きくなったら、ノードとルールをプロバイダーファイルへ分離し、メイン設定から参照できます。1つのファイルに数千行を詰め込むより更新しやすく、「ノードデータ」と「ルーティングロジック」を分けて管理できます。

最小構成と読み込みの境界

起動できる最小構成が、正常にインターネットへ接続できる構成とは限りません。ポートとモードだけを設定するとコアは待ち受けできても、ルールが参照するポリシーが存在しない、DNSでノードのドメインを解決できないなどの理由で接続に失敗します。確認は構文、参照の完全性、ネットワーク動作の順に進めてください。クライアントの「設定の読み込みに成功」という表示は、基本構造を解析できたことを示すだけで、ノード認証情報、リモートプロバイダーのURL、ルールの転送先が有効とは限りません。

また、サポートされるフィールドはコアの開発段階によって完全には一致しません。公式Clash、Clash Meta、現在のmihomoにおける名称の変遷と互換性については、コアのバージョン差異を参照してください。mihomoコアを採用しているクライアントでは拡張フィールドを利用できますが、複数のクライアントで設定を共有する場合は、各クライアントが実際に搭載するコアを確認してください。画面上のクライアント名だけで判断しないようにしましょう。

02 / RUNTIME

共通フィールド：ポート、モード、コントロールインターフェース

mixed-port、port、socks-port

mixed-port は同じ待ち受けポートでHTTPとSOCKS5のプロキシ接続を受け付けるため、デスクトップクライアントや一般的な手動プロキシ設定に適しています。port はHTTPプロキシのみ、socks-port はSOCKS5のみを提供します。必要に応じて組み合わせられますが、複数のフィールドで同じポートを使ったり、端末上の他のプログラムの待ち受けポートと競合させたりしないでください。GUIクライアントがポート設定を管理している場合、起動時に画面上の値が設定ファイルを上書きすることがあります。トラブル時は画面と実際の実行ログを併せて確認してください。

アプリにプロキシアドレスを入力する場合、同じ端末上で動作するプログラムは通常 127.0.0.1 に接続します。LAN上の他の端末から接続するには、Clashを実行している端末のLANアドレスを指定し、allow-lan を有効にしたうえで、システムのファイアウォールが対象ポートを許可していることを確認します。LAN待ち受けを公開するとアクセス範囲が広がるため、bind-address でインターフェースを制限し、必要に応じて認証情報を設定してください。ポート設定後は、試行錯誤で何度も変更するのではなく、OSのネットワーク接続情報で待ち受け状態を確認しましょう。

mixed-port: 7890
allow-lan: false
bind-address: "*"
mode: rule
log-level: info
ipv6: false
unified-delay: true
tcp-concurrent: true

rule、global、directモード

mode: rule は rules を上から順に照合する、日常利用の基本モードです。global はプロキシ可能なトラフィックを一括してグローバルポリシーへ渡すため、特定ノードの動作確認には便利ですが、本来のルーティング意図を迂回します。direct は直接接続し、問題がプロキシ経路にあるかを素早く切り分ける際に使います。画面でモードを切り替えても、実行状態だけが変わりYAMLを書き換えないクライアントがあります。再起動後も保持されるかはクライアントの設定によります。

障害切り分けでは比較テストが有効です。ルールモードで失敗しグローバルモードで成功するなら、ルールの転送先、順序、プロキシグループの参照に問題がある可能性が高いでしょう。グローバルモードでも失敗する場合は、ノード、システムプロキシ、TUN、DNS、ネットワーク環境を確認します。ダイレクトモードでもローカルサービスに接続できないなら、問題はClash設定にない可能性があります。テスト後はルールモードへ戻し、ドメインや地域別ルーティングが長時間失われないようにしてください。

ログ、IPv6、外部コントローラー

log-level の主な値は silent、error、warning、info、debug です。通常は info で十分です。ルールのヒットや接続段階が不明なときだけ一時的に debug へ切り替え、情報を集めたら戻してください。ログの増大を防ぐためです。ログでは対象ドメイン、ヒットしたルール、最終ポリシー、DNSエラー、接続タイムアウトを確認し、最後の1行だけを見ないようにします。

ipv6 はコアがIPv6関連機能を扱うかを制御しますが、DNSにもIPv6専用の設定があります。安定したIPv6接続があり、ノード経路も対応している場合は有効にできます。ローカルでIPv6アドレスを取得できても利用可能な出口がなければ、アプリがIPv6を優先してタイムアウトすることがあります。トラブル時は、システムネットワーク、DNSの応答、Clashトップレベルのスイッチ、DNSの個別項目を分けて確認してください。

external-controller はコントロールパネルやクライアントのフロントエンドにAPIを提供します。例として 127.0.0.1:9090 があります。ローカル以外で待ち受ける場合は、secret を設定し、ファイアウォールのアクセス元を制限してください。コントロールインターフェースはプロキシポートではないため、ブラウザーやアプリからHTTPプロキシとして利用できません。external-ui は静的パネルのファイルディレクトリを指します。パスは実行環境の実際のディレクトリに合わせ、特定端末の絶対パスを他のシステムへそのまま同期しないでください。

external-controller: 127.0.0.1:9090
secret: "your-controller-secret"
external-ui: ui

profile:
  store-selected: true
  store-fake-ip: true

profile.store-selected はプロキシグループの選択結果を保存し、再起動後も前回の選択を使えるようにします。store-fake-ip はFake-IPマッピングの永続化に関係します。複数端末で設定を同期する場合、実行状態までYAMLと一緒に同期されるとは考えないでください。サブスクリプション、オーバーライド、プライベートリポジトリという3つの同期経路の境界については、Clashの複数端末設定同期も参照してください。

03 / DNS PIPELINE

DNS設定とFake-IP名前解決の流れ

DNSリクエストはどの段階を通るか

ClashのDNSモジュールは、単にドメインを特定のサーバーへ転送するだけではありません。有効にするとアプリからの問い合わせを受け、nameserver-policyやfallbackなどのルールに基づいて上流を選び、結果をルール照合と接続処理へ渡します。ノードサーバー自体がドメイン名を使う場合は、bootstrap名前解決も関係します。暗号化接続を確立するには、コアが先にノードのアドレスを取得しなければなりません。そのためDNS障害は、Webサイトが開けないだけでなく、すべてのドメイン型ノードが同時にタイムアウトする形でも現れます。

listen はDNSサービスの待ち受けアドレスを指定します。デスクトップGUIクライアントはシステムDNSやTUNによるリダイレクトをすでに処理していることが多く、ユーザーがシステムDNSを手動でこのポートへ変更する必要はありません。ルーターやLANゲートウェイでは、クライアントからの問い合わせをここへ転送する構成がよく使われます。0.0.0.0 で待ち受ける場合は、ファイアウォールでアクセス範囲を制限してください。端末内だけで使うなら、ループバックアドレスでの待ち受けを優先します。

dns:
  enable: true
  listen: 127.0.0.1:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  use-hosts: true
  respect-rules: true
  default-nameserver:
    - 223.5.5.5
    - 119.29.29.29
  nameserver:
    - https://dns.alidns.com/dns-query
    - https://doh.pub/dns-query
  proxy-server-nameserver:
    - https://1.1.1.1/dns-query
  direct-nameserver:
    - https://dns.alidns.com/dns-query
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "time.*.com"
    - "+.stun.*.*"

default-nameserverとnameserverの違い

default-nameserver は主に暗号化DNS上流自身のドメインを解決します。通常は直接到達できるIP形式のDNSアドレスを指定し、「DoHへ接続するにはDoHのドメイン解決が必要だが、その解決にもDoHが必要」という循環を避けます。nameserver は通常の問い合わせに使う上流で、UDP、TCP、DoT、DoHのアドレスを指定できます。上流は多ければよいわけではありません。性質の大きく異なるリゾルバーを混在させると結果が予測しにくくなり、切り分けも複雑になります。

proxy-server-nameserver はプロキシノードのサーバードメインを専用に解決し、誤った経路で問い合わせるのを防ぎます。direct-nameserver はダイレクト接続用の名前解決に使い、国内向けの通信を近いリゾルバーへ渡す場合に適しています。respect-rules を有効にするとDNS問い合わせもルール経路をより強く参照するため、ノードのドメインに独立した名前解決経路があることを確認してください。そうでないとポリシー依存の循環が起きる可能性があります。

Fake-IPとRedir-Hostの選び方

enhanced-mode: fake-ip は予約アドレス帯からドメインに一時アドレスを割り当てます。アプリはまずこのマッピングアドレスを取得し、接続時にコアが元のドメインへ戻してドメインルールを適用します。接続段階でドメイン情報を保持できるため、先にIPへ解決されてIPルールしかヒットしない状況を減らせます。Fake-IPは接続先が実際にその予約ネットワークにあるという意味ではなく、コア内部のドメインマッピング識別子です。

redir-host は実際の名前解決アドレスを返し、透過プロキシやスニッフィングでドメイン情報を補います。LAN探索、ローカルドメイン、特殊な認証、解決先アドレスの直接確認に依存するアプリでは、実アドレス方式が適する場合があります。ただしルールの精度やキャッシュ動作は環境ごとに評価が必要です。一般的なデスクトップ・モバイルのプロキシ利用では、まずFake-IPを使い、互換性のないドメインだけを fake-ip-filter に追加するのがよいでしょう。局所的な問題だけで全体を切り替える必要はありません。

除外項目はできるだけ具体的にします。*.lan や *.local はローカルデバイス探索でよく使われます。時刻同期、STUN、ゲームプラットフォーム、一部の企業内ドメインでも実アドレスが必要になることがあります。広すぎるワイルドカードは多くのドメインをFake-IPから除外し、ルールの一貫性を下げます。マッピング、ルールヒット、除外項目の詳しい流れは、Fake-IPモードの仕組みを参照してください。

DNSリークと名前解決障害の切り分け

DNS経路の異常は、通常3つの問題に分けて考えます。問い合わせをどのコンポーネントが発行したか、どの上流へ送られたか、最終的にどのポリシーで接続したかです。ブラウザーが独自のセキュアDNSを使ったり、システムサービスがアプリのプロキシを迂回したり、TUNがDNSリダイレクトで問い合わせを引き取ったりすることがあります。Webページに表示されたリゾルバー名だけでは、すべての通信経路を断定できません。テストに不要なブラウザー独自DNSを先に無効にし、Clashログの問い合わせとルール記録を確認してください。

サブスクリプションは更新できるのに、すべてのノードでドメイン解決エラーが出る場合は、まず default-nameserver とノードドメインの解決を確認します。通常のWebサイトだけ失敗しIPアドレスには接続できる場合は、主要な nameserver、待ち受けポート、システムDNSの引き継ぎを確認します。一部のLAN機器だけ失敗するならFake-IPの除外項目を確認してください。断続的なタイムアウトでは、到達性を確認した上流を1つだけ残し、上流間の差、ネットワーク遮断、キャッシュの影響を切り分けてから順に戻します。

04 / PROXY OBJECTS

プロキシフィールドとプロトコルオブジェクト

すべてのノードに共通する識別フィールド

proxies の各オブジェクトには少なくとも name、type、server、port が必要で、その他のフィールドはプロトコルによって異なります。name は設定内部の一意な識別子で、クライアント画面にも表示されます。名前が重複すると、プロキシグループの参照や画面上の選択が曖昧になるため、生成時に一意性を確保してください。server にはドメインまたはIPを指定できます。ドメインを使うとサーバー側でアドレスを切り替えやすい一方、ノードドメインの名前解決という前処理が増えます。

udp はノードがUDPを通せるかを示しますが、実際の可否はプロトコル、サーバー、クライアントの入口にも左右されます。ゲーム、音声、QUIC、一部のDNS通信はUDPに依存します。フィールドを有効にしても経路が必ず対応するわけではなく、サーバーや中間ネットワークが非対応だと、ログ上はハンドシェイク成功後にUDPだけ応答しないことがあります。interface-name と routing-mark は複数NICやLinuxルーティング向けの制御フィールドです。一般的なデスクトップ設定で積極的に追加する必要はありません。

ShadowsocksとTrojanの例

proxies:
  - name: "SS-サンプル"
    type: ss
    server: ss.example.com
    port: 443
    cipher: aes-128-gcm
    password: "your-password"
    udp: true

  - name: "Trojan-サンプル"
    type: trojan
    server: trojan.example.com
    port: 443
    password: "your-password"
    sni: service.example.com
    skip-cert-verify: false
    udp: true
    network: tcp

Shadowsocksの cipher はサーバー側と一致させ、パスワードも元の内容をそのまま入力します。フィールド名が同じだからといって、異なるプロトコルの認証情報を流用しないでください。TrojanはTLSに依存します。sni はハンドシェイクで送るサーバー名で、通常はサーバー証明書の対象ドメインと一致させます。skip-cert-verify: false は証明書検証を行う設定で、正常な構成ではこちらを優先します。検証に失敗したら、端末時刻、証明書ドメイン、SNI、サーバー証明書チェーンを確認し、検証無効のまま運用しないでください。

network はTCP、WebSocket、gRPCなどの下位トランスポートを指定します。WebSocketではパスとリクエストヘッダー、gRPCでは通常サービス名も必要です。トランスポートの設定はサーバー側の入口と完全に一致させます。プロトコル、アドレス、パスワードだけをコピーしてトランスポートのパスを忘れ、TCPではポートに到達できるのにハンドシェイクだけが失敗するケースがよくあります。

VMessとVLESSの階層フィールド

proxies:
  - name: "VLESS-WS-サンプル"
    type: vless
    server: edge.example.com
    port: 443
    uuid: "00000000-0000-4000-8000-000000000000"
    network: ws
    tls: true
    servername: service.example.com
    udp: true
    ws-opts:
      path: /network-path
      headers:
        Host: service.example.com

  - name: "VMess-gRPC-サンプル"
    type: vmess
    server: grpc.example.com
    port: 443
    uuid: "00000000-0000-4000-8000-000000000000"
    alterId: 0
    cipher: auto
    tls: true
    servername: grpc.example.com
    network: grpc
    grpc-opts:
      grpc-service-name: proxy-service

VLESSとVMessはいずれもUUID形式の識別情報を使いますが、プロトコルの動作とフィールド構成は異なります。ws-opts と grpc-opts は network に対応するネストしたマッピングで、インデントを誤るとノードオブジェクトの間違った階層に値が入ります。TLS環境では接続先アドレス、SNIまたはservername、HTTP Hostを別々に設定できます。接続先アドレスは実際の接続先、SNIはTLS証明書とバーチャルホストの選択、HostはHTTPまたはWebSocketのリクエストヘッダーを決めます。3つが同じかどうかはサーバー構成によるため、経験則で置き換えないでください。

サンプルのUUIDとドメインはフィールド構造の説明専用で、実際の接続には使えません。実際のノード情報は、利用権限のあるサービス設定から取得してください。サブスクリプションで生成されたノードは、1項目ずつ手動で書き換えない方がよいでしょう。トランスポートフィールドを1つ欠くだけでも原因の分かりにくい差異が生じます。providerで読み込み、プロキシグループとルールで管理する方法が適しています。

Reality、証明書、フィンガープリント関連フィールド

mihomoがサポートする一部のVLESS設定には、公開鍵、ショートID、クライアントフィンガープリントなどのRealityパラメーターが含まれます。フィールド名と階層は、現在のコアがサポートする形式に従い、サーバー設定と一致させてください。これらの機能は古いコアやクライアントでは利用できない場合があります。別の端末へ同期する前に、コアの互換性を確認してください。「フィールドがサポートされていない」「設定を解析できない」と表示されたら、まずクライアントのコア種別を確認し、フィールドを調整するか対応クライアントへ変更するか判断します。

client-fingerprint はTLSクライアントのフィンガープリント偽装に影響しますが、すべてのハンドシェイク障害を直す万能スイッチではありません。証明書名の誤り、端末時刻のずれ、SNIの不一致、ネットワーク遮断は個別に確認してください。クライアントを選ぶ際は、デスクトップ・モバイルともにまずインストールパッケージ一覧からClash Plusを選ぶのがおすすめです。別のUIやOS対応が必要なら、Clash Verge Rev、FlClash、Clash Nyanpasu、Clash Meta for Android、Surfboard、ClashX Meta、アーカイブ版のClash for Windowsを比較してください。

05 / POLICY GROUPS

プロキシグループのフィールドと選択ロジック

select：選択をユーザーに委ねる

プロキシグループはルールとノードの間にある中間層です。ルールから変動するノード名を直接指定せず、「ノード選択」「ストリーミング」「ダウンロード」など安定したプロキシグループを指定します。ノードが更新されても、変更するのはグループのメンバーだけで済み、ルール構造を維持できます。select グループではユーザーがメンバーを手動選択します。メンバーにはノードだけでなく、別のプロキシグループや組み込みポリシーも指定できます。

proxy-groups:
  - name: "ノード選択"
    type: select
    proxies:
      - "自動選択"
      - "フォールオーバー"
      - "香港ノード"
      - "日本ノード"
      - DIRECT

  - name: "香港ノード"
    type: select
    use:
      - subscription-main
    filter: "(?i)港|hk|hong kong"

proxies は静的ノードや他のグループを参照し、use は proxy-providers を参照します。両者はコアの機能に応じて組み合わせられます。filter は通常、正規表現でprovider内のノード名を絞り込みます。命名規則が結果に直接影響するため、サブスクリプションが地域名の形式を変えると既存のフィルターが空のグループを返すことがあります。設定を保守するときは、フィルター式をサブスクリプションの命名に依存するデータルールとして扱い、更新後にグループ内のメンバーを確認してください。

url-test：テスト結果で自動選択

url-test は指定URLへ定期的にアクセスし、テスト結果に基づいてグループ内から適切なノードを選びます。url には容量が小さく応答が安定し、実際の利用経路にも合うテストリソースを指定します。interval はテスト間隔、tolerance は結果が近いときの頻繁な切り替えを抑える値です。速度テストは特定時点におけるテスト先への応答を示すだけで、ダウンロード速度、動画の帯域、すべてのサイトの体感を保証するものではありません。

  - name: "自動選択"
    type: url-test
    use:
      - subscription-main
    url: https://www.gstatic.com/generate_204
    interval: 600
    tolerance: 80
    lazy: true
    expected-status: 204

lazy: true はプロキシグループが実際に使われるまでテストを遅らせ、利用していないグループへの探測リクエストを減らします。テストURLが現在のネットワークでリダイレクト、遮断、異なるステータスを返すと、すべてのノードが誤って利用不可と判定されることがあります。まずテストURL自体の到達性を確認し、安定したリソースへ変更してください。自動選択グループは一般的なWeb通信に適していますが、固定出口が必要なログインセッション、リモート管理、許可リスト型サービスでは手動選択でノードを固定する方が適切です。

fallbackとload-balance

fallback はリストや探測結果に基づいて利用可能な順序を管理し、現在のノードが失敗すると別のメンバーへ切り替えます。重視するのは継続的な可用性で、毎回もっとも低遅延のノードを選ぶとは限りません。load-balance は複数ノードへ異なる接続を割り当てるため、複数の出口を許容できる並列通信に適しています。同じログイン中に出口が変わると異常とみなすサイトでは、負荷分散がセッションに悪影響を与えることがあります。

  - name: "フォールオーバー"
    type: fallback
    proxies:
      - "香港ノード 01"
      - "日本ノード 01"
      - "シンガポールノード 01"
    url: https://www.gstatic.com/generate_204
    interval: 600

  - name: "負荷分散"
    type: load-balance
    use:
      - subscription-main
    url: https://www.gstatic.com/generate_204
    interval: 600
    strategy: consistent-hashing

負荷分散では、一貫性ハッシュは同じ宛先をできるだけ安定したノードへ割り当て、ラウンドロビンは接続の分散を重視します。利用前に出口の変化が許容されるかを確認し、「複数ノードを同時に使う」ことを1本の接続の帯域が単純に合算される意味だと考えないでください。1本のTCP接続は通常1つのノードで処理され、複数ノードは主に異なる接続を分担します。

プロキシグループのネストとループ防止

グループは別のグループを参照できるため、「サービス方針 → 地域方針 → ノード」の階層を構築できます。たとえば動画ルールから「ストリーミング」を指定し、そのグループで「香港ノード」または「日本ノード」を選択します。重複を減らせる一方、階層が深すぎると切り分けが難しくなります。さらに循環参照は避けてください。AがBを含み、BがAを含むと、設定検証に失敗したり実行時の挙動を決められなくなったりします。

名前は一時的なノード状態ではなく機能を表すものにします。ルールの転送先には「メッセージング」「開発サービス」「フォールバックプロキシ」など安定した名前を使い、地域グループには「香港ノード」「日本ノード」を使います。具体的なノード名は最下層に置いてください。サブスクリプションの更新、ノードの増減、地域フィルターの変更があっても、上位ルールを書き換えずに済みます。再起動後に選択が失われる場合は、profile.store-selected とクライアントの永続化方式を確認し、選択ノードをすべてのルールへ直接埋め込まないでください。

06 / ROUTING RULES

ルール構文、照合順序、フォールバック

ルールは上から順に最初に一致したものを使う

rules は順序を持つリストです。接続が来るとコアは先頭から確認し、最初に一致したルールのポリシーを直ちに採用します。下にある「より具体的な」ルールを探し続けることはありません。そのため、具体的なドメイン、サービス別ルール、特殊なダイレクト接続は前に置き、広いドメインサフィックスやIP地域ルールを後ろに置き、最後に MATCH で残りを処理します。ルール順序の逆転は、ルールが存在するのに効かない主な原因の1つです。

標準的なルールは、ルール種別、照合内容、転送先ポリシーをカンマで区切ります。種別によっては追加パラメーターも指定できます。たとえば DOMAIN-SUFFIX,example.com,ノード選択 は対象ドメインとサブドメインに一致し、DOMAIN,api.example.com,DIRECT は完全一致のみ、DOMAIN-KEYWORD,example,ノード選択 はキーワードを含むドメインに一致します。後者は範囲が広いため、一般的すぎるキーワードは避けてください。

rules:
  - DOMAIN,router.local,DIRECT
  - DOMAIN-SUFFIX,example.cn,DIRECT
  - DOMAIN-SUFFIX,example.com,ノード選択
  - 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 は完全な1つのドメイン名に厳密一致し、API、ダウンロード用ドメイン、LANホストの個別処理に適しています。DOMAIN-SUFFIX はドメイン境界に基づいて親ドメインとサブドメインに一致するため、サイト単位のルールで最もよく使われます。DOMAIN-KEYWORD はドメイン内に指定文字列があれば一致する可能性があり、他サイトを誤って対象にしやすいので、完全一致ルールの後ろに置き、十分に特徴的なキーワードを選んでください。

同じサービスが複数のドメインを使う場合、トップページのドメインを追加するだけでは不十分です。ログイン、API、画像、メディア、静的リソースのドメインへもアクセスすることがあります。ページタイトルから推測せず、接続ログで実際のリクエストを確認してルールを追加してください。継続的に変化する大規模サービスには、手作業で大量のドメインを追加するより、適切に保守されたrule-providerが適しています。

IP-CIDR、GEOIP、no-resolve

IP-CIDR はIPv4ネットワークを、IP-CIDR6 はIPv6を照合します。LAN、ループバック、特定サービスのアドレスはCIDRでダイレクト接続にすることがよくあります。ルール末尾の no-resolve は、そのIPルールを照合するために追加のDNS解決を行わないことを示します。接続にすでに宛先IPがある場合に適しています。ドメインを解決してIPを得ないと判定できないルールへ、機械的に追加しないでください。

GEOIP はIPデータベースに基づいて地域を判定します。宛先IPを取得した後に動作するため、ドメインルールを完全に置き換えるものではありません。CDNはネットワーク環境によって異なる地域のアドレスを返すことがあり、同じサイトが複数地域のインフラを使うこともあります。「ドメインが属する地域」と「現在のIPがデータベースで分類された地域」は別物です。明確なサービスにはドメインルールやルールセットを優先し、GEOIPは後段の広域ルーティングに使うのが適しています。

プロセス、ポート、論理結合ルール

対応する機能を備えたプラットフォームとコアでは、PROCESS-NAME、PROCESS-PATH、DST-PORT、SRC-IP-CIDR などのルールを使えます。プロセスルールはシステムが提供するプロセス情報に依存するため、モバイル、コンテナ、権限制限環境、TUN実装の違いによって利用できない場合があります。ポートルールは宛先ポートを示すだけで、アプリの種類を示すものではありません。多くのサービスが443番ポートを共有するため、ポートだけでプロキシを指定すると範囲が広くなりすぎます。

mihomoの論理ルールではAND、OR、NOTを使って複数条件を組み合わせられます。「特定のプロセスが特定のネットワークへ接続する」といった条件に適しています。ただし式が複雑になるほど、括弧、引用符、パラメーターの区切りを正確に管理する必要があります。実際の保守では、まず通常のルールで各条件が単独でヒットすることを確認してから組み合わせ、構文エラー、プラットフォームの対応状況、論理結果を混同しないようにしてください。

rules:
  - PROCESS-NAME,example-client,ノード選択
  - DST-PORT,22,開発サービス
  - AND,((NETWORK,TCP),(DST-PORT,443)),ノード選択
  - OR,((DOMAIN-SUFFIX,example.org),(DOMAIN-SUFFIX,example.net)),開発サービス
  - MATCH,フォールバックプロキシ

ルールが想定どおりヒットしない場合の切り分け

最初に接続ログで対象ドメインまたはIP、ヒットしたルール、最終ポリシーを確認します。次に、ヒットしたルールより上に広いルールがあり、先に通信を捕捉していないか確認します。続いて、ルールが指定するプロキシグループで現在どのメンバーが選ばれているかを確認します。DNSモードがドメイン情報を保持しているかも確認してください。アプリが直接IPへ接続している場合、ドメインルールには自然に一致しません。最後にrule-providerの更新成功、behaviorとファイル内容の一致を確認します。

一時テストでは、完全一致ルールをリストの先頭へ移動し、設定を再読み込みして新しい接続を開始します。既存接続が古い経路を再利用することがあるため、ページ更新だけでは不十分な場合があります。必要ならアプリの接続を閉じるか接続一覧を消去してください。確認後はルールを適切な階層へ戻します。地域別ルーティングのYAML構成例は、Clashルーティング実践も参照してください。

07 / PROVIDERS

プロキシプロバイダー、ルールプロバイダー、リモート更新

proxy-providersでノードデータをメイン設定から分離する

proxy-providers はリモートまたはローカルのノード集合を読み込みます。メイン設定にはプロバイダー名、取得元、更新間隔、ヘルスチェックだけを残し、プロキシグループから use で参照します。サブスクリプションを更新してもノード層だけが変わり、ポート、DNS、プロキシグループ、ルールはローカル設定で管理できます。サブスクリプションを完全な設定として直接使うより、固定したルーティングロジックを保守しやすい構成です。

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

proxy-groups:
  - name: "ノード選択"
    type: select
    use:
      - subscription-main
    proxies:
      - DIRECT

type: http はリモートアドレスから取得することを示し、path はダウンロード後のローカル保存先、interval は自動更新間隔です。proxy は更新リクエストが通るポリシーを決めます。初回起動時はプロキシポリシーに利用可能なノードがまだないことがあるため、通常は DIRECT を使います。現在のネットワークからサブスクリプションへ直接接続できない場合は、クライアントのサブスクリプション更新用プロキシ機能を利用してください。provider自身がまだ読み込まれていないノードに依存すると、起動時の依存循環が起きやすくなります。

ヘルスチェックは固定URLでノードの応答を確認するだけで、サブスクリプションのダウンロードエラーを修復するものではありません。更新失敗は、HTTPステータス、ネットワークタイムアウト、無効なURL、YAMLではない応答、ファイル書き込み失敗、解析失敗に分けて確認します。クライアントが同じ「更新に失敗しました」と表示しても、ログの段階情報が切り分けの手掛かりになります。一般的な対処法はよくある質問でも確認できます。

rule-providersとbehavior

rule-providers は大量のルールを独立ファイルへ分離し、メインのルールリストから RULE-SET で参照します。重要な behavior は集合の内容形式を示します。domain はドメイン項目、ipcidr はIPネットワーク、classical は従来型の完全なルール式の保存に適しています。behaviorとファイル内容が一致しないと、集合の読み込みに失敗したり、想定どおりヒットしなかったりします。

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

  private-networks:
    type: file
    behavior: ipcidr
    format: yaml
    path: ./ruleset/private-networks.yaml

rules:
  - RULE-SET,private-networks,DIRECT
  - RULE-SET,local-services,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,ノード選択

domain behaviorのYAMLファイルでは通常、payload にドメイン項目を保存します。ipcidrファイルにはネットワークを、classicalファイルにはメイン設定と同様の完全なルールを保存します。ただし通常、項目内に最終ポリシーは書きません。ポリシーはメイン設定の RULE-SET 行で指定するためです。参照側が転送先を決め、集合ファイルが照合対象を定義する分担により、同じ集合を複数の設定で異なるポリシーへ向けられます。

payload:
  - "+.example.cn"
  - "api.example.net"
  - "download.example.org"

更新間隔、キャッシュ、失敗時のフォールバック

更新間隔はデータの変化頻度に合わせて設定します。ノードサブスクリプションは短め、安定したルール集合は日単位で更新できます。間隔が短すぎるとリモートリクエストと設定再読み込みが増え、ネットワークが不安定なときに大量のエラーログが発生します。リモート更新に失敗すると、コアは通常ローカルキャッシュを使い続けようとします。そのため path の保存先は書き込み可能にし、システムのクリーンアップ処理で頻繁に削除されないようにしてください。

初回読み込みで失敗すると、ローカルにキャッシュがまだないため、そのproviderを参照するグループやルールセットが利用できないことがあります。新しい端末へ導入する前に、リモートアドレスへの到達性、応答形式、保存ディレクトリの作成可否を確認してください。複数OSで設定を同期する場合は相対パスを優先します。Windows、macOS、Android、iOS、Linuxでは設定ルートが異なるため、特定OSの絶対パスを固定すると他の端末で読み込みに失敗します。

サブスクリプション認証情報と設定の分離

サブスクリプションURLにはアクセス認証情報が含まれることが多く、公開リポジトリ、公開ログ、公開スクリーンショットに載せてはいけません。複数端末で同期する場合は、認証情報を含まないメイン設定、プロキシグループ、ルールをプライベートな管理経路に置き、サブスクリプションURLはクライアントのローカルオーバーライドや端末専用ファイルに追加します。これによりルーティングロジックを共有しつつ、すべての端末で同じ実行パラメーターを使う必要がなくなります。

設定の階層は4つに分けて考えられます。メイン設定は動作方式、providerはノードやルールデータ、プロキシグループは選択可能な出口、端末オーバーライドは端末固有の差異を担当します。変更はできるだけ該当する層だけに加えてください。ポート、ノード、ルール、端末パスをすべてサブスクリプション生成ファイルへ詰め込むと、更新時の衝突と切り分けコストが大きくなります。

08 / OVERRIDE & DEBUG

オーバーライド、マージ、検証、トラブルシューティング

サブスクリプション更新で手動編集が上書きされる理由

多くのGUIクライアントは、リモートサブスクリプションを実行用設定へ変換します。変換後のファイルを直接編集しても、次回更新時にクライアントが内容を再生成するため、追加したルール、ポート、DNS設定が消えることがあります。オーバーライドは、サブスクリプション更新後かつコアの読み込み前にローカル変更を生成結果へ再適用するための機能です。クライアントによって「オーバーライド」「拡張」「スクリプト」「ミックスイン」「設定マージ」など呼び方が異なり、対応するマージ規則も異なります。

単純なスカラー値は通常、後の値が前の値を上書きします。たとえばローカルの mixed-port でサブスクリプションのポートを置き換えます。マッピングは再帰的にマージされ、dns.ipv6 だけを変更して他のDNS項目を残せる場合があります。リストは実装差が最も出やすい部分です。rules 全体を置き換える実装、先頭追加・末尾追加・削除に対応する実装、スクリプトから完全な配列を返す必要がある実装があります。利用前にクライアントのオーバーライド仕様を確認し、最終生成設定で結果を検証してください。

# ローカルオーバーライドの例：具体的なファイル入口はクライアントによって異なる
mixed-port: 7890
mode: rule
log-level: info

dns:
  enable: true
  ipv6: false

profile:
  store-selected: true
  store-fake-ip: true

ルールのマージでは先頭追加か末尾追加かを明確にする

ルールは最初に一致したものを使うため、追加位置によって意味が変わります。LANへのダイレクト接続、単一ドメインの修正、サブスクリプションの既定動作を上書きしたいルールは通常先頭に追加します。既存の完全一致ルールへ影響させたくない補足項目は、サブスクリプションのルールの後ろ、最終MATCHの前に置きます。MATCHの後ろへ追加しても、残りの接続はすでにMATCHに捕捉されているため機能しません。

クライアントがリスト全体の置き換えしかサポートしない場合は、オーバーライドに完全なルール順序を保持するか、rule-providerを使ってカスタム集合をメイン設定から安定して参照します。「マージツールがより具体的なルールを自動判定する」と考えないでください。YAMLマージが扱うのはデータ構造であり、ルーティングの意味ではありません。マージ後は最終設定を開き、カスタムルールの位置と、妥当なフォールバックが1つだけ存在することを確認します。

rules:
  # ローカルサービスとLANルールを先頭に追加
  - DOMAIN,router.local,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve

  # カスタムルールセット
  - RULE-SET,development-services,開発サービス

  # 共通地域ルールとフォールバックルール
  - GEOIP,CN,DIRECT
  - MATCH,ノード選択

読み込み前の構文と参照の検証

構文検証では、まずYAMLを解析できるか確認し、次にClashのフィールドが有効か確認します。一般的なYAMLツールはインデント、コロン、引用符の誤りを見つけられますが、proxy-groups が存在しないノードを参照しているかまでは分かりません。コアの設定テストでは、フィールド型、プロキシグループ参照、provider定義、ルール形式まで確認できます。GUIクライアントはインポートや再読み込み時にエラー位置を表示することがあります。Linuxのコマンドライン導入では、インストールしたコアが提供する設定テスト用パラメーターを使い、実際のコマンドはそのコアのヘルプを確認してください。

行番号が表示されても、その行だけを確認しないでください。YAMLパーサーは「これ以上構造を解析できない」と判断した位置を報告することがあり、実際の原因は数行前の引用符、インデント、リストのハイフン不足かもしれません。エラー行から上へたどり、直近の同じ階層のフィールドを見つけてインデントを比較します。長い設定では、直近に追加した領域を二分してコメントアウトすると、エラー箇所を早く絞り込めます。

# Linux環境の例：まず実際にインストールされたコアのパラメーターを確認
mihomo -h

# 一般的な設定テスト形式。パスは端末のディレクトリに合わせる
mihomo -t -f ./config.yaml

再現可能なトラブルシューティング手順

第1段階ではコアが起動しているか確認します。設定の読み込み結果、待ち受けポート、コントロールインターフェースを確認し、起動前に失敗しているならYAML、フィールドの互換性、ファイル権限に集中します。第2段階ではトラフィックがClashへ入っているか確認します。システムプロキシ、アプリプロキシ、TUNの状態、ログに該当リクエストが出ているかを確認してください。リクエスト記録がない場合は、まだコアへ到達していないため、先にノードやルールを変更しないようにします。

第3段階ではDNSとノードを確認します。ログから対象ドメインが解決されているか、ノードサーバーへ到達できるか、TLSまたはプロトコルのハンドシェイクがどの段階で失敗したかを判断します。モードを一時的にグローバルへ切り替え、利用可能と確認したノードを1つ選ぶと、ルール問題とノード問題を分離できます。第4段階ではポリシーとルールを確認します。ヒットしたルール、対象プロキシグループ、グループ内の現在の選択、providerの状態を記録してください。第5段階で、ブラウザー独自のプロキシ、セキュアDNS、QUIC、プロセス識別、LAN探索などアプリ固有の要因を確認します。

安全なロールバックと変更記録

一度に変更する機能領域は1つにし、読み込み可能な設定を必ず1つ残します。ポート、DNS、TUN、ルールを同時に変更すると、障害発生時に原因を特定しにくくなります。安全な手順は、元の設定をコピーし、変更目的を記録し、1組の変更を加え、構文テストを実行し、再読み込み後に新しい接続を観察することです。安定を確認してから次の変更へ進みます。設定をプライベートなバージョン管理へ入れる場合、コミットには「LANドメインを実アドレス解決へ変更」「開発サービスのルールを先頭へ追加」など動作の変化を明記し、「設定更新」だけで済ませないでください。

ロールバックではYAMLを戻すだけでなく、クライアントが保存したプロキシグループの選択、Fake-IPキャッシュ、providerキャッシュ、システムプロキシの状態も考慮します。ファイルを戻しても症状が変わらない場合は、設定を再読み込みして新しい接続を作り、必要ならコアを再起動して古い接続が元のポリシーを使い続けていないか確認します。最初からすべてのキャッシュや設定を消去しないでください。現状を残しておく方が、どの層で変化が起きたかを判断しやすくなります。

マニュアルから実際の設定へ

初回構築では小さな段階に分けます。まず mixed-port、ルールモード、利用可能なノードを1つ設定し、次に「ノード選択」プロキシグループを作り、基本的なダイレクト接続とMATCHルールを追加します。通信が正常になってからDNS拡張モードを有効にし、providerとサービス別ルールセットを導入してください。各段階で検証結果が明確になり、サブスクリプション、DNS、TUN、複雑なルールを一度に持ち込まずに済みます。

クライアントをインストールまたは変更する場合は、Clashインストールパッケージ一覧からOSに合うものを選び、デスクトップ・モバイルともにClash Plusを優先してください。サブスクリプションの読み込み、モード選択、接続確認だけを行いたい場合は、Clash利用ガイドへ戻ります。ポート競合、サブスクリプション更新失敗、システムプロキシが戻らない問題、特定OSの権限問題は、よくある質問で症状別に確認できます。Linuxデスクトップ、コマンドライン、systemdサービスとしての導入は、LinuxへのClash導入を参照してください。