Clash設定項目リファレンス

YAML構造の概要

Clashの設定は、互いに無関係なスイッチの集まりではなく、相互参照する項目で構成されています。共通設定がコアの接続待ち受け方法を決め、DNSがドメインの名前解決を行い、ノードが接続先を提供し、プロキシグループが接続先をまとめ、ルールがリクエストをグループへ振り分けます。すべてのキー名を暗記するより、この流れを理解することが大切です。トラブル対処も同じ順序で進めましょう。まずリクエストがコアに届いているかを確認し、次にルールの振り分け先、最後に選択中のノードを調べます。

まず階層を確認し、次に項目を読む

YAMLではインデントで親子関係を表します。トップレベルのdns、proxies、proxy-groups、rulesは同じ階層です。nameserverはDNSの項目なので、インデントを下げます。リストのハイフンは新しい項目を示すもので、飾りではありません。半角スペース2つに統一し、タブは使わないでください。エディター上で揃って見えても、実際の文字が同じとは限りません。Webページからコピーした場合は、行頭に全角スペースが混ざっていないかも確認しましょう。

以下は、直結の出口だけを含む構造サンプルです。設定の読み込み、待ち受けポート、ポリシーの参照関係を確認するために使えます。ただし、この設定だけでプロキシサービスが利用できるわけではなく、サービス提供元から渡された接続情報の代わりにもなりません。まず小さな設定を検証し、問題がなければノードやルールを少しずつ追加しましょう。出所の異なる設定を一度に大量に組み合わせるより、原因を特定しやすくなります。

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

dns:
  enable: false

proxies: []

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

rules:
  - MATCH,PROXY

文字列・リスト・参照関係

ノード名とプロキシグループ名は、文字列による参照に使われます。ルールにPROXYと書いた場合、設定内に同じ名前のプロキシグループまたは出口が必要です。似た名前でも別物として扱われ、大文字・小文字、空白、句読点も照合に影響します。短く変更されにくい名前を使い、変動する通信量の表示や日付を参照名にしないようにしましょう。ノード名を変更したら、プロキシグループの候補一覧と、そのノードを直接参照するルールも併せて確認してください。構文に問題がなくても、参照関係の検証に失敗することがあります。

真偽値は通常trueまたはfalse、ポート番号や間隔は数値で指定します。パスワードなどの文字列は引用符で囲むのがおすすめです。コロンと空白、シャープ記号、角括弧などを含む文字列は、特に明示的に引用してください。引用符は機密情報を隠すものではなく、データ型を明確にするためのものです。キーと値の区切りに全角コロンを使わないでください。日本語入力で入力した引用符も、YAMLで必要な半角の引用符とは異なる場合があります。

同じ階層で同じキーを重複して宣言しないでください。たとえば、先にDNS設定を書いたあと、ファイル末尾にdns:を貼り付けても、2つの設定が自動で統合されるわけではありません。パーサーによっては重複キーを拒否し、後の値だけを残す場合もあります。どちらの動作も前提にしないでください。DNSサーバーを追加する場合は、元のリストを編集します。クライアントによる設定マージが必要なら、明示的な上書き機能を使い、最終的に生成された内容を確認してください。

完全な設定ファイルとノードリストの違い

完全な設定ファイルには、待ち受け設定、プロキシグループ、ルールなどの実行情報が含まれます。一方、ノードリストは主に接続情報を記述します。どちらもYAML形式の場合がありますが、用途は異なります。proxy-providersが参照するのは通常、プロバイダー形式のファイルです。拡張子だけを見て、完全なサブスクリプションとして使えると判断しないでください。読み込みに失敗した場合は、取得した内容がログインページやエラーメッセージ、エンコードされた文字列に変わっていないか確認しましょう。形式の違いについてはサブスクリプションURLとYAML形式の解説もご覧ください。

以降のサンプルは、設定項目の一部を記述する例として読み、単独で動作するファイルとは考えないでください。プロキシグループ名やプロバイダー名を含む場合は、自分の設定にある定義と一致させる必要があります。保存前に、その項目がトップレベルに属するのか、リスト項目の中に属するのかを確認しましょう。階層を誤った場合、すぐにエラーが出ず、項目が無視されて古い動作が続くこともあります。

ポートと動作モード

ポート設定で決めるのは「アプリからの接続をどこで受け付けるか」であり、「最終的にどのノードを経由するか」ではありません。システムプロキシでは通常、アプリの接続先をローカルのHTTPポートまたは混合ポートに設定します。アプリ内でSOCKSを指定する場合は、SOCKSの待ち受け口に対応させてください。まず入口の種類を確認してから、アドレスとポートを設定しましょう。リモートのプロキシサーバーのポートをローカルの待ち受けポートに設定したり、その逆を行ったりすると接続に失敗することがありますが、両者は接続経路上の別の場所にあります。

