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

YAML構造とファイルの範囲

Clashの設定ファイルには通常YAMLを使用します。ファイル名はconfig.yamlが一般的ですが、名前だけで用途が決まるわけではありません。実際に読み込まれるファイルは、クライアントで選択中の設定や、コアの起動時に指定されたファイル引数によって決まります。このページの例ではmihomoでよく使われる項目を取り上げます。ほかのClash系コアでは一部の項目しか実装されていない場合があり、クライアントが起動前に別の実行用設定を生成することもあります。問題を調べるときは、まずコアの名称、設定の取得元、最終的な読み込み先を確認してから、項目が有効かどうかを判断してください。

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

YAMLではキーと値のマッピングで設定を表します。たとえばmode: ruleのように記述します。リストは各項目をハイフンで並べます。たとえばrulesには複数のルールを記述できます。トップレベルの項目は行頭から書き、子項目はスペースでインデントします。スペース2つに統一するのがおすすめです。インデントの深さは項目の親子関係を表し、見た目を整えるためのものではありません。nameserverをdnsと同じ位置に書くと、DNSの子項目ではなく別のトップレベルキーになります。構文として読み込めても、コアが意図どおりに使うとは限りません。

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

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  nameserver:
    - https://dns.alidns.com/dns-query

proxy-groups:
  - name: 出口選択
    type: select
    proxies:
      - DIRECT

rules:
  - MATCH,出口選択

これは構造を確認するための直結設定で、リモートのプロキシノードは含みません。読み込むと、ルールはリクエストを「出口選択」に渡します。このグループに含まれるのはDIRECTだけです。ファイルの読み込み、ポートのリッスン、グループ名の参照を確認する用途には使えますが、リモートプロキシの可用性は判断できません。ほかの章のスニペットは、対応する項目に追加することを前提としています。トップレベルのdnsを含む例を複数、そのまま連結しないでください。

文字列とデータ型

真偽値はtrueまたはfalse、ポートは整数、アドレスや名前は通常文字列で記述します。パスワード、特殊記号で始まる値、コロンとスペースを含むテキストには引用符を付けるのがおすすめです。コメントは#で始まります。パスワードにシャープ記号が含まれる場合、適切に引用しないと後続の文字列がコメントとして扱われることがあります。シングルクォートの文字列ではバックスラッシュのエスケープは処理されませんが、ダブルクォートでは一部のエスケープシーケンスが解釈されます。ほかの形式からパスワードをコピーするときに、バックスラッシュをむやみに増減しないでください。

リスト内の各ノードは通常、ひとつのマッピングとして記述します。ノードのname、type、serverなどのキーは、同じリスト項目に含める必要があります。ハイフンが抜けると、新しいノードが前の項目に統合されることがあります。同じマッピング内でnameを重複させたり、トップレベルの項目を重複して記述したりすると、パーサーに拒否される場合や、後の値が前の値を上書きする場合があります。重複キーによる上書きに頼らず、クライアントが明示的に提供するマージ機能を使ってください。

完全な設定とノード集合の違い

完全な設定にはポート、DNS、ノード、プロキシグループ、ルールを含められます。一方、プロキシ集合ファイルが提供するのは通常、proxiesリストだけです。ルールセットにも独自のpayload構造があります。いずれもYAMLですが、読み込み先を入れ替えることはできません。サブスクリプションURLの応答が正しいYAMLでも、メイン設定としてそのまま読み込めるとは限りません。単一ノードのURI、Base64テキスト、ログインページが返ってきた場合は、インデントを修正する前にサブスクリプションの形式を確認してください。

編集前に元ファイルのコピーを保存し、エディターはUTF-8に設定して空白文字を表示してください。まず最小限の読み込み可能な構成を残し、DNS、ノード、グループ、ルールの順に内容を追加します。一度に変更するのは一つの領域だけにしてください。問題が起きても、戻す範囲が明確になります。オンラインのYAML整形ツールを必須の手順にする必要はありません。設定にはサブスクリプションURLや認証情報が含まれることが多いため、ローカルで編集し、ローカルで構文を確認するほうが適しています。

ポート、モード、アクセス範囲

