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

YAML構造の概要と読み込み順序

トップレベルの各ブロックが連携する仕組み

動作するClashまたはmihomo設定は通常、共通設定、DNS、プロキシノード、プロキシグループ、ルールの5つで構成されます。これらは独立したリストではなく、参照関係を持つ一連の流れです。proxiesで接続可能なノードを定義し、proxy-groupsでノードや他のプロキシグループを選択可能な出口としてまとめ、rulesで各接続をプロキシグループ、DIRECT、REJECTのいずれかへ振り分けます。DNSはドメイン解決をこの流れに組み込み、共通項目は待ち受けポート、動作モード、LANからのアクセス範囲、制御インターフェースを決定します。

項目の位置はインデントで決まります。トップレベルのキーは行頭から始め、子項目は通常2つのスペースでインデントし、リスト項目はハイフンで始めます。YAMLではタブで階層を表現せず、同じ階層で2スペースと4スペースを混在させることもできません。テキストエディターで正常に表示されても、パーサーが受け入れるとは限りません。日本語の句読点、全角コロン、見えないタブ、誤ったインデントは読み込み失敗のよくある原因です。文字列にコロン、シャープ記号、波括弧、前後の空白が含まれる場合は、シングルクォートまたはダブルクォートで囲むと安全です。

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

dns:
  enable: true
  enhanced-mode: fake-ip
  nameserver:
    - 1.1.1.1
    - 8.8.8.8

proxies:
  - name: "サンプルノード"
    type: ss
    server: 192.0.2.10
    port: 443
    cipher: aes-128-gcm
    password: "your-password"

proxy-groups:
  - name: "ノード選択"
    type: select
    proxies:
      - "サンプルノード"
      - DIRECT

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

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

設定を読むときは、まず3種類の基本データに分けて考えると分かりやすくなります。マッピングはキーと値の組み合わせで、たとえば mode: rule のように記述します。リストはハイフンで始まる項目の集合で、nameserver 配下のアドレスなどが該当します。スカラーは文字列、数値、真偽値です。true と false はクォート不要で、ポートは通常数値、ノード名は文字列として記述します。真偽値をクォート付きの "false" と書くと、一部の実装では通常の文字列として扱われ、意図と異なる結果になることがあります。

YAMLでは、proxies: [ノード A, ノード B, DIRECT] のようなインライン配列も使えます。短いリストには便利ですが、ノード数が多い場合や名前に記号が含まれる場合、頻繁に管理する場合は可読性が大きく下がります。体系的な設定には、1行ずつ記述するリストが適しています。アンカー、参照、複雑な型はYAML標準の機能ですが、すべてのクライアントのオーバーライド機能で完全に保持されるとは限りません。複数のクライアントで使うなら、通常のマッピングとリストを優先してください。

解析から反映までの確認手順

設定の読み込みは3段階で確認できます。第1段階はYAML構文で、インデント、コロン、リスト形式を確認します。第2段階は項目の構造で、ノードに server がない、プロキシグループが存在しない名前を参照している、といった問題を確認します。第3段階で、リモートサーバーに到達できない、DNSの上流がタイムアウトする、システムプロキシが通信を取得していない、といった実行時の問題を調べます。「接続できない」と表示されても、すぐにルールを変更しないでください。まずクライアントログに設定解析エラーがないか、次に対象のプロキシグループでノードを選択できるか、最後に接続とDNSを確認すると、効率よく原因を絞り込めます。

共通項目、待ち受けポートと動作モード

ポート項目の役割

port はHTTPプロキシのポート、socks-port はSOCKS5プロキシのポート、mixed-port は1つのポートでHTTPとSOCKS5の両方を受け付けます。デスクトップのGUIクライアントでは通常、mixed-port だけを設定し、クライアントにシステムプロキシを自動設定させれば十分です。特定のアプリでプロキシ種別を個別に指定する必要がある場合だけ、2つのポートに分けます。複数の項目を同時に設定することはできますが、ポート番号がシステム上の他のプログラムや別のClashインスタンスと重複してはいけません。

ポート競合の典型的な症状は、コアが起動直後に終了し、ログに bind、listen、address already in use が表示されることです。まず残っているプロセスを終了するか、設定のポートを未使用の番号に変更し、ブラウザー、開発ツール、システムプロキシのポートも合わせて変更します。YAMLだけを変更して手動設定のアプリを更新しないと、コアは正常に動作しているのにアプリが接続できない状態になります。クライアントにポート設定画面がある場合は、そこから変更してください。サブスクリプションの元のポートがオーバーライド層で上書きされることがあるためです。

LAN待ち受けと制御インターフェース

