Clash設定項目リファレンス：YAML・DNS・プロキシグループ・ルール

1. YAML構造と設定の読み込み

設定ファイルと実行中の設定を区別する

Clashの設定ファイルには、待ち受けポート、名前解決の方法、利用可能なプロキシ、通信の振り分けルールを記述します。ノード一覧の別名ではありません。ノードだけでプロキシグループやルールがない場合、意図した振り分けを実現するには不十分なことがあります。GUIクライアントが設定の読み込み、保存、起動を担い、コアが生成された設定を読み込んで接続を処理します。エディターで見えるサブスクリプションの原文、クライアントが保存したローカル設定、コアが実際に読み込むファイルは、別々の内容である可能性があります。

変更を始める前に、クライアントの設定画面で現在有効な設定を確認し、編集、実行設定の表示、設定フォルダーを開くなどの項目を探してください。項目名はクライアントによって異なりますが、変更対象のファイルを特定することが大切です。ファイル名だけで判断しないでください。config.yamlという名前でも、キャッシュや起動用テンプレートの場合があります。変更が反映されないときは、項目が無効だと決めつける前に、設定を再読み込みしたか確認しましょう。

インデント、マッピング、リスト

YAMLではインデントで親子関係を表します。各階層は半角スペース2つを使い、タブは避けてください。コロンの後ろには半角スペースを1つ置いてキーと値を区切り、リスト項目はハイフンと半角スペースで表します。トップレベルのdns、proxies、proxy-groups、rulesはそれぞれ別のセクションです。インデントを間違えても解析自体は通り、項目が誤った階層に配置されることがあります。構文チェックだけでなく、構造の意味も確認してください。

# ローカル直結用の基本設定：構造と待ち受けポートの確認
mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

proxies: []

proxy-groups:
  - name: Proxy
    type: select
    proxies:
      - DIRECT

rules:
  - MATCH,Proxy

この設定にはリモートプロキシノードがなく、プロキシグループには組み込みのDIRECTしかないため、すべての通信が最終的に直結します。複雑なサブスクリプションの影響を切り分けるのには向いていますが、リモートプロキシサービスの接続確認には使えません。ノードを追加する場合は、ノード名をプロキシグループにも追加し、ルールがそのグループを参照していることを確認してください。proxiesに項目を1つ追加しただけでは、既存の通信が自動的にそのノードを選ぶわけではありません。

文字列、真偽値、同名の項目

ポート番号は通常、整数で記述します。オン・オフにはtrueまたはfalseを使います。シャープ記号、コロンの後の空白、特殊な接頭辞などを含む文字列や、別の型として解釈されやすい値は、引用符で囲むのがおすすめです。パスワードも文字列として扱ってください。シャープ記号は適切な位置に置くとコメントになり、実行時には無視されます。ルール内のカンマはルール文字列の構文の一部であり、YAMLのキーと値を区切る記号ではありません。ルール全体を複数の項目に分割しないでください。

同じマッピング階層で同じキーを重複して定義しないでください。たとえば、先にdnsを記述し、ファイル末尾でもう一度dnsを追加しても、設定を安全にマージする方法にはなりません。パーサーがエラーにしたり、どちらか一方だけを残したりする場合があります。子項目は同じマッピング内にまとめてください。ノード名、プロキシグループ名、参照文字列も完全に一致させる必要があります。全角スペース、末尾の空白、大文字と小文字の違いによって参照先が見つからなくなることがあります。

元に戻せる手順で編集する

まず元の設定をコピーして保存し、機能を1つだけ変更してから保存・再読み込みし、ログを確認します。クライアントに設定テスト機能があれば、そちらを優先してください。コマンドライン版のコアを使う場合は、次のコマンドで構造を確認できます。コマンドに指定するプログラム名とパスは、実際の環境に合わせてください。この確認でネットワーク接続やノードの認証情報が正しいことまでは検証できません。テストに失敗した場合は、最初に表示された具体的なエラーから対処しましょう。後続のエラーは連鎖的に発生している可能性があります。

mihomo -t -f ./config.yaml

このガイドでは、mihomoでよく使われる設定を中心に説明しています。オリジナル版Clash、過去の派生版、GUIクライアントによって互換性が異なる場合があります。現在のコア向けの設定が、すべてのクライアントで使えるとは限りません。コアとGUIの違いを確認するには、まずClash、Clash Meta、mihomoのエコシステムを参照し、必要な項目を見極めてください。

2. ポート、モード、共通項目

待ち受けポートで通信の入口が決まる

portはHTTPプロキシの待ち受け、socks-portはSOCKSプロキシの待ち受けに使います。mixed-portは1つのポートで両方のプロキシ接続を受け付けます。一般的なデスクトップ利用では、混合ポートだけで足りることが多く、ほかの入口も設定するかどうかはアプリの要件によります。ポート番号はローカルの入口であり、リモートノードのサーバーポートとは異なります。ブラウザーがローカルプロキシに接続した後、コアがポリシーに応じて実際のリモート出口を選択します。

