Clash 設定ファイル完全ガイド

01 / Structure

YAML 構造の概要

設定ファイルの構成要素

Clash の設定ファイルは、基本的に 1 つの YAML ドキュメントです。mihomo コアはこれを読み込むと、まず待ち受けポートと DNS サービスを設定し、その後にプロキシノード、プロキシグループ、ルールセット、動作パラメータを読み込みます。一般的な設定は、共通の動作項目、DNS、ノードまたはノード Provider、プロキシグループ、ルール Provider、ルールの 6 層に分けられます。テキスト上の記述順は通常、解析結果に影響しませんが、参照関係には明確な方向があります。ルールはプロキシグループを参照し、プロキシグループはノードや他のプロキシグループを参照します。Provider はプロキシグループやルールに更新可能なデータを提供します。

以下は階層を理解するための最小構成例です。ローカルの HTTP ポートと SOCKS ポートを使用し、手動プロキシグループを定義して、事前に一致しなかった通信を直接接続します。例にあるノードのアドレスとパスワードは学習用のダミー値であり、そのまま接続には使えません。

port: 7890
socks-port: 7891
allow-lan: false
mode: rule
log-level: info

proxies:
  - name: Example-Trojan
    type: trojan
    server: example.com
    port: 443
    password: "your-password"
    sni: example.com

proxy-groups:
  - name: ノード選択
    type: select
    proxies:
      - Example-Trojan
      - DIRECT

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

トップレベルのキーは行頭から記述します。キーに属する子項目は統一したインデントで記述し、通常は半角スペース 2 つを使います。YAML では 2 つに固定されていませんが、同じ階層のインデントは必ず統一してください。Tab はインデントには適しません。リスト項目はハイフンで始め、キーと値の間には半角コロンと 1 つ以上のスペースを置きます。ノード名やプロキシグループ名に日本語を使うことはできますが、スペース、大文字・小文字、記号を含め、すべての参照箇所で完全に一致させる必要があります。

マッピング、リスト、スカラー

3 種類のデータ形式を理解すると、ほとんどの設定をすぐに読み解けます。マッピングはキーと値の組で、たとえば dns: の下にある enable: true が該当します。リストは順番を持つ項目の並びで、たとえば rules: の下に 1 行ずつ記述するルールです。スカラーは文字列、数値、真偽値、null などを指します。true と false は引用符を付けず、真偽値として記述してください。ポート番号は数値で記述します。コロン、シャープ記号、前後のスペースを含む文字列や、YAML が別の型として解釈する可能性がある文字列は、引用符で囲むのが安全です。

シャープ記号はコメントの開始を表します。パスワードや名前そのものにシャープ記号が含まれる場合は、必ず引用符で囲んでください。そうしないと、後続の文字列がコメントとして扱われて破棄されます。同じトップレベルキーが設定内に重複すると、パーサーによって前の値を残す場合、後の値を残す場合、またはエラーになる場合があります。重複キーによる上書きに依存しないでください。サブスクリプションファイルを編集する際は特に注意が必要です。新しい dns: セクションを既存の dns: セクションの後ろに貼り付けても、マージが完了したことにはなりません。

名前の参照と読み込み順序

プロキシグループ名は、ルールが最終的に送る先です。たとえばルールが DOMAIN-SUFFIX,example.org,自動選択 であれば、設定内に「自動選択」という名前のプロキシグループ、または同名の組み込みアクションが必要です。DIRECT や REJECT などはコアが認識するアクションです。それ以外の名前は proxy-groups で宣言しなければなりません。プロキシグループが別のプロキシグループを参照することもできますが、A が B を参照し、B が A を参照するような循環は避けてください。

クライアントで設定を取り込む際、元のサブスクリプションを保存してからローカルの上書きを適用し、最後にコアへ渡して解析する場合があります。そのため、画面に表示される最終設定は、サブスクリプションサーバーが返したテキストと完全には一致しないことがあります。トラブルシューティングでは、実際に動作している設定がどれか、最後の更新が成功したか、クライアントでスクリプトやマージルールが有効になっていないかを確認してください。サブスクリプションの取り込みと初回接続だけが目的なら、YAML 全体を手書きする必要はありません。まずクイックスタートガイドに従ってください。

02 / General

共通項目：ポート、モード、ログ

待ち受けポートの選び方

port は HTTP プロキシポート、socks-port は SOCKS5 プロキシポート、mixed-port は同じポートで HTTP と SOCKS の両方を受け付けます。デスクトップでは、システムプロキシに HTTP または mixed ポートを使うことが多く、SOCKS5 を個別に指定するコマンドラインツールでは socks ポートを利用できます。多くの場合、mixed-port を選ぶとポート数を減らせますが、既存のスクリプトが 7890 と 7891 を固定参照している場合は、従来のポート設計を維持してください。

mixed-port: 7890
allow-lan: false
bind-address: "*"
mode: rule
log-level: info
ipv6: false

同じデバイス上の 2 つのプログラムが、同一のアドレスとポートを同時に待ち受けることはできません。クライアントに「address already in use」と表示されたら、まず別のプロキシソフトを終了するかポートを変更してください。ノードの問題と決めつけないようにしましょう。ポート番号は 1〜65535 の範囲で、低い番号のポートは一部のデスクトップ環境で追加権限が必要になることがあります。ポートを変更した後は、ブラウザー、ターミナルの環境変数、LAN 上のデバイスに設定したプロキシアドレスも合わせて変更します。

LAN アクセスとバインドアドレス

