Clash設定項目

YAML構造と設定の基本

要点：設定ファイルは相互に参照するオブジェクトの集合であり、順不同の設定一覧ではありません。トップレベルの項目が待ち受け、名前解決、転送の動作を決め、ノードが接続先を提供し、プロキシグループが接続先の選択肢をまとめ、ルールがリクエストの振り分け先を指定します。見慣れない設定を読むときは、まずこの4層がそろっているかを確認し、次に名前の参照先を確かめましょう。個々の行が正しいだけでは、設定全体が想定どおり動くとは限りません。たとえば、ルールが存在しないプロキシグループを参照している場合、インデントが正しくても有効な設定にはなりません。

トップレベルのマップ、リスト、ネスト

YAMLではインデントで階層を表します。半角スペース2つに統一し、タブは使わないのがおすすめです。dns: の下にある enable はDNSの子項目なので、トップレベルの mode と同じ位置に置くと意味が変わります。ハイフンで始まるのはリスト項目です。同じノードの name、type、server は同じマップ階層に置いてください。コロンの後には通常、半角スペースが必要です。半角コロンを全角の句読点に置き換えることはできません。エディターのインデントガイドを使うと、空白を目で数えるより確実です。

# 単体で読み込める、リモートプロキシノードを含まない構造例
mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

proxies: []

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

rules:
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

この例は構造を示すもので、プロキシ機能が自動的に使えるようになるわけではありません。PROXY グループにあるのは DIRECT だけなので、接続は直接行われます。実際に使う場合は、有効なノードまたはプロキシプロバイダーをグループに追加してください。空のリスト [] は、項目がまだない状態でフィールドを定義する書き方です。フィールド自体を削除するのとは異なります。設定を少しずつ拡張するときは、読み込み可能な骨組みを保ち、一度に追加するオブジェクトの種類を1つにすれば、問題の原因を特定しやすくなります。

文字列、真偽値、名前の参照

ポートや間隔は通常、数値で指定します。スイッチには true または false を使い、日本語で「有効」とは書かないでください。ノード名やパスワード、コロンやシャープ記号を含む文字列は、解釈違いを防ぐため引用符で囲むのがおすすめです。シングルクォート内にシングルクォートを含める場合は2つ続けて書きます。ダブルクォート内ではバックスラッシュがエスケープとして扱われることがあります。Windowsのパスをコピーするときは、シングルクォートを使うと意図しないエスケープを減らせます。コメントは読みやすさのためのもので、項目の適用順には影響しません。

同じマップ内で dns や rules を重複して定義しないでください。重複キーの扱いはパーサーによって異なり、読み込みを拒否するものもあれば、後の値を残すものもあります。重複キーを統合の仕組みとして使うことはできません。プロキシ名も重複しないようにし、大文字・小文字、空白、記号を含めて正確に参照してください。ノード名を変えたらプロキシグループ内の参照も変更します。グループ名を変えた場合は、ルールの振り分け先や他のグループからの参照も更新してください。

ファイル、Profile、実行時設定

クライアントのProfileは設定元と管理情報をまとめたもので、ローカルファイルまたはリモートのサブスクリプションを参照します。サブスクリプションを更新して保存された内容が、そのままカーネルに読み込まれるとは限りません。クライアントが後からポート設定を適用したり、ルールを統合したり、スクリプトを実行したりすることがあるためです。トラブルシューティングでは、「サブスクリプションの原文」「ローカル編集用コピー」「実行時設定」を区別してください。ダウンロードキャッシュ内のファイルだけを編集すると、次回更新で変更が失われる場合があります。選択されていないProfileを変更しても、現在の接続には反映されません。

設定を保存する前に、元に戻せるコピーを作り、選択中のProfileを記録しておきましょう。一般的なテキストエディターではUTF-8で保存し、リッチテキスト形式、全角スペース、自動置換された引用符を避けてください。拡張子はクライアントによるファイル判別に役立ちますが、拡張子を .yaml に変えても、Webページが設定ファイルに変換されるわけではありません。インポート後にHTML、ログイン案内、サブスクリプションの利用量が表示された場合は、インデントを調整する前に取得元を確認してください。複数の設定の切り替えや保存については、Profileと複数設定の管理をご覧ください。

ポート、待ち受けアドレス、トラフィックの入口

要点：待ち受けポートは接続口を用意するだけで、すべてのアプリの通信が自動的にプロキシ経由になるわけではありません。アプリがその接続口を使うか、システムプロキシや透過転送などで通信をカーネルに送る必要があります。よく使われる mixed-port は、同じポートでHTTPとSOCKSのプロキシ接続を受け付けるため、デスクトップアプリの設定をまとめるのに便利です。port と socks-port はHTTPとSOCKSの接続口を別々に作ります。入口を分ける必要がある場合に限って有効にし、追跡しにくい待ち受けを増やさないようにしましょう。

ポートの選び方と使用中かどうかの確認

mixed-port: 7890
allow-lan: false
bind-address: 127.0.0.1
mode: rule