項目	用途	変更時の注意
`mixed-port`	HTTPとSOCKSの混合入口	システムプロキシとアプリのポートをそろえる
`allow-lan`	LANからの接続を許可するか	待ち受けアドレスとファイアウォールも確認
`mode`	実行モードを選択	rulesによる振り分けはルールモードでのみ有効
`log-level`	ログの詳細レベルを設定	トラブル対処後は通常のレベルに戻す
`external-controller`	コントロールAPIの待ち受けアドレス	プロキシ通信の入口とは別

ポートを変更したら、クライアントのシステムプロキシ設定やアプリ内のプロキシアドレスも更新してください。「アドレスが使用中」というエラーは、別のプロセスが同じポートの組み合わせを使っているか、以前のコアプロセスが終了していない可能性を示します。実行中のクライアントとログを確認し、重複したプロセスを停止してから、ポートを変更するか判断してください。ポートだけ変更してシステムプロキシに古いアドレスを残すと、コアは正常に起動しているのにウェブページを開けない状態になります。

3つのモードは、ネットワーク全体を切り替えるスイッチではない

mode: ruleはルールの順序に従って接続先を決めます。globalはグローバルポリシーで接続先を選び、directではコアが受け取った接続を直結します。対象はあくまでコアに届いた通信であり、端末上のすべての通信ではありません。ルールモードを有効にしても、システムプロキシ、アプリ内プロキシ、適切な通信の取り込み方法が設定されていなければ、ブラウザーのリクエストがコアに届かず、ルールにも一致しません。

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

profile:
  store-selected: true

この例では待ち受けをローカルに限定し、プロキシグループの選択状態を保存します。クライアントによっては、起動時に画面上の設定に基づいてこれらの項目を書き換えることがあります。画面に表示されたモードとサブスクリプションの原文が異なる場合は、最終的な実行設定を確認してください。モードを切り替えても既存の接続が再作成されるとは限りません。新しいリクエストで動作を確認し、必要に応じてクライアントの接続画面から古い接続を閉じてください。3つのモードの違いは、ルール・グローバル・直結モードの解説も参照してください。

LAN共有とコントロールAPI

allow-lan: trueを設定するとほかの端末から接続できますが、bind-address、システムのファイアウォール、ネットワークの分離設定もあわせて確認してください。ローカルだけで使う場合は、無効にしておくとアクセス範囲を管理しやすくなります。スマートフォンや別のPCと共有する場合、接続先にはクライアントを実行している端末のLANアドレスを指定します。ほかの端末自身のループバックアドレスではありません。接続元を信頼できる端末に限定し、必要に応じてプロキシ認証も設定してください。

external-controllerはパネルやクライアントから呼び出す管理用APIで、混合プロキシポートとは用途が異なります。このAPIではポリシーの変更や接続情報の確認ができるため、通常はループバックアドレスにバインドし、認証はクライアント側で管理します。ウェブページが開けないからといって、コントロール用ポートをシステムプロキシに設定しないでください。また、公共ネットワークに直接公開するのも避けてください。プロキシ入口の認証とコントロールAPIの認証は別の仕組みであり、互いに代用できません。

ログ、IPv6、通信の取り込み範囲

通常利用ではinfoレベルから始め、トラブル対処のときだけ詳細度を一時的に上げ、解決したら元に戻してください。ログが多すぎると確認しづらくなるうえ、接続先のドメイン名や通信情報が含まれる場合があります。共有する前にサブスクリプションURLや機密情報を削除してください。トップレベルのipv6とDNSセクション内の同名スイッチは作用する範囲が異なります。一方だけを変更して端末全体のIPv6が無効になったと判断せず、OS側のネットワーク設定も確認してください。

TUNは別の通信取り込み方式です。仮想ネットワークアダプター、ルーティング、権限、DNSの横取りが関係し、混合ポートを設定すれば自動で有効になるわけではありません。デスクトップクライアント、モバイルOSのインターフェース、サーバーのコマンドライン環境では、必要な権限設定も異なります。初めて設定するときは、まず通常のプロキシ入口を動作させてから、TUNを個別に検証しましょう。権限やルーティングの問題が起きても、動作確認済みの接続経路を残せます。複数の設定を同時に変えて原因が分からなくなるのを防げます。

3. DNSとFake-IPの設定項目

まず、どこでドメイン名を名前解決するか確認する

DNS設定では、ドメイン名をIPアドレスに変換する方法と、ドメイン名と接続の関連付けを保つ方法を指定します。ブラウザー、OS、アプリ、コアがそれぞれ名前解決に関わることがあるため、dns.enable: trueを設定しただけで端末全体のDNSリクエストがコアに渡るわけではありません。システムプロキシでは、ドメイン名がプロキシリクエストとともに渡される場合があります。TUNではDNSの横取りやシステムルートとの組み合わせが必要になることが多く、アプリ内蔵の暗号化DNSが別経路を使う場合もあります。

dns.listenは、コアがDNSサービスを提供するための待ち受けアドレスです。上流のDNSサーバーではありません。ローカルの高番ポートで待ち受けていても、システムが自動的にそこを使うことはありません。クライアントやネットワーク側でDNSクエリの送信先を設定する必要があります。次の例は設定項目の関係を示すもので、TUNによる通信の取り込み設定は含みません。暗号化DNSの接続先が利用できるかはネットワーク環境によります。安定してアクセスでき、利用環境の要件に合うDNSサービスを選んでください。

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