共通項目では、コアがリクエストを受け付ける方法、ルーティングモード、アクセスを許可する対象を設定します。まず3種類の入口を区別しましょう。アプリがHTTPまたはSOCKSポートにプロキシリクエストを送る方法、システムプロキシ設定で対応アプリをこれらのポートに向ける方法、仮想ネットワークインターフェースでルーティング条件に合う通信を取り込むTUNです。リッスンポートを有効にしても、システムプロキシが自動設定されるわけではありません。システムプロキシを有効にしても、すべてのプログラムが従うとは限りません。入口の問題を調べるときは、アプリが実際にどのプロキシ方式を使っているか確認してください。

port、socks-port、mixed-port

一般的なデスクトップ利用では、まずmixed-portだけを設定すると、アプリとポートの対応関係を簡素化できます。複数のリッスン項目に同じアドレスの同じポートを指定しないでください。また、ほかのクライアントや古いコアのプロセスがポートを使用していないか確認してください。ポートを変更しても、アプリに手動で設定したプロキシアドレスが自動で更新されるとは限りません。クライアント管理のシステムプロキシは連動する場合がありますが、システム設定のホストとポートが現在のインスタンスに合っているか確認してください。

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

allow-lanとbind-address

allow-lan: falseはローカル端末からのアクセスに使います。LAN内の端末にプロキシを提供する場合はtrueにし、適切なbind-addressを設定してください。127.0.0.1にバインドすると、ローカルのIPv4ループバックからのアクセスだけを受け付けます。"*"にすると、リッスン範囲が広がります。アクセス可能かどうかは、リッスン範囲、OSのファイアウォール、ルーターの端末間通信制限、クライアント認証によって決まります。真偽値をひとつ変更しただけで、スマートフォンやテレビから接続できるとは限りません。

LAN内の端末には、コアを実行しているPCのアドレスを指定します。自分自身の127.0.0.1ではありません。PCのアドレスはDHCPリースによって変わることがあるため、ルーターでアドレス予約を設定すると変動を抑えられます。共有する場合は、信頼できるネットワークだけにアクセスを許可してください。プロキシポートをインターネットに公開しないでください。共有方法とファイアウォールの確認は、mixed-portとallow-lanを使ったLAN共有の解説をご覧ください。共有用の入口と管理用の入口は分けて制限してください。

modeとログレベル

mode: ruleではrulesの順序に従って接続先を選択します。globalではグローバルポリシーを使い、directでは直接接続します。モードの切り替えは問題の切り分けに役立ちますが、グローバルモードで接続できたからといって、ルールモードの構文に誤りがあるとは限りません。別のルールが異なる出口を選んでいる可能性もあります。ルールモードでは、LAN内、指定ドメイン、デフォルトのリクエストにそれぞれ異なる接続先を指定できます。ルールの順序を管理するのはこのためです。

log-levelは通常infoを使い、問題の調査中だけ一時的にdebugへ変更できます。詳細ログにはアクセス先のドメイン、接続先、サブスクリプション関連の情報が含まれることがあるため、長期間公開したままにしないでください。ipv6: falseはコアのIPv6関連動作を制御しますが、OSのIPv6ネットワーク機能をすべて無効にするものではありません。DNSの子項目にも独立したipv6設定があります。通信の入口とあわせて理解し、端末全体のIPv6が遮断されたと判断しないでください。

TUNのenable、auto-route、auto-detect-interface、dns-hijackは、権限、ネットワークインターフェース、システムルートに関わります。設定の構文が似ていても、プラットフォームごとの導入手順は同じとは限りません。まずクイックスタートの手順で通常のプロキシ接続を確認してからTUNを有効にしてください。そうしないと、ポート、権限、DNSの問題が同時に発生し、原因の切り分けが難しくなります。

DNSとFake-IP

dnsは独立したマッピング領域です。enableは内蔵DNSを有効にするかどうか、listenはリッスンアドレス、enhanced-modeは拡張名前解決モードを設定します。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
  nameserver:
    - https://dns.alidns.com/dns-query
  fake-ip-filter:
    - "*.lan"
    - "localhost"
  nameserver-policy:
    "+.lan": 192.168.1.1

例の192.168.1.1は、ローカル名を解決できるルーターを想定しています。実際のネットワークに合わせて置き換えてください。nameserverは通常の上流DNSリストで、指定できるアドレス形式はコアによって異なります。例ではHTTPS DNSを使っています。上流のアドレス自体にホスト名が含まれる場合は、そのホスト名を先に解決する必要があります。default-nameserverはこのような初期解決に使われます。初期解決が、まだ確立されていない同じプロキシ経路に依存しないようにしてください。起動時に循環依存が発生します。