allow-lan は、他のデバイスから現在のデバイスが提供するプロキシポートへ接続できるかどうかを制御します。本機だけで使う場合は false にすると、不要な公開を減らせます。同じ Wi‑Fi 上のパソコン、テレビ、テスト端末から接続する場合は true にし、プロキシホストの LAN アドレスを使います。この場合、システムファイアウォールが対象ポートを許可していること、2 台のデバイスが相互通信可能なネットワークにあることも確認してください。公共のネットワークでは有効にしないでください。

bind-address は、どのローカルアドレスで待ち受けるかを決めます。アスタリスクは通常、利用可能なすべてのインターフェースを表し、ループバックアドレスなら本機からのみアクセスできます。クライアントによっては、これらの項目を GUI で管理します。画面の「LAN を許可」スイッチが、実行時に対応するキーを生成することもあります。iOS のネットワーク拡張はデスクトップのポートプロキシとは動作が異なり、同じ設定を取り込んでも、他のデバイスに待ち受けポートを公開するとは限りません。デバイス間共有は、実際のクライアント機能を基準にしてください。

rule、global、direct

mode: rule はルールリストを上から順に評価し、各接続の行き先を決めます。日常利用で最も一般的なモードです。global はすべての通信をグローバルプロキシグループへ渡すため、短時間で特定ノードの利用可否を確認するのに向いていますが、細かなルールの結果は確認できません。direct は接続先へ直接アクセスし、プロキシ使用前後のネットワーク状態を比較できます。モードを切り替えても、無効なノードや誤った DNS が自動的に修復されるわけではありません。

クライアント画面に「ルールモード」「グローバルモード」「直接接続モード」がある場合、画面上の選択が設定ファイルの既定の mode を上書きすることがあります。ルールが反映されないときは、YAML と現在の画面状態を両方確認してください。グローバルモードのままでは rules を変更しても変化が見えません。直接接続モードでは、プロキシグループ内のノード選択も主要な通信を処理しません。

ログ、コントロール API、設定の保存

log-level では info がよく使われ、接続、ルールの一致、一部のエラーを確認できます。ログが少なすぎると原因を特定しにくくなり、詳細なデバッグ出力を長期間有効にすると読みにくくなります。接続に失敗したら、対象ドメイン、一致したルール、選択されたプロキシグループ、エラー種別を記録してから設定と照合してください。「開けない」という現象だけで、すべての設定を何度も変更しないようにしましょう。

external-controller は、互換性のあるコントロール画面へ API を提供するために使います。たとえば本機のループバックアドレスで待ち受けます。secret を設定した場合、コントロール側でも同じ認証情報が必要です。モバイルクライアントでは通常、コントロール API が管理済みです。デスクトップ向け手順に合わせるためだけに LAN へ不用意に公開しないでください。設定に含まれる認証情報には自分専用の値を使い、サブスクリプション URL、ノードパスワード、コントロールキーを含む完全なファイルをフォーラムへ貼り付けないようにしましょう。

profile の保存オプションでは、プロキシグループの選択や Fake IP のマッピングを保持できます。対応状況や書き込みのタイミングは、クライアントのコア統合方法によって異なります。クライアントのアップデートや設定変更後もプロキシグループが以前の選択を保持している場合は、まず選択の記憶が有効か確認し、その後に設定が更新されていない可能性を調べてください。システム要件と利用可能なクライアントはダウンロードページでプラットフォーム別に確認できます。

03 / DNS

DNS 設定：名前解決の経路とハイジャック

DNS セクションが解決する問題

DNS セクションは、ドメイン名をアドレスへ変換する方法と、名前解決リクエストをコアが一元的に処理するかどうかを決めます。プロキシノードが利用できても、DNS が正しいとは限りません。名前解決がシステムのネットワークから直接行われたり、ルーター、通信事業者のネットワーク、別の VPN に引き継がれたりすることがあります。よくある症状は、一部のドメインだけ開けない、ルールの一致結果が想定と違う、ネットワーク切り替え後だけ一時的に不安定になる、プロキシ接続中なのにアプリがアクセス不能と表示するといったものです。

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
  nameserver:
    - https://1.1.1.1/dns-query
    - https://8.8.8.8/dns-query
  proxy-server-nameserver:
    - 223.5.5.5
  fake-ip-filter:
    - "*.lan"
    - "localhost.ptlogin2.qq.com"

enable は内蔵 DNS の有効・無効を制御します。listen は DNS サービスの待ち受けアドレスで、デスクトップやルーター環境ではシステムからの転送先になります。モバイルでは通常、ネットワーク拡張が処理するため、待ち受けポートだけで動作状況を判断しないでください。ipv6 は AAAA レコードを返すか、処理するかを制御します。ローカルネットワークの IPv6 経路が不安定な場合、一時的に無効にするとデュアルスタックが原因かどうかを切り分けられますが、IPv6 の無効化を DNS 障害すべての定番解決策にしないでください。

nameserver と bootstrap の関係

nameserver は主要な名前解決サーバーのリストです。従来の UDP アドレスのほか、暗号化 DNS の URL も指定できます。DoH を設定すると、DoH サーバー自身のドメイン名も先に解決する必要があり、起動時に依存関係が生じます。mihomo では、default-nameserver や専用のサーバー名前解決項目を使って初期解決を処理できます。ここには直接到達できる IP 形式のリゾルバーを指定し、まだ確立していないプロキシ経路に初期解決が依存しないようにします。