この例はローカルからの接続のみ許可するため、単一の端末で使い始める場合に適しています。ポート番号は性能を示す値でも、ノード側のサーバーポートでもありません。ローカルの待ち受けポートを変更したら、ブラウザー、ターミナル、手動でプロキシを設定しているアプリも合わせて変更してください。同じポートを複数の待ち受け項目に割り当てたり、2つのプロキシクライアントで同じアドレスとポートを使ったりしないでください。カーネルにアドレスの競合を指摘された場合は、古いプロセスを終了するか待ち受け設定を変更してから再読み込みします。ノードを何度切り替えても、ローカルのバインドエラーは解消しません。

Windowsでは Get-NetTCPConnection -LocalPort 7890 で該当するTCPの待ち受けを確認できます。Linuxでは ss -lntp、macOSでは lsof -nP -iTCP:7890 -sTCP:LISTEN を使います。プロセス情報の表示には、より高い権限が必要な場合があります。結果を確認するときはアドレス、ポート、プロセスを併せて見てください。ポート番号が一致するだけでプロキシが動作中だと判断しないようにしましょう。ループバックアドレスで待ち受けているサービスには、別の端末から直接接続できません。

ローカルプロキシとLAN共有

同じLAN内の別の端末から使う場合は、接続範囲を理解したうえで allow-lan を有効にし、待ち受けアドレスが該当インターフェースを含むように設定してください。接続する端末には、クライアントを実行しているPCのLANアドレスを指定します。接続側端末自身の 127.0.0.1 ではありません。PCのファイアウォール、無線アクセスポイントの端末間通信の遮断、異なるサブネット間のルーティングも到達性に影響します。まずローカルの入口から接続できることを確認し、その後LAN内の別端末から試すと、カーネルの問題とネットワーク分離を切り分けられます。

プロキシ認証とノード認証は別のものです。前者はローカルの入口を使える人を制限し、後者はリモートサービスへの接続に使います。入口の認証を有効にしたら、接続するアプリも対応していることを確認し、ユーザー名とパスワードを設定してください。システムプロキシの画面では必要な情報をすべて指定できない場合があるため、アプリ側のプロキシ設定が必要になることがあります。共有できない場合でも、トラブルシューティングのためにファイアウォールを長時間すべて無効にしないでください。必要なインターフェース、接続元アドレス、ポートだけを確認しましょう。

システムプロキシ、ターミナル、TUNの違い

システムプロキシは、通常、システム設定に従うアプリへ接続先を知らせるだけで、すべてのプログラムがその設定を参照するとは限りません。コマンドラインツールでは、環境変数や独自の引数が必要なことがあります。下のコマンドでHTTPプロキシを明示すると、環境変数の設定漏れをカーネルの問題と取り違えずに確認できます。テストが成功しても、指定した入口からそのリクエストを送信できたことを示すだけです。他のアプリも接続されていることや、すべてのドメインが正しく振り分けられることを保証するものではありません。

curl --proxy http://127.0.0.1:7890 https://example.com/

TUNは仮想ネットワークインターフェースを使う入口で、システム権限、ルーティング、DNSの引き継ぎ、既存のネットワークソフトウェアが関係します。通常の待ち受けポートを開いた後に必ず必要となる機能ではありません。アプリがプロキシに対応していない場合や、より広範囲の通信を取り込む必要がある場合に、クライアントのドキュメントに従って有効にしてください。システムプロキシは動作するのにターミナルで失敗する場合は、ブラウザーとコマンドラインを分けて確認する方法をご覧ください。クライアントを選ぶ際は、まずダウンロードページからClash Plusを確認し、プラットフォームや必要な機能に応じて他のクライアントと比較してください。

プロキシモード、ログ、管理インターフェース

要点：mode は転送先の選び方を決める項目であり、ノードを作成したりアプリの通信を取り込んだりするものではありません。ルールモードはルール一覧を参照し、グローバルモードはグローバルポリシーの選択肢を使い、ダイレクトモードは宛先に直接接続します。モードを切り替える前に、通信がカーネルに届いていることと、利用できるポリシーがあることを確認してください。グローバルモードに変更しても、待ち受けの失敗、空のサブスクリプション、リモートサーバーへの接続不能は直りません。ルール選択の経路が原因かどうかを見分ける手がかりになるだけです。

rule・global・direct

mode: rule
log-level: info
ipv6: false

rule は、ドメイン、アドレス、アプリの用途に応じて長期的に通信を振り分ける場合に適しています。global は通常のルール選択を使わず、グローバルポリシーで選択中の項目に従います。そのため、クライアントのグローバルグループで何が選ばれているかも確認してください。直結が選択されていれば、グローバルモードにしてもプロキシ接続にはなりません。direct は、プロキシを経由しない接続との比較に使えます。どのモードもシステム側の入口設定の代わりにはなりません。カーネルに届いていないアプリは、モードを変えても通信経路が変わりません。

