Clash 設定ファイルのフィールドリファレンス

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

トップレベルのマッピングがカーネルの読み込み対象を決める

Clash の設定ファイルは本質的に1つの YAML ドキュメントです。最外層には通常、複数のキーと値が並びます。ポートや動作パラメーターはスカラー、dns はネストしたマッピング、proxies、proxy-groups、rules はリストで表します。カーネルは起動時に YAML 構文を解析し、フィールドの型と参照関係を検証してから、待ち受けポート、DNSモジュール、プロキシ出口、プロキシグループ、ルールツリーを構築します。構文を解析できても、設定が必ず動作するとは限りません。たとえば、プロキシグループが存在しないノードを参照している場合、エラーは設定検証時に初めて発生することがあります。

YAML は波かっこでオブジェクトを囲まず、インデントで階層を表します。インデントは2スペースに統一し、同じファイルにタブを混在させないことを推奨します。コロンの後にはスペースを置き、リスト項目はハイフンとスペースで始めます。コロン、シャープ、アスタリスク、角かっこ、または前後の空白を含む名前は、パーサーに構文記号として扱われないよう引用符で囲んでください。ノード名には日本語も使えますが、プロキシグループ名やルールの振り分け先で何度も参照するため、短い名前ほど確認しやすくなります。

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

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

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

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

rules:
  - DOMAIN-SUFFIX,example.com,ノード選択
  - MATCH,DIRECT

上の例は最小限の一連の流れを構成しています。受信トラフィックは mixed-port に入り、ドメイン解決は DNS モジュールが担当し、ルールがリクエストを「ノード選択」へ振り分けます。プロキシグループが具体的なノードまたは DIRECT を選択します。proxy-groups を削除する場合、ルールの振り分け先にはノード名か組み込みアクションを直接指定する必要があります。rules を削除すると、rule モードでは通常、完全なトラフィック分岐を行えません。実際のサブスクリプションにはより多くのノードが含まれますが、構造の関係は同じです。

スカラー、リスト、マッピングの型は入れ替えられない

mode: rule はスカラーであり、リストにはできません。rules は順序を持つリストなので、ルール種別をキーにしたマッピングへ変更できません。dns はマッピングで、各サブフィールドにも固有の型があります。真偽値は小文字の true または false で記述し、「はい」「いいえ」や引用符付き文字列で代用しないことを推奨します。ポートは整数で記述してください。"7890" と書いても互換処理される場合はありますが、クライアント間の差異が増えます。

アンカーとエイリアスは YAML 標準の機能です。たとえば &common で共通パラメーターを定義し、<<: *common でマージできます。重複を減らせる一方、複数クライアント間で同期するサブスクリプション設定には向きません。シリアライズ時に展開されたり、アンカーが失われたりするオーバーライダーがあるためです。長期運用するファイルでは重要なフィールドを明示的に記述し、インポート経路が YAML の意味を完全に保持すると確認できた場合だけアンカーを使ってください。

読み込みパス、サブスクリプションファイル、実行時設定

GUIクライアントは通常、リモートサブスクリプションをローカルの設定ディレクトリへダウンロードし、選択した設定を mihomo カーネルへ渡します。画面に表示される設定名、サブスクリプションURL、更新時刻はクライアント管理層の情報であり、YAML に含まれるとは限りません。カーネルが処理するのは最終的に生成された設定ファイルだけです。クライアントによっては読み込み前にスクリプト、グローバルオーバーライド、ローカルパッチを適用するため、画面から書き出したファイルがサブスクリプションサーバーの原文と異なることもあります。

解析に失敗した場合は、まずダウンロード段階と解析段階を切り分けます。ブラウザーでサブスクリプションURLを開けても、サーバーが応答したことしか確認できず、内容が YAML だとは限りません。ログインページ、レート制限の案内、JSON形式のエラーが返ると、クライアントはそれを保存し、後から先頭行で構文エラーを出すことがあります。サブスクリプション解析失敗のセルフチェック手順で、レスポンス状態、Content-Type、インデント、キャッシュを確認してください。手動編集する場合は原ファイルを保存し、変更を小さな単位に分け、1回につき1つの構造ブロックだけを変更して再検証します。

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

受信ポートとLANアクセス

port は HTTP プロキシのみ、socks-port は SOCKS5 プロキシのみを提供し、mixed-port は1つのポートで両方の接続に対応します。デスクトップクライアントでは通常 mixed-port が使われるため、システムプロキシ、ブラウザー、SOCKS対応ツールで同じ待ち受けポートを共有できます。3つを同時に有効にする必要はありません。同時に設定する場合は異なるポートを指定しないと、カーネルがアドレスをバインドできません。ポート番号自体に通信を高速化する意味はなく、未使用でシステムプロキシの設定と一致していれば十分です。

allow-lan はLAN内のデバイスからの接続を許可するかどうかを制御します。false では通常ローカルホストからのアクセスだけを受け付け、true にすると bind-address、OSのファイアウォール、ルーターの分離設定も確認が必要です。LAN向けの待ち受けを開放するとアクセス範囲が広がるため、認証を設定するか、ファイアウォールで送信元を制限してください。プロキシポートをインターネットへ直接公開してはいけません。モバイル端末からパソコンのプロキシを利用する場合は、リモートノードのサーバーアドレスではなく、パソコンのLANアドレスと Clash の受信ポートを入力します。

mixed-port: 7890
allow-lan: false
bind-address: "*"
authentication:
  - "local-user:your-password"

mode: rule
log-level: info
ipv6: false
unified-delay: true
tcp-concurrent: true

allow-lan はLAN共有が本当に必要な場合だけ有効にしてください。クライアントによってはGUIのスイッチが YAML の値を上書きするため、変更後は実行状態ページで実際の待ち受けアドレスを確認します。システムプロキシを有効にしてもブラウザーが接続できない場合は、まずクライアントログに「address already in use」がないかを確認し、次にシステムプロキシのポートが古い設定を指していないかを確認します。Windowsのアプリコンテナーでは UWP のループバック制限を受ける場合があります。これはシステムのネットワーク権限の問題であり、ルールフィールド自体の問題ではありません。