allow-lan は、他のデバイスが現在のデバイス上のプロキシポートへ接続できるかどうかを制御します。false はローカル利用だけの場合に適しています。true にした場合も、実際にアクセスできる範囲は bind-address とシステムファイアウォールを合わせて判断する必要があります。LANに公開すると、同じネットワーク上のデバイスから接続を試みられる可能性があるため、制御インターフェースやプロキシポートを信頼できないネットワークへ無条件に公開しないでください。スマートフォンやテスト端末へ一時的にプロキシを提供する場合は、現在のネットワークの安全性を確認し、利用後は制限を元に戻します。

external-controller は、クライアントの画面とコアが通信する制御アドレスです。一般的には 127.0.0.1:9090 のように指定します。ローカル画面から利用する場合は、ループバックアドレスにバインドすれば十分です。secret は制御インターフェースの認証に使われ、設定後はパネルからのリクエストに対応する値を付ける必要があります。これはプロキシノードのパスワードではなく、プロキシプロトコルも変更しません。GUIクライアントが制御インターフェースを自動管理している場合は、サブスクリプション本文を何度も変更しないことをおすすめします。コアの状態を画面から読み取れなくなる可能性があるためです。

mixed-port: 7890
allow-lan: false
bind-address: "127.0.0.1"
mode: rule
log-level: info
ipv6: false
external-controller: "127.0.0.1:9090"
secret: "your-controller-secret"

Rule、Global、Direct

mode: rule は rules を上から順に照合する、日常利用で最も一般的なモードです。global はルール判定を省略し、通信をすべてグローバルプロキシグループへ送ります。特定のノードが使えるかを短時間で確認するには便利ですが、ルール設定が正しいかを判断する方法にはなりません。direct はプロキシノードを経由せず直接接続するため、問題がプロキシ経路にあるかを切り分ける際に使えます。多くのクライアントでは画面上でモードを切り替えられ、ファイル内の mode を実行時設定で上書きします。トラブル対応では画面の状態と実際の設定を両方確認してください。

log-level は通常、silent、error、warning、info、debug から選択します。普段は info が適切です。ルールのヒット、DNSクエリ、接続ハンドシェイクを調べる場合は、一時的に debug へ変更できます。デバッグログは情報量が多いため、確認後は通常のレベルに戻してください。ipv6 はコアがIPv6関連の機能を処理するかどうかを決めますが、最終的な結果はシステムのネットワーク、DNSの応答、ノードの対応状況にも左右されます。ネットワークに安定したIPv6環境がない場合は無効にするとエラー経路を減らせます。完全なIPv6環境がある場合は、必要に応じて有効にしてください。

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

DNSブロックが解決する問題

プロキシルールはドメイン名に依存することが多い一方、アプリが接続を確立するときはシステムへIPアドレスだけを渡す場合があります。ドメイン解決がすべてコアの外で行われると、ルールエンジンは元のドメイン名を失い、IPルールでしか処理できなくなる可能性があります。dns.enable でコアのDNSモジュールを有効にすると、ドメインクエリをルール、プロキシ出口、キャッシュと連携させられます。これはシステムDNSを単に別のアドレスへ置き換える機能ではなく、名前解決を通信処理の一部に組み込む機能です。

nameserver は主要な上流リゾルバーです。default-nameserver は主に暗号化DNSサーバー自身のドメイン名を解決するために使われ、通常は直接到達できるIPアドレスを指定します。これにより「リゾルバーのドメイン名を先に解決する」という循環依存を避けられます。fallback には別の解決元を指定でき、フィルター条件と組み合わせて予備の結果を使うタイミングを決めます。新しいmihomo設定では、proxy-server-nameserver を使ってプロキシサーバーのドメイン名だけを解決し、ノードサーバーの解決経路と通常のWebサイト検索が干渉するのを防げます。

dns:
  enable: true
  listen: "127.0.0.1:1053"
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: "198.18.0.1/16"
  fake-ip-filter:
    - "*.lan"
    - "localhost.ptlogin2.qq.com"
    - "+.stun.*.*"
  default-nameserver:
    - 1.1.1.1
    - 8.8.8.8
  nameserver:
    - "https://1.1.1.1/dns-query"
    - "https://8.8.8.8/dns-query"
  proxy-server-nameserver:
    - 1.1.1.1

Fake-IPの仕組み

enhanced-mode: fake-ip を有効にすると、コアは予約アドレス範囲のマッピングアドレスをアプリへ返し、そのアドレスに対応する元のドメイン名を記録します。アプリが続いてそのアドレスへ接続すると、コアはドメイン名を復元してドメインルールを適用できます。そのため、アプリがIPアドレスへの接続だけを開始しても、DOMAIN、DOMAIN-SUFFIX、GeoSite系のルールが正確にヒットする可能性があります。通常の予約範囲は 198.18.0.0/16 にあり、このアドレスはベンチマーク用ネットワークに使われるため、パブリックな宛先としてアクセスしてはいけません。