nameserver-policyではドメインごとにDNSサーバーを指定でき、LAN内ドメインをローカルDNSに任せる場合などに使えます。これは問い合わせ先を制御する設定で、rulesで接続先の出口を選ぶこととは異なります。fallbackとfallback-filterは結果の選択に関与しますが、単に「最初のサーバーに失敗したら次へ問い合わせる」という機能ではありません。明確な振り分け要件がない場合は、複数のパブリックDNSを追加するより、説明しやすい名前解決経路をひとつ整えて検証しましょう。

Fake-IPとredir-hostの違い

fake-ipモードでは、コアがアプリに予約済みアドレス範囲の合成アドレスを返し、そのマッピングからドメインを復元して出口を選択できます。このアドレスは接続先サイトの実アドレスではないため、コマンドラインで198.18から始まる結果が表示されても、必ずしも名前解決エラーではありません。一方、redir-hostは実際の名前解決結果を主に使用します。どちらのモードでも、正しい通信の入口とドメイン情報が必要です。アプリとの互換性、DNSの経路、透過プロキシの方式を考慮して選んでください。

fake-ip-filterは、一部のローカル名や特殊な検証処理を行うサービスなど、合成アドレスを返すのに適さないドメインを除外します。アプリ全体の通信を直接接続に切り替えたり、ルーティングルールを自動変更したりするものではありません。互換性の問題が起きたら、まず特定のドメインだけを除外して動作を比較してください。よく見かけるすべてのサフィックスをフィルターに追加するのは避けましょう。除外範囲が広すぎると通信ごとに名前解決経路が分かれ、後の管理が難しくなります。

ノードの名前解決とルールの名前解決

プロキシサーバーのドメインは、プロキシへ接続する前に名前解決する必要があります。mihomoのproxy-server-nameserverでは、この問い合わせに使う上流を指定できます。DNS接続にもルールを適用する場合は、respect-rulesも関係します。この組み合わせでは、プロキシサーバーのドメイン解決が同じプロキシに再び依存しないようにしてください。まず通常の直接接続上流を使い、ノードのアドレスが解決できることを確認してから、DNSの出口ルールを段階的に追加するほうが、複雑な振り分け設定をそのままコピーするより確実です。

IPルールでは、ドメインを名前解決してから、接続先アドレスが特定のネットワーク範囲にあるか判定する場合があります。ルールのno-resolveを使うと、そのIPルールの照合時に追加の名前解決を行わないようにできますが、アプリがすでに行ったDNS問い合わせを止めるものではありません。DNSリークを調べるときは、システムの名前解決、アプリ内蔵DoH、コアの上流、プロキシ側の名前解決をそれぞれ確認してください。ブラウザーに表示されるDNSアドレスをひとつ確認しただけでは、端末のすべての問い合わせが同じ経路を通るとは判断できません。

検証では、まず一般的なドメイン、次にローカルドメインを問い合わせ、最後に該当サービスへの接続を試してください。一般的なドメインは解決できるのにローカル名が失敗する場合は、ローカル名前解決のポリシーとフィルター項目を優先して確認します。すべての問い合わせがタイムアウトする場合は、リッスンアドレス、ポート、ファイアウォール、上流への到達性を確認してください。DNSの応答とアプリの接続成功は別の段階です。名前解決が失敗したときに、まずノードのプロトコル設定を変更しないでください。

プロキシノードの項目

proxiesはノードのリストで、各項目はプロキシグループから参照できる出口を表します。共通項目は通常、name、type、server、portです。認証やトランスポートの項目はプロトコルによって異なります。ノード名は設定内で参照する識別子で、表示用のメモではありません。名前を変更したら、プロキシグループ内の同名の参照も更新してください。名前は一意にし、異なるノードに同じ名前を付けないでください。選択結果が判断しにくくなります。

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

typeによって、残りのパラメーターをコアがどのプロトコルとして解釈するかが決まります。たとえば、Shadowsocksではcipherとpasswordが必要です。Trojanではパスワードを使い、TLSの設定も関係します。VMessとVLESSでは、それぞれの認証情報とトランスポート設定を使います。typeを別のプロトコルに変更するだけでは変換できません。サーバーのプロトコル、認証方式、トランスポート層、TLS設定を実際のサーバー構成に合わせてください。不明なパラメーターはサービス提供元に確認しましょう。

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

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