proxy-server-nameserver は主にプロキシサーバーのドメイン名を解決するために使います。通常の宛先ドメインの名前解決と分離できるため、「プロキシサーバーへ接続するために、先にそのプロキシ経由でサーバー名を解決する」という循環依存を減らせます。ノードの server がすでに IP アドレスなら影響は小さくなります。サブスクリプション内の多くのノードがドメイン名を使う場合は、現在のネットワークから直接到達できるリゾルバーを設定する方が安定します。

暗号化 DNS だからといって、すべての問い合わせが自動的にプロキシ経由になるわけではありません。リゾルバー URL は直接接続することも、コアが対応するアドレス指定によって特定のプロキシグループで処理することもできます。名前解決の経路を設計する前に、ローカル DNS の干渉を避けたいのか、ルール判定を統一したいのか、特定ドメインを特定リゾルバーへ送る必要があるのかを決めてください。目的によって設定は変わります。公共 DNS を大量に並べ、コアが最適なものを自動選択すると期待するのは避けましょう。リゾルバーごとに応答が異なるため、かえって不確定要素が増えることがあります。

fake-ip と redir-host

fake-ip モードでは、まずアプリに予約アドレスプール内のマッピングアドレスを返し、コアがマッピングから元のドメイン名を復元してルールを適用します。ドメイン情報を保ったままルールに一致させやすく、透過的な通信の取り込みにも向いています。redir-host は実際の名前解決結果を返すため、一部の LAN サービスやアドレスの挙動に敏感なアプリとの互換性が高くなる場合がありますが、ドメイン情報の保持方法と一致経路は異なります。

fake-ip-range には専用に計画したアドレス範囲を使い、家庭、会社、コンテナ、VPN が使用しているネットワークと重複させないでください。LAN ドメインへアクセスした結果 Fake IP が返る場合、そのドメインが除外されていない可能性があります。実アドレスで解決する必要が明確なドメインは、fake-ip-filter に追加できます。たとえば LAN 用のサフィックス、デバイス検出用ドメイン、特定のログインドメインなどです。フィルターはできるだけ具体的にしてください。広すぎるワイルドカードを加えると、多数のリクエストが Fake IP を迂回し、一元的な取り込み効果が弱くなります。

nameserver-policy とドメイン別名前解決

nameserver-policy を使うと、特定のドメインやルールセットに指定したリゾルバーを割り当てられます。たとえば内部ドメインは社内 DNS、それ以外は公共の暗号化リゾルバーに送る設定です。条件は具体的な方が保守しやすくなります。1 つのドメインが複数のポリシーに一致する場合は、コアの優先順位を確認し、ログで最終結果を検証してください。設定の並びだけで判断しないようにしましょう。

dns:
  enable: true
  enhanced-mode: fake-ip
  nameserver:
    - https://1.1.1.1/dns-query
  nameserver-policy:
    "geosite:cn":
      - https://223.5.5.5/dns-query
    "+.internal.example":
      - 192.168.1.1
  fake-ip-filter:
    - "+.internal.example"
    - "*.lan"

内部リゾルバーは通常、指定された Wi‑Fi、企業ネットワーク、VPN 内でしか利用できません。そのネットワークを離れた後もポリシーが到達不能な内部アドレスへ名前解決を送ると、タイムアウトまで待たされます。モバイル端末は携帯回線と Wi‑Fi を頻繁に切り替えるため、このような設定は対応するオンデマンド接続条件や独立した設定に分けるのがおすすめです。オフィスネットワークに強く依存する DNS 設定で、すべての環境を上書きしないでください。

DNS のトラブルシューティング手順

まずドメイン名と IP アドレスを別々にテストします。IP には接続できるのにドメイン名で失敗するなら、名前解決を重点的に確認します。両方とも失敗する場合は、プロキシグループ、ノード、システムネットワークを調べます。次にログで DNS のタイムアウト、接続拒否、リゾルバーのハンドシェイクエラーを確認します。さらに、別の VPN、プライベート DNS、フィルタリングアプリ、ルーターの DNS 書き換えが同時に有効になっていないか確認してください。enhanced mode、リゾルバー、IPv6 の変更は最後に行います。毎回 1 つの変数だけを変更し、アプリやシステムの短期キャッシュを消去してから再テストしてください。

「接続済みなのにインターネットへアクセスできない」場合は、上から順に確認するトラブルシューティングリストも参照してください。fallback、フィルター、DNS ハイジャックを項目ごとに理解したい場合は、DNS 設定の詳しい解説を確認できます。クライアントによっては一部の項目が GUI にまとめられているため、最終的には実行ログとエクスポートした有効設定を基準にしてください。

04 / Proxies

プロキシノードの項目

共通項目と参照名

proxies は静的なノード一覧です。各ノードには少なくとも name、type、server、port が必要で、その他の項目はプロトコルによって決まります。name は設定内部で参照する識別名であり、ネットワーク接続先ではありません。サーバーのドメイン名やアドレスは server に指定します。プロキシグループからノードを参照するときは名前を使うため、ノード名を変更したら、直接参照しているすべてのプロキシグループも更新してください。

ノード名は短く、変更されにくいものが適しています。サブスクリプション更新でサーバー側が名前を変更すると、クライアントが記憶していたプロキシグループの選択先が見つからず、既定のノードへ戻ることがあります。長期的に選択を固定したい場合は、Provider とフィルターを使って特定の種類のノードを選ぶか、ローカルの上書きで命名を統一してください。名前に含まれる地域名だけで回線品質を判断しないでください。実際の利用可否は、ローカルネットワーク、入口、転送パラメータ、サーバーの状態にも左右されます。