Fake-IPは、Webサイトが実際に予約アドレスへ名前解決されたことを意味しません。また、予約アドレスへ直接接続してインターネット到達性をテストするものでもありません。通信が現在のコアを経由し続けることが前提です。アプリがシステムプロキシやTUNを迂回し、マッピングアドレスを取得した後に直接ネットワークへ接続すると、アクセスに失敗します。したがって「解決結果が198.18で始まっている」ことだけでは障害の証拠になりません。アプリの通信が取得されているかを合わせて確認してください。

fake-ip-filter は、マッピングに適さないドメインを除外します。LAN機器の検出、プリンター、オンラインゲーム、STUN、時刻同期、実際のアドレスが必要な一部のサービスでは、実IPの解決結果が必要になることがあります。ネット上の大きなリストをそのままコピーして長期利用するのは避けてください。除外範囲が広すぎると、ドメイン復元能力が弱まります。最小構成から始め、明確な互換性問題が発生したドメインだけを追加し、理由を記録する方法が安全です。

Redir-HostとDNSリークの確認

redir-host は実IPを返し、スニッフィング、マッピング、既存の解決情報を通じてドメイン名との関連付けを試みます。Fake-IPと互換性のない一部の環境では分かりやすい一方、ドメインルールの安定性はリクエスト経路に左右されやすくなります。どちらのモードにも、環境を問わない絶対的な優劣はありません。デスクトップでTUNを使い、ドメインルールを完全に適用したい場合は、まずFake-IPを試してください。ルーター、特殊なLANサービス、マッピング互換性の問題が明確な場合は、Redir-Hostを検討します。

DNSのトラブル対応では、リクエスト経路を段階的に確認します。システムのリクエストがコアの待ち受けポートへ入っているか、コアがどの上流を使ったか、上流への接続が直接かプロキシ経由か、結果がキャッシュされているか、最終的にどのルールへ入ったかを確認してください。nameserver を変更するだけでは、すべての問題を解決できないことがあります。ブラウザーが独自のセキュアDNSを使っている場合や、システムが古い結果をキャッシュしている場合もあります。設定変更後はコアを再読み込みし、必要に応じてシステムとブラウザーのキャッシュを消去してください。

検査結果でDNSの出口が想定と異なる場合は、まずブラウザー独自のDNS設定を確認し、次に nameserver-policy、予備リゾルバー、ルールモードを確認します。詳しい操作はClashのDNSリーク検査と防止設定の実践ガイドを参照してください。「リゾルバーの所在地」と「接続の出口」を混同しないことも重要です。DNSクエリに応答する上流と、Webサイトへの接続を行うノードは、関連はありますが完全に同じ経路ではありません。

プロキシノードの項目とプロトコルの違い

ノード定義に共通する基本構造

proxies の各項目は、利用可能な出口を表します。すべてのノードには少なくとも一意の name、プロトコルの type、サーバーの server、ポートの port が必要で、そのほかの項目はプロトコルによって異なります。ノード名は画面表示だけでなく、プロキシグループから文字列で参照されます。名前を変更したら、すべての proxy-groups も更新してください。名前は大文字と小文字を区別し、前後の余分な空白でも参照に失敗することがあります。

server にはIPアドレスまたはドメイン名を指定できます。ドメイン名を使う場合は、ノードサーバー自体の名前解決に成功してから後続の接続を確立します。これが proxy-server-nameserver が役立つ理由です。ポートは数値で記述し、認証情報は通常文字列で記述します。サンプル設定のアドレスや認証情報は構造の説明用です。実際にはサブスクリプションまたはサービス提供者の指定に従い、プロトコル名だけから暗号化方式、トランスポート、サーバー名を推測しないでください。

Shadowsocks、Trojan、VLESSの例

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

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

  - name: "VLESS WSサンプル"
    type: vless
    server: 192.0.2.30
    port: 443
    uuid: "11111111-2222-3333-4444-555555555555"
    network: ws
    tls: true
    servername: "edge.example.net"
    ws-opts:
      path: "/proxy"
      headers:
        Host: "edge.example.net"

Shadowsocksの主要項目は cipher と password で、どちらもサーバー側と一致している必要があります。Trojanは通常TLS上で動作し、sni はハンドシェイクで送るサーバー名を指定します。VLESSは項目の組み合わせが多く、TLS、Reality、WebSocket、gRPC、通常のTCPなどで差が生じます。設定で network: ws を指定した場合は、ws-opts のパスとHostもサーバー側と一致させてください。トランスポートを誤ると、サーバーポートへのTCP接続は確立できても、プロトコルのハンドシェイクには失敗します。