テストでは一度に変更する条件を1つにしましょう。たとえば、あるWebサイトに接続できない場合は、ノードとDNSを変えずにルールモードからグローバルモードに切り替え、再接続します。グローバルモードでは接続できてルールモードでは失敗するなら、ルールの一致状況と振り分け先を確認します。どちらも失敗するなら、ノードと名前解決を調べましょう。ノード、モード、DNSを同時に変更して直ったとしても、原因を特定できません。既存の接続は以前の出口を使い続ける場合があるため、テストでは古い接続を閉じてから確認してください。

log-levelを使った原因の調べ方

info は、日常的に必要な実行情報を残す場合に適しています。個々のリクエストを追跡するときは、短時間だけ debug に切り替えてください。warning、error の順に出力が少なくなり、silent では原因を調べる手がかりがほとんど残りません。ログレベルを変えてもノードの速度は上がらず、詳細ログは出力の負荷を増やすことがあります。再現可能な操作をしばらく観察したら通常のレベルに戻し、不要なログを長期間ため込まないようにしましょう。

ログは処理段階ごとに分類して読みましょう。設定の解析段階のエラーはファイル内容、待ち受け段階の失敗はローカルアドレスや権限を示します。リクエストが入った後の名前解決エラーならDNS経路、ダイヤルやハンドシェイクの失敗なら接続先の出口やプロトコル設定を確認します。同じタイムアウトでも、DNS問い合わせ、TCP接続、TLSハンドシェイクのどこで起きたかによって調べる対象は異なります。英語のエラーメッセージを1つ見ただけで、関係のない項目までまとめて置き換えないでください。

再現条件を記録するには、使用中のProfile、モード、一致したルール、選択中のポリシー、同じ時刻付近のエラーを含めます。ログを共有する前に、サブスクリプションURL、認証情報、個人用ドメイン、LAN構成などの機密情報を削除してください。ログの読み方は実行ログとよくあるエラーの見方で詳しく解説しています。対象リクエストがログにない場合は、実行されていないルールを調べ続けるのではなく、まず入口を確認しましょう。

管理インターフェースはプロキシ入口ではありません

external-controller はクライアントやパネルからカーネルを管理するための項目です。状態の確認、ポリシーの切り替え、一部の実行設定の変更などに使えますが、ブラウザーのHTTPプロキシとして指定するものではありません。デスクトップクライアントは通常、このインターフェースとアクセス情報を自動管理するため、サブスクリプションからむやみに上書きしないでください。カーネルを手動で実行する場合は、まずループバックアドレスで待ち受けます。遠隔管理が必要なら、認証とネットワーク上のアクセス制限を設定し、管理ポートを通常のLAN共有ポートとして公開しないでください。

トップレベルの ipv6 はカーネルでIPv6を使う動作に影響し、DNS配下にある同名の項目は名前解決の設定です。片方だけを変更してネットワーク全体の結果を判断することはできません。有効にするかどうかは、ローカルネットワーク、プロキシサービス、アプリの要件を踏まえて決めてください。IPv6を無効にすることを常に最適な設定と考えるべきではありません。特定のアドレス種別だけで失敗する場合は、名前解決の結果と実際の接続経路を別々に確認し、該当する階層の項目を調整します。

DNS、Fake-IP、名前解決の経路

要点：DNS設定では、アプリの問い合わせ、カーネルによる名前解決、ノードのホスト名解決が関係します。サーバーアドレスを1つ見るだけでは十分ではありません。アプリがシステムDNSを使う場合もあれば、独自に暗号化DNSで問い合わせる場合もあります。カーネルも接続先やノードの名前解決を行うことがあります。そのため、nameserver を変更しても、すべての問い合わせがその一覧を通るとは限りません。まず、どこでリクエストが発生し、誰が受け取り、結果を誰が使うのかを確認してから、待ち受け、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
  nameserver:
    - https://dns.alidns.com/dns-query
  fake-ip-filter:
    - "*.lan"
    - "*.local"

この設定例はローカルDNSの待ち受けを作りますが、システムDNSを自動で変更するものではありません。一般的なシステムDNS設定では、標準外のポートを指定できません。そのため、システムのDNSアドレスをループバックに変えるだけで、問い合わせが自動的に 1053 番ポートへ届くわけではありません。クライアントのDNS引き継ぎ、TUNの関連機能、または明示的な転送の仕組みが必要です。端末上ですでにDNSサービスが動いている場合は、アドレスとポートの競合を確認してください。上流DNSに接続できない問題と、読み込みエラーを混同しないようにしましょう。

default-nameserver は、DNSサービス自体のホスト名を解決するために使えます。ホスト名の解決にDNSが必要になる問題を避けるため、通常は直接接続できるIPアドレスを指定します。nameserver は主要な上流サーバーの一覧です。利用できるかどうかは、ネットワークの接続性と対応する出方向の設定に左右されます。暗号化DNSを使うと問い合わせの転送方式を変えられますが、問い合わせが必ずプロキシを経由することや、現在のネットワークからリモートサービスに接続できることを保証するものではありません。上流サーバーを増やせば結果が正確になるとは限らないため、まず検証しやすい構成を使いましょう。