port・socks-port・mixed-port

portはHTTPプロキシの待ち受け、socks-portはSOCKSプロキシの待ち受けに使います。mixed-portでは、同じポートでHTTPとSOCKSの両方を受け付けられます。通常の利用なら混合ポートを1つ使えば十分で、「機能を一通り揃える」ためにすべての入口を有効にする必要はありません。複数の待ち受けが同じアドレスとポートの組み合わせを使うことはできません。ほかのクライアントやバックグラウンドサービスがポートを使用中の場合、新しいコアが起動に失敗することがあります。

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

LANからのアクセスには複数の条件が必要

allow-lan: falseは、ローカル端末だけで使う場合に適しています。別のデバイスから接続するには、LANからの接続を許可するだけでなく、アクセス可能なアドレスで待ち受ける必要があります。接続する側のデバイスには、クライアントを実行しているPCのLAN内アドレスを入力してください。接続する側自身のループバックアドレスではありません。そのうえで、OSのファイアウォールとWi-Fiのデバイス間通信制限を確認します。LAN接続を許可しても認証が自動で設定されるわけではなく、待ち受けポートをインターネットに公開してよいわけでもありません。

接続口を共有する場合は、利用者とネットワークの範囲を明確にしてください。必要に応じて、入口の認証やクライアントが対応するアクセス制限も設定します。管理インターフェースとプロキシの入口も区別しましょう。external-controllerはコアを制御するためのインターフェースで、ブラウザーに入力するプロキシアドレスではありません。リモート制御が不要なら、ローカル端末からのみアクセスできるようにしてください。公開状態で待ち受ける管理インターフェースのサンプルをそのまま使ったり、制御用の認証情報を公開ダウンロード用の設定ファイルに含めたりしないでください。

モードとトラフィックの取り込み方は別

ruleはルールに従って出口を選び、globalはグローバルポリシーを使い、directは直結します。グローバルモードにしても、すべてのアプリの通信が自動的にプロキシを通るわけではありません。コアに届いたリクエストの経路選択が変わるだけです。システムプロキシを使わないアプリは、画面上でグローバルモードになっていても直結する場合があります。まずクライアントの接続一覧にリクエストが表示されるかを確認し、その後でモードの選択に問題がないか調べましょう。

システムプロキシは、通常、OSのプロキシ設定に従うアプリに適用されます。一方、TUNは仮想ネットワークインターフェースを通じて通信を取り込みます。両者は同じ項目の別名ではありません。TUNでは権限、ルーティング、DNSの横取り、ほかの仮想NICとの競合も関係します。スイッチをオンにしただけで、すべての準備が整ったと判断しないでください。最初はプロキシに対応したアプリで混合ポートをテストし、その後にTUNを個別に有効にすると、入口とルーティングの問題を切り分けやすくなります。

設定ファイルのモードやプロキシグループの選択は、クライアントに保存された状態で上書きされることがあります。サンプルのstore-selectedはグループの選択を保存するため、再起動後に選び直す手間を減らせます。一方で、設定ファイルのデフォルト候補順を変更しても、現在の選択に反映されない場合があります。確認時は、画面に表示されている現在のモード、グループの出口、コアの実行設定を基準にしてください。サブスクリプションの特定の行だけを見て判断しないようにしましょう。

ポートが競合している場合は、まず同じクライアントが複数起動していないか確認し、バックグラウンドのコアが待ち受けを続けていないか調べてから、ポートの変更を検討します。変更後は、システムプロキシ、ブラウザー拡張機能、アプリ内に手動設定したアドレスも合わせて更新してください。YAMLだけを変更してアプリ側の古いポートを残すと、「コアは正常なのにWebページが開かない」という状態になります。ソフトウェアを再インストールする必要はありません。入口とアプリの設定を一致させれば、原因が分かることがほとんどです。

DNS設定

DNSはドメイン名からIPアドレスを取得する仕組みで、ドメイン名やアドレスを使った振り分けにも影響します。Webページが開かないからといって、ノードが使えないとは限りません。リモートサーバーに接続する前に、名前解決で失敗している可能性があります。トラブル対処では、アクセス先のドメイン、プロキシサーバーのドメイン、上流DNSサーバーのドメインを分けて考えましょう。それぞれが同じ経路で名前解決されるとは限りません。1つのDNSサーバーですべてをまかなう設定はシンプルに見えますが、ネットワーク環境によっては依存関係が循環することがあります。

内蔵DNSとfake-ipを有効にする