skip-cert-verify: true は証明書検証をスキップしますが、汎用的な修復策として使うべきではありません。証明書エラーは、端末の時刻が正しくない、サーバー名が一致しない、証明書チェーンに問題がある、中間ネットワークが干渉しているなどの原因で発生します。まず sni、servername、システム時刻を確認し、本当にテスト上の理由がある場合だけ使用を判断してください。本番環境では証明書検証を有効にしておく方が、実際の設定ミスを見つけやすくなります。

UDP、ネットワークインターフェースとチェーンプロキシ

udp: true は、ノードでUDP転送を試行できることをコアに伝えます。ただし実際に使えるかどうかは、プロトコル、サーバー、ネットワーク環境にも左右されます。この項目を有効にしただけで、すべてのUDPアプリが自動的に動作するわけではありません。アプリの通信もTUNまたは透過プロキシによって正しく取得される必要があります。ゲーム、音声通話、QUICに問題がある場合は、まずログでUDPセッションがコアに入っているか確認し、その後でノードの対応状況を調べてください。

interface-name は、送信に使うシステムのネットワークインターフェースを指定できます。複数のNIC、ダイヤルアップ、ルーター環境に適しています。通常のデスクトップユーザーは設定する必要がありません。誤ったインターフェース名を指定すると、すべての接続が存在しない、または到達できないNICへ向かいます。routing-mark は主にLinuxのポリシールーティング用で、他の設定からそのままコピーするのには適していません。

mihomoでは、dialer-proxy などの仕組みにより、あるノードが別のプロキシを経由して基盤接続を確立できます。特定のチェーン出口に利用できますが、経路が長くなるほどDNS、ハンドシェイク、トラブル対応が複雑になります。まず各区間が単独で動作することを確認してからチェーン化してください。基礎ノードのテストに合格していない段階で、チェーンプロキシ、特殊なトランスポート、インターフェース指定を同時に追加しないでください。

ノードがサブスクリプション由来の場合の変更方法

サブスクリプションの更新では、ノード一覧全体が置き換えられることが一般的です。サブスクリプションから生成された proxies を直接編集すると、次回の更新で変更が失われる可能性があります。SNIを固定する、特定のノードを除外する、UDPを調整するといった変更には、クライアントのオーバーライド、スクリプト、ノード変換機能を優先して使ってください。Clash Plus、Clash Verge Rev、FlClash、Clash Nyanpasuではオーバーライドの入口が異なりますが、原則は同じです。元のサブスクリプションをデータソースとして保持し、ローカルの差分は独立した層に置きます。

プロキシグループの種類、参照関係と選択ロジック

Select、URL-Test、Fallback、Load-Balance

プロキシグループは、ルールとノードの間で通信を振り分ける層です。select はユーザーがノードまたは下位のプロキシグループを手動で選択する方式で、「ノード選択」「ストリーミング」「ダウンロード」など、出口を明確に制御したい場合に適しています。url-test はテスト結果に基づいて条件を満たすノードを自動選択し、利用可能な接続へ自動で切り替えたい場合に向いています。fallback はリスト順に最初の利用可能なノードを選ぶため、最小のテスト値よりも優先順位を重視します。load-balance はポリシーに従って複数ノードへ接続を分散します。セッションの一貫性への影響を理解しているユーザー向けの方式です。

自動テストには通常、url と interval が必要です。テストURLは安定していて応答が軽く、対象ネットワークの経路を反映できるものを選びます。間隔が短すぎると不要なリクエストが増え、長すぎるとノードの変化を発見するのが遅れます。tolerance はテスト値が近い場合の頻繁な切り替えを抑えるためのもので、1回のテスト結果を実際のダウンロード速度とみなしてはいけません。ノードの測定値、Webページの初回応答、継続的なスループット、混雑時間帯の安定性は、それぞれ異なる指標です。

proxy-groups:
  - name: "ノード選択"
    type: select
    proxies:
      - "自動選択"
      - "フェイルオーバー"
      - "SSサンプル"
      - "Trojan TLSサンプル"
      - DIRECT

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

  - name: "フェイルオーバー"
    type: fallback
    url: "https://www.gstatic.com/generate_204"
    interval: 600
    proxies:
      - "Trojan TLSサンプル"
      - "SSサンプル"

プロキシグループは他のプロキシグループを参照できる