fake-ipとredir-hostの違い

fake-ip は問い合わせに合成アドレスを割り当て、ドメイン名とアドレスの対応を保持します。合成アドレスへの接続時にドメイン名を復元して処理するため、ドメイン情報を維持しやすくなります。ただし、DNS問い合わせと後続の通信が同じ処理経路に入る必要があります。合成アドレスを受け取ったアプリがカーネルを経由せず直接接続すると、通常は接続できません。redir-host は実際の名前解決結果を返す方式です。両者は単純な速度切り替えではなく、互換性や処理経路が異なります。

fake-ip-filter は、指定したドメインを合成アドレスの処理から除外します。LAN内サービスの検出や、実際のアドレスとの対応が必要なアプリに利用できます。例にあるLAN用のサフィックスは出発点にすぎず、あらゆる環境に対応した完全な一覧ではありません。ドメインをフィルターに追加しても、直結ルールが自動で追加されたり、適切なLAN DNSが自動で指定されたりすることはありません。プリンター、内部ドメイン、ローカルサービスで問題が起きた場合は、名前解決元、応答アドレス、接続ルートを併せて確認してください。フィルター範囲を広げただけで調査を終えないようにしましょう。

ドメインごとの上流選択とDNSループの防止

nameserver-policy を使うと、特定のドメインに使用する上流サーバーを指定できます。たとえば、内部ドメインをLAN内のDNSサーバーに問い合わせられます。ポリシーキーの構文はカーネルの対応範囲に合わせてください。通常のルール表現をそのまま使える2つ目の rules ではありません。proxy-server-nameserver はプロキシノードのドメイン名解決に使い、出口の確立に必要な基本的な名前解決を個別に管理できます。ノードのサーバー名を解決できなければ、接続先Webサイトの名前解決が正しくてもプロキシ接続は確立できません。

respect-rules など、振り分けルールでDNSの出方向を決めるオプションを有効にする前に、ノードのホスト名を解決する独立した経路を設計してください。DNS問い合わせにプロキシが必要で、そのプロキシの接続にも同じDNS問い合わせが必要だと、ループが発生する場合があります。ルールに沿った出方向の選択、複数の上流、複雑なフィルター、多段のフォールバックを一度に導入しないでください。まず基本の上流に接続できることを確認し、その後で制約を1つずつ追加します。ログで名前解決と接続の各段階が順につながっているかを確認してください。

fallback と関連するフィルター設定は、常に有効な予備ボタンというわけではありません。どの結果を選ぶかはフィルター条件の影響を受けます。他のネットワークのIP範囲や地域設定をそのままコピーすると、想定外の名前解決になることがあります。トラブルシューティングでは、問い合わせたドメイン、応答アドレス、使用した上流、接続先のポリシーを記録してください。一部のアプリだけが失敗する場合は、アプリ内蔵のDNSがシステム設定を迂回していないかも確認します。具体的な症状への簡潔な回答はFAQをご覧ください。DNSのオプションをすべて同時に有効にするのは避けましょう。

プロキシノードの項目とプロキシプロバイダー

要点：ノードの各項目はサービス提供元のプロトコル設定と一致させてください。名前が似ていても、相互に置き換えられるとは限りません。proxies はノードオブジェクトのリストです。共通項目には名前、タイプ、サーバーアドレス、ポートなどがあります。認証、暗号化、トランスポート、TLS関連の項目はプロトコルによって異なります。サブスクリプションをインポートできても、それはクライアントが設定の構造を受け付けたことを示すだけです。サーバーに到達できることや、認証とハンドシェイクの設定が正しいことまでは確認できません。

共通項目とプロトコル固有の項目

# 構造例：example.comと認証情報は項目の説明用です
proxies:
  - name: サンプル出口
    type: socks5
    server: proxy.example.com
    port: 1080
    username: "your-username"
    password: "your-password"
    udp: true

proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - サンプル出口
      - DIRECT

この例は、SOCKS5ノードをプロキシグループから参照する方法を示すもので、実際に使えるプロキシサービスは提供しません。name はローカルで使う識別名です。変更してもサーバーには影響しませんが、他の項目からの参照には影響します。server はリモートアドレス、port はサーバー側の待ち受けポートです。ローカルの mixed-port で代用することはできません。ユーザー名とパスワードは実際のサービス設定に合わせてください。サーバーがその認証方式を使わない場合は、項目を埋めるためだけに追加しないでください。

type によって、後続の項目の解釈方法が決まります。Shadowsocksの暗号化方式とパスワード、VMessやVLESSのユーザー識別子、Trojanの認証とTLS、その他のプロトコルのトランスポート設定には、それぞれ異なる要件があります。互換性を期待して、異なるプロトコルの項目を1つのノードに混在させないでください。未対応の項目がある場合は、使用中のカーネルが該当プロトコルと項目に対応しているかを確認してから、サブスクリプションの形式を調べましょう。エラーの項目をすべて削除するのは避けてください。必要なトランスポート項目を削除すると、設定を読み込めても接続できなくなることがあります。