mode はルールを判定に参加させるか決める

mode でよく使う値は rule、global、direct です。rule モードではリクエストを順番に rules へ照合します。global モードでは通常、トラフィックをグローバルプロキシグループへ渡します。direct モードでは通常のルール分岐を使わず、直接接続します。設定のデバッグでは、長期的な利用状態に近い rule を優先してください。一時的にグローバルモードへ切り替えれば、障害の原因がルールかどうかを判断できますが、DNS、ノード、システムプロキシがすべて正常だとは証明できません。

GUIクライアントのモード切り替えは、実行時状態として扱われることがよくあります。サブスクリプション更新後、前回の選択を保持する場合もあれば、YAML の mode を再適用する場合もあります。安定した動作が必要なら、設定ファイルとクライアントのグローバルオーバーライドを両方確認してください。ルールモードで「特定サイトが誤ったプロキシグループへ入る」場合は、ルールのヒット記録を確認します。グローバルモードではすべてのリクエストが同じプロキシグループへ入るため、ドメインルールを変更しても効果はありません。これはトラブル対処で最も見落とされやすい前提です。

ログ、IPv6、同時接続

log-level はログの詳細度を制御します。よく使う値は silent、error、warning、info、debug です。通常利用では info で十分です。解析、ハンドシェイク、ルールヒットの問題を調べるときだけ一時的に debug へ切り替え、終了後に戻してください。大量のログで重要な情報が埋もれるのを防げます。ログにはアクセス先のドメイン、ノード名、宛先アドレスが含まれる場合があるため、トラブル対処の画面を共有する前に機密情報を削除します。

ipv6 はカーネルが IPv6 の名前解決と接続を処理するか決めます。無効にしてもOS全体の IPv6 が無効になるわけではなく、Clash の該当モジュールが制限された動作をするだけです。安定した IPv6 環境があり、プロキシノードと上流 DNS も対応している場合は有効にできます。一部サイトで AAAA レコードが優先されるものの接続できない場合は、ルールを何度も切り替える前に DNS の応答とノードの対応状況を確認してください。tcp-concurrent は宛先アドレスへの接続を並行して試行します。複数アドレスが返る環境では待ち時間を短縮できる一方、一時的な接続数は増えます。

unified-delay は遅延テストをより統一された基準で計算するための設定です。プロキシグループのテスト結果の解釈に影響しますが、利用できないノードを利用可能にはしません。遅延テストが示すのはテスト先への接続状況だけで、実際のアクセスは対象サイト、プロトコルのハンドシェイク、出口品質、ルール経路にも左右されます。そのため、1回の数値だけでノードを並べ替えるべきではありません。ノード選びの考え方は遅延、倍率、地域、プロトコルの解説を参照してください。

外部コントローラーと管理画面

external-controller はカーネルの制御インターフェースを公開し、GUIクライアントはそこから接続情報の取得、プロキシグループの切り替え、設定の再読み込みを行います。一般的にはローカルアドレスとポートを指定して待ち受けます。ローカル以外のアドレスにバインドする場合は secret を設定し、ファイアウォールで送信元を制限してください。external-ui は静的な管理画面のディレクトリを指すだけで、画面ファイルを自動ダウンロードするものではありません。一般的なGUIクライアントが管理層を内蔵している場合、別途設定する必要はありません。

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

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

profile.store-selected はプロキシグループの選択状態を保存し、再起動後に前回の選択を復元します。profile.store-fake-ip は Fake-IP のマッピングを保存し、再起動によるマッピング変更の影響を抑えます。実際の保存場所はクライアントの作業ディレクトリで決まります。設定ファイルは意図を宣言するだけなので、クライアントが起動時にキャッシュディレクトリを毎回削除する場合、永続化フィールドも状態を保持できません。複数デバイスで同期する場合は実行ディレクトリ全体を同期せず、サブスクリプション、オーバーライド、必要な設定ファイルだけを同期してください。ロックファイル、キャッシュ、プラットフォーム固有のパスまでコピーするのは避けます。

DNSフィールド、Fake-IP、名前解決経路

DNSモジュールは接続判断の前段にある

ドメインへのリクエストは通常、まず DNS で解決され、その後ルールと出口によって接続が確立されます。Clash の DNS モジュールは単に「ドメインをアドレスへ変換」するだけではありません。ドメインルールを維持できるか、Fake-IP のマッピングをどう作るか、上流ごとの振り分け、プロキシノードのサーバーアドレスを誰が解決するかにも影響します。「プロキシは接続済みなのにWebページが開かない」問題の多くは、DNS上流へ到達できない、汚染された応答が返る、Fake-IPフィルターが不完全、システムのリクエストがカーネルを迂回するといった DNS 周辺で発生しています。

dns.enable は内蔵 DNS を有効にし、listen は待ち受けアドレスを定義します。デスクトップクライアントは、システムDNSのリダイレクト、TUN、ローカルポートを通して問い合わせをこのモジュールへ送る場合があります。YAML で DNS を有効にしただけでは、OSが必ずそれを使うとは限りません。クライアント側でシステムDNSを正しく設定するか、対応する取り込み方式を有効にする必要があります。逆に、ポートを別の DNS サービスが使用していると、カーネルの起動に失敗したり、待ち受けを省略したりします。

dns:
  enable: true
  listen: 0.0.0.0: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
    - 1.1.1.1
  nameserver:
    - https://dns.example/dns-query
    - tls://dns.example:853
  proxy-server-nameserver:
    - 223.5.5.5
  nameserver-policy:
    "geosite:cn":
      - 223.5.5.5

default-nameserver は主に暗号化 DNS 上流自身のドメインを解決するため、直接アクセスできる IP アドレスを指定するのが一般的です。ここにもドメインを指定すると、「上流ドメインを解決するために上流が必要なのに、その上流ドメインの解決も同じ上流に依存する」という循環が起きます。nameserver は主要な問い合わせ先で、UDP、TCP、DoT、DoH などを利用できます。サンプルの dns.example は架空のドメインなので、実際の設定では利用可能なサービスへ置き換えてください。