ここではドキュメント用に予約されたアドレスとサンプルドメインを使っています。項目の構造を示すもので、実際に接続できるサービスではありません。利用時には、サーバーアドレス、認証情報、TLSホスト名をすべて実際の値に置き換えてください。serverにはIPアドレスまたはドメイン名を指定できます。portはサーバー側のリッスンポートで、ローカルのmixed-portとは異なります。サーバーにドメイン名を指定した場合は、接続前にノードのドメイン解決も行われます。サーバーにIPアドレスを指定しても、TLSホスト名を別途指定する必要がある場合があります。

TLS、SNI、証明書の検証

Trojanでは、TLSハンドシェイクに使うサーバー名をsniで指定するのが一般的です。ほかのプロトコルではservernameなどの項目を使うことがあるため、プロトコルの仕様に従ってください。TLSホスト名はサーバー証明書と実際の構成に合わせる必要があります。Webサイトのドメインを適当に指定しないでください。skip-cert-verify: falseにすると、証明書の検証が有効になります。証明書エラーが出たら、システム時刻、ホスト名、証明書チェーンを確認してください。検証を無効にすることを一般的な解決策にしないでください。

WebSocketのリクエストパス、Hostリクエストヘッダー、gRPCのサービス名は、それぞれ別のトランスポート設定です。サーバーがWebSocketを要求する場合、クライアントでも対応するnetworkとws-optsが必要です。パスの大文字・小文字やスラッシュはルーティングに影響することがあります。既存のURIをYAMLに変換したら、これらの詳細をひとつずつ確認してください。リンク内でエンコードされた文字は正しくデコードする必要があります。パスワードやパスを誤ってデコードすると、「設定は読み込めるがハンドシェイクに失敗する」状態になります。

UDPと通信経路の対応状況

udp: trueは、対応するプロトコルでUDP機能を有効にする設定です。通信経路全体でUDPを転送できる保証ではありません。アプリの入口、プロキシプロトコル、サーバー側の構成、ファイアウォール、通信事業者のネットワークが制限となる場合があります。Webページには接続できるのにリアルタイム通信が失敗する場合は、まずアプリがUDP対応の入口を実際に使っているか確認し、その後ノード設定を確認してください。HTTPのテストに成功しても、DNS、QUIC、ゲーム通信が正常とは限りません。

プロトコルによっては、ALPN、クライアントフィンガープリント、Realityなどの固有パラメーターも関係します。利用できる項目はコアの実装によって異なり、古いクライアントではYAMLを読み込めても、該当プロトコルに対応していないことがあります。未知の項目や未対応の種類が見つかったら、まずコアの対応状況を確認してからクライアントの変更を検討してください。プラットフォームに合ったClash Plusなどのクライアントはダウンロードページから選べます。見慣れない項目を削除して無理に読み込ませないでください。サーバーが要求する認証方式やトランスポートが変わるおそれがあります。

手動でのノード管理は、少数の固定出口を使う場合に適しています。ノードが頻繁に変わる場合は、プロキシ集合にまとめて更新し、プロキシグループから参照してください。サブスクリプションが生成したノードリストの名前を毎回手作業で変更すると、次の更新で元に戻ることがあります。形式変換後に問題が起きた場合は、YAMLサブスクリプションとノードリンク形式の解説を参考に、認証、トランスポート、TLSの項目が保持されているか確認してください。

プロキシグループとノード集合

proxy-groupsは出口の選択方法を定義し、proxy-providersはノード集合の取得元を定義します。役割は異なります。集合が候補ノードを提供し、プロキシグループが候補からの選び方を決めます。ルールでは、頻繁に変わるノード名ではなく、変更の少ないグループ名を参照するのが一般的です。ノードを更新しても、グループ名と集合への参照が有効なら、ルールをひとつずつ書き換える必要はありません。グループから別のグループを参照することもできますが、自分自身や相互の循環参照は避けてください。

select、url-test、fallback

selectはユーザーまたは管理APIから選択する方式で、出口を明示的に制御したい場合に適しています。url-testは指定したURLのテスト結果に応じて自動選択します。fallbackは通常、メンバーの順序に沿って利用可能なものを選びます。load-balanceは対応する負荷分散方式を使う設定で、1つの接続を複数回線に分割して帯域を合算するという意味ではありません。種類ごとに目的が異なるため、「自動」という理由だけですべての振り分けグループを自動テストに変更しないでください。