TLS、トランスポート層、UDP

TLSを使うノードには、サーバー名、ALPN（アプリケーション層プロトコルネゴシエーション）、証明書関連の設定が含まれる場合があります。サーバー名は通常、ハンドシェイクと証明書の検証に使われ、接続先アドレスと同じとは限りません。接続先アドレス、TLSのサーバー名、WebSocketリクエストヘッダーのHostは、それぞれ異なる役割を持つ場合があります。サービス提供元の指定に従って設定してください。アクセスできるWebサイトのドメインをこれらの項目に適当に入力しないでください。ドメイン名が正しく見えても、該当サーバーがハンドシェイクを受け付けるとは限りません。

証明書の検証に失敗した場合は、システム時刻、サーバー名、証明書の有効性、サーバー設定を確認してください。検証を省略すると相手の身元を確認しにくくなるため、一般的な修正方法として常時有効にするべきではありません。WebSocketやgRPCなどのトランスポートでは、パス、サービス名、リクエストヘッダーなども一致させる必要があります。いずれかが異なると、接続が切断されることがあります。調査時はサービス提供元の元の設定を比較用に保存し、クライアント画面に表示されるノード名だけを見比べないようにしましょう。

udp: true は該当ノードでUDPを利用できるようにする項目であり、UDP非対応のサーバーに機能を追加するものではありません。アプリの入口、プロキシグループ、ノードのプロトコル、リモートサービスまでの経路全体が必要な通信に対応していることも確認してください。Webページは開くのにゲームや音声通話が失敗する場合は、まずTCPとUDPを切り分けましょう。HTTPのテストが1回成功しても、すべてのアプリで使えるとは限りません。反対に、UDPが使えなくても通常のHTTPSリクエストが必ず失敗するわけではありません。

proxy-providersとサブスクリプション全体の違い

# プロバイダー設定例：ローカルファイルは事前に用意し、proxiesリストを含めてください
proxy-providers:
  local-nodes:
    type: file
    path: ./providers/local-nodes.yaml

proxy-groups:
  - name: PROXY
    type: select
    use:
      - local-nodes
    proxies:
      - DIRECT

proxy-providers はノードの取得元を独立させる仕組みです。プロキシグループから use でプロバイダーを参照し、プロバイダー名を通常のノード一覧に入れるわけではありません。ファイルを使う場合は、ファイルが存在し、内容がプロバイダー形式に合っている必要があります。ネットワークから取得する場合は、URL、保存先、更新設定も正しく指定してください。一般的なProfileにはDNS、ルール、プロキシグループも含まれるため、サブスクリプション全体をノードだけのプロバイダーファイルとして使えるとは限りません。取得元が対応する出力形式を確認してください。

プロバイダーから取得できることと、取得したノードに接続できることは別々に確認します。前者はダウンロード経路と内容の形式、後者はプロトコルと接続先に左右されます。ログインページ、エラーテキスト、空のリストが返された場合は、サブスクリプションの認証、利用期限、応答内容をまず確認してください。サブスクリプションURLにアクセス情報が含まれる場合があるため、公開ログやオンライン変換ツールに貼り付けないでください。すべてのノードで接続に失敗する場合は、サブスクリプションから出口までの段階的な確認手順に沿って原因を切り分けましょう。

クライアントが特定のノード項目を編集できるかどうかと、カーネルがその項目に対応しているかどうかは別の問題です。Clash Plus、Clash Verge Rev、FlClashなどを選ぶ際は、現在使用しているカーネルとインポート機能も確認してください。画面に表示されない項目が無効とは限らず、画面から入力できてもサーバーが受け付けるとは限りません。ノードを管理するときは、信頼できる取得元の元の設定を保ち、ポリシーやルールのカスタマイズは外側で行うと、認証情報を手作業で書き換えるリスクを減らせます。

プロキシグループ、自動選択、参照関係

要点：プロキシグループは出口を選ぶ仕組みです。ルールでグループを指定した後も、実際のノードはグループ内で選択中の項目によって決まります。proxy-groups は複数のノード、他のグループ、プロバイダーをまとめます。設定を設計する際は、手動で出口を固定したいのか、自動選択したいのか、障害時に切り替えたいのかなど、必要な判断を先に整理してからグループのタイプを選びましょう。すべてのタイプを詰め込んでも信頼性は自動的に高まりません。むしろ実際の出口が分かりにくくなります。

selectとネストしたポリシー

# 直結グループは読み込み可能な構造を示す例です。必要に応じて実際のノードを追加してください
proxy-groups:
  - name: 手動選択
    type: select
    proxies:
      - DIRECT

  - name: PROXY
    type: select
    proxies:
      - 手動選択
      - DIRECT

rules:
  - MATCH,PROXY