proxy-server-nameserver はプロキシノードのサーバードメイン専用です。ノードの server にドメインを指定した場合、プロキシ接続を確立する前に実アドレスを取得する必要があります。この処理まで未確立のプロキシ経路へ送ると、依存関係の循環が生じます。このフィールドに直接接続できる DNS 上流を指定すれば、ノードの名前解決と通常のWebサイトの問い合わせを分離できます。ノードに IP を直接指定した場合はこの処理を通りませんが、ドメイン切り替えによるバックエンドアドレス変更の柔軟性は失われます。

Fake-IP モードでドメイン情報を保持する仕組み

enhanced-mode: fake-ip では、カーネルがまずアプリへ予約アドレス範囲内のマッピングアドレスを返します。アプリがそのアドレスへ接続すると、カーネルはマッピングテーブルから元のドメインを復元してルールを適用します。アプリが IP 接続だけを開始する場合でも、ドメインルールによる判定が可能です。fake-ip-range には専用に予約されたテスト用アドレス範囲を使い、実際のLAN、企業VPN、コンテナネットワークと重複させないでください。

Fake-IP はリモートサーバーのアドレスではなく、インターネットへ送信されるものでもありません。ローカルカーネルが管理する一時的なマッピングです。システムの接続先が 198.18.x.x になっていても、DNSの誤りとは限りません。確認すべきなのは、その接続が Clash に取り込まれているかどうかです。アプリがシステムプロキシを迂回し、TUNもトラフィックを取り込んでいない場合、予約アドレスへ直接接続しようとしてタイムアウトします。この場合はすべてのドメインをフィルターへ追加するのではなく、取り込み経路を確認してください。

fake-ip-filter は特定ドメインに実アドレスを返すための設定です。LANサービス、ネットワーク検出、時刻同期、一部のゲーム、ローカル検出を必要とするサービスは、マッピングアドレスに適さない場合があります。フィルター範囲はできるだけ具体的にし、広すぎるワイルドカードで大量のドメインを対象外にすると、Fake-IP のドメイン識別機能を失います。変更後は古い DNS キャッシュを削除するか、関連アプリを再起動してください。そうしないと、アプリが以前の結果を使い続ける場合があります。

dns:
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "localhost.ptlogin2.qq.com"
    - "+.stun.*.*"
    - "time.*.com"
    - "time.*.gov"

redir-host と Fake-IP の使い分け

redir-host は実際に解決されたアドレスを返すため、経路が分かりやすく、実IPに依存するアプリとの互換性も比較的良好です。一方、透過プロキシではカーネルが宛先IPしか見られない場合があり、スニッフィングや名前解決マッピングでドメインを復元する必要があります。ドメインルールの安定性は取り込み経路に左右されます。fake-ip はドメイン情報を完全に保持したい TUN 環境に適していますが、予約アドレスを受け付けない一部プログラムへの対応が必要です。モードはノード速度のスイッチではなく、システムの取り込み方式とアプリの互換性で選んでください。

respect-rules は既存ルールを参照して DNS 問い合わせを行いますが、名前解決上流とプロキシポリシーの間に循環依存がないことが前提です。主要な DoH 上流にプロキシが必要で、そのプロキシノードのサーバードメインも主要 DoH に依存すると、初期接続を確立できません。ノードドメイン用に独立した直結DNSを用意するか、少なくとも1つの基礎上流をプロキシなしで利用できるようにしてください。ログに DNS timeout が続く場合は、依存関係の最下層から確認します。

nameserver-policy の振り分け範囲

nameserver-policy はドメインまたは geosite の集合に応じて DNS 上流を選びます。つまり「DNSをどこへ問い合わせるか」を決めるもので、後続の接続が DIRECT かプロキシかを直接決めるものではありません。接続ポリシーは rules が制御します。同じドメインでも上流によって異なるアドレスが返る場合、DNSの振り分けが接続先へ間接的に影響します。そのため、DNSの地域分けとルールの地域分けは意図を揃え、中国本土のドメインを遠隔上流で解決して地域外アドレスになったり、プロキシ用ドメインをローカル上流で解決して異常な結果になったりしないようにします。

DNSを調べるときは3段階に分けるとよいでしょう。まずシステムの問い合わせが Clash に入っているか確認し、次に Clash が指定上流へ接続できるか確認し、最後に返されたアドレスとルールのヒット結果が想定どおりか確認します。ブラウザーのページだけを試しても、キャッシュ、HTTP/3、システムプロキシの影響を切り分けられません。一時的にブラウザーのセキュアDNSを無効にし、アプリのキャッシュを消去し、カーネルログでドメイン問い合わせと接続記録を確認してください。より詳しい手順はシステムプロキシ、DNS、ルールモードのトラブル対処チェックリストを参照してください。

プロキシノードのフィールドとプロトコルパラメーター

各ノードには参照可能な一意の名前が必要

proxies の各項目は、1つの静的な出口ノードを表します。共通フィールドは name、type、server、port で、その他のフィールドはプロトコルによって異なります。name はプロキシグループやルールから参照する識別子なので、同じ設定内で一意にしてください。名前が重複すると、クライアントによっては前の項目が上書きされ、別のクライアントでは同名の選択肢が2つ表示されることがあります。結果としてルールがどちらを参照しているか判断できなくなります。サブスクリプション生成器では、ノード名に地域や用途を残しつつ、長すぎる告知文は含めないようにします。

server には IP またはドメインを指定できますが、プロトコルの接頭辞やパスは付けられません。port はリモートサービスのポートであり、ローカルの mixed-port ではありません。接続に失敗した場合は、ローカルの受信とリモートの送信を分けて考えます。システムプロキシはローカルポートへ接続し、カーネルがノードフィールドに従ってサーバーへ接続します。この2種類のポートを混同するのは、手動設定でよくあるミスです。

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

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

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

サンプルのアドレスと認証情報は、フィールド間の関係を示すためだけのものです。Shadowsocks の cipher はサーバー側と一致させる必要があります。Trojan は TLS で接続することが多く、sni はサーバー名を送信するために使います。VMess の uuid、伝送方式、TLS、WebSocket パラメーターは一組で対応していなければなりません。1つのフィールドだけを変更してもハンドシェイク失敗は解消しにくく、かえってクライアントとサーバーの設定が不一致になります。