Trojan の例

proxies:
  - name: Example-Trojan
    type: trojan
    server: edge.example.com
    port: 443
    password: "your-password"
    sni: edge.example.com
    udp: true
    skip-cert-verify: false

Trojan は TLS と組み合わせて使うことが多いプロトコルです。sni は TLS ハンドシェイクで使うサーバー名で、サーバー証明書やデプロイ設定と一致させる必要があります。password の特殊文字は完全に保持し、引用符で囲むと安全です。udp はノードが UDP 通信を扱うかどうかを制御しますが、クライアント、コア、サーバーがすべて対応している場合にのみ実際に利用できます。skip-cert-verify は証明書検証を無効にして本人確認を弱めるため、通常の構成では false を維持してください。証明書エラーは、サーバー名、証明書の有効性、システム時刻、ネットワークによる改ざんの可能性から解決します。

Shadowsocks の例

proxies:
  - name: Example-SS
    type: ss
    server: 203.0.113.10
    port: 8388
    cipher: aes-128-gcm
    password: "your-password"
    udp: true

Shadowsocks の主要項目は暗号方式とパスワードで、両端で一致していなければなりません。cipher は好みで変更せず、サーバー側の設定と同じ値を入力します。接続に失敗したら、アドレス、ポート、方式、パスワードの 4 点を確認し、サーバーのファイアウォールとローカルネットワークが対象通信を許可しているか調べてください。別プロトコルの項目をコピーしても互換性は向上しません。認識されない項目は無視される場合があるほか、設定検証エラーの原因になることもあります。

VMess、VLESS と転送層のパラメータ

VMess では uuid、alterId、cipher などを使うことが多く、VLESS では UUID に加えて、構成に応じて TLS、Reality、その他の転送設定を指定します。WebSocket や gRPC などの転送層には、パス、Host、サービス名、リクエストヘッダーが必要になる場合もあります。項目の階層は mihomo が対応する形式に合わせてください。他のクライアントが出力した JSON の項目を、そのまま YAML に移さないでください。

  - name: Example-VMess-WS
    type: vmess
    server: ws.example.com
    port: 443
    uuid: 00000000-0000-4000-8000-000000000000
    alterId: 0
    cipher: auto
    tls: true
    servername: ws.example.com
    network: ws
    ws-opts:
      path: /network
      headers:
        Host: ws.example.com

ここでの server は接続先を決め、servername または対応する SNI 項目は TLS に影響します。WebSocket の Host は上位層のリクエストに影響します。単純な構成では 3 つのドメイン名が同じこともありますが、リバースプロキシや入口を分離した構成では異なる場合があります。どれか 1 つでも誤記すると、TCP 接続は確立するのにハンドシェイクだけ失敗することがあります。トラブルシューティングでは、「ドメイン解決、TCP ポート、TLS、転送層、プロトコル認証」の順に層ごとに確認してください。

ノード単位のネットワークオプション

interface-name は送信に使うネットワークインターフェースを指定でき、routing-mark は Linux のポリシールーティングで使われることがあります。モバイルクライアントでは通常、手動設定は不要です。ip-version や prefer-ipv6 などは、ノードサーバーのドメイン名からどのアドレスを選ぶかに影響します。対応状況はコアによって異なります。デュアルスタック環境で誤ったアドレスが選ばれていると確認できた場合だけ変更し、一般的な回線障害を IP バージョンの問題と誤認しないようにしてください。

ノードの項目が正しいのに利用できない場合は、まずそのノードを単純な select グループに入れ、一時的にグローバルモードへ切り替えてテストし、複雑なルールの影響を除外します。テスト後はルールモードへ戻してください。すべてのノードが同時に使えない場合は、サブスクリプションの状態、システム時刻、DNS、ローカルネットワークを優先的に確認します。1 つのノードだけが失敗する場合に、そのプロトコルパラメータを詳しく調べます。クライアントの選択肢とプラットフォームごとの差異はダウンロードページで確認できます。全プラットフォーム向けの第一候補として Clash Plus を推奨します。まず基本接続を確立してから、設定を段階的に調整できます。

05 / Policy

プロキシグループの項目と選択ロジック

select：選択を利用者に委ねる

プロキシグループはノードとルールの間に位置します。ルールは通常、特定のノードを直接指定せず、プロキシグループを参照します。クライアント画面でグループ内の選択を変更すると、そのグループを参照するすべてのルールが新しい結果を使います。select は手動選択グループで、「ノード選択」「ストリーミング」「ダウンロード」など、明確に制御したい入口に適しています。グループ内にはノードだけでなく、他のプロキシグループや DIRECT も配置できます。

proxy-groups:
  - name: ノード選択
    type: select
    proxies:
      - 自動選択
      - フォールバック
      - Example-Trojan
      - DIRECT

リストの順番は、画面での既定表示とフォールバック時の使い勝手に影響します。最もよく使う選択肢を前に置きつつ、上位グループと下位グループが循環しないようにしてください。たとえば「ノード選択」に「自動選択」を含めるのは適切です。しかし「自動選択」が候補として「ノード選択」を含めると、解析または実行できない循環が生じます。複雑な設定では、まず参照方向を図にしてから階層を決めると安全です。

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