proxy-groups:
  - name: 出口選択
    type: select
    proxies:
      - 自動選択
      - フェイルオーバー
      - DIRECT

  - name: 自動選択
    type: url-test
    use:
      - 手動ノード
    url: https://cp.cloudflare.com/generate_204
    interval: 300
    tolerance: 50

  - name: フェイルオーバー
    type: fallback
    use:
      - 手動ノード
    url: https://cp.cloudflare.com/generate_204
    interval: 300

proxy-providers:
  手動ノード:
    type: file
    path: ./providers/nodes.yaml
    health-check:
      enable: true
      url: https://cp.cloudflare.com/generate_204
      interval: 300

この例では、作業ディレクトリにproviders/nodes.yamlがあり、その中にproxiesリストを含むノード集合が存在することを前提としています。useが参照するのはprovider名の「手動ノード」で、ファイル名や個別のノードではありません。proxiesリストでは既存のノード、ほかのグループ、組み込みの出口を直接参照します。両方の参照方法を組み合わせられますが、候補集合に実際にノードが含まれていることを確認してください。空の場合、自動選択グループに利用可能なメンバーがなくなります。

テストパラメーターの実際の意味

urlはヘルスチェックのリクエスト先を指定します。intervalは通常、秒単位でテスト間隔を設定します。toleranceは該当する自動選択の動作で使われ、わずかな差による頻繁な切り替えを抑えます。テスト結果が示すのは、指定したテスト先へのリクエスト状況です。すべてのWebサイト、長時間接続、大容量ファイル転送の品質を示すものではありません。テスト先によるリクエストの拒否、TLSハンドシェイクの異常、DNS障害などでテストが失敗しても、プロキシサーバーのポートには到達できる場合があります。

providerのヘルスチェックとグループ単位のテストは、それぞれ別に設定できる場合があります。設定前に、集合とプロキシグループのどちらがテストを担当するか確認してください。同じノードに不要な高頻度チェックを重ねるのは避けましょう。特にモバイル端末では、頻繁なチェックによってスリープ解除や通信が増えます。グループを切り替えても、既存の接続が新しいノードへただちに移るとは限りません。切り替え後は、以前から継続しているダウンロードだけを見るのではなく、新しい接続を確立してテストしてください。

集合の更新、フィルター、名前の安定性

HTTPタイプのproxy-providersでは、url、path、intervalを使って、リモートの取得元、ローカルキャッシュ、更新間隔を設定します。ダウンロードする内容はコアが受け付けるノード集合の形式である必要があり、任意のWebページや完全なクライアント設定は使えません。リモートURLに認証情報が含まれる場合は、ローカル設定に保存し、公開の問い合わせや不具合報告に貼り付けないでください。サブスクリプションの更新エラーは、サブスクリプション更新失敗時のトラブルシューティングも参考に、リクエスト自体の失敗か、内容の解析失敗かをまず切り分けてください。

グループのfilterでは、名前を条件に候補を絞り込めます。正規表現として扱う必要があります。命名規則を変更すると、フィルターの結果が空になることがあります。サブスクリプションを更新したら、ノード一覧だけでなく各グループの実際のメンバーも確認してください。地域名、特殊記号、大文字と小文字もマッチ結果に影響します。まず単純な条件で目的のノードを選べることを確認し、段階的に範囲を絞ると管理しやすくなります。

profile.store-selectedはプロキシグループの選択状態を保存し、profile.store-fake-ipは関連するマッピング状態を保存できます。状態を永続化するかどうかは、利用方法とクライアントの管理動作によって異なります。グループのメンバーを変更したら、現在の選択状態を確認し、古い選択、フィルター結果、実行中の設定に食い違いがないか調べてください。

ルールとルールセット

rulesは順序のあるリストです。コアは先頭から順に適用できるルールを探し、最初に一致したルールで指定された出口を使います。「より細かく見える」ルールが自動的に優先されるわけではなく、後ろのドメインルールが先に実行されることもありません。通常はローカルや業務上の明確な例外を先に置き、その後に広範囲のドメイン、アドレス、ルールセットを配置し、最後にMATCHをフォールバックとして置きます。順序そのものが設定の一部です。ルールを編集する際は、前後の条件も確認してください。

ドメイン、アドレス、フォールバックの構文

rules:
  - DOMAIN,intranet.example.com,DIRECT
  - DOMAIN-SUFFIX,example.org,出口選択
  - DOMAIN-KEYWORD,example,出口選択
  - IP-CIDR,127.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR6,fc00::/7,DIRECT,no-resolve
  - RULE-SET,ローカルドメイン,DIRECT
  - MATCH,出口選択