TLS、SNI、証明書検証

TLSを有効にするプロトコルでは、接続先アドレス、SNI、HTTP Host を区別する必要があります。server は接続先を決め、sni または servername は TLS ハンドシェイクで申告するホスト名を決めます。WebSocket の Host は HTTP リクエストヘッダーに属します。3つが同じ場合もあれば、サーバー構成により異なる値にする場合もあります。証明書名が一致しない場合は、サーバー証明書の対象ドメインと SNI を確認し、すぐに skip-cert-verify を有効にしないでください。

skip-cert-verify: true は証明書の有効性検証をスキップします。サーバー証明書の状況を明確に把握している場合の一時的なテストに限って使用してください。長期運用では false を維持し、システム時刻、証明書チェーン、SNI、サーバー設定を修正します。システム時刻が誤っていると、証明書がまだ有効でない、または期限切れという判定がすべて異常になります。ログでは通常、ルールやプロキシグループではなく TLS 検証失敗として現れます。

トランスポート層のオプションは階層どおりにネストする

WebSocket のパラメーターは ws-opts、gRPC のパラメーターは grpc-opts、HTTP のパラメーターは対応するトランスポートオプション内に記述します。server と同じ階層に置いて自由に名前を変えることはできません。YAML のインデントを誤ると、headers が ws-opts の外へ出てしまいます。テキストとしては読めても、カーネルが未知の位置にあるフィールドを無視したり、読み込みを拒否したりします。トラブル対処では値だけを比較せず、プロトコル仕様に沿って階層を1つずつ確認してください。

  - name: "VLESS-gRPC-サンプル"
    type: vless
    server: 192.0.2.40
    port: 443
    uuid: "00000000-0000-4000-8000-000000000001"
    network: grpc
    tls: true
    servername: grpc.example.com
    udp: true
    grpc-opts:
      grpc-service-name: example-service

udp はノードが UDP を運べるかどうかを示します。有効にするには、プロトコル、サーバー、ネットワーク経路のすべてが UDP に対応している必要があります。ゲームや音声アプリが動かない場合、ノード設定に udp: true と書かれているかだけでは不十分です。TUN の取り込み、プロキシグループの選択、サーバー側の転送、アプリ自身のプロトコルも確認してください。UDPだけが失敗し、TCPのWebアクセスは正常ということもあります。

プロトコルフィールドの違いと選び方

ノードのフィールドは実際のサーバーまたはサブスクリプションに基づくもので、推測で補完してはいけません。クライアント間の互換性の差は、新しいプロトコル機能、トランスポートパラメーターの命名、カーネルの対応状況で生じます。「サポートされていないプロキシ種別」や「未知のフィールド」が出たら、まず現在のクライアントが使用するカーネル種別を確認し、次にサブスクリプションがそのクライアント向けの形式を生成しているか確認してください。クライアントを変更する場合は、ダウンロードページから Clash Plus、Clash Verge Rev、FlClash、Clash Nyanpasu、Clash Meta for Android、ClashX Meta、Surfboard など、各プラットフォーム向けの入口を選べます。

静的ノードは少数の手動設定に適しています。ノード数が多い、またはリモート更新が必要な場合は proxy-providers を使います。両者は同時に存在でき、プロキシグループから静的ノードとプロバイダーの両方を参照できます。どのソースを使う場合でも、最終的にプロキシグループへ入る名前をカーネルが解決でき、リモートファイルにも有効なノード構造が必要です。

プロキシグループの種類、ネスト、ヘルスチェック

プロキシグループはルールとノードの間にある制御層

proxy-groups は複数のノード、他のプロキシグループ、組み込みアクションを参照可能な振り分け先としてまとめます。ルールは通常、具体的なノードではなく「ノード選択」「自動選択」「ストリーミング」などのプロキシグループを指定します。ノードが変わってもグループ内のメンバーを調整するだけで済み、大量のルールを変更する必要がありません。プロキシグループ名も大文字と小文字を区別し、参照名に余分な空白を入れないでください。

select は手動選択グループで、クライアント画面からメンバーを指定します。url-test はメンバーを定期的にテストし、結果のよいノードを選びます。fallback は順番に利用可能なメンバーを探します。load-balance は指定した方式で複数メンバーへ接続を分配します。タイプごとに解決する問題は異なります。出口を安定して固定したい場合は手動グループを使い、自動グループの頻繁な切り替えに依存しないでください。障害時に優先順位どおり予備ノードへ戻したい場合は、単純に最低遅延を選ぶより fallback のほうが意図に合います。

proxy-groups:
  - name: "ノード選択"
    type: select
    proxies:
      - "自動選択"
      - "フェイルオーバー"
      - "SS-サンプル"
      - "Trojan-サンプル"
      - DIRECT

  - name: "自動選択"
    type: url-test
    proxies:
      - "SS-サンプル"
      - "Trojan-サンプル"
      - "VMess-サンプル"
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    lazy: true

  - name: "フェイルオーバー"
    type: fallback
    proxies:
      - "Trojan-サンプル"
      - "SS-サンプル"
    url: https://www.gstatic.com/generate_204
    interval: 300
    lazy: true

url はヘルスチェックの対象です。安定していてレスポンスが小さく、すべての候補ノードからアクセスできるアドレスを選んでください。テストに成功しても、そのノードですべてのサイトが利用できるとは限りません。interval はテスト間隔で、短すぎると不要な接続が増え、長すぎるとノード障害の反映が遅れます。lazy を有効にすると、グループが実際に使われるまで能動的なテストを減らせます。tolerance は結果が近いときの頻繁な切り替えを抑える値であり、固定の速度差ではありません。

グループのネストは一方向の参照を維持する