グループ内の proxies には、ノードだけでなく別のプロキシグループや組み込み出口の DIRECT、REJECT も指定できます。この組み合わせは階層構造の構築に適しています。下位グループがノードの健全性を確認し、中位グループが用途別の選択を担い、上位グループをルールの送信先にします。たとえば「ストリーミング」グループに「ノード選択」と複数の地域グループを含め、地域グループ内で自動テストを行う構成です。

参照関係では循環を避ける必要があります。AグループがBを含み、BもAを含むと、コアは最終的な出口を決定できません。プロキシグループ名とノード名を混同しないことも重要です。大規模な設定ではグループ名に一貫した接頭辞を付けると管理しやすくなりますが、記号を増やしすぎないでください。ログ検索には装飾的な文字列より、意味が明確な用途名の方が便利です。ルールの送信先はプロキシグループ名と完全一致していなければならず、異なる場合は読み込み時にグループが見つからないエラーになります。

Providerでノードを追加する

ノードが proxy-providers 由来の場合、プロキシグループでは use でProviderを参照でき、各ノード名を proxies に書く必要がありません。リモートのノード一覧が更新されると、自動テストグループも新しいノードを受け取ります。filter と exclude-filter では名前による絞り込みができますが、正規表現とサブスクリプションの命名に依存するため、提供元が名前を変更すると結果が空になる可能性があります。フィルターを使うグループには確認手段を用意し、地域キーワードが永遠に変わらないと考えないでください。

proxy-providers:
  main-subscription:
    type: http
    url: "https://config.example.net/subscription.yaml"
    path: "./providers/main.yaml"
    interval: 3600
    health-check:
      enable: true
      url: "https://www.gstatic.com/generate_204"
      interval: 600

proxy-groups:
  - name: "サブスクリプションノード"
    type: select
    use:
      - main-subscription

  - name: "自動テスト"
    type: url-test
    use:
      - main-subscription
    url: "https://www.gstatic.com/generate_204"
    interval: 600

保守しやすいグループ階層の設計

プロキシグループは多ければ細かく制御できるというものではありません。階層を1つ増やすたびに、ユーザーが理解すべき選択状態とトラブル対応の分岐が増えます。基本構成は、総合入口グループ、自動選択グループ、明確な用途がある少数の業務グループという3層に抑えられます。ルールは通常、総合入口を指し、独立した出口が本当に必要なサービスだけに業務グループを作ります。手動制御を残しつつ、サブスクリプションの更新後に意味の似たグループが何十個も並ぶ事態を避けられます。

「ルールにヒットしたのに想定したノードを使わない」場合は、ログのルール送信先から確認します。まずルールがどのグループへ送られたか、次にそのグループで現在どの子グループが選ばれているか、最後に実際の下位ノードを確認してください。画面で最上位のグループ名だけを見ると、下位の自動選択を見落としやすくなります。ノードを切り替えても既存の接続がすぐに移行するとは限りません。検証時は接続を再確立するか、対象アプリのセッションを終了してから試してください。

ルール構文、照合順序とフォールバック戦略

ルールは上から順に照合され、最初の一致で停止する

rules は順序を持つリストです。コアは1行目から確認し、最初に一致した項目で検索を停止して、ルール末尾に指定されたプロキシへ接続を渡します。そのため、ルールは数より順序が重要です。完全一致のドメイン、特殊な用途、拒否したい項目は前方に置き、広いドメインサフィックス、IPネットワーク、地域ルールは後方に配置します。最後に MATCH で未一致の接続を処理します。

MATCH を途中に置くと、その後のすべてのルールが機能しなくなります。広すぎる DOMAIN-SUFFIX を完全一致の例外より前に置くと、本来別のプロキシへ送るべきサブドメインまで先に取得されます。ルールを変更するときは、その行自体が正しいかだけでなく、前にもっと広いルールがないかも確認してください。ログのルール種別とプロキシ名が、実際にどこでヒットしたかを判断する直接的な手がかりです。

rules:
  - DOMAIN,api.example.com,ノード選択
  - DOMAIN-SUFFIX,example.net,ノード選択
  - DOMAIN-KEYWORD,stream,ストリーミング
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - GEOIP,LAN,DIRECT
  - GEOSITE,private,DIRECT
  - GEOSITE,category-ads-all,REJECT
  - MATCH,ノード選択

ドメインルールの違い

DOMAIN は api.example.com のような完全なドメイン名だけに一致し、他のサブドメインには自動で一致しません。DOMAIN-SUFFIX,example.com はルートドメインとサブドメインに一致し、サイト全体に同じプロキシを使う場合に適しています。DOMAIN-KEYWORD はドメイン名に指定文字列が含まれていれば一致する可能性があり、範囲が広いため、短いキーワードでは無関係なサイトまで巻き込むことがあります。完全なドメイン名やサフィックスを使える場合は、キーワードルールを優先しないでください。