DOMAINはドメイン名全体に一致し、単一のホスト名に適しています。DOMAIN-SUFFIXは指定したドメインとそのサブドメインに一致します。DOMAIN-KEYWORDはキーワードで照合するため、より広い範囲に適用されます。キーワードが短すぎると、関係のないサイトまで対象になることがあります。IP-CIDRとIP-CIDR6は、それぞれIPv4とIPv6のネットワーク範囲に一致します。例に含まれるLANの範囲は完全な一覧ではなく、構文を示すためのものです。実際のネットワークに合わせて追加してください。プライベートアドレスの完全な一覧として扱わないでください。

ルールの末尾に指定する出口には、ノード名、プロキシグループ名、DIRECTやREJECTなどの組み込みの接続先を指定できます。名前はスペースや句読点も含めて定義と完全に一致させてください。MATCHには追加条件がないため、フォールバックとして最後に配置します。リストの先頭に書くと、後続の大半のルールが実行されません。業務ルールに一致しない場合は、似たルールを追加する前に、前にある広範囲のルールが先に適用されていないか確認してください。

rule-providersの定義とファイル形式

rule-providersでは、複数のマッチ条件をまとめて再利用できます。typeはファイルまたはHTTPの取得元、behaviorは内容の意味、formatはシリアライズ形式を示します。domain集合にはドメインの条件を、ipcidr集合にはアドレス範囲を保存します。classical集合には、対応する従来型のルール条件を含められます。どちらもYAMLだからといって、プロキシノードの集合をルールセットのディレクトリに入れないでください。トップレベルのキーも各項目の内容も異なります。

rule-providers:
  ローカルドメイン:
    type: file
    behavior: domain
    format: yaml
    path: ./rules/local-domain.yaml

# ./rules/local-domain.yaml の内容:
# payload:
#   - "+.lan"
#   - "intranet.example.com"

上のファイルに記載したpayloadは独立したファイルの内容です。このコメントを書いただけでファイルが作成されたことにはなりません。メイン設定ではRULE-SET,ローカルドメイン,DIRECTを使って、この条件セットに接続先を指定します。classical形式では、通常、集合内の項目は条件を記述するものであり、メイン設定のルールにある出口名を機械的に追加するものではありません。リモートの集合にはダウンロードとキャッシュも関係します。初回起動時に取得できず、ローカルキャッシュもない場合は、まずリソースへの接続を解決してください。

名前解決のタイミング、プロセス、プラットフォームの違い

ドメイン名のリクエストにIP条件を適用するため、名前解決が行われる場合があります。no-resolveを指定したルールでは、照合のためにドメインの名前解決を行いません。このオプションは、接続先IPアドレスがすでに分かっている通信に適していますが、名前解決結果に依存するルールが一致しなくなる場合があります。ドメインルールを適用するには、コアがドメイン情報を取得できる必要があります。通信に接続先IPしか含まれず、利用可能なDNSマッピングもスニッフィング結果もない場合、ドメイン条件が適用されるとは限りません。

PROCESS-NAMEなどのプロセスルールは、OSが提供する情報、コアの権限、通信の入口に依存します。デスクトップアプリで使えるプロセス条件が、ルーターの背後にある別の端末でも使えるとは限りません。GEOIPやGEOSITEも対応するデータリソースとコアのサポートが必要で、データベースの内容が変われば一致結果も変わります。別のプラットフォームへ移行する際は、ルールの文字列が同じかだけでなく、こうした外部依存も確認してください。

ルールファイルは役割ごとに分け、簡潔なコメントを付けてください。例外ルールをテストする際は、まず特定のドメインを明示したルールを前のほうに置き、新しい接続で適用を確認してから、長期的な配置を決めます。新しいルールを常に先頭へ追加する方法を恒久的な解決策にしないでください。優先順位の理由が後から分かりにくくなり、広い範囲のルールが既存の振り分けを隠しやすくなります。

サブスクリプション、上書き、マージ

クライアントの「サブスクリプション設定」が、コアが最終的に読み込むファイルとは限りません。一般的には、リモートの設定をダウンロードし、サブスクリプションのコピーを保存した後、ローカルの上書きやスクリプトを適用し、画面から設定されたポートやTUNの項目を追加して、最後に実行用設定を生成します。クライアントによって段階の名称や順序は異なります。「ファイルを編集したのに設定が変わらない」場合は、ダウンロード済みのキャッシュを何度も編集するのではなく、実行用設定や設定プレビューを開き、最終的な項目を確認してください。