url-test は指定した URL に対して候補ノードの接続性をテストし、結果が適切なノードを選択します。測定対象へのリクエスト結果であり、すべてのウェブサイトでの実速度を示すものではありません。テスト URL には安定して応答し、レスポンスが小さく、主な利用ネットワークを代表するものを選びます。テスト頻度が高すぎるとバックグラウンド処理やサーバーへのリクエストが増え、モバイル端末では電池消費も増加します。

  - name: 自動選択
    type: url-test
    proxies:
      - Example-Trojan
      - Example-SS
    url: https://www.gstatic.com/generate_204
    interval: 600
    tolerance: 80
    lazy: true

interval はテスト間隔で、通常は秒単位です。tolerance は、わずかな差だけで候補が頻繁に切り替わるのを防ぎます。lazy を使うと、必要時に近い形でテストできます。これらの項目は、常時更新よりも安定性を重視して設定してください。同じ出口を維持する必要がある通信では、ノードの頻繁な切り替えがセッション変更を招くことがあります。許容差と間隔を大きくするか、手動グループを使いましょう。

fallback と load-balance

fallback はリストの優先順位に従ってノードを使い、現在のノードのテストに失敗すると次の候補へ切り替えます。「第一候補を優先し、利用できない場合だけ切り替える」用途に適しています。url-test とは異なり、最低のテスト結果だけを目的にせず、順序の優先度を維持します。常に 2 番目のノードへ切り替わる場合は、通常のウェブページだけでなく、第一候補からテスト URL へ到達できるかを確認してください。

load-balance は、ポリシーに従って異なる接続を複数のノードへ振り分けます。1 つのダウンロードの帯域幅を単純に合算する機能ではなく、出口アドレスの変化によってログイン状態、リスク判定、長時間接続に影響することもあります。送信元アドレスを固定する必要があるウェブサイトで、負荷分散を安易に使わないでください。具体的な方式はハッシュやラウンドロビンなどで、選択前に利用中のクライアントとコアが対応する項目を確認します。

Provider からノードを選ぶ

ノードが proxy-providers から提供される場合、プロキシグループでは proxies にすべてのノード名を記述せず、use で Provider を参照できます。サブスクリプションの更新でノードが追加・削除されても、グループ内の候補が連動して変わります。filter で名前を絞り込み、特定の地域名を含むノードだけを対象にすることもできます。フィルターには通常、正規表現を使います。大文字・小文字、全角記号、サーバー側の名称変更を考慮してください。

  - name: モバイル回線
    type: select
    use:
      - provider-main
    filter: "(?i)mobile|モバイル"
    exclude-filter: "(?i)expire|残り|期限"

名前によるフィルタリングは文字列だけを基準にし、ノードの実際の所在地、プロトコル、回線特性を検証しません。サブスクリプションの命名規則が変わると、グループが突然空になることがあります。重要なプロキシグループには、表示されるフォールバック候補を用意し、サブスクリプション更新後に候補数を確認してください。クライアント画面でグループが空の場合は、まず Provider の更新が成功したかを確認し、次にフィルター式、最後に Provider 名の誤りを調べます。

プロキシグループの階層は深くしすぎない方がよいでしょう。多くの用途では、ノードプールと自動テストグループを下層に置き、「ノード選択」を総合入口とする中層、その上に動画、ダウンロード、特定サービス向けのポリシーを置く 3 層で十分です。階層が増えるほど、ログから最終出口を追跡しにくくなります。ルールが一致したら、「ルールの対象グループ → 現在のグループ選択 → 下位グループの選択 → 具体的なノード」の順に確認してください。

06 / Rules

ルール構文と評価順

上から順に評価し、一致した時点で停止

rules は順序を持つリストです。コアは先頭から接続を確認し、一致するとそのルールで指定されたポリシーを使い、後続のルールを評価しません。そのため、具体的なルールを広いルールより前に置き、最後にフォールバックを置きます。MATCH を早い位置に置くと、その下にあるドメインやアドレスのルールは実行されません。「ルールを書いたのに反映されない」ときは、同じルールを追加する前に、ログで実際にどのルールへ一致したかを確認してください。

rules:
  - DOMAIN,api.example.com,ノード選択
  - DOMAIN-SUFFIX,example.com,ノード選択
  - DOMAIN-KEYWORD,example,ノード選択
  - IP-CIDR,203.0.113.0/24,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,ノード選択

典型的なルールは、ルール種別、マッチ内容、ポリシーの対象で構成され、半角カンマで区切ります。対象は既存のプロキシグループ、ノード名、組み込みアクションのいずれかでなければなりません。ルール行の余分なスペースが内容の一部になることがあるため、形式は統一してください。ドメインマッチングは URL のパスを対象にしません。ウェブページのパスで振り分けたい場合、DOMAIN 系ルールだけでは対応できません。

DOMAIN、DOMAIN-SUFFIX、DOMAIN-KEYWORD

DOMAIN は完全なドメイン名に一致します。たとえば DOMAIN,api.example.com はそのホストだけに一致し、www.example.com を自動的に含みません。DOMAIN-SUFFIX,example.com はルートドメインとサブドメインに一致し、同じサービスの複数ホストをまとめて対象にするのに適しています。DOMAIN-KEYWORD はドメイン名に指定文字列が含まれると一致する可能性があり、範囲が広いため、無関係な似た名前のサイトまで巻き込むことがあります。

ルール設計では、まず完全一致のドメインとサフィックスを使い、ドメインの集合を整理できない場合にだけキーワードを使います。サービスはログイン、API、画像、メディアなど複数のドメインに依存することがあり、ウェブサイトのメインドメインだけではすべてのリクエストをカバーできません。接続ログを見ながら段階的に補完できますが、一時的な CDN ホストをすべてメイン設定へ固定記述するのは避けてください。大規模なドメイン集合にはルールセット Provider が適しています。