GEOSITE は分類データベースのドメイン集合を参照し、大規模なサービス分類の管理に適しています。結果は、ローカルにGeoSiteデータが存在するか、ルールセット名が正しいか、データが適切に更新されているかに依存します。データベースが古いと新しいドメインに一致しないことがあり、分類名を誤ると設定の読み込み時やルール初期化時にエラーが発生します。詳しい管理方法はGeoIPとGeoSiteデータベース更新ガイドをご覧ください。

IPルールとno-resolve

IP-CIDR はIPv4ネットワークに、IP-CIDR6 はIPv6ネットワークに一致します。ルール末尾の no-resolve は、現在の接続に宛先IPがない場合、このルールに一致させるための追加DNSクエリを発行しないことを示します。LANのネットワークや既知のIP集合でよく使われ、不要な名前解決を減らし、ドメインルールの後に再度クエリが発生するのを防げます。ただし、ドメイン解決結果がなければ判断できないIPルールに、このパラメーターを機械的に付けるべきではありません。

GEOIP は、宛先IPが属する地域データベースの分類に基づいて接続を処理します。IP層で動作し、ドメインを分類する GEOSITE とは異なります。1つのドメインが世界各地に分散したアドレスを使うこともあり、解決結果はネットワークの場所によって変わる可能性があります。そのため、GeoIPだけではサービスの事業地域を正確に表せないことがあります。Webサイトやサービス単位で振り分けるならドメイン集合を優先し、実際の宛先ネットワークで処理したい場合にIPルールを使います。

DIRECT、REJECT、MATCH

DIRECT はローカルネットワークから直接接続します。LAN、システムサービス、明確にローカル出口が必要な宛先に適しています。REJECT は接続を拒否し、確認済みの広告やトラッキングドメインなどに使います。拒否範囲が広すぎると、ページのリソース不足、ログイン失敗、アプリの繰り返し再試行を招くため、ログを確認しながら調整してください。MATCH は最終的なフォールバックで、ドメインやIPの条件を判定せず、それまでに一致しなかったすべての接続をこのプロキシへ送ります。

分かりやすい標準構成は、LANとプライベートドメインを直接接続し、明確な拒否対象を用途に応じて許可または拒否し、特定のサービスを業務グループへ送り、それ以外を総合入口グループへ渡す方法です。出所が不明な大量のルールをそのまま統合して、一度で動くと期待しないでください。ルール同士が上書きし合い、異なるリストが同じドメインに相反するプロキシを指定することがあります。新しいルールセットを追加したら、代表的なドメインをいくつか選び、ログでヒット順を確認してください。

プロキシProvider、ルールセットと外部ファイル

Providerが解決する管理上の課題

ノードやルールが増え続けると、すべての内容を1つのYAMLに詰め込むのは更新しにくくなります。proxy-providers はノード集合を読み込み、rule-providers はルール集合を読み込みます。メイン設定にはソース、キャッシュパス、更新間隔、参照関係だけを残せるため、リモート内容の更新ごとにメインファイル全体を書き直す必要がありません。Providerはサブスクリプションや公開ルールセットに適していますが、ダウンロード、キャッシュ、形式という3種類の依存も生じます。トラブル対応では、メイン設定の解析失敗とリモートファイルの更新失敗を分けて考えてください。

type: http はネットワークアドレスから取得し、type: file はローカルファイルを読み込みます。path はキャッシュまたはファイルの場所で、通常は実行ディレクトリからの相対パスを使います。クライアントによって設定ディレクトリが異なるため、別の端末にある絶対パスをそのままコピーしないでください。interval は秒単位で更新間隔を制御します。短すぎると頻繁なリクエストが発生し、長すぎると変更の反映が遅れます。クライアントでサブスクリプションを手動更新した際に、Providerも更新される場合があります。

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

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

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

behaviorとファイル内容を一致させる

behavior: domain は、ルールセットに主にドメイン項目が含まれることを示します。内容には完全なドメイン、サフィックス、対応するドメインルール形式を指定できます。ipcidr はIPネットワーク、classical はより完全な従来型ルール構文をルールセットに保持できます。behaviorと実際の内容が一致しないと、ルールを解析できなかったり、意図どおりに一致しなかったりします。種類はファイル名だけで判断せず、ルール提供元の形式に基づいて選んでください。

一般的なYAMLルールセットでは、項目を payload の下に置きます。domain形式の簡略項目にはドメインサフィックスを使い、classical形式では種別を含む完全なルールを記述できます。メイン設定では RULE-SET によってプロキシを指定するため、Providerファイルでは通常、各行にプロキシグループを繰り返し書かず、照合内容だけを定義します。ルールソースにすでにプロキシ項目が含まれている場合は、classical形式が本当に必要か確認してください。