取得元ファイル、永続設定、実行結果を区別する

取得元ファイルにはサブスクリプションが提供する内容を保存します。ローカルの上書き設定には端末固有の要件を記述します。実行用設定は、その両方とクライアント側の設定を組み合わせたものです。それぞれの層にmixed-port、dns、tunが存在することがあります。画面上のスイッチが優先される場合もあります。ファイル名から優先順位を推測せず、クライアントの説明を確認するか、項目をひとつだけ変更して動作を調べてください。たとえばポートかログレベルだけを変更し、再生成後の実行結果を確認します。

Clash Plus、Clash Verge Rev、FlClashなどでは、設定管理画面の構成がそれぞれ異なります。設定の読み込み、拡張、マージの入口は、実際に使うクライアントで確認してください。クライアントを変更するときは、特定のクライアント専用の拡張スクリプトを、汎用的なmihomoの項目として扱わないでください。コアが認識するのは最終的な設定であり、クライアントはその生成方法を担います。クライアントの選び方とプラットフォーム対応状況はクライアント選択ガイドをご覧ください。初回の設定はクイックスタートに沿って進めてください。

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

マッピングはキーごとに上書きできますが、リストは全体置き換え、先頭への追加、末尾への追加になる場合があります。具体的な動作はマージツールによって異なります。たとえばdnsを再帰的にマージすると、nameserverだけが置き換わり、ほかの子項目が残ることがあります。浅い階層で置き換えると、DNS領域全体が新しい内容だけになる場合があります。rulesをリストごと置き換えると、サブスクリプション内のルールがすべて失われる可能性があります。「マージ」と書かれているだけで元の値が必ず保持されるとは限りません。

# YAMLの上書きに対応するクライアントで使用します。
# 再帰的にマージされるかどうかは、クライアントの仕様を確認してください。
log-level: info

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

dns:
  enable: true
  nameserver:
    - https://dns.alidns.com/dns-query

この上書きを適用した後、元のdns.listen、enhanced-mode、フィルターリスト、名前解決ポリシーが残っているか確認してください。想定と違う場合は、重複する項目をさらに追加するのではなく、マージ方法を見直します。ルールを前後どちらに追加するかも確認してください。既存のMATCHの後に通常のルールを追加しても、意図した振り分けにならないことがほとんどです。範囲の広いルールを先に置きすぎると、元の業務例外が適用されない場合があります。

サブスクリプションの更新とローカル変更の保護

ダウンロード後のサブスクリプションファイルを直接編集すると、更新時にリモートの内容で上書きされることがあります。端末固有のDNS、LANルール、ポート設定を長期間保持する場合は、クライアントが対応するローカルの永続設定領域に保存してください。手動管理のノード集合とルール集合には専用のパスを使い、サブスクリプションのキャッシュと同じファイルを使わないでください。複数のHTTP providerに同じキャッシュパスを指定すると、内容が互いに上書きされ、ノードが突然消えたり、構造の解析に失敗したりすることがあります。

サブスクリプションの形式変換で、すべての項目がそのまま保持されるとは限りません。単一ノードのURIでは通常、DNS、ルール、プロキシグループ全体を表現できません。完全なYAMLをノードリンクに変換すると、こうしたトップレベルの設定が破棄されることがあります。変換後は、まずプロトコル、認証、トランスポートを比較し、その後にプロキシグループとルールが変換ツールによって再生成されているか確認してください。個人用サブスクリプションを扱うときは、信頼できないオンライン変換サービスに完全なリンクを渡さず、信頼できるローカルツールかサービス提供元の形式を使ってください。

元に戻せる更新手順

更新前に、現在正常に使える設定とローカル拡張を保存し、選択中の設定名を記録してください。更新後はまず構文を確認し、次にプロキシグループのメンバーとルールの接続先を確認してから、新しい接続をテストします。ダウンロードに成功しても読み込みに失敗する場合は、返された内容がWebページ、エラーメッセージ、別のサブスクリプション形式になっていないか比較してください。読み込みに成功して動作が変わった場合は、元のサブスクリプションだけでなく実行用設定を比較します。タイムアウト、リンクの期限切れ、自動更新間隔については、サブスクリプション更新のトラブルシューティング記事もご覧ください。