プロキシグループは別のプロキシグループを参照できます。たとえば「ノード選択」に「自動選択」を含め、「ストリーミング」に「ノード選択」を含める構成です。このネストは既定ポリシーと用途別ポリシーを作るのに適していますが、循環させてはいけません。A が B を含み、B が A を含むと、カーネルは最終的な出口を決められません。グループ関係は用途グループから基礎グループ、さらにノードへ向かう一方向のツリーとして設計し、すべての経路が最終的に具体的なノード、DIRECT、REJECT のいずれかへ到達するようにします。

ネストが深すぎるとトラブル対処の負担も増えます。「ストリーミング」にヒットしたリクエストが「地域選択」、「自動選択」を経由し、最後にノードへ到達することもあります。画面で最上位の選択肢しか見えないと、実際の出口を誤認しやすくなります。基本設定は、ルールの振り分け先グループ、選択またはテストグループ、具体的なノードの3層以内に保つことを推奨します。サービスごとに地域を固定したい場合は、用途グループから地域グループを直接参照し、ノードリストを複製しないでください。

filter と use でプロバイダーノードを管理する

プロキシグループは use で proxy-providers を参照し、filter でノード名からメンバーを絞り込みます。フィルター式は通常正規表現として扱われるため、文字を正しくエスケープしてください。ノード名はサブスクリプション提供元が決め、更新で変わる可能性があります。安定した地域表記をフィルターに含めつつ、広すぎる一致は避けます。たとえば「米」だけでは告知文まで一致する可能性があるため、一般的な地域コードと日本語表記を明記したほうが安全です。

proxy-groups:
  - name: "米国ノード"
    type: url-test
    use:
      - remote-nodes
    filter: "(?i)米国|US|United States"
    exclude-filter: "テスト|期限切れ|満了"
    url: https://www.gstatic.com/generate_204
    interval: 600

  - name: "用途別分岐"
    type: select
    proxies:
      - "米国ノード"
      - "ノード選択"
      - DIRECT

フィルター結果が空になると、プロキシグループが使用できなくなる場合があります。サブスクリプション更新後に突然グループ内のノードがなくなったら、まずプロバイダーの更新が成功したかを確認し、次にノード名が変わっていないか、最後に正規表現が YAML の引用符やバックスラッシュの影響を受けていないかを確認します。ダブルクォート文字列はエスケープ文字を処理するため、複雑な正規表現ではシングルクォートを使うとバックスラッシュの階層を減らせます。

DIRECT、REJECT、PASS の意味

DIRECT はプロキシノードを経由せず直接接続し、REJECT は接続を拒否します。PASS は特定のルール構成やサブルールセットで使われ、照合を後続の処理へ渡します。これらは組み込みアクションなので、proxies に宣言する必要はありません。手動プロキシグループに DIRECT を入れると、ユーザーが一時的に直結へ切り替えられます。広告や悪意あるドメインのルールに REJECT を使う場合は、誤ブロックによるページ内リソースへの影響を考慮してください。

プロキシグループに DIRECT を追加するかどうかは用途の境界で決まります。既定のプロキシグループに追加すると診断しやすくなりますが、誤って選ぶと機密性の高い通信が直結する可能性もあります。プロキシ必須の用途別グループでは直結メンバーを提供しなくても構いません。グループ名は動作を表すように設計します。たとえば「ノード選択」は手動変更を許可し、「自動選択」はテストで決定し、「中国本土直結」はノードの地域ではなくルールの振り分け先を示します。

自動プロキシグループは「ノードが多いほどよい」わけではありません。候補が多すぎるとテスト通信が増え、品質差が大きい場合は結果も不安定になります。まず地域、用途、プロトコルで絞り込み、限られた候補をテストすると、安定した動作を得やすくなります。複数デバイスで同じ構造を使う場合は複数デバイスの設定同期方法を参照し、サブスクリプション、オーバーライド、デバイス固有設定を分けて保存してください。

ルール構文、優先順位、フォールバックの順序

ルールは宣言順に最初の一致で決まる

rules は順序付きリストです。カーネルは上から確認し、通常は1つのルールに一致すると後続のルールを比較しません。具体的なルールを前に、広いルールを後ろに置き、最後に MATCH でフォールバックします。「ドメインルールはIPルールより常に優先される」という全体規則はなく、実際の優先順位はファイルの順序で決まります。MATCH を途中に置くと、その後のルールはすべて通常の照合機会を失います。

一般的な形式は「ルール種別,照合内容,振り分け先」で、一部のルールには追加パラメーターがあります。カンマはフィールドの区切りなので、照合内容に複雑な値を入れる場合は対応するルール種別やルールプロバイダーを使い、むやみにカンマを追加しないでください。振り分け先は、存在するプロキシグループ、ノード、組み込みアクションでなければなりません。ルール自体がプロキシグループを作成することはありません。

rules:
  - DOMAIN,api.example.com,ノード選択
  - DOMAIN-SUFFIX,example.com,ノード選択
  - DOMAIN-KEYWORD,example,ノード選択
  - GEOSITE,cn,DIRECT
  - 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 はドメインにキーワードが含まれていれば一致する可能性があり、範囲が最も広く誤一致しやすい方式です。完全なドメインを指定できる場合はキーワードを使わず、サフィックスを使える場合もルートドメインまで対象にする必要があるか確認します。たとえば DOMAIN-SUFFIX,example.com は example.com と www.example.com の両方に一致し、サイト全体に同じポリシーを適用する場面に適しています。

IPルールと no-resolve

IP-CIDR は IPv4 アドレス範囲、IP-CIDR6 は IPv6 アドレス範囲に使います。リクエストに宛先IPがすでにある場合は直接照合できます。まだドメインで指定されている場合、カーネルはアドレス範囲に含まれるか判断するために先に解決することがあります。no-resolve を追加すると、そのルールのために能動的な名前解決を行いません。プライベートアドレスや、すでにIPであることが明らかな接続で不要な問い合わせを減らすために使います。

GEOIP はアドレスデータベースから地域を判定します。結果はローカルデータベースの内容と更新状況に左右されます。広範囲のフォールバックには適していますが、個別サービスの正確な判定には向きません。クラウドサービスやCDNのアドレスは変化し、同じドメインでもネットワークによって異なる地域のアドレスが返ることがあります。サービス単位のルールではドメイン指定や明確なルールセットを優先してください。IPv6を有効にした場合は、対応するアドレス族もルールが対象にしているか確認します。