payload:
  - "example.com"
  - "+.example.net"
  - "service.example.org"

更新、キャッシュと失敗時のフォールバック

リモートルールの更新に失敗した場合、コアは通常、既存のキャッシュを使い続けようとします。ただし初回読み込みでローカルキャッシュがない場合、該当するProviderは利用できない可能性があります。ログのHTTPステータス、タイムアウト、ファイル権限、形式エラーは、それぞれ異なる問題を示します。まずブラウザーやコマンドラインでアドレスへアクセスできるか確認し、次にクライアントが path の指すディレクトリへ書き込めるか確認します。最後に、ダウンロード内容が想定したYAMLまたはMRS形式であり、ログインページやエラーページではないことを確認してください。

キャッシュファイルを複数の実行インスタンスから同時に書き込まないでください。同じ端末で2つのクライアントを起動し、同じ設定ディレクトリを使うと、ポート競合やProviderファイルの競合が発生する可能性があります。設定を移行する際は、必要なローカルルールファイルも一緒に移行するか、新しい環境からリモートソースへアクセスできることを確認してください。メインYAMLだけをコピーしてローカルProviderを忘れると、メイン設定には参照があるのに実ファイルが存在しない状態になります。

ルールセットの順序はメイン設定で決まる

Providerは多くの項目を1つの参照にまとめますが、上から順に最初の一致を採用する原則は変わりません。2つのルールセットの範囲が重複する場合、先に書かれた RULE-SET が先に一致する機会を得ます。大規模なルールセットをすべての完全一致ルールより前に無条件で置くと、ローカルの例外が隠れてしまいます。公開ルールセットを上書きしたい場合は、対応する RULE-SET より前に少数の完全一致ルールを配置してください。

ルールソースが増えるほど、競合の確認が重要になります。各ルールセットの用途、behavior、更新元、対象プロキシを記録し、長期間使っていないものや機能が重複する集合は削除することをおすすめします。サービスの振り分けに異常がある場合は、何万件ものリモートルールを闇雲に検索するより、最近追加したProviderを一時的に無効にする方が効率的です。データベースやルールセットの更新後は、ダウンロードが成功したかだけでなく、重要なドメインを再度確認してください。

オーバーライド、マージ、サブスクリプション更新とシステムのトラブル対応

ローカルの変更をオーバーライド層に置く理由

サブスクリプション設定のライフサイクルは通常、「リモートで生成、クライアントがダウンロード、ローカルで読み込み、定期的に更新」という流れです。ダウンロード後の元ファイルを直接編集すると、次回の更新で置き換えられやすくなります。オーバーライド層には、固定ポート、DNS調整、少数のルール追加、プロキシグループの初期選択など、ローカル固有の差分を保存します。サブスクリプションはノードと基本構造を提供し、ローカル層は端末固有の設定を担うため、役割が明確になります。

クライアントによってオーバーライドの呼び方や機能は完全には同じではなく、オーバーライド、拡張、マージ、スクリプト、前処理などと表示されることがあります。Clash Plus、Clash Verge Rev、FlClash、Clash NyanpasuなどのGUIクライアントには通常、設定管理の入口がありますが、マージの意味は現在のクライアント画面とドキュメントを確認してください。単純なキーと値の上書きは理解しやすい一方、配列のマージには注意が必要です。rules、proxies、proxy-groups はいずれも順序または参照関係を持つリストだからです。

マッピングの上書きと配列のマージの違い

マッピング項目は通常、キー単位で上書きされます。たとえば基本設定に log-level: info があり、オーバーライド層で debug にすると、最終値は1つだけになります。ネストしたマッピングは深くマージされる場合もあれば、ブロック全体が置き換えられる場合もあります。オーバーライド機能が dns ブロック全体を置き換える場合、ipv6: false だけを書くと、元の nameserver が消える可能性があります。オーバーライド後は、断片だけでなくクライアントが生成した最終設定を確認してください。

配列はさらに複雑です。ルールを追加する場合は挿入位置を考える必要があります。先に一致させたいローカルの例外は公開ルールセットより前に置き、通常のフォールバックルールは MATCH の後に追加してはいけません。プロキシグループの配列を全体置換すると、サブスクリプションにあったグループがすべて消える可能性があります。単純に追加すると、同名グループが生じることもあります。ノード配列を名前で重複排除するか、位置に応じて追加するかも実装によって異なります。マージ動作を確認できない場合は、最小のテスト設定で検証してからメインのサブスクリプションへ適用してください。