IP-CIDR と no-resolve

IP-CIDR は IPv4 のネットワーク範囲、IP-CIDR6 は IPv6 のネットワーク範囲に一致します。CIDR のサフィックスはネットワークプレフィックス長を示し、たとえば /24 は隣接する一定範囲の IPv4 アドレスを対象にします。IP ルールでは頻繁に変わるクラウドサービスのドメインを安定して表現できないため、一度解決したアドレスを長期ルールとして使わないでください。サービスが安定したネットワーク範囲を提供する場合、LAN アドレスや明確なネットワーク範囲を指定する場合に適しています。

no-resolve は、この IP ルールの判定のために追加のドメイン解決を行わないことを示します。接続に宛先 IP がすでに含まれていれば直接一致できますが、ドメイン名しかない場合、コアはこのルールのためだけに解決しません。不要な問い合わせや潜在的な循環を減らせる一方、名前解決結果を必要とする IP ルールが一致しなくなることもあります。使うかどうかは、リクエストがコアへ入る時点で利用できる情報に基づいて判断してください。

rules:
  - IP-CIDR,127.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR6,::1/128,DIRECT,no-resolve

LAN への直接接続ルールは前方に置き、プリンター、ルーター、ファイルサーバーがリモートプロキシへ送られないようにすることが多いです。企業ネットワークではより広いプライベートアドレス範囲を使うことがあり、家庭内ネットワークと VPN の範囲が重複する場合もあります。LAN サービスへ接続できないときは、まず実際の宛先アドレスを確認し、ルールの誤り、Fake IP の除外不足、システムルートがローカルインターフェースを向いていないことのどれが原因かを判断します。

GEOIP、GEOSITE、ルールセット

GEOIP は対象 IP が属するデータベース上の地域分類に基づいて振り分けますが、データセンターの所在地とサービスの事業地域は一致しないことがあります。国内向けのサービスが別地域のクラウドを使うこともあれば、海外サービスが国内にエッジアドレスを配置することもあります。GEOSITE はドメイン分類データを使い、対象範囲はルールデータベースの内容に依存します。どちらもデータ更新の影響を受けるため、常に正確な固定情報とは考えないでください。

mihomo でよく使われるルールセットの一致方式には RULE-SET もあります。ルールセットには domain、ipcidr、classical の形式のデータを格納でき、参照時は Provider の behavior と対応させる必要があります。classical 形式の完全なルールを domain 用ルールセットに入れたり、IP ルールセットへ誤った behavior を指定したりすると、解析に失敗したり一致結果が不正になったりします。

プロセスルールとプラットフォームの制約

PROCESS-NAME や PROCESS-PATH などのプロセスルールは、OS が提供するプロセス情報に依存します。デスクトップでは権限があれば使える場合がありますが、iOS のネットワーク拡張は通常、デスクトップのように任意のプロセスパスを読み取れません。クロスプラットフォーム設定では、重要な振り分けをプロセスルールだけに依存しないでください。基本はドメイン、IP、ルールセットとし、プロセスルールは特定のデスクトップ環境向けの補助として使う方が安全です。

同じ設定でも Windows、macOS、Android、iOS で挙動が異なるのは、YAML 構文の違いではなく、システムによる取り込み方式、権限、ネットワークスタックの違いが原因であることが多いです。プラットフォーム固有のルールはローカルの上書きへ分け、サブスクリプション本体は共通化できます。こうすれば、デスクトップ専用のプロセスルールが更新時にモバイルへ強制適用されるのを防げます。

REJECT、DIRECT、最終フォールバック

DIRECT は接続先へ直接アクセスし、REJECT は接続を拒否します。ブロックルールは具体的にしてください。広すぎるキーワードやドメインサフィックスは、ログイン、決済、基本 API まで遮断する可能性があります。最後のルールには通常、MATCH から総合プロキシグループまたは直接接続を指定します。目的によって選択してください。最終フォールバックがない場合、一致しなかった通信の処理はコアの既定ロジックに委ねられ、設定の意図が不明確になります。

ルール変更後は、主要な分岐を網羅してテストしてください。直接接続すべきドメイン、プロキシ経由にすべきドメイン、LAN アドレス、ルールセットの対象をそれぞれ 1 つずつ確認します。1 つのウェブページだけでは、ルールチェーン全体が正しいとは証明できません。速度の問題はノード、回線、本機の設定を分けて考え、通信速度が遅いときの 3 層チェックも参照してください。すべての性能問題をルール数のせいにしないようにしましょう。

07 / Providers

Proxy Provider と Rule Provider

Provider を使う理由

Provider は、頻繁に更新されるデータをメイン設定から分離します。proxy-providers はノード一覧を、rule-providers はルールセットを提供します。メイン設定では参照名、更新間隔、ポリシーを定義し、リモートファイルが実際の内容を持ちます。これにより、サブスクリプション更新のたびにメイン設定全体を書き換える必要がなくなり、複数のプロキシグループで同じノードプールを共有できます。

Provider URL にはアクセス認証情報が含まれることが多いため、完全な設定を機密データとして扱ってください。トラブルシューティングで構造を共有する場合も、認証情報を削除した形にし、実際のサブスクリプション URL は公開しないでください。リモートファイルへアクセスできないと、クライアントがローカルキャッシュを使い続けることもあれば、初回ダウンロードの失敗で対象グループが空になることもあります。古いノードが残っているからといって、更新が成功したとは限りません。更新時刻と Provider のログを確認してください。