dns.enableは内蔵DNS機能を制御します。listenは待ち受けアドレスを指定しますが、待ち受けを設定しただけでOSから自動的にクエリが送られるわけではありません。OSのDNS設定、クライアントによる通信の取り込み、またはTUNによるDNS横取りが必要です。enhanced-mode: fake-ipでは、ドメインに仮想アドレスを割り当て、コアがドメインとの対応を保持して実際の接続時に出口を処理します。この仮想アドレスはWebサイトの実サーバーのアドレスではないため、ノードのアドレスとして使わないでください。

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
  proxy-server-nameserver:
    - 223.5.5.5
  fake-ip-filter:
    - "*.lan"
    - "localhost"

上記のアドレスは設定項目の関係を示す例です。現在のネットワークで利用できるか、実際に確認してください。default-nameserverはDNS上流サーバーのドメイン名を解決するために使われることが多く、現在のネットワークから直接アクセスできる初期の名前解決先を指定します。proxy-server-nameserverでは、プロキシサーバーのドメイン名を解決する経路を指定できます。「プロキシに接続するにはノードの名前解決が必要だが、その名前解決にはプロキシが必要」という循環を避けるのに役立ちます。すべてのWebサイトの問い合わせに使う共通の出口ではありません。

名前解決の経路と接続の経路は別々に確認

nameserverは主な上流DNSサーバーのリストで、nameserver-policyではドメインや対応するルール条件ごとに上流を指定できます。細かく制御する場合は、対象を絞り、結果を確認できるポリシーから始めて、少しずつ広げてください。DNSクエリが特定の経路を使っても、その後のWebサイトへの接続が同じ出口を使うとは限りません。実際の接続経路は、引き続き振り分けルールで決まります。両者を混同すると、「名前解決に成功したからプロキシ接続も成功している」と誤解しかねません。

mihomoのrespect-rulesを使うと、DNS上流への接続にもルーティングルールを適用できます。ただし、有効にする前にプロキシサーバーのドメイン名をどう解決するか決め、ルールが未完了の名前解決に依存していないか確認してください。初心者には、暗号化DNSの上流をいくつも重ねるより、分かりやすい名前解決経路を保つことが重要です。現在のネットワークからアクセスできない上流がある場合、同じ経路にさらにサーバーを追加しても改善しないことがあります。ログが読みにくくなるだけの場合もあります。

fake-ip-filterは、LAN内のデバイス検出や実アドレスに依存するアプリなど、仮想アドレスを割り当てたくないドメインに使います。ただし、フィルターが変えるのは名前解決の結果であり、直結ルールを設定するものではありません。特定のドメインを直結させたい場合は、接続ルールがDIRECTを指していることも確認してください。問題のあるWebサイトを何でもフィルターに追加するのは避けましょう。リストが大きくなりすぎると、本来の通信取り込みの問題を見えにくくし、ドメインとの対応関係も追いにくくなります。

IPv6・キャッシュ・問題の切り分け

トップレベルのipv6とDNS内の同名項目は、まったく同じスイッチではありません。前者はコアがIPv6を使うかどうかに関わり、後者は内蔵リゾルバーがアドレスを問い合わせ、応答する方法に影響します。OS、アプリ、ほかのDNSサービスに、独自のIPv6経路が残っていることもあります。一部のWebサイトだけが不安定な場合は、IPv4だけがプロキシ経由になり、IPv6が迂回していないか確認してください。すぐにノードの不安定さと決めつけないようにしましょう。

DNSを変更しても、既存の接続が自動で名前解決し直されるわけではありません。アプリやOSのキャッシュに古い結果が残る場合もあります。まず設定を再読み込みし、対象アプリの接続を閉じてから、新しいリクエストを送ってください。必要な場合に限り、該当するキャッシュを消去します。fake-ipを使っている場合は、互換性のない別のアドレス対応関係に古いキャッシュを持ち越さないようにしてください。アドレスを取得できたのは名前解決の段階が完了したというだけです。接続一覧で接続先、ルール、出口も確認しましょう。

複数のDNS設定を比較する場合は、毎回1つの条件だけを変えてください。たとえば、まず上流を変更し、次にフィルターをテストし、最後にルールへの追従方法を調整します。失敗したドメイン、テスト時刻、ログでエラーになった段階を記録し、「ページが遅い」とだけ記録するのは避けましょう。初期の名前解決の失敗、上流への接続不可、ドメインとの対応異常、名前解決後の接続失敗のどれかを切り分けやすくなります。最後の場合はノードとルールの項目を確認し、DNSサーバーを増やさないでください。

プロキシノードの項目

proxiesには、リモートサービスへ実際に接続するための情報を記述します。ノード名はローカルで識別するための名前で、プロトコルを決めるものではありません。プロトコルはtypeで指定し、必要なほかの項目もプロトコルによって異なります。名前にプロトコル名が含まれていても、実際にその方式を使っているとは限りません。実際の項目を確認し、現在のコアが該当するタイプに対応しているかを調べましょう。GUIでテキストを読み込めても、コアが接続できるとは限りません。読み込みと接続は分けて確認してください。

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