# 基本設定
mode: rule
log-level: info
rules:
  - GEOSITE,private,DIRECT
  - MATCH,ノード選択

# ローカル対象
# 1. 既存のプライベートドメインルールを保持
# 2. MATCHの前に完全一致の例外を追加
# 3. ログレベルだけを一時的にdebugへ変更

上記のローカル対象は、「ファイル末尾にルールを1行追加する」だけでは実現できません。既存の MATCH が先にフォールバックするためです。クライアントが対応するルール前置き領域に例外を追加するか、マージ後の完全なルール配列を生成してください。クライアントが rules ブロック全体の置換にしか対応していない場合は、保持したい元のルールもオーバーライド結果に含める必要があります。

再現可能なトラブル対応手順

第1段階では、設定の解析に成功したか確認します。YAMLの行番号、未知の項目、重複する名前、存在しない参照を確認してください。第2段階では、コアが起動して想定ポートを待ち受けているか確認します。起動直後に終了する場合は、まずポート競合、設定ディレクトリの権限、制御インターフェースの競合を調べます。第3段階では、アプリの通信がコアに入っているかを確認し、ログで対象ドメインや接続を確認できるか調べます。接続が見えない場合は、ノードを変更するのではなく、システムプロキシ、TUN、アプリ自身のプロキシ設定を確認してください。

第4段階ではルールのヒットを確認します。ログには、ドメインまたはIPがどの種類のルールに一致し、どのプロキシグループへ入ったかが表示されるはずです。プロキシが想定と違う場合は、ルールの順序とProviderの内容を確認します。プロキシが正しければ、プロキシグループを展開して実際の下位ノードを確認してください。第5段階ではDNSを確認します。ドメインを解決できない、Fake-IPの通信が取得されない、ブラウザーが独自DNSを使うといった問題は、Webページを開けない症状につながります。第6段階ではノードの接続段階を確認します。タイムアウトは経路に到達できないことが多く、接続拒否はポートが待ち受けていない場合によく発生します。TLSエラーではサーバー名と時刻を、認証エラーでは認証情報を確認してください。

各段階を終えるたびに、明確な結論を残してください。たとえば「設定解析に成功し、7890が待ち受け中。ブラウザーの接続はコアに入り、ノード選択グループに一致したが、TLSハンドシェイクに失敗した」という記録です。これにより、すべての設定ブロックを行き来して変更するのではなく、問題をノード項目まで絞り込めます。起動直後のクラッシュについてはClashクライアント起動クラッシュの確認リストも参照してください。画面の入口が分かりにくい場合はプロキシ、設定、ログの3画面ガイドをご覧ください。

サブスクリプション更新後の回帰チェック

サブスクリプションを更新すると、ノード名、プロキシグループ、ルールの送信先、Providerのアドレスが変わる可能性があります。更新後は少なくとも4項目を確認してください。元のローカルオーバーライドが有効であること、ルールが参照するプロキシグループが存在すること、自動選択グループに利用可能なノードがあること、DNSとポートがサブスクリプション項目で意図せず上書きされていないことです。プロキシグループが突然空になった場合は、フィルターの正規表現が新しいノード名にも一致するか確認してください。

長期的な管理では、サブスクリプション内部の構造への依存をできるだけ減らします。たとえばすべてのルールを安定したローカルの総合入口グループへ向け、そのグループからサブスクリプションのノードを参照する方が、数十件のルールに具体的なノード名を直接書くより更新に強くなります。ノードの変更はサブスクリプションに任せ、プロキシ選択の意図はローカル設定で表現します。両者を分離すると、クライアントの移行も容易です。

最終設定のセルフチェックリスト

• YAMLはスペースでインデントされ、トップレベルのキーとリスト階層が明確で、タブや全角の句読点がない。
• 待ち受けポートが競合しておらず、システムプロキシまたはTUNが実際に動作しているコアを指している。
• 各プロキシグループが参照するノード、下位グループ、Providerが存在し、グループ間に循環参照がない。
• ルールが完全一致から広い範囲の順に並び、すべてのフォールバックルールが末尾にあり、送信先の名前が正確である。
• DNSの上流へ到達でき、Fake-IPのフィルターが必要最小限に保たれ、ブラウザー独自のDNSも確認済みである。
• オーバーライド適用後の最終設定に、元のサブスクリプションが必要とする項目が残っており、更新後に回帰検証を完了している。

項目の確認が終わったら、入門ガイドに戻り、読み込み、プロキシの選択、接続、検証の流れで操作してください。クライアントを変更する場合はクライアントダウンロードページへ進みます。よくある症状と簡潔な回答はよくある質問にまとめています。エラーが発生した段階を確認した後、対応方法をすばやく探すのに便利です。