select はユーザーまたは管理インターフェースで現在の選択肢を決める方式で、出口を固定したいアプリに向いています。この例ではルールからまず PROXY に進み、次に「手動選択」を経て、最終的に DIRECT に到達する可能性があります。実際の接続では、この参照経路をたどってください。グループ名は識別用であり、動作を保証するものではありません。名前が「自動」でも、タイプが select のままなら、ノードを自動測定して選ぶことはありません。

グループの参照が循環しないようにしてください。たとえば、AグループがBグループを参照し、BグループがAグループを参照する形です。名前は用途と取得元を区別すると管理しやすくなります。用途別のグループには仕事、メディア、既定の出口などを設定し、取得元別のグループはプロバイダーごとに分けられます。こうすれば、サブスクリプションのノードが更新されても、すべてのルールを変更せずに済みます。グループ階層は深くしすぎず、少ない段数で最終的な出口を説明できるようにしましょう。深くなると、画面上では選択した名前しか見えず、実際の経路を知るために何段も展開しなければなりません。

url-test、fallback、load-balance

url-test はテスト結果に基づいて候補の出口を選び、自動切り替えを利用したい場合に適しています。fallback は候補の順序と利用可能かどうかを重視し、優先する出口を使い、失敗時に次へ切り替えたい場合に向いています。load-balance はポリシーに応じて接続を複数の候補に振り分ける仕組みで、1つのダウンロード接続の帯域を合算するものではありません。ログイン、決済、セッションなど、接続元のIPアドレスを安定させたい用途では、出口が変わる可能性のあるグループを慎重に使ってください。

# 例：local-nodesプロバイダーはproxy-providersで定義済みである必要があります
proxy-groups:
  - name: 自動選択
    type: url-test
    use:
      - local-nodes
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50

この例の interval はテスト間隔、tolerance はわずかな差による頻繁な切り替えを抑えるための値です。どちらもノードの速度測定値ではありません。テスト先には現在のネットワークと出口から安定して接続でき、接続テストに適した応答を返すアドレスを指定してください。特定のアドレスへのテストが失敗しても、テスト先の制限が原因で、ノードがすべての接続先で使えないとは限りません。実際のアプリのリクエストと照らし合わせ、1つのテスト結果だけですべての用途のポリシーを決めないようにしましょう。

候補一覧、フィルター、テストの注意点

proxies にはノード名またはプロキシグループ名を指定し、use ではノードプロバイダーを参照します。両方を組み合わせることもできますが、候補の重複や空のリストに注意してください。filter などで名前を絞り込む場合は、正規表現がプロバイダー名ではなく実際のノード名に一致することを確認します。サブスクリプション側でノード名が変更されると、以前は一致していたフィルターが空になることがあります。自動グループにノードが表示されない場合は、まずプロバイダーの内容、次にフィルターの結果を確認し、その後にテスト設定を調べてください。

ヘルスチェックで確認できるのは、指定したテスト先へのリクエストが条件どおり完了するかどうかです。すべてのプロトコルや接続先に対するノードの総合評価ではありません。頻繁に並行してテストすると余計な接続が発生します。モバイル回線、省電力端末、通信量に制限のあるサービスでは特に注意してください。プロバイダーとプロキシグループの両方でチェックを設定している場合は、重複してテストされていないか確認します。利用可否の判断に必要な頻度を保ち、画面の数値を更新し続けるためだけに間隔を短くしないでください。

ルールの振り分け先に使う用途別グループは、なるべく安定させ、ノードの切り替えはグループ内で行いましょう。同じWebサイトで出口が変わる場合は、自動グループの切り替え、アプリが作る複数接続、ドメインごとのルール経路を先に確認し、その後でサーバー側の問題を調べます。出口を長時間固定したい作業には、日常的な自動選択と分けて手動グループを作るとよいでしょう。各クライアントのグループ選択画面は、クライアント選びのガイドでプラットフォームの要件と合わせて比較できます。

ルール構文、一致順、ルールセット

要点：ルールはリストの上から順に処理され、最初に一致した項目で振り分け先が決まります。文字列の長さで優先度が自動的に決まるわけではありません。rules を編集するときは、具体的な例外を一般的なルールより前に置き、最後にフォールバックルールを配置してください。ルールを追加する前に、ドメイン、宛先アドレス、送信元アドレス、プロセスのどの情報に一致させるのかを明確にしましょう。利用できる情報は入口やシステム環境によって異なり、すべての接続で完全なドメイン名やプロセス名を取得できるとは限りません。

ドメインルールと振り分け先

# 例：PROXYプロキシグループは事前に定義しておく必要があります
rules:
  - DOMAIN,login.example.com,PROXY
  - DOMAIN-SUFFIX,example.com,PROXY
  - DOMAIN-KEYWORD,internal,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,PROXY