多くのノードにはname、type、server、portが含まれます。サーバーにはドメイン名またはIPアドレスを指定し、ポートはリモートサービスの設定と一致させます。認証方式はプロトコルによって異なり、パスワード、ユーザーID、その他の認証情報を使う場合があります。異なるプロトコルの項目を混ぜて記述しないでください。typeの値を別の名前に変えるだけでプロトコルを切り替えられるわけでもありません。サーバーとクライアントの接続方式を一致させる必要があります。

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

このサンプルはShadowsocksノードの構造を示しています。example.comとサンプルのパスワードではサービスを利用できません。実際に使うには、サービス提供元から渡された情報に置き換え、ノード名をプロキシグループの候補に追加してください。cipherはサーバー側と一致させます。「より強そう」という理由で別の方式を選ばないでください。サーバーアドレスが正しくても、認証情報が異なると、基礎的な接続が確立してもアプリのデータを正常に転送できないことがあります。

TLSとトランスポート層を同時に変更しない

TLS対応プロトコルでは、servername、証明書の検証、アプリケーション層プロトコルなどの設定が必要な場合があります。トランスポート方式によっては、パス、リクエストヘッダー、その他のオプションもあります。これらは異なる階層の情報です。サーバーアドレスは接続先を決め、サーバー名はTLSハンドシェイクに使われ、トランスポートパスはサーバーが上位層の接続を識別する方法に影響します。サーバーアドレスを解決後のIPアドレスに直接変更し、元のサーバー名を残さないと、証明書の検証に失敗することがあります。

証明書関連のエラーが起きたら、まずシステム時刻、サーバー名の正しさ、証明書チェーンの完全性、ネットワーク上の中間機器の有無を確認してください。証明書検証の無効化を一般的な解決策にしてはいけません。一時的に接続できたからといって、問題が解決したと判断することもできません。サービス提供元から特定の設定が案内されている場合は、その内容を確認し、失敗ログに記録された段階を残してください。ハンドシェイク、認証、接続先のタイムアウトでは、対処方法が異なります。

udp: trueは、そのノード設定で関連するUDP機能を許可する指定です。実際に使えるかどうかは、プロトコル、リモートサービス、接続口、ローカルネットワークにも左右されます。すべてのアプリでUDPプロキシが使えるようになる万能スイッチではありません。ブラウザーでページが開けても、一部のTCP通信やアプリの接続が使えたことしか確認できません。ゲーム、音声通話などのUDPアプリは個別にテストし、アプリが現在のプロキシ接続口を迂回していないかも確認してください。

ノードプロバイダーとサブスクリプション更新

ノード数が多く更新も頻繁な場合は、proxy-providersを使ってノードの取得元とプロキシグループの定義を分けられます。プロバイダーはノードリストを読み込む、または取得し、プロキシグループはuseでプロバイダー名を参照します。ここで参照するのはプロバイダーであり、個別のノードではありません。ファイル形式、アクセス可能なパス、更新方法が、使用中のコアとクライアントに対応していることを確認してください。ノードリスト専用の入口に、クライアント設定全体を渡すことはできません。

proxy-providers:
  local-nodes:
    type: file
    path: ./providers/local-nodes.yaml
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 600

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

対象ファイルでは、トップレベルのproxies:の下にノードリストを記述します。パスは通常、コアの作業ディレクトリを基準に解決されます。ただし、GUIクライアントが読み込み可能な場所を制限したり、ディレクトリを変更したりする場合があるため、ファイルとサブスクリプションを同じ場所に置いたかだけでは判断できません。ファイルが見つからない場合は、実際のパスが実行ログに記録されているか確認してください。ヘルスチェックに結果が表示されない場合は、プロバイダーが未読み込みなのか、リストが空なのか、テストリクエストが失敗したのかを切り分けてから、ノード全体が使えないと判断しましょう。

サブスクリプションを更新してノード名が変更または削除されると、名前を直接参照しているプロキシグループに影響します。長期的に使うカスタム設定では、変更されにくいプロバイダー参照を使うか、クライアント対応のフィルター機能でノードを管理するとよいでしょう。更新のたびに上書きされるノードリストの原文を、何度も手作業で変更しないでください。更新自体に失敗している場合は、ノードの設定を調べる前にサブスクリプション更新のトラブル対処手順でURL、ネットワーク、取得内容の形式を確認しましょう。

プロキシグループとヘルスチェック

プロキシグループは、ルールとノードの間にある中間層です。ルールはどのサーバーが使えるかを知る必要はなく、変更されにくいグループ名にリクエストを渡せば十分です。グループ内で手動選択、自動選択、フェイルオーバーを行います。ノードを変更してもルールを1つずつ書き換える必要がなく、用途別にも整理できます。たとえば、普段のWeb閲覧と特定サービスで別々のグループを使えます。ただし、グループ名そのものに特別な機能はありません。実際の動作は、グループの候補、テスト方法、ルールのマッチ結果で決まります。