ノード Provider の設定

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

type: http はリモートから取得することを示し、url はリソースの URL、path はローカルキャッシュのパス、interval は更新間隔を指定します。複数の Provider が同じファイルを共有すると、更新時に互いの内容を上書きする可能性があるため、パスは分けてください。クライアントがサンドボックス環境で動作する場合、実際の保存場所はアプリが管理します。相対パスは通常、コアの作業ディレクトリを基準に解決されるため、デスクトップの絶対パスをそのまま使わないでください。

health-check は Provider 内のノードが利用可能かを確認します。すべてのプロキシグループの選択を自動的に変更するわけではなく、url-test や fallback などのグループがテスト結果に応じて選択を行います。確認頻度は、即時性とバックグラウンド処理の負荷のバランスを取ってください。iPhone で多数の Provider を高頻度に検査すると、ネットワーク拡張の負荷が増えます。オンデマンド接続と実際の利用頻度に合わせて調整しましょう。

Provider のレスポンスは、完全な Clash 設定ではなく、プロキシ Provider の形式でなければなりません。一般的には proxies: で始まり、その内部にノード一覧が含まれます。リモートが HTML のログインページ、エラーメッセージ、通常のテキストを返した場合、HTTP ステータスが成功に見えても解析できません。更新に失敗したら、レスポンスの Content-Type、リダイレクト、アクセス権限、システム時刻を確認してください。

ルール Provider の設定

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

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

rules:
  - RULE-SET,private-network,DIRECT,no-resolve
  - RULE-SET,service-domains,ノード選択
  - MATCH,ノード選択

behavior はルールセット項目の解釈方法を決めます。domain はドメイン集合、ipcidr はアドレス範囲、classical はタイプとパラメータを含む従来形式のルールに使います。format はリモートファイルの形式と一致させてください。YAML 形式のルールセットは通常、payload: の下にリストを置きます。テキストまたはバイナリ形式のルールセットには対応する形式を指定します。拡張子だけではデータ形式を判断できないため、最終的には実際のデータ構造を確認します。

payload:
  - "+.example.com"
  - "api.example.net"
  - "*.service.example"

domain 形式のルールセットで使うワイルドカードは、mihomo のルールセット仕様に合わせてください。ブラウザーのマッチパターンや正規表現をそのまま混在させないようにします。classical 形式なら、DOMAIN-SUFFIX,example.com のような完全なルール項目を記述できます。参照時に no-resolve を加える場合は、そのルールセットが本当に IP 形式で、追加の名前解決を必要としないことを確認してください。

更新、キャッシュ、フォールバック

Provider の更新は、独立した確認可能な手順として扱ってください。ノードが突然消えたら、まずリモートファイルが変更されたかを確認し、次にフィルター条件とプロキシグループの参照を調べます。ルールの挙動が突然変わった場合は、ルールセットの更新時刻を記録し、データソースの分類が変更されていないか確認します。すべての問題をメイン設定のせいにすると、外部データの変化を見落とします。

初回起動時に Provider ファイルを取得できなければ、それを参照するグループやルールセットを完全には構築できません。既存キャッシュは一時的なフォールバックにすぎず、無効な URL を長期間隠すためのものではありません。リモートへ到達できない場合は、ネットワークが利用可能なときに更新してから設定を有効にできます。また、重要な LAN ルールと最終フォールバックをメイン設定に残し、基本的な接続を外部ルールセットだけに依存させない方法もあります。

更新間隔は短ければよいとは限りません。ノードのサブスクリプションは 1 日に数回更新されることがありますが、安定したルールセットなら 1 日 1 回以下で十分な場合があります。高頻度更新はリクエスト、書き込み、解析の回数を増やし、モバイル回線では特に不要な負荷になります。更新に失敗したら、「アドレスへアクセスできるか → 内容が正しいか → ローカルパスへ書き込めるか → format と behavior が一致しているか → 参照名が正しいか」の順に確認してください。

08 / Override

上書き、マージ、設定のトラブルシューティング

サブスクリプション、ローカル上書き、最終設定

多くのクライアントはサブスクリプションの原文を直接実行しません。一般的には、サブスクリプションをダウンロードし、基本設定を解析し、ローカルの上書きやスクリプトを適用して最終設定を生成し、それを mihomo コアへ渡します。この層を理解することが重要です。サブスクリプションのページでルールを確認できても、実際に動作する設定が同じとは限りません。同様に、ローカルで編集した項目が次回の更新で置き換えられることもあります。

サブスクリプションに置くのに適した内容は、サーバーが管理するノード、基本的なプロキシグループ、一般的なルールです。ローカルの上書きに適するのは、ポート、LAN スイッチ、デバイス固有の DNS、個人用ルール、プラットフォーム固有の差異です。自動更新されるサブスクリプションファイルへ個人的な変更を大量に直接加えないでください。更新のたびに比較し直す必要が生じます。

上書きとディープマージは別のもの

上書きは通常、新しい値で古い値を置き換えることを意味します。ディープマージではマッピングの内部まで入り、指定した子キーだけを置き換えます。リストの扱いはさらに異なり、全体を置き換えるマージャーもあれば、先頭追加、末尾追加、名前による変更に対応するものもあります。「merge」という語だけで挙動を判断せず、クライアントの上書き仕様を確認し、最終設定をエクスポートして検証してください。