プロセス、ポート、ネットワーク種別のルール

デスクトッププラットフォームでは PROCESS-NAME、PROCESS-PATH などのプロセスルールを使える場合がありますが、利用可否はシステム権限、カーネルの動作方式、プラットフォームの機能に左右されます。プロセス名ルールは特定アプリをプロキシグループへ固定するのに適し、パスルールはより正確ですが、インストール先が変わると無効になりやすくなります。モバイルプラットフォームではデスクトップのようにプロセスパスを読み取れないことが多いため、クロスプラットフォーム設定をプロセスルールだけに依存しないでください。

DST-PORT、SRC-PORT などのポートルールは特定プロトコルやローカルサービスを処理できますが、ポートはアプリの識別子ではありません。現代のサービスの多くが443番ポートを共有しているため、DST-PORT,443 で広範囲にプロキシを指定すると、ほぼすべての HTTPS 通信を対象にします。ポートルールは既知のサービス用ポート、LAN管理ポート、デバッグ用途に適しており、より具体的なルールを遮らない位置に置く必要があります。

rules:
  - PROCESS-NAME,example-client.exe,用途別分岐
  - DST-PORT,22,DIRECT
  - NETWORK,udp,ノード選択
  - DOMAIN-SUFFIX,internal.example,DIRECT
  - MATCH,ノード選択

NETWORK,udp は広範囲の UDP トラフィックに一致します。適切かどうかは、ノードが UDP に対応しているか、DNSを独立モジュールで処理しているか、アプリの用途によって決まります。すべての UDP を UDP 非対応のプロキシグループへ送ると、音声、ゲーム、QUIC接続が失敗します。特定アプリだけをプロキシへ通したい場合は、すべての UDP を覆う1本のルールではなく、ドメイン、プロセス、ポートを組み合わせてください。

ルールは構文より先に意図を決めて設計する

ルールを管理する前に、要件をいくつかの層に整理します。プライベートネットワークは直結、明示的に拒否するドメイン、特定地域が必須のサービス、普段使う中国本土のドメインは直結、その他の通信は既定プロキシグループへ送る、といった具合です。その後、各層をルールへ変換し、「例外を前に、一般的な条件を後ろに」並べます。複数のネットワーク設定断片を直接つなぎ合わせるより、競合を見つけやすくなります。

たとえば、あるドメイン全体は直結させたいものの、1つのAPIサブドメインだけはプロキシが必要な場合、まず完全なAPIドメインのルールを書き、その後にドメインサフィックスの直結ルールを書きます。順番を逆にするとサフィックスルールが先に一致し、例外ルールは実行されません。トラブル対処では、ファイルにそのルールが存在するかを検索するだけでなく、接続ログで実際にヒットしたルール種別と振り分け先を確認します。

rules:
  - DOMAIN,api.example.com,ノード選択
  - DOMAIN-SUFFIX,example.com,DIRECT
  - GEOSITE,private,DIRECT
  - GEOIP,LAN,DIRECT,no-resolve
  - GEOSITE,cn,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,ノード選択

ルールが増えると、重複や競合を目視だけで見つけるのは困難です。安定した共通ルールを rule-providers へ移し、ローカルの rules には少数の高優先度の例外と最終フォールバックだけを残せます。リモートルールセットも動作種別と振り分け先を確認し、信頼できる提供元だからといって対象範囲を無視しないでください。ルール更新後にサイトの経路が誤った場合は、すぐにノードを変更するのではなく、更新前後のヒット結果を比較します。

プロキシプロバイダーとルールプロバイダー

proxy-providers はリモートノード集合を管理する

proxy-providers はノードリストをメイン設定から分離します。各プロバイダーには通常、種別、ダウンロードURL、ローカルキャッシュパス、更新間隔、ヘルスチェックを設定します。プロキシグループはノード名を proxies に1つずつ書くのではなく、use でプロバイダーを参照します。サブスクリプション更新に適しており、ソースごとにフィルターやチェックを設定できます。

type: http はリモートURLから取得することを示し、path はダウンロード後のローカルキャッシュ先、interval は更新間隔を制御します。リモートファイルはカーネルが対応するプロキシプロバイダー形式でなければならず、完全な Clash 設定をノード集合として直接扱うことはできません。サブスクリプションが完全な設定を返す場合は、クライアントのサブスクリプション管理層で取り込むか、信頼できる変換処理で provider ファイルを生成します。

proxy-providers:
  remote-nodes:
    type: http
    url: "https://subscription.example/nodes.yaml?token=xxxx"
    path: ./providers/remote-nodes.yaml
    interval: 21600
    health-check:
      enable: true
      lazy: true
      url: https://www.gstatic.com/generate_204
      interval: 600

proxy-groups:
  - name: "プロバイダー選択"
    type: select
    use:
      - remote-nodes
    proxies:
      - DIRECT

サンプルのサブスクリプションURLには明らかな架空データを使用しています。実際のサブスクリプションにはアクセス認証情報が含まれることが多いため、公開リポジトリ、スクリーンショット、共有ドキュメントに書かないでください。プロバイダーのダウンロードに失敗しても、カーネルがローカルキャッシュを使い続ける場合があります。そのため画面には古いノードが表示されます。トラブル対処では「今回の更新が成功したか」と「キャッシュを読み込めるか」を同時に確認し、ノード一覧が存在するだけで正常と判断しないでください。

path はクライアントが書き込みを許可している設定ディレクトリ内に置く必要があります。絶対パスはクロスプラットフォームの移植性を下げます。Windows、macOS、Linux、Android ではディレクトリ構造も異なります。クライアントの作業ディレクトリからの相対パスを優先し、プロバイダーごとに異なるファイル名を指定してください。複数のプロバイダーが同じパスへ書き込むと互いに上書きし、1つを更新した後に別のソースのノードまで突然変わることがあります。

ヘルスチェックはプロバイダー単位の可用性確認