よく使う4種類の選び方

selectは手動で選ぶ方式で、出口を固定したい場合に適しています。url-testはテスト結果をもとに自動選択するため、候補の中からコアに選ばせたい場合に向いています。fallbackは、テスト値が最小の候補を常に選ぶのではなく、リスト順に使用可能な候補を選びます。load-balanceは対応する方式で接続を振り分けますが、1つのダウンロードで複数回線の帯域が自動的に合算されるわけではありません。

proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - 自動選択
      - DIRECT
  - name: 自動選択
    type: url-test
    proxies:
      - SS-サンプル
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50

このサンプルを使うには、前の章にある同名ノードの定義も必要です。外側の手動グループでは利用者が選択し、内側の自動グループでは候補をテストします。自動グループに候補が1つだけでもテストはできますが、切り替え先はありません。intervalはチェック間隔、toleranceはテスト値のわずかな変動による頻繁な切り替えを抑えるための項目です。ダウンロード速度の基準値ではなく、どのWebサイトでも同じ使い勝手になることを保証するものでもありません。

テスト成功で分かるのは一つだけ

ヘルスチェックで分かるのは、「指定した方法でテスト先に接続できる候補かどうか」です。実際のサービスの動作確認に代わるものではありません。テスト先に接続できない場合や、現在のネットワークからアクセスが制限されている場合、テスト先の名前解決に問題がある場合は、利用可能なノードでも失敗と表示されることがあります。反対に、テストリクエストが成功しても、特定のアカウントサービス、動画配信、ゲームが使えるとは限りません。テスト先は安定していて負荷が軽く、用途との関連があるものを選びましょう。

チェック間隔を極端に短くすると、継続的なリクエストが増える一方で、選択の精度が上がるとは限りません。ネットワークの状態が頻繁に変われば、テスト結果も変動します。まず、スリープ復帰後だけ、特定のネットワークだけ、特定のテスト先だけで失敗するなど、規則性があるかを確認しましょう。原因を調べるときは、一時的に手動グループへ切り替えてノードを固定します。自動切り替えによるログと実際の挙動への影響を減らしてから、候補を個別に検証してください。

プロバイダーのヘルスチェックとプロキシグループのチェックは別のレイヤーです。設定時には、誰がどの候補を対象にチェックを実行するのか把握してください。プロバイダーに結果が表示されていても、それを参照するすべてのグループが同じ選択動作をするとは限りません。useでノードの取得元を参照する場合は、プロバイダーの読み込みが成功していることも確認してください。名前リストとプロバイダーを併用する場合は、候補の重複や、意図しない直結出口の混入がないか調べましょう。

グループの入れ子参照と状態の保存

プロキシグループから別のグループを参照できますが、循環参照は作れません。AグループがBグループを指し、BグループがAグループに戻ると、名前がすべて存在していても出口を確定できません。階層はできるだけ少なく保ちましょう。用途別グループから選択用グループを参照し、そのグループからノードを参照する構成で十分です。階層が深くなると接続記録が読みづらくなり、「画面ではノードを選んだのに、実際の出口が違う」という状況を理解しにくくなります。

ログイン、決済、長時間のセッションでは、出口の変更が影響することがあります。自動切り替えや接続の振り分けによってリクエストごとに出口が変わると、サービス側で再認証を求められる場合があります。これはノードの障害とは限りません。そのような用途には、専用の手動選択グループを使い、経路を安定させるとよいでしょう。グループタイプを変更した後は、新しい接続で確認してください。既存の長時間接続はすぐに切り替わらないことがあり、画面上の新しい選択と古いセッションが短時間併存する場合があります。

サブスクリプション切り替え後に、プロキシグループの選択が想定と異なる場合は、クライアントが過去の選択を復元していないか、元のノードが削除されていないか、グループ名が以前の設定と重複していないかを確認してください。グループ名を固定すれば以前の選択を保ちやすくなりますが、状態も引き継がれます。トラブル対処の際は「自動選択を使用」とだけ記録せず、現在選択されている実際のノードを記録してください。再読み込みや自動切り替えの後も、当時の接続条件を再現しやすくなります。

ルールの構文と優先順位

ルールは上から順に評価され、通常は最初に一致したルールで出口が決まります。対象範囲の狭い例外を前に、広い分類を後ろに置き、最後のMATCHで残りのリクエストを受けます。キーワードだけで順序の設計を代替することはできません。同じルールでも、前後を入れ替えると結果が変わることがあります。カスタムルールを書くときは、まず対象にしたいリクエストを明確にし、それを正確に表せるルールタイプを選びましょう。

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