# 基本設定
dns:
  enable: true
  enhanced-mode: fake-ip
  nameserver:
    - https://1.1.1.1/dns-query

# 変更内容
dns:
  ipv6: false
  nameserver:
    - https://8.8.8.8/dns-query

ディープマージを使うと、最終 DNS に enable と enhanced-mode を残したまま、ipv6 と nameserver だけを置き換える場合があります。トップレベルの上書きなら、元の DNS セクション全体が消え、上書き側の 2 つの項目だけが残る可能性があります。リストを追加する方式では、2 つの nameserver が同時に存在することもあります。クライアントがどの意味で処理したかは、最終結果を確認しなければ分かりません。

ルールの先頭追加、末尾追加、削除

個人用ルールは通常、サブスクリプションのルールより前に追加します。ルールは一致した時点で停止するためです。特定の内部ドメインを直接接続したい場合は、そのドメインを対象にできる広範なプロキシルールより前に置きます。MATCH の後ろへ追加しても反映されません。上書きツールが prepend と append に対応しているなら、具体的な例外は prepend に置き、最終フォールバックはメイン設定に任せてください。

# 論理例：先頭に追加するルール
rules-prepend:
  - DOMAIN,router.example,DIRECT
  - DOMAIN-SUFFIX,internal.example,DIRECT

# 論理例：MATCH の後ろに追加内容を置いてはいけない
rules-append:
  - DOMAIN-SUFFIX,archive.example,ノード選択

上記のキー名はマージ処理を説明するための例であり、すべてのクライアントが直接認識するわけではありません。実際の操作では、クライアントが提供する上書き画面、または公式ドキュメントで指定されたキーを使ってください。ルールの削除は追加よりもテキストの差異の影響を受けやすくなります。スペース、プロキシグループ名、パラメータが少し違うだけで、完全一致による削除に失敗することがあります。より安全なのは、壊れやすい文字列削除に頼らず、より具体的な先頭ルールで以前の結果を上書きする方法です。

最小構成で障害箇所を特定する

複雑な設定で問題が起きても、DNS、ノード、プロキシグループ、ルールを同時に変更しないでください。まず既知の正常なノード 1 つ、select グループ 1 つ、MATCH 1 つだけを残した最小構成を作ります。最小構成で接続できるなら、問題は削除した層にあります。その後、DNS、Provider、プロキシグループ、ルールの順に少しずつ戻します。最小構成でも失敗する場合は、ノードパラメータ、システム権限、現在のネットワークを重点的に確認してください。

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

proxies:
  - name: Test
    type: trojan
    server: example.com
    port: 443
    password: "your-password"
    sni: example.com

proxy-groups:
  - name: TEST
    type: select
    proxies:
      - Test
      - DIRECT

rules:
  - MATCH,TEST

モバイル端末でテストする際は、システムの VPN 状態も考慮します。まずネットワーク拡張を使用している可能性のある他のアプリを終了し、現在の設定を再度有効にして、クライアントがシステム VPN を正常に確立できるか確認します。Wi‑Fi では正常で携帯回線では失敗する場合は、アプリのモバイルデータ通信権限、オンデマンド接続条件、DNS の到達性を調べます。特定の Wi‑Fi だけで失敗する場合は、そのネットワークの認証ページ、ルーターのフィルタリング、プライベートアドレス設定を確認してください。

エラーの種類ごとに層を分けて対処する

保存、ロールバック、変更履歴

変更前に動作する設定を 1 つ保存し、ローカルコピーには分かりやすいファイル名を付けてください。毎回 1 種類の項目だけを変更し、目的とテスト結果を記録します。問題が見つかったら、記憶を頼りに複数箇所を戻すより、直前の正常な設定へ戻す方が確実です。サブスクリプション URL とノード認証情報を公開リポジトリへ入れないでください。構造を記録する場合は、サーバー、パスワード、アクセスパラメータを明らかな学習用ダミー値に置き換えます。

編集が終わったら、4 層に分けて確認します。第 1 層は YAML：インデント、コロン、リスト、重複キー。第 2 層は参照：プロキシグループ、Provider、ルールの対象名が一致しているか。第 3 層は実行：ポートが競合せず、DNS と Provider を読み込めるか。第 4 層は動作：直接接続、プロキシ接続、LAN、最終フォールバックがそれぞれ想定どおり一致するか。4 層すべてを通過して、初めて設定が完成したと判断できます。

リファレンスから実際の操作へ戻る

目的が初回接続の完了だけなら、使い方ガイドに戻り、サブスクリプションの取り込み、モード選択、接続、動作確認を順番に行ってください。クライアントの変更やインストールはダウンロードページから、Windows、Android、iOS、macOS、Linux の各入口を選べます。設定は読み込めたのにウェブサイトで証明書エラーが表示される場合は、HTTPS 証明書エラーの原因と対処法を確認してください。iPhone のバックグラウンド通信による異常な電池消費については、ネットワーク拡張のバックグラウンド動作と省電力設定を参照できます。

設定保守で重要なのは、すべての項目を 1 つのファイルに詰め込むことではありません。参照関係を明確にし、更新元を追跡できるようにし、プラットフォーム差異を分離することです。メイン設定は安定した構造を担当し、Provider は更新可能なデータを、ローカルの上書きはデバイス固有の要件と個人設定を担当します。問題が起きたら、YAML、DNS、ノード、プロキシグループ、ルール、システムネットワークの順に範囲を絞り込む方が、設定全体を置き換えるより本当の原因を見つけやすくなります。