Fake-IPでドメイン名との関連付けを保つ

enhanced-mode: fake-ipを設定すると、アプリにはマッピング用のアドレスが返されます。その後、コアがマッピングからドメイン名を復元し、ポリシーを選択します。このアドレスは接続先サイトの実際のサーバーアドレスではありません。システムの検索結果に表示されても、DNSが改ざんされたことを意味しません。重要なのは、その後の接続がマッピングを保持するコアに戻ることです。DNSリクエストを処理したインスタンスと、接続を受け取るインスタンスが異なると、アドレスは取得できても正しくアクセスできないことがあります。

fake-ip-rangeはアドレスの割り当て範囲です。リモートノードのアドレスでも、プロキシを迂回するリストに追加すべきネットワークでもありません。ローカルネットワーク、仮想ネットワークアダプター、ほかのツールのルートと競合する場合は、全体を確認してください。空いていそうな範囲に適当に変更するだけでは解決しません。DNSモードの切り替えやコアの再起動後も、アプリに古いマッピングが残ることがあります。新しい接続を作り直し、必要ならアプリやシステムの関連キャッシュを消してから変更の効果を確認してください。

fake-ip-filterには、マッピング用アドレスを返すのに適さないドメインを指定します。たとえば、一部のLAN内ドメインや実アドレスが必要なサービスが該当します。リストに追加しても、その接続が必ず直結になるわけではありません。実際の出口はルールによって決まります。フィルター対象を広げすぎると、多数のドメインで名前解決の経路が変わり、トラブルの切り分けも難しくなります。サービスに問題が起きたら、まず実アドレスが必要かを確認し、すべてのドメインをまとめて除外せず、必要なドメインだけを追加してください。

上流DNS、ブートストラップ、ノードの名前解決

default-nameserverは主に、DNS上流サーバー自体のドメイン名を解決するために使います。暗号化DNSの接続先アドレスがまだ分からず、接続できない問題を防ぐためです。nameserverは通常のクエリで使う上流サーバーです。名前だけを見て、両者を同じ候補リストと考えないでください。上流サーバーのアドレスがドメイン名の場合、ネットワーク起動時に使えるブートストラップDNSが必要です。ブートストラップに失敗すると、その後の暗号化DNSも接続できないことがあります。

リモートプロキシノードのサーバーアドレスがドメイン名の場合、その名前解決方法も考慮する必要があります。mihomoにはproxy-server-nameserverなど、ノードのサーバー名を解決する上流を指定する項目があります。DNSサービスへの通信をプロキシ経由にし、そのプロキシ接続にも同じDNSサービスで解決したノードアドレスが必要だと、依存関係のループが発生することがあります。まずノードのドメイン名を独立した経路で解決できるようにしてから、ほかのクエリをプロキシ経由にすると安定して起動しやすくなります。

nameserver-policyでは、ドメイン名や対応するマッチ条件に応じてDNS上流を指定できます。内部ドメインとパブリックドメインで異なるDNSサーバーを使う場合に便利です。これはDNSクエリの送信先を決める項目であり、アプリの通信出口を決めるものではありません。通信の出口は引き続きrulesで指定します。ルールと連動するDNSオプションを使う前に、プロキシサーバーの名前解決経路が確立しているか確認し、DNSポリシーと通信ポリシーが互いに依存するループを避けてください。

症状からDNSの問題を切り分ける

LAN内サービスだけが失敗する場合は、フィルターリストと内部DNSサーバーを確認します。すべてのドメインで失敗する場合は、上流DNSに到達できるか、待ち受けポートにクエリが届いているかを確認してください。IPアドレスは取得できるのに接続できない場合は、ルールと出口を調べます。タイムアウトの原因をすべてFake-IPのせいにしないでください。ポートの誤り、ノード認証の失敗、リモート側の接続拒否でも、似た症状が出ます。接続済みなのにウェブサイトを開けないときの確認リストも参考に、入口、名前解決、出口を分けて検証してください。

4. プロキシノードとプロトコル設定

共通項目とプロトコル固有の項目を分けて考える

proxiesは静的なノード一覧で、各項目にリモート接続方式を記述します。共通項目には、表示名のname、プロトコルのtype、サーバーアドレスのserver、リモート側の待ち受けポートのportがあります。このポートはサービス提供元が指定するもので、ローカルの混合ポートとは関係ありません。ノード名はプロキシグループから参照され、サーバー項目は実際の接続先を指定します。サブスクリプションURLや管理パネルのログインURLをサーバー項目に入力しないでください。

プロトコルごとに必要な認証項目や通信設定は異なり、互いに流用できません。Shadowsocksでは暗号化方式とパスワード、TrojanではパスワードとTLSを使うのが一般的です。ほかのプロトコルではユーザーID、フロー設定、専用の通信パラメーターが必要な場合があります。サービス提供元が指定したプロトコルに対応する項目を入力してください。typeの値だけを別のものに変えても、ノードが別のプロトコルに変換されるわけではありません。設定が読み込めても、ハンドシェイクできない場合があります。

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: trojan.example.com
    skip-cert-verify: false
    udp: true