DOMAINは指定したドメインに一致し、DOMAIN-SUFFIXはそのドメインとサブドメインに一致します。DOMAIN-KEYWORDはキーワードによって対象を広げます。短すぎるキーワードは無関係なサイトまで一致するため、日常的な例外には完全なドメイン名やサフィックスを使うのが基本です。ルールのドメインにスキーム、パス、クエリパラメーターを含めないでください。Webアドレスは完全なURLですが、ドメインルールが扱うのはそのうちホスト名の部分です。

rules:
  - DOMAIN,router.example.com,DIRECT
  - DOMAIN-SUFFIX,example.com,PROXY
  - DOMAIN-KEYWORD,example,PROXY
  - 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

この例では、router.example.comは正確な直結ルールに一致するため、後続のサフィックスルールでプロキシに切り替わることはありません。IPアドレス範囲のルールはLAN内や特定のネットワーク範囲に向いており、GEOIPは地理データを使って分類します。地理的位置がWebサイトの用途を示すとは限りません。コンテンツ配信ネットワークでは、同じサービスが複数の地域のアドレスに対応することもあるため、IPアドレスの分類結果を不変のサービス属性とみなさないでください。

no-resolveが適用される範囲

no-resolveは主にIPアドレスルールで使い、そのルールに一致させるためだけの名前解決を明示的に行わないようにします。「リクエスト全体でDNSを禁止する」という意味ではなく、すべてのドメインリクエストがルールを必ず迂回するということでもありません。コアがすでに接続先アドレスを把握している場合は、IPアドレスで照合されることがあります。このパラメーターは、不要な名前解決を減らしたり、照合の流れを制御したりするためのものです。あらゆるDNSの問題を回避する手段ではありません。

ドメインルールを使うには、コアがドメイン名を把握している必要があります。アドレスを直接指定するリクエスト、アプリ独自の暗号化DNSによる名前解決、利用可能なホスト名を含まない接続入口では、照合に必要な情報が不足する場合があります。状況によってはDNSマッピングやスニッフィングで情報を補えますが、スニッフィングにも対応プロトコル、暗号化方式、設定上の制約があります。まず接続の詳細にドメイン名が表示されているか確認し、ルールの記述に誤りがあるのか、そもそもドメインルールに必要な情報がないのかを判断しましょう。

GEOSITEとRULE-SET

GEOSITEはドメイン分類データを使ってサービス群を指定し、RULE-SETはルールプロバイダーを参照します。どちらも利用可能なデータソースが必要で、分類名が実在することも確認しなければなりません。Web上で見かけた分類名をルールに書くだけでは、対応するデータは自動で取得されません。大規模なルールセットを読み込む前に、データ形式、更新パス、コアの対応状況を確認してください。設定を読み込めても、実行時に参照先のリソースが見つからない場合があります。

rule-providers:
  private-domains:
    type: file
    behavior: domain
    format: yaml
    path: ./rules/private-domains.yaml

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

上記のプロバイダーファイルでは、トップレベルにpayload:を置き、リスト内に引用符付きの"+.example.com"などのドメイン条件を記述します。behavior: domainはドメイン一覧、ipcidrはIPアドレス範囲、classicalは対応する完全なルール項目を対象とします。相互に変換せずに置き換えることはできません。ドメイン専用リストに完全なルール項目を入れると、形式エラーや想定外のマッチ結果につながります。

ルールプロバイダーが一致条件を提供し、RULE-SETの行が、一致したリクエストをどのプロキシグループに渡すかを決めます。この方法なら、同じドメイン一覧を複数の設定で使え、一覧の中に出口を固定せずに済みます。複数の一覧に同じ条件が含まれる場合も、外側のルール順が優先されます。集合名が具体的だからといって、自動的に優先順位が高くなるわけではありません。優先順位を変えるには、参照ルールの位置を変更してください。

接続記録からルールの結果を確認する

意図しない振り分けが起きたら、具体的な接続を1つ選び、ドメイン、接続先アドレス、マッチしたルール、最終的な出口を記録します。MATCHに一致した場合は、前の条件に一致しなかったということです。フォールバックルールの故障ではありません。ルールが正しく一致しているのに出口が違う場合は、プロキシグループの現在の選択を確認してください。接続一覧にリクエスト自体がない場合は、入口で通信を取り込めているか確認します。詳しい組み合わせ方はGEOIP・GEOSITE・RULE-SETによる振り分け実践ガイドをご覧ください。

設定の上書きとマージ

上書き機能を使うのは、「サブスクリプションは更新したいが、ローカル設定も保持したい」場合です。サブスクリプションの原文を直接編集すると、次回の更新でサービス提供元の内容に戻る可能性があります。実行時に生成されたファイルを直接編集しても、クライアントの再起動時に作り直されることがあります。通常はクライアントが提供する永続的な上書き設定、拡張設定、マージ機能を使います。クライアントによって実装が異なるため、ある画面の上書き形式を、すべてのコアが認識する標準項目だと考えないでください。