DOMAIN は完全一致のドメイン名、DOMAIN-SUFFIX はドメインのサフィックスと該当するサブドメイン、DOMAIN-KEYWORD はドメイン名に含まれるキーワードで照合します。キーワードルールは通常、対象範囲が広く、関係のないドメインまで一致するおそれがあります。特定の対象に絞りたい場合は、完全一致またはサフィックスを優先してください。値には https://、パス、ポートを含めないでください。これらはURLの他の部分であり、ドメインルールが照合する値ではありません。

ルールの最後の項目には振り分け先を指定します。組み込みのアクション、定義済みのノード、プロキシグループを指定できます。安定して管理するには、サブスクリプション更新で名前が変わる可能性のあるノードではなく、用途別グループを振り分け先にするのが一般的です。DIRECT は直接接続、REJECT はリクエストの拒否を表します。ポリシー名は定義と完全に一致させてください。グループ名の間違いは「ルールに一致しない」のではなく、設定の参照関係に問題があります。読み込み時に修正してください。

アドレス照合とno-resolve

IP-CIDR はIPv4ネットワークに一致し、IPv6ネットワークには対応する IP-CIDR6 を使います。リクエストがドメイン名で届き、ルールの判定に実際のアドレスが必要な場合、カーネルが名前解決を行うことがあります。末尾の no-resolve は、このアドレスルールのためにドメイン名を能動的に解決しないようにする項目です。すでに宛先アドレスがある接続の照合を妨げるものでも、DNSを全体的に無効にするものでもありません。すべてのアドレスルールに機械的に付けると、従来の振り分け結果が変わる場合があります。

GEOIP はアドレスデータベースに基づいて分類するため、結果はデータベースの内容と更新状況に左右されます。ドメイン分類によく使われる GEOSITE には、対応するデータとカーネルのサポートが必要です。例にある地域別の直結ルールは書き方を示すもので、あらゆるネットワークに適した既定のポリシーではありません。データベースの分類はサービスの実際の所在地を示すものではなく、宛先への接続を保証するものでもありません。企業ネットワーク、地域をまたぐサービス、自前のアドレスについては、単一の分類に頼らず実際の用途に合わせて例外を設定してください。

rule-providersとRULE-SET

# ファイルは事前に用意し、内容の形式をbehaviorに合わせてください
rule-providers:
  local-domains:
    type: file
    behavior: domain
    format: yaml
    path: ./rules/local-domains.yaml

rules:
  - RULE-SET,local-domains,DIRECT
  - MATCH,PROXY

ルールプロバイダーを使うと、更新可能な照合条件を独立したファイルに置き、メイン設定から RULE-SET で参照できます。behavior は内容がドメイン、アドレス範囲、従来形式のルール表現のどれかを指定します。ファイルの拡張子だけで形式を判断しないでください。YAML形式のドメインプロバイダーでは、通常 payload の下にドメインの照合項目を並べます。従来形式のルールセットには対応するルール表現を記述し、メイン設定で指定する振り分け先を各行に重ねて書くわけではありません。

ルールセットのファイルをダウンロードできても、形式とbehaviorが一致しているか確認が必要です。単なるドメイン一覧をYAMLとして読み込んだり、通常のルール一覧をドメイン用behaviorで解析したりすると、エラーや想定外の結果になります。ネットワーク上のルール取得元では、更新先に接続できるか、キャッシュファイルに書き込めるかも確認してください。更新に失敗した場合は、使用可能なキャッシュを残して取得の問題を調べましょう。すでに正常な他の設定まで失わないよう、メイン設定全体をすぐに初期化しないでください。

接続履歴からルールをたどる

新しいルールを検証するときは新規接続を発生させ、リクエストのドメイン名、一致したルール、最終的なポリシーを記録してください。ブラウザーのページは、メインドメインに加えてログイン、静的リソース、APIなどにも同時に接続することがあります。ページの一部だけ表示される場合は、それぞれの接続を調べてください。アドレスバーのドメインにルールを1つ追加するだけでは解決しない場合があります。接続先がIPアドレスだけで記録される場合は、アプリが独自に名前解決していないか、DNSがカーネルに届いているか、現在の入口でドメイン情報が保持されているかを確認します。

プロセスルールはプラットフォーム、権限、入口の影響も受けます。同じ設定でも端末が変わると、同じプロセス情報を取得できない場合があります。複数のプラットフォームで使う唯一の判定方法にしないでください。順に調べる際は、最初に一致する可能性のあるルールを探し、次にグループ内の選択を確認し、最後に出口を検証します。ルールモードで失敗してグローバルモードでは動く場合は、広範囲なキーワードルールをまとめて追加するより、この経路を調べるほうが確実です。一時的な例外で動作を確認できたら、対象範囲を絞り、用途を記録してください。

サブスクリプションの上書き、設定の統合、読み込み検証

要点：継続して使うカスタマイズは、リモート更新で置き換わるサブスクリプションの原文から分離し、最終的な実行時設定で検証してください。クライアントには上書き、統合、追加設定、スクリプトなどの機能がありますが、これらはクライアント独自の設定生成方法であり、すべてのクライアントに共通するYAML仕様ではありません。別のクライアントへ移行する際は、適用順と統合方法を改めて確認してください。「上書き」という名前のファイルをコピーするだけで、同じ結果になるとは限りません。