上記は項目の記述例です。ドメイン名やパスワードを実際の接続に使うことはできません。よく使われる安全なポート番号だからといって、特定のプロトコルや暗号化方式が使われていると決めつけないでください。サーバーは任意のポートで稼働できます。クライアントとサーバーで、プロトコル、認証、通信方式、TLSの設定を一致させることが重要です。認証情報は信頼できるサービス設定から取得してください。共有画像を見て、記載されていない項目を推測しないでください。

TLSの名前とサーバーアドレス

サーバーアドレスは接続先を決め、TLS名はハンドシェイクと証明書名の検証に使われます。両者は同じ場合も、サーバー側の指定により別々の場合もあります。Trojanの例にあるsniは、接続できないからといって有名サイトのドメイン名に安易に変更しないでください。servernameなど別の項目名を使うプロトコルでは、そのプロトコルの仕様に従って設定します。あらゆるTLS名の項目を並べて、コアが自動判定することを期待しないでください。

skip-cert-verify: falseは証明書の検証を有効にする設定です。証明書エラーが出たら、端末の時刻、サーバー名、証明書の有効性、サービス提供元の設定を確認してください。検証を無効にするとエラーの表示が変わることはありますが、サーバーを識別するための保護を回避することになります。通常の解決策として使わないでください。プライベート環境で独自の証明書を使う場合は、まず信頼チェーンの構築方法を確認し、適切なクライアント設定を選びましょう。

通信方式、UDP、名前解決の経路

プロトコルによっては、network、ws-opts、grpc-optsなどの通信設定も必要です。パス、リクエストヘッダー、サービス名はサーバー側の仕様の一部であり、ドメイン名が同じだからといって省略できるものではありません。WebSocketのパスは、通常のウェブページのURLとは異なります。ハンドシェイクに失敗したら、サービス提供元の元の設定を確認し、サブスクリプション変換、コピー、クライアントへの読み込みで通信設定が失われていないか調べてください。

udp: trueは、ノードが該当するUDP通信を処理できることを示しますが、通信経路全体でUDPが使える保証にはなりません。アプリ側の入口、通信の取り込み方法、リモートプロトコルの機能、サーバー設定、ネットワークのファイアウォールが影響します。ウェブページは開けるのに音声通話やゲームが失敗する場合は、通信がコアに届いているか、リモート出口が必要な通信方式に対応しているかを個別に確認してください。ノードのUDPスイッチを何度も切り替えるだけでは解決しません。UDPを使うプロキシプロトコルの中には、ネットワークが該当する通信を許可している必要があるものもあります。

ノードのサーバーにドメイン名を使っている場合、リモート接続の前に名前解決が必要です。ログでノード名は正しいのにサーバーアドレスの解決に失敗している場合は、DNSの章に戻り、ノードの名前解決に使う上流を確認してください。アドレスへの接続後に認証を拒否された場合は、パスワードとプロトコルを確認します。エラーを名前解決、接続、ハンドシェイク、認証、アプリのリクエストに分けて読むと、ノードが使えないと一括りにするより原因を特定しやすく、サービス提供元にも状況を伝えやすくなります。

ノードの管理と情報の取り扱い

同じ名前のノードが複数あると参照先が曖昧になり、サブスクリプションの更新後に古い名前が残ることもあります。静的リストでは、各ノードに重複しない名前を付け、名前を変更したらプロキシグループやルールの参照先も確認してください。大量のノードを動的に管理する場合は、後述のプロキシプロバイダーを使い、一覧を手作業で複製するのは避けましょう。クライアントを変更する場合は、ダウンロードページでOSに合ったものを選べます。一般的なGUIクライアントにはClash Plusが候補になります。必要なプロトコルに実際のコアが対応していることを、事前に確認してください。

5. プロキシグループと出口の選択

プロキシグループでノードをまとめ、ルールから参照する

proxy-groupsを使うと、ルールから安定した名前で接続先を指定できます。ルールでは常にProxyを参照し、ユーザーはグループ内でノードを切り替えられるため、ドメインルールを1つずつ変更する必要はありません。候補には個別のノード、ほかのプロキシグループ、組み込みのポリシーを指定できます。仕組みを理解するには、参照先が決まった有向グラフとして考えるとよいでしょう。リクエストがルールに一致してからグループに進み、現在の選択をたどって最終的な出口が決まります。すべてのグループが同じ接続を同時に処理するわけではありません。

selectは手動選択用で、全体の入口、用途別の出口、接続先を明示的に固定したいサービスに適しています。url-testは測定結果から候補を自動選択し、fallbackは候補を順に確認して利用できるものを選びます。load-balanceは対応する方式で接続を振り分けます。自動選択がすべてのユーザーに適しているとは限りません。出口の変化を許容できるか、セッションを維持する必要があるか、ノードが同じサービス環境に属しているかも考慮してください。

proxy-groups:
  - name: Proxy
    type: select
    proxies:
      - 自動選択
      - DIRECT

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

rules:
  - MATCH,Proxy