最終的な設定を生成しているものを確認する

設定が反映されるまでの流れには、サブスクリプションの原文、ローカルに保存された設定、クライアントによる加工、コアの実行状態など、複数の段階があります。クライアントが待ち受けポートを固定し、管理インターフェースを追加し、DNSを置き換えたり、読み込み時にルールを挿入したりする場合もあります。サブスクリプション内の行が反映されなくても、項目が非対応とは限りません。後の段階で上書きされている可能性があります。まずクライアントの実行時設定プレビュー、エクスポート、ログのいずれかを確認し、変更前後にコアへ渡された最終結果を比較しましょう。

Clash Plusは、複数のプラットフォームで使えるクライアントの有力な選択肢です。設定を追加できる場所は、実際の画面で確認してください。インストールする場合はクライアントのダウンロードページでプラットフォームを選びます。Clash Verge RevやFlClashなどでは、拡張設定の名前や適用順が異なる場合があります。別のクライアントのボタン名をそのまま頼りに操作したり、ローカルルールを残すためにクライアントが毎回生成する一時ファイルを編集したりしないでください。

オブジェクトのマージとリストのマージは異なる

オブジェクト内の項目は再帰的にマージされる場合もあれば、オブジェクト全体が置き換わる場合もあります。リストは置き換え、先頭への追加、末尾への追加、重複の削除など、実装によって動作が異なります。たとえば、DNSの子項目だけを上書きした場合、元のDNS項目が保持される仕組みもあれば、オブジェクト全体を設定し直す必要がある仕組みもあります。ルールリストには特に注意が必要です。カスタムルールを既存のMATCHより後ろに追加すると、ファイルにルールがあっても実際には一度も一致しません。

# 対応するマージ機能を持つクライアントの上書き例
# すべてのコアにそのまま渡せる共通項目ではありません
prepend-rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
append-proxies:
  - name: ローカルSOCKS
    type: socks5
    server: 127.0.0.1
    port: 1080

prepend-rulesやappend-proxiesのような名前は、クライアントが提供するマージ操作を示している可能性があります。通常のconfig.yamlのトップレベルに、確認せず追加しないでください。コアに渡す最終設定では、通常のrulesとproxiesのリストが必要です。現在のクライアントがこれらのキーに対応していない場合は、そのクライアントのマージ機能や拡張機能を使いましょう。同じ断片を何度も貼り付けるのは避けてください。

ローカルSOCKSの設定例では、指定したアドレスとポートで対象のサービスが実際に待ち受けている必要があります。ノード定義を追加しても、そのサービスが起動するわけではありません。ノードを選択できるようにするには、通常、プロキシグループにも追加します。グループがプロバイダーから自動生成される場合は、ローカルで追加したノードが含まれるかも確認してください。設定内にノードが存在することと、ルールからそのノードに到達できることは、別々に検証する必要があります。

変更範囲を絞って保守性を保つ

長期的に設定を管理する場合は、サブスクリプション全体を複製して独自設定に分岐させるのではなく、必要な項目だけを明示的に上書きしてください。すべてを複製すると、ノードの変更、プロキシグループの調整、ルールデータの更新までローカルで管理することになります。ドメインを1つ直結させたいだけなら、目的を説明できるルールを先頭に追加します。ポートだけを固定したいなら、入口の項目だけを変更してください。変更範囲が小さいほど、サブスクリプションの構造が変わったときに競合を見つけやすく、元に戻すのも簡単です。

スクリプトで設定を加工する場合は、気軽に貼り付けるテキストではなく、設定を生成するプログラムとして扱ってください。項目が見つからない、リストが空、名前が変わったなどの理由で失敗する可能性があるため、入力の前提と失敗時の動作を明確にする必要があります。認証情報をコンソールに出力したり、ノードリストの固定インデックスに依存したりしないでください。安定したグループ名や明確な条件を使って処理し、空のグループ、重複した名前、無効な参照がないか確認しましょう。

設定が永続化されたことを確認するには、2段階のテストが必要です。まずローカル設定を再読み込みし、現在の実行状態が正しいか確認します。次にサブスクリプションを更新し、ローカルの変更が正しい位置に残るか確認してください。最後にクライアントを終了して再起動し、過去の状態が結果に影響していないか調べます。編集直後に1回テストしただけでは、更新後も設定が維持されるとは限りません。サブスクリプション原文とローカルの上書き設定をどう使い分けるか記録しておけば、後でクライアントを移行するときも設定を再構築しやすくなります。

設定の検証とトラブル対処