プロバイダーの health-check は、ノードからテスト先へアクセスできるか確認します。プロキシグループの url-test と関係はありますが、目的は異なります。前者はプロバイダー内のノードの利用可能状態を管理し、後者はグループ内のメンバーから選択します。両方を短い間隔にすると大量のテストリクエストが重複します。通常はプロバイダーを長めの周期で確認し、自動選択が必要なグループだけ適切な周期でテストする構成がよいでしょう。

テスト先は安定していてレスポンスが軽いものを選びます。あるノードだけテスト先へアクセスできない場合、ノード障害の可能性もあれば、その宛先が出口ネットワークで制限されている可能性もあります。すべてのノードが同時に失敗したら、まず DNS とテスト先自体を確認します。一部のプロトコルだけ失敗する場合は、ハンドシェイクログを確認してください。ヘルスチェックは帯域幅テストではなく、動画、ログイン、特定地域のコンテンツが利用できることも検証しません。

rule-providers で大規模なルールセットを分割する

rule-providers はリモートまたはローカルのルール集合を読み込みます。よく使われる behavior は domain、ipcidr、classical です。domain はドメイン項目、ipcidr はアドレス範囲、classical は種別付きの従来型ルールを格納します。behavior の種別とファイル内容が一致しないと、解析に失敗したり、ルールが適用されなかったりします。

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

  service-rules:
    type: http
    behavior: classical
    format: yaml
    url: "https://rules.example/service-rules.yaml"
    path: ./rules/service-rules.yaml
    interval: 86400

rules:
  - RULE-SET,private-domain,DIRECT
  - RULE-SET,service-rules,用途別分岐
  - MATCH,ノード選択

ルールプロバイダーは照合集合だけを提供します。使用時にはメイン設定の rules で RULE-SET を指定し、振り分け先を設定する必要があります。同じルールセットを別の設定で異なるプロキシグループへ割り当てることもできます。リモートファイルの更新で対象範囲が変わる可能性があるため、提供元と用途を記録し、内容不明の大規模集合を最高優先度へ直接置かないでください。

format はリモートの内容と一致させる必要があります。YAML のルールファイルは payload リストで構成されることが多く、バイナリ形式はカーネルの対応状況と拡張機能に依存します。拡張子を変更するだけでは内容は変換されません。取得したファイルが実際には HTML のエラーページだった場合、パーサーは通常先頭でエラーを出します。プロバイダー更新に失敗したら、まず HTTP ステータスとレスポンス内容を確認し、その後 behavior、format、ローカルパスの権限を確認してください。

プロバイダーとメイン設定の更新範囲

メイン設定はポート、DNS、プロキシグループ構造、最終的なルール順を制御します。プロバイダーは変化するノード集合やルール集合を担当します。安定した構造をメイン設定に、頻繁に変わるデータをプロバイダーに置くと、サブスクリプション更新でローカル設定が上書きされる可能性を下げられます。すべてをリモートサブスクリプションで生成する場合、ローカル固有の設定はオーバーライド層へ追加し、更新のたびにキャッシュファイルを直接編集しないでください。

複数のノードソースはそれぞれプロバイダーを作成し、プロキシグループで組み合わせられます。ただしノード名の重複に注意が必要です。異なるソースに同じ表示名があると、グループ内のフィルタリングやログでの識別が難しくなります。ルールで同名ノードに依存するのではなく、サブスクリプション変換やオーバーライドの段階でソース名の接頭辞を付けてください。ルールプロバイダーも役割を重複させないようにします。広範囲のドメイン集合を2つ用意して異なるプロキシグループへ向ける場合、実際の動作は rules 内の順序で決まります。

オーバーライド、マージ、検証、障害の切り分け

オーバーライド層は安定した構造を変更し、サブスクリプションキャッシュを直接編集しない

サブスクリプションを更新すると、通常はキャッシュファイルが再ダウンロードされて置き換えられます。サブスクリプションの内容を直接編集すると、次回更新で失われやすくなります。安定した方法は、リモートサブスクリプションをデータソースとして保持し、クライアントのグローバルオーバーライド、拡張スクリプト、ローカルマージファイルでポート、DNS、プロキシグループ、ルールを変更することです。クライアントごとに対応するオーバーライド形式は異なり、Clash Plus、Clash Verge Rev、FlClash などでは画面上の名称や実行順も異なる場合があります。オーバーライドがサブスクリプション解析の前後どちらで適用されるかを先に確認してください。

オーバーライドは「スカラーの置換」「マッピングのマージ」「リストの追加」「リストの先頭挿入」「フィールドの削除」に分けられます。mode のようなスカラーは通常そのまま置換します。dns はマッピングなので、一部のサブフィールドだけ変更できます。rules は順序付きリストで、末尾へ単純追加すると MATCH の後ろに入り無効になることがあります。そのためローカルの高優先度ルールはリストの先頭へ挿入します。プロキシグループのリストを名前でマージする場合は、クライアントがオブジェクトのキーで識別できるか確認してください。対応していないと同名グループが2つできる可能性があります。

# base.yaml
mode: rule
dns:
  enable: true
  enhanced-mode: fake-ip
rules:
  - GEOSITE,cn,DIRECT
  - MATCH,ノード選択

# override.yaml の目的と意味
dns:
  ipv6: false
  fake-ip-filter:
    - "*.lan"
    - "*.local"

# MATCH より前に挿入するローカルルール
rules-prepend:
  - DOMAIN,api.example.com,用途別分岐
  - DOMAIN-SUFFIX,internal.example,DIRECT

rules-prepend はオーバーライドツールで採用されることがある意味論の例であり、すべてのカーネルがトップレベルフィールドとして直接認識するわけではありません。mihomo に渡す最終ファイルでは、標準の rules リストへ展開する必要があります。特定クライアントの拡張フィールドはクライアント用オーバーライドファイルに残し、カーネルへ直接渡す設定へコピーしないでください。フィールドがクライアント用かカーネル用かは、書き出した最終設定と起動ログで確認できます。

リストをマージするときは順序と重複排除の方法を明確にする