この例は前章で定義した2つのノードを使います。プロキシグループだけをコピーしても動作しません。測定先のURLは接続可能かを調べるためのもので、プロキシサーバーでも、特定サイトへのアクセス確認を完全に代替するものでもありません。現在のネットワークからそのURLに到達できない場合、候補がすべて利用不可と判断されることがあります。利用環境に合った応答の安定した測定先を選び、測定が意図したノードを経由していることも確認してください。アプリのページ読み込み時間だけでは、グループ内の選択結果を判断できません。

自動測定に関する項目の役割

intervalは通常、秒単位で測定間隔を指定します。自動選択のtoleranceは、小さな差による頻繁な切り替えを抑えるために使います。間隔は短ければよいわけではありません。測定頻度が高すぎるとリクエストや電力消費が増えるため、特にモバイル端末では注意が必要です。一部の自動グループは遅延測定などのオプションにも対応します。実際の動作はグループの種類とコアの実装によって異なります。利用していないグループもすべて同じ頻度で測定するとは限りません。

測定に成功しても、そのノードから測定先にアクセスできることが分かるだけです。すべてのサイト、プロトコル、アカウントのセッションが正常に動作する保証にはなりません。特定のサービスが地域、ログイン状態、出口の制限を受ける場合は、新しい接続で実際の利用状況を確認してください。自動選択で出口が切り替わっても、既存の接続が以前の経路を維持することがあります。同時に複数の出口が見えても設定の競合とは限らず、接続ごとにライフサイクルが異なるために起きる正常な動作の場合があります。

グループのネストと参照の制約

グループをネストすると、手動での選択と自動選択を分けられます。たとえば、入口のグループで自動グループと直結を手動で切り替え、自動グループの中でノードを選ぶ構成です。2つのグループを相互に参照したり、グループ自身を候補に加えたりしないでください。循環参照が発生します。名前の誤りを調べるときは、ルールの接続先から順に参照をたどります。対象のグループ、候補のグループ、最後に接続するノードが存在するか確認し、実際に接続できる最終候補までたどってください。

useを使うとプロキシグループにプロキシプロバイダーの候補を取り込めます。filterでは名前で候補を絞り込めます。フィルター式はマッチ条件であり、ノードを分類するタグではありません。サブスクリプションのノード名が変わると、以前は使えたフィルターに一致する候補がなくなる場合があります。自動グループの候補が空なら、測定間隔を長くするのではなく、プロバイダーが読み込まれているか、フィルターが厳しすぎないか確認してください。まずフィルターを外して候補があることを確かめ、その後、条件を少しずつ絞りましょう。

選択状態の保存と、通信先の固定は別

profile.store-selectedは手動グループの選択を保存するための設定ですが、クライアント独自の状態保存機能が使われる場合もあります。設定の更新でグループ名が変わると、以前の選択を新しいグループに引き継げないことがあります。候補ノードが削除された場合も、別の候補に切り替わる可能性があります。特定サービスの出口を固定するには、安定したグループ名とノード名を保ち、そのサービス用のルールを汎用ルールより前に置いてください。全体用グループの選択だけを見ても、より具体的なルールが別のグループを参照している場合があります。

組み込みのDIRECTは直結、REJECTは通信拒否を意味し、手動で定義するリモートノードではありません。直結を自動測定グループに加える前に、測定に成功しやすいために選ばれ続け、本来のプロキシ利用の目的から外れないか考えてください。自動選択の結果が分かりにくい場合は、まず手動グループで利用可能と確認済みのノードを固定し、実際のサービスが復旧することを確認しましょう。その後、自動選択を1つずつ戻すと、ノードの問題かグループ設定の問題かを切り分けやすくなります。

6. ルール構文とマッチ順序

上から確認し、最初に一致したルールで決まる

rulesは順序を持つルールのリストです。コアは上から順に接続を確認し、最初に一致したルールのポリシーを適用します。それ以降のルールは確認しません。特定のドメイン向けルールは上に、広い範囲のアドレスルールは下に置き、最後に未一致の通信をMATCHで受けます。フォールバックを先頭に置くと、多くのルールが機能しなくなります。構文チェックに通っても、実際の振り分けが意図と大きく異なることがあります。

ルールは通常、ルールの種類、マッチ条件、適用するポリシーの3つを英語のカンマで区切って記述します。MATCHにはマッチ条件がないため、ポリシーだけを指定します。接続先にはノード、プロキシグループ、組み込みのポリシーを指定できますが、コアが参照先を見つけられる必要があります。名前に全角の記号や見えない空白が混ざったり、コピー時に余分な引用符が加わったりすると、参照に失敗することがあります。ルールは機能ごとに分け、後から管理しやすいよう短いコメントを付けてください。

rules:
  # LAN内の名前とプライベートアドレス
  - DOMAIN-SUFFIX,lan,DIRECT
  - 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

  # サンプルドメインはProxyへ
  - DOMAIN-SUFFIX,example.com,Proxy

  # 利用可能な地理情報データベースが必要
  - GEOIP,CN,DIRECT

  # どのルールにも一致しない通信
  - MATCH,Proxy

ドメインルールとアドレスルール