設定の差分を共有する場合は、関係する項目だけを残し、参照先を伏せてください。DNSの子項目ひとつを説明するために実行用設定全体をアップロードしないでください。ノードのパスワード、管理用の認証情報、リモートサブスクリプションの資格情報が含まれることがあります。関係のないルールが大量に含まれる完全なファイルより、再現可能な最小スニペットのほうが正確な判断につながります。

検証、ログ、問題の切り分け

設定の検証は、静的な構造の確認から実際の接続テストへ段階的に進めます。最初からモード、ノード、DNSを同時に切り替えないでください。まずコアがファイルを受け付けるか、次にリクエストが正しいポートへ届くか、その後で適用ルールとノードへの接続を確認します。各段階で問題をひとつずつ切り分け、入力、結果、変更内容を記録してください。設定に使えるノードが複数あっても、現在のグループで選択中のノードが利用できるとは限りません。同様に、クライアント画面が「実行中」と表示していても、実際のリクエストテストの代わりにはなりません。

まずファイルを確認してから実行する

mihomoを直接実行する場合は、設定テスト用の引数を使えます。コマンド内のディレクトリは実際の作業ディレクトリに置き換えてください。providerやキャッシュの相対パスは、作業ディレクトリによって参照先が変わります。GUIクライアントでは、内蔵の検証、プレビュー、ログ機能を優先して使いましょう。同じポートを使う2つ目のインスタンスを別途起動しないでください。設定の検証に通った後も、起動ログにリッスン失敗やリソースの読み込みエラーがないか確認します。こうした問題は静的検査では見つからない場合があります。

# 設定とリソースがあるディレクトリで実行
mihomo -t -d . -f ./config.yaml

# ローカルのHTTPプロキシ経由でリクエストを送信
curl -I --proxy http://127.0.0.1:7890 https://example.com

# SOCKSを使い、ドメイン名の解決をプロキシ側に任せる
curl -I --proxy socks5h://127.0.0.1:7890 https://example.com

2つのcurlリクエストではDNSの経路が異なる場合があるため、同じテストとして扱わないでください。socks5hはプロキシ側でホスト名を解決し、通常のsocks5では一般にローカルで先に解決します。Windowsのターミナルでcurlが別のコマンドに割り当てられている場合は、実際のcurlプログラムを明示的に呼び出してください。HTTPエラーが返っても、プロキシに到達できないとは限りません。Webサイトによる拒否、プロキシ認証の失敗、基盤となる接続の失敗を区別してください。

エラーが発生した段階から原因を絞り込む

エラー行番号は、最初に誤りがある場所ではなく、パーサーが停止した位置を示すことがあります。その行を確認すると同時に、前の行で引用符やコロンが抜けていないかも調べてください。見つからないプロキシ名は通常、参照の問題です。まずネットワーク設定を変更する必要はありません。接続タイムアウトは接続先を特定して考えます。サブスクリプションサーバー、ノードサーバー、Webサイトのどこでタイムアウトしたかに応じて、ダウンロード、プロキシ、Webサイトの各経路を別々に確認してください。

ログの記録と最小再現

debugを短時間だけ有効にし、対象のリクエストひとつを再現して、時刻、接続先、適用ルール、最終的な出口を記録してください。その後、通常のログレベルに戻します。TUN、システムプロキシ、アプリへの手動設定という3つの入口がある場合は、まずひとつの明確な入口だけを残して比較します。ブラウザーの接続プール、バックグラウンドサービス、DNSキャッシュによって古い接続が残ることがあります。重要な変更の後は、新しいリクエストプロセスを使うか、テストするアプリを再起動して、古い状態を観察しないようにしてください。

最小再現では、動作確認済みのノードひとつ、手動選択のグループひとつ、テスト用ドメインのルールひとつ、末尾のフォールバックを残します。最小構成で動作したら、DNSポリシー、ルールセット、自動選択、ローカル上書きをひとつずつ戻します。ルールをすべて削除して動作したからといって、ルール自体に問題があるとすぐに判断しないでください。削除によってDNSの解決タイミングやデフォルトの出口が変わることもあります。各段階の設定差分を残せば、どの変更が結果に影響したか説明できます。

よくある境界的な問題

問題の切り分けが終わったら、一時的なテストルールを削除し、適切なログレベルに戻してください。調査中にLANのアクセス範囲を広げていないかも確認します。安定した変更はローカルの永続的な上書き設定に反映し、サブスクリプションの更新と設定の再読み込みをもう一度テストしてください。現在の接続だけでなく、次回の更新後も意図した動作が保たれることを確認できます。