ルールリストのマージで最も重要なのは順序です。ローカルの強制ルールはリモートルールより前に、補足ルールは地域ルールより前に置き、最終フォールバックは末尾に1つだけ残します。マージ後は MATCH が複数存在しないか、プライベートネットワークのルールがプロキシのフォールバックより後ろになっていないか、同じドメインがより早い広範囲ルールに覆われていないかを確認します。ルール本文の重複は起動エラーにならない場合もありますが、照合と保守の負担を増やします。

プロキシグループとノードリストの重複排除は、行全体のテキスト比較だけでは不十分です。ノードオブジェクトは同じ名前でもサーバーが異なる場合があり、サーバーが同じでも名前が異なる場合があります。通常の手動管理では、一意な名前を最初の制約とし、プロトコル、サーバー、ポートを照合します。プロキシグループの同名はノードの同名より危険です。ルールはグループ名だけで参照するため、重複定義の扱いがパーサーやクライアントによって変わる可能性があります。

DNSマッピングをマージするときは、リスト型フィールドが置換されるのか追加されるのかに注意します。オーバーライダーが nameserver を完全置換すると、基本設定の予備上流が消えます。fake-ip-filter を追加するなら、通常は補足フィルターの意図に合います。オーバーライド断片だけを見て判断せず、マージ後の最終 YAML を確認してください。GUIクライアントに「実行中の設定を表示」や「現在の設定を書き出す」機能がある場合は、その結果を検証対象にします。

設定検証は4つの層に分けて行う

第1層は YAML 構文です。インデント、コロン、引用符、リスト、データ型が正しくなければなりません。第2層はフィールド検証で、カーネルがフィールドを認識するか、プロトコル必須パラメーターが揃っているかを確認します。第3層は参照関係で、ルールの振り分け先、プロキシグループのメンバー、プロバイダー名、ローカルパスが存在するかを確認します。第4層は実行動作で、ポートが待ち受けできるか、DNSが上流へ接続できるか、ノードがハンドシェイクできるか、ルールが想定したプロキシグループにヒットするかを確認します。前の層を通過していない状態で、後のネットワークテストをしても意味がありません。

# クライアント内蔵の検証機能を使う場合は、実際のカーネルパスと設定パスを基準にする
mihomo -t -f config.yaml

# 設定に問題がなければ、通常は設定テストの完了を示す出力が表示される
# 失敗した場合は、エラー行、フィールド名、参照名を重点的に記録する

コマンドラインの実行ファイル名とパラメーターは、実際のインストール方法によって異なります。GUIクライアントには通常、設定チェックの入口が用意されています。テストではクライアントと同じ mihomo カーネルを使い、片方のカーネルでは受け付けられるフィールドが別のカーネルでは非対応になる事態を避けます。エラー行はパーサーが問題を検出した場所であり、根本原因の場所とは限りません。前の行で引用符を閉じ忘れ、次の行で初めてエラーが表面化することもあります。

設定を変更した後、複数の章を一度に書き換えないでください。まず動作するバージョンへ戻し、DNS、ノード、プロキシグループ、ルールをブロック単位で追加する二分法の切り分けを推奨します。あるブロックでエラーが出たら、具体的なフィールドまで絞り込みます。リモートプロバイダーは一時的に1～2個の静的サンプルノードへ置き換え、問題がダウンロード経路にあるのか、プロキシグループ構造にあるのかを確認できます。対処が終わったら完全なソースへ戻します。

よくあるエラーの切り分け経路

設定は起動するのにインターネットへ接続できない場合、まず Clash を通さない基礎ネットワークが正常か確認し、次にローカルの受信ポート、DNS、プロキシグループ、ノードのハンドシェイク、ルールのヒットを確認します。最初からすべてのルールを削除したり、すべてのセキュリティ設定を無効にしたりしないでください。障害時の状況を壊してしまいます。ログには最初に失敗した時刻を残し、その時点で選択されていたモードとプロキシグループを照合します。何度も再起動するより効果的です。

ブラウザーだけが異常な場合は、独自のセキュアDNS、プロキシ拡張、QUICが有効になっていないか確認します。すべてのアプリが異常なら、システムプロキシまたは TUN を確認します。LAN内デバイスだけが異常で本機が正常なら、待ち受け範囲とファイアウォールを確認します。特定のプロキシグループだけが異常なら、グループ内のメンバーとヘルスチェックを確認します。症状の範囲は設定層に対応するため、まず範囲を限定すると無関係な変更を避けられます。

保守しやすい設定にするための最終チェックリスト

設定完了後、トップレベルフィールドに有効な定義が重複していないこと、ポートが競合していないこと、DNS上流への基礎解決経路があること、各ノード名が一意であること、プロキシグループの参照が一方向であること、すべてのルールの振り分け先が存在すること、MATCH が末尾に1回だけあること、プロバイダーのキャッシュパスが重複していないこと、ローカルオーバーライドにサブスクリプション認証情報の公開コピーが含まれていないこと、最終的な実行設定を現在のカーネルで検証できることを確認します。その後、直結ドメイン、プロキシドメイン、IP宛先、UDPアプリを個別にテストし、単一のWebページだけで偶然成功していないことを確かめます。

設定ファイルは、サブスクリプションのソース、オーバーライドファイル、実行状態と分けてバックアップします。複数デバイスで再利用する場合は、まずプラットフォーム固有のパスと制御ポートを取り除き、各デバイスには独立したシステム取り込み設定を残します。リモートサブスクリプションはノードの変化を担当し、ローカルオーバーライドは安定した好みを担当し、クライアントの実行ディレクトリはキャッシュと選択状態を担当します。3つを分ければ、サブスクリプション更新、クライアント更新、デバイス移行で互いに上書きされません。

分類できない問題はヘルプセンターで、基礎知識、インストールと設定、使い方、トラブル対処の項目から探してください。インストールから初回接続まで、動作する基準状態を作り直す場合は入門ガイドへ戻って手順を進めます。クライアントやカーネルのインストーラーを選び直す場合は、インストーラーページでプラットフォーム別に確認してください。トラブル対処では、必ず現在の設定を保存してから、元に戻せる小さな変更を行います。