DOMAINは完全なドメイン名に一致し、特定のホストだけを対象にするのに適しています。DOMAIN-SUFFIXは指定したドメイン名とそのサブドメインに一致します。DOMAIN-KEYWORDはドメイン名に含まれるキーワードに一致しますが、範囲が広く、対象サービス以外にも適用される可能性があります。名前が似ているというだけで短いキーワードを使い、サービス全体を対象にするのは避けてください。サービスによっては複数のドメインを使います。トップページが想定したルールに一致していても、ログイン、画像、APIリクエストまで同じ出口を使うとは限りません。

IP-CIDRはIPアドレスの範囲に一致します。IPv6の範囲には通常IP-CIDR6を使います。通信が最初にドメイン名で行われる場合、アドレスルールの判定に名前解決が必要なことがあります。末尾のno-resolveは、そのアドレスルールのためだけに名前解決を開始するのを避ける設定です。すでに取得済みの接続先アドレスを消すものではなく、別の名前解決処理が一切行われなくなる保証もありません。すべてのルールに機械的に追加すると、アドレスマッチに期待していた動作が変わることがあります。

GEOIPとGEOSITEを使うには、対応するデータリソースが必要です。コアがサポート対象のデータを読み込んでいるか確認してください。地域やサイトの分類はデータの管理者によるもので、サービスの帰属、実際のサーバー所在地、アクセス結果を永久に保証するものではありません。分類が個別の用途に合わない場合は、広範で相反するルールを複数追加するのではなく、より正確なドメインルールを前に追加してください。

プロセスルールと接続元情報の範囲

mihomoはプロセス名やプロセスパスなどのルールにも対応しますが、プロセス情報を取得できるかはOS、権限、通信の取り込み方法、検索設定によって異なります。ローカルのデスクトップアプリではプロセスを特定できても、LAN内の別端末からのプロキシリクエストでは、その端末の完全なプロセス情報は通常取得できません。ルールの記述が正しいのに一致しない場合は、ルールの種類が非対応だと判断する前に、接続ログにマッチ対象の情報があるかを確認してください。

アプリの表示名と、実際に接続を開始するプロセス名は異なる場合があります。ブラウザーの補助プロセス、更新サービス、バックグラウンドコンポーネントが個別に通信することもあるため、ウィンドウのタイトルだけを見てプロセスルールを設定しないでください。業務アプリの出口を固定したい場合は、まず対象のドメインを明示したルールで確認してから、残りの通信をプロセスルールで扱えるか検討しましょう。複雑なロジックルールは基本の振り分けを確認してから導入し、個別にテストできるシンプルな条件を残してください。

接続ログでルールを検証する

検証を始める前にルールモードが有効か確認し、クライアントの接続画面やログ画面を開いて、新しい接続を発生させます。一致したルールと最終的なポリシーの経路を確認してください。ページが開くかどうかだけでは、ルールに従ってプロキシ接続したのか、直結したのか、既存の接続を再利用したのか分かりません。ルールを変更した後も新しい接続を作成してください。必要に応じて対象アプリの長時間接続を閉じます。古い接続が以前の出口を使い続けているだけなのに、ルールが更新されていないと誤解することがあります。

意図しないルールに一致した場合は、まず上位に範囲の広いルールがないか確認します。次に、ドメイン名が想定した情報源から取得されたものか、最後に対象グループで現在選択されている接続先を確認してください。設定全体をグローバルモードに変えたままにするのは、恒久的な解決策にはなりません。原因がルール経路と出口のどちらにあるかを切り分けるために使い、その後、ルールモードで失敗するなら一致ログをたどって該当ルールを修正してください。モードの違いはプロキシモードの解説も参照してください。

ルールセット内の順序も重要です。メイン設定でルールセットを参照する位置によって、ほかのルールとどちらが先にマッチ判定されるかが決まります。個別の例外を管理する場合は、少数の変更頻度が低いルールを共通ルールセットより前に置き、最後に明確なフォールバックを残してください。ルールを1つ追加するたびに、既存のどのルールより先に一致するか検討しましょう。特にキーワード、地域、全ポートを対象にする条件に注意が必要です。正確なドメインで解決できるなら、ネットワーク全体やすべてのアプリに対象を広げる必要はほとんどありません。

7. プロキシプロバイダーと外部ルールセット

更新するリソースをメイン設定から分ける

proxy-providersではプロキシプロバイダーを、rule-providersではルールセットを定義します。どちらも、更新頻度の高い情報をメイン設定から分離できますが、読み込むデータの形式は異なります。完全なサブスクリプションファイルをそのままルールセットとして使ったり、ドメイン一覧をノード一覧として使ったりすることはできません。メイン設定では、リソースの場所、読み込み方法、参照方法を指定します。リソース本体にはノードまたはルールが含まれます。参照関係がそろって初めて、実際の動作に反映されます。

初めてトラブルを切り分けるときは、まずローカルファイルで形式と参照が正しいことを確認してから、リモート更新を設定しましょう。これにより、ネットワークからのダウンロード失敗と内容の解析失敗を分けて調べられます。ローカルパスはコアの作業ディレクトリやクライアントのパス制限に従って解釈され、エディターで開いている場所を基準にするとは限りません。クライアントによっては設定ファイルを専用フォルダーにコピーするため、元ファイルを変更しても自動反映されない場合があります。実行設定で最終的にどのパスが参照されているか確認してください。