スカラー、マップ、リストで異なる統合方法

mode、mixed-port のようなスカラー項目は、通常、後から書き込まれた値が前の値を上書きします。dns のようなマップは、項目ごとに統合される場合と全体が置き換わる場合があります。rules や proxies のようなリストは、置換、先頭への挿入、追加など動作が異なります。実際の動作はクライアントの説明と生成結果を確認してください。「統合」機能があるというだけでは、既存のノードやルールが保持されるか判断できません。

# 概念例：ルールを先頭に追加できるクライアントの上書き機能を想定
# 2つ目のトップレベルrulesとして直接追加しないでください
rules:
  - DOMAIN,work.example.com,DIRECT

クライアントがこの内容で既存のルール全体を置き換えると、サブスクリプションのルールがすべて削除される可能性があります。既存の MATCH の後ろに追加した場合は、ルールが一度も適用されないことがあります。クライアントが対応する先頭挿入機能を使うか、スクリプトで順序を明示し、最終的なリストを確認してください。DNSの統合も同様です。上流サーバーの一覧を変更するときは他の子項目が保持されるか確認し、1つのアドレスを変えただけで待ち受けやモード設定まで消さないようにしましょう。

書き込み順と名前の安定性を確認する

簡単な設定元の記録を作りましょう。サブスクリプションがどのノードとルールを提供するか、クライアントの全体設定がどのポートを管理するか、上書きがどのDNS設定や例外を追加するか、スクリプトがプロキシグループを変更するかを記録します。同じ項目を複数の機能で変更している場合は、できるだけ1か所に集約してください。実行モードが戻る、保存後にポートが変わる、更新のたびにルールが消えるといった場合、エディターが保存できていないのではなく、後続の生成処理が前の変更を上書きしていることがあります。

カスタムルールが参照するプロキシグループには、安定した名前を使い、サブスクリプションの更新後も生成されることを確認してください。カスタムグループが特定のノードを直接参照していて、サービス提供元が定期的に名前を変更すると、更新後に候補がなくなることがあります。固定の用途別グループを介して、プロバイダーやクライアントのノード一覧につなぐ方法がより安定します。スクリプトを変更する前には、対象項目のデータ型も確認してください。すべてのサブスクリプションに同じリスト構造があるとは限りません。必要なオブジェクトがない場合は、半端な設定を生成せず、原因が分かるエラーを返すようにしましょう。

構文チェック、読み込みチェック、実際の接続

# mihomoのコマンドライン版をインストールした環境向け
mihomo -t -f ./config.yaml

コマンドラインでのテストでは、設定の解析や初期化の問題を確認できます。作業ディレクトリ、リソースのパス、実行権限は実際の起動環境にできるだけ合わせてください。参照しているプロバイダーファイル、地域データベース、その他のリソースが存在しない場合、YAMLの構文が正しくても読み込みに失敗することがあります。デスクトップクライアントでは、別のカーネルプログラムの結果を現在の環境に当てはめず、まずクライアント内の設定チェック機能を使ってください。チェックに合格しても読み込み可能な状態だと分かるだけで、リモートノードへの接続までは保証されません。

完全な検証は3段階で行います。まず設定が選択され、正常に読み込まれていることを確認します。次に入口が待ち受け、アプリのリクエストが届いていることを確認します。最後にDNS、ルール、グループの選択、リモートとのハンドシェイクを調べます。各段階で再現可能なリクエストを1つ用意して比較してください。変更後も既存の接続だけが古い経路を使う場合は、接続を新しく作り直します。新しいリクエストが一切記録されない場合は入口に戻り、正しいポリシーが記録されているのにハンドシェイクで失敗する場合は、ノードの項目とサーバーの状態を確認しましょう。

よくある失敗からの切り戻し手順

設定がすぐエラーになる場合は、最後の変更を元に戻し、インデント、重複キー、参照先の不足、項目の型を確認します。読み込めても接続できない場合は、まず直結とプロキシ指定のリクエストを比較し、実際に一致したポリシーを確認してください。設定の問題と接続の問題を混同しないようにしましょう。自動更新後にだけ失敗する場合は、更新前後のノード名、プロバイダーの形式、ルールの振り分け先を比較します。特定のクライアントでしか再現しない場合は、上書きの適用順、カーネルの機能、システム権限を確認してください。

復旧したら、例外が必要な通信の種類、特定のDNS経路を使う理由、ルールの前後関係など、成功条件をコメントや管理記録に残してください。実際の認証情報は記録せず、一時的な回避策を恒久的な既定設定にしないでください。初めて使う場合は、入門ガイドに沿って接続経路を一通り確認しましょう。画面操作の問題はFAQで確認できます。クライアントを変更する場合はクライアントのプラットフォーム別ダウンロードから選び、新しい環境で動作を確認するまで元の設定を残してください。