検証は3段階に分けて行います。ファイルを解析できるか、コアを起動できるか、実際のリクエストが想定した出口を通るかです。最初の段階を通過しても、残り2つが成功するとは限りません。テスト先に接続できても、すべてのアプリの通信が取り込まれているとは限りません。この3段階を分ければ、何度も再インストールするより早く原因を見つけられます。問題に関係する項目を一度に1つだけ変更し、変更前の設定と再現可能なリクエストを残してください。何を変えた結果、どうなったのかを判断できます。

まず静的チェックを行い、次に設定を再読み込みする

mihomoコアを単体で使っている場合は、設定ファイルの検証用オプションで内容を確認できます。GUIクライアントでは、まずクライアントが提供する検証機能や再読み込み機能を使ってください。コマンドは、プログラムとファイルがあるディレクトリで実行します。プログラムが環境変数に登録されていない場合は、実際のパスを指定してください。以下のコマンドで、アプリのシステムプロキシが自動的に設定されるわけではなく、リモートノードの稼働も確認できません。主に構文、参照、関連設定のエラーを事前に見つけるためのものです。

mihomo -t -f ./config.yaml

Windowsのコマンド環境では、プログラム名やパスを実際の実行ファイルに合わせて記述する必要がある場合があります。エラーメッセージで行番号が示されても、その行だけでなく、直前のリスト項目、閉じ忘れた引用符、1つ上の階層のインデントも確認してください。存在しないプロキシグループの参照エラーなら、その名前の定義と使用箇所を検索しましょう。報告された行だけを削除すると、通信が別のフォールバック出口に流れる可能性があります。

接続の段階に沿ってログを読む

再読み込み後は、まず設定の読み込みが成功したことを確認し、次に待ち受けが確立しているか調べます。ポートの競合、権限不足、プロバイダーファイルの読み込み失敗は、Webリクエストを送る前に起きる可能性があります。クライアントが起動しない場合は、起動時にクラッシュする場合の確認手順をご覧ください。コアの起動後に新しいリクエストを送り、DNS、ルールの一致、プロキシグループの選択、リモート接続の順に確認します。問題をすべて「ネットワークの不具合」とまとめないでください。

ログにタイムアウトが記録されている場合は、対象と発生段階を合わせて判断します。DNSサーバーのタイムアウトなら上流DNSへの経路を、プロキシサーバーへの接続タイムアウトならノードのアドレス、ポート、現在のネットワークを確認します。プロキシ接続の確立後に接続先サイトがタイムアウトする場合は、サーバー側の出口と接続先への到達性を調べましょう。エラー1行だけでは判断できないことが多く、前後のログや同時刻の接続詳細が役立ちます。ログの読み方は実行ログの見方とトラブル対処手順をご覧ください。

小さなテストで問題を切り分ける

まず手動ノードを1つ選び、不要な自動切り替えをオフにしてから、プロキシ対応が明確なアプリでリクエストを送ります。この入口で接続できるのにTUNを有効にすると失敗する場合は、ノードのパスワードを変え続けるのではなく、権限、ルーティング、DNSの横取り、ほかの仮想NICを確認してください。直結とプロキシのどちらでも同じドメインを解決できない場合は、まず名前解決の経路を調べます。条件を1つずつ変えれば、テスト結果を比較できます。

カスタムルールをテストするには、正確なドメインを指定したルールを前方に追加し、新しい接続を作って一致するか確認します。正確なルールは有効なのに大規模なルールセットが機能しない場合は、セットの形式、読み込み状態、外側のルール順を調べてください。正確なルールにも一致しない場合は、リクエストのホスト名が想定と同じかを確認します。Webページでは複数のドメインにリクエストすることがあり、トップページが開いても、すべてのリソースが同じ出口を使うとは限りません。実際に失敗している接続を調べましょう。

設定を再読み込みした後も、既存の接続、DNSキャッシュ、保存済みの選択状態が影響することがあります。長時間の接続は元の出口を使い続け、ブラウザーが既存の接続プールを再利用し、クライアントが以前保存したプロキシグループを復元する場合もあります。条件を整理してテストする場合は、まず現在の状態を保存し、対象の接続を終了してから新しいリクエストを送ってください。古いセッションを残したまま、画面上の新しいグループ名だけを見てすべての通信が切り替わったと判断すると、矛盾する結果になりやすいので注意しましょう。

設定のロールバックとトラブル情報の共有

変更に失敗した場合は、誤った設定にスイッチを追加し続けるのではなく、直近の正常な設定に戻してください。ポート、DNS、ノード、プロキシグループ、ルール、上書き設定の順に変更を1つずつ適用し、成功・失敗の境界を記録するとよいでしょう。サポートを求める際は、OS、クライアント名、使用中のコア、失敗した段階、関連する最小限の設定を伝えます。サブスクリプションURL、パスワード、ユーザーID、管理用認証情報は削除してください。公開するスクリーンショットも、サイドバーやログに機密情報が表示されていないか確認しましょう。