# メイン設定の関連部分
proxy-providers:
  local-nodes:
    type: file
    path: ./providers/nodes.yaml

proxy-groups:
  - name: Proxy
    type: select
    use:
      - local-nodes

rule-providers:
  local-direct:
    type: file
    behavior: domain
    format: yaml
    path: ./rules/direct.yaml

rules:
  - RULE-SET,local-direct,DIRECT
  - MATCH,Proxy

プロキシプロバイダーのファイルには、独自のproxiesリストが必要です。サーバーから完全な設定ファイルが返される場合、その内容とコアの処理方法によってはプロキシプロバイダーとして読み込めることもありますが、すべてのトップレベル設定が適用されるとは限りません。プロバイダーにはノードデータだけを持たせるのが確実です。更新後にノード名が変わると、手動選択やフィルター式に影響することがあります。更新成功の表示だけで判断せず、グループの候補を再確認してください。

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

ルールセットの動作と内容を一致させる

behavior: domainはドメインデータ、ipcidrはIPアドレスの範囲、classicalは従来形式のルールに適しています。formatでは、YAMLや対応するテキスト形式、バイナリ形式など、ファイル形式を指定します。behaviorとformatは別の設定項目です。拡張子がYAMLだからといって、内容がドメインルールの形式に合っているとは限りません。解析エラーが出たら、設定名を変えるだけでなく、実際のデータを開いて確認してください。

# ./rules/direct.yaml
payload:
  - "example.org"
  - "+.example.net"

上のドメインデータには、ドメインルールセット向けの記述方法を使っています。プラス記号とドットを含む項目は、ドメインとそのサブドメインに一致させるためのものです。classicalを使う場合、データには通常、ドメインのサフィックスルールなど、ルールの種類とマッチ条件を記述します。出口のポリシーはメイン設定のRULE-SET参照部分で指定します。ポリシー付きの完全なルールをそのままデータに移すと、接続先を重複指定したり、形式エラーになったりすることがあります。変換前に必要なbehaviorを確認してください。

リモート更新はURLを指定するだけではない

HTTP形式のプロバイダーでは、通常、ダウンロードURL、保存先、更新間隔も設定します。更新間隔は秒単位です。URLから期待するリソース本文が返る必要があります。ログイン画面、アクセスに関する案内、エラー文書が返されても、ネットワーク上はダウンロード成功に見えることがありますが、その内容は解析できません。サブスクリプションURLには個人用の認証情報が含まれる場合があります。自分の設定だけに保存し、スクリーンショット、公開リポジトリ、公開の問い合わせに載せないでください。

各リソースには別々のキャッシュパスを設定し、複数のプロバイダーが同じファイルに書き込んで上書きし合うのを防いでください。リモート更新に失敗したときもキャッシュを使えるかどうかは、キャッシュの有無と有効性、クライアントの管理方法によって異なります。初めて設定を読み込む端末には古いキャッシュがないため、長期間利用している端末とは起動時の動作が違う場合があります。ある端末で一時的に使えているからといって、サブスクリプションサーバーに問題がないとは限りません。

プロキシプロバイダーのヘルスチェックは、プロバイダー内のノードに接続できるかを確認します。プロキシグループの自動選択の測定と関係はありますが、まったく同じ仕組みではありません。複数の場所で高頻度のチェックを有効にすると、測定が重複する場合があります。まず、更新を担当する層、測定を担当する層、接続先の選択を担当する層を整理してから、適切な間隔を設定してください。リモートリソースのダウンロードをプロキシ経由にするかは、起動時にプロキシノードが読み込まれる前後関係も考慮します。リソースのダウンロードに、そのリソース自身が必要になる循環を避けてください。

更新失敗を2つに分けて対処する

タイムアウト、名前解決失敗、証明書エラーがログに出ている場合は、まずリソースの取得経路を確認します。データは取得できたのに項目や内容のエラーが出る場合は、内容の形式を調べてください。後者でネットワークを何度もリセットしたり、前者でルールセットのbehaviorをむやみに変更したりしないでください。サブスクリプション取得に関する詳しい情報は、サブスクリプションの更新失敗と自動更新の設定を参照してください。修正後は再読み込みし、ダウンロードできたかだけでなく、ルールが実際に一致するかも確認します。

8. サブスクリプションの上書き、マージ、トラブル対処

配信元の設定、上書き、最終設定を区別する

サブスクリプションを更新すると通常は配信元の設定を再取得するため、サブスクリプションのキャッシュを直接編集しても、次回の更新で変更が失われることがあります。上書き機能を使うと個人設定を独立した層として保存し、クライアントが実行設定を生成するときに適用できます。この処理は主にGUIクライアント側で行われるもので、すべてのコアに共通の上書きスイッチがあるわけではありません。Clash Plus、Clash Verge Rev、FlClashを使う場合は、それぞれの設定管理画面とマージ方法を確認してください。あるクライアント向けのスクリプトを別のクライアントにそのままコピーしないでください。

よくある構成では、リモートサブスクリプションからノードと基本ルールを読み込み、クライアントが待ち受けポートやコントロールAPIなどの実行項目を追加し、個人用の上書きでDNS、ポリシー、例外ルールを調整します。適用順序はクライアントによって異なり、複数の上書きを順番に適用できる場合もあります。確認するときは、特定の編集画面に表示された内容ではなく、最終的な実行設定を基準にしてください。画面上の設定が上書きされる場合は、まず各層を整理し、最後にその項目を書き込む層を特定します。

マッピングのマージとリストの置き換えは別の動作

スカラー値は通常、新しい値で上書きされます。マッピングは再帰的にマージされる場合があり、リストは全体置換、追加、独自のルールによる処理など、クライアントによって異なる動作をします。こうした動作はYAML形式が一律に決めるものではありません。特にrules、proxies、proxy-groupsを全体置換ではなく自動追加だと思い込むと、サブスクリプションのルールやノードをすべて失うことがあります。保存前に、現在の画面が完全な設定を受け付けるのか、差分となる設定片だけを受け付けるのか確認してください。

# 上書きしたい項目を示すだけで、汎用の上書きファイル形式ではない
mode: rule
log-level: info

dns:
  enable: true
  enhanced-mode: fake-ip

profile:
  store-selected: true

上の設定片は変更内容を示すための例です。実際にそのまま貼り付けられるかは、クライアントの上書き機能の説明に従ってください。画面がdnsのマッピング全体を置き換える仕様なら、既存の上流サーバーやフィルターリストが失われる場合があります。再帰的にマージする仕様なら、指定していない項目は残ることがあります。操作後は最終的なDNSセクションを確認し、上流設定がそろっていることを確かめてください。短いサンプルをすべてのサブスクリプションに使える汎用設定とみなしたり、同じキーを重複して記述してマージを試みたりしないでください。

ルールの挿入位置を明確にする

個人ルールを追加する場合は、先頭への挿入と末尾への追加を区別してください。特定の例外ルールは通常、共通ルールより前に置き、フォールバックは最後に置きます。クライアントがリストへの追加しかできない場合、個人ドメインルールを既存のMATCHの後ろに追加しても、保存は成功しますが実行されません。クライアントが対応する先頭への挿入機能か、リスト全体の置き換え機能を使い、実行設定で実際の位置を確認してください。リストを作り直す場合は、引き続き必要な既存ルールを残します。

ノードやプロキシグループにも参照順序の制約があります。新しいルールが参照するグループは存在し、そのグループが参照するノードやプロバイダーは読み込める必要があります。ノードを削除する前に、関連する参照を削除してください。名前の変更は、表示ラベルだけでなく参照先の移行として扱います。サブスクリプションの自動更新後に接続先が見つからなくなる場合、個人ルールに古いグループ名が残っていることがあります。安定した名前の個人用グループを中間層にすると、配信元のノード名変更による影響を減らせますが、候補が有効かどうかは確認が必要です。

4段階で変更を検証する

第1段階は解析の確認です。インデント、型、重複キー、非対応項目によって起動に失敗していないかを調べます。第2段階は参照の確認です。ルールの接続先、プロキシグループの候補、プロバイダー名、リソースパスが存在するか確認します。第3段階は通信の取り込み確認です。リクエストが現在のコアに届いているか、システムプロキシのポートが一致しているか、TUNの権限やルートに問題がないか調べます。第4段階はネットワークの確認です。ノードの名前解決、リモート接続、TLS、認証、接続先サービスが順に成功するかを確認します。前の段階を飛ばさず、1段階ずつ進めてください。

設定を読み込めるのにリクエストがログにまったく表示されない場合は、まずアプリのプロキシ設定と通信の取り込み入口を確認します。リクエストはあるのにポリシーが違う場合は、ルールの順序とグループの選択を調べます。ポリシーが正しいのに接続できない場合は、ノードとDNSを確認してください。ログの時刻も重要です。古いエラーが今回の変更後も続いているとは限りません。設定を再読み込みしたら時刻を確認し、新しいテストリクエストを実行して、そのリクエストに関する記録を見てください。複数のノードを次々に切り替えてからログを読むより、原因を把握しやすくなります。

スリープ、ネットワークの切り替え、クライアントの異常終了後は、システムプロキシの設定が残っていないか、仮想ネットワークアダプターが復旧しているか、古いコアがポートを使用し続けていないかも確認してください。別のクライアントに切り替える前に、先に使っていたインスタンスを終了し、2つの通信取り込み機能が同時に動作しないようにします。OS別のインストールや権限の問題を、設定項目を何度も変更して解決しようとしないでください。再インストールが必要な場合はクライアントのダウンロードページへ。初めて接続を復旧する場合はクイックスタートガイドに戻ってください。

再現可能な変更履歴を残す

変更後は、変更前のコピー、変更の目的、検証結果を残せば十分です。すべての過去キャッシュを複製する必要はありません。問題が起きたら、まず直近の変更を元に戻して改善するか確認し、その後で1項目ずつ再適用します。トラブル対処の情報を共有する場合は、クライアント名、コアの種類、通信の取り込み方法、失敗した段階、機密情報を削除した関連設定を記載してください。サブスクリプション全体を公開しないでください。どのリクエストがどのルールに一致し、どの段階で失敗したかが分かると、「インターネットに接続できない」という説明だけの場合より原因を見つけやすくなります。