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

CHAPTER / 01

YAML構造の全体像と解析順序

まずトップレベル、次に参照関係を確認

読み込めるClash設定が、正しくトラフィックを振り分けられる設定とは限りません。YAMLパーサーはまずインデント、リスト、キーと値の型を処理し、続いてコアがトップレベルのフィールドを読み込み、ノード、プロキシグループ、ルールプロバイダー、ルール間の参照を解析します。校正時はこの順序で確認してください。まずファイルが正しいYAMLであること、次に参照される名前が実際に存在すること、最後に実行時の挙動を確認します。いきなり特定のルールから調べると、上流にある名前やインデントの誤りを見落としがちです。

代表的なトップレベル領域には、待受ポート、動作モード、ログレベル、コントロールAPI、DNS、プロキシノード、ノードプロバイダー、プロキシグループ、ルールプロバイダー、ルールがあります。フィールドの順序は通常意味を変えませんが、用途ごとに一定の順序で整えると保守性が大きく向上します。基本の待受フィールドを上部、大きなノードとプロバイダーを中段、プロキシグループをノードの後、ルールを最後に置く構成がおすすめです。読むときに「材料—組版—印刷」という自然な流れになります。

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: example.net
    port: 443
    cipher: aes-128-gcm
    password: "your-password"

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

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

上記の設定は完全な参照チェーンを示しています。ルールがリクエストを「ノード選択」に渡し、プロキシグループが「サンプルノード」を参照し、ノード欄が実際の接続パラメータを提供します。名前のどこかに余分なスペース、全角記号、大文字・小文字の違いがあるだけで参照は切れてしまいます。日本語の名前も使用できますが、長期運用では文字列を完全に一致させてください。名前にコロン、シャープ、カンマ、前後の空白が含まれる場合は、パーサーがYAML構文と誤認しないよう引用符で囲むのが安全です。

インデント、リスト、データ型

YAMLは空白で階層を表現するため、タブをインデントに使えません。2つの空白で統一し、同じ階層のフィールドを厳密にそろえるのがおすすめです。ハイフンで始まる行はリスト項目です。ハイフンに続くノードオブジェクトには、さらに複数のキーを含められます。最も多い障害は、プロキシグループの proxies リストを誤った階層にインデントすることです。その結果、コアが未知のフィールドとして扱ったり、プロキシグループに必要な項目がないと判断したりします。

ブール値は true または false と記述し、ポートは通常、引用符なしの整数で指定します。名前やアドレスは文字列として扱われます。一部のパーサーは yes や on など古いブール表記も受け付けますが、クライアント間で移行すると差異が生じやすいため、安定した設定では明確な標準表記を使ってください。数字だけのパスワード、ゼロから始まる識別子、特殊文字を含む文字列は、型の自動推定を防ぐため引用符で囲みます。

最小構成でエラーを切り分ける

数千行に及ぶサブスクリプションファイルを扱う場合、元ファイルを何度も編集するより、ポート1つ、ノード1つ、選択グループ1つ、ルール2つだけを残した最小構成を別名で保存する方が効果的です。最小構成が読み込めれば、基本フィールドとクライアント環境は正常です。その後、DNS、プロバイダー、カスタムルールを段階的に追加すれば、どの部分でエラーが発生したか特定できます。追加は一度に1つの論理領域だけにし、再読み込み後すぐログを確認してください。複数の変更を同時に入れると因果関係が判断できません。

CHAPTER / 02

ポート、モード、コントロールAPIなどの共通フィールド

待受ポートの役割と範囲

port はHTTPプロキシの待受、socks-port はSOCKS5プロキシの待受に使います。mixed-port は同じポートで両方のリクエストを受け付けます。GUIクライアントでは通常 mixed-port が優先されます。システムプロキシとSOCKS5対応アプリで1つの入口を共有できるためです。3つを同時に有効にする必要はありません。同時に設定する場合は、ポートが重複せず、ブラウザーのデバッグツール、ローカル開発サーバー、別のプロキシソフトに使われていないことを確認してください。

システムプロキシ設定は、OSのHTTPまたはSOCKSリクエストを待受ポートへ向けるだけで、設定内の数値を自動修正するものではありません。mixed-port を変更した後は、クライアントのシステムプロキシ設定が新しいポートを読み込んでいるか確認してください。ブラウザーに接続拒否が表示され、コアログにリクエスト記録がない場合は、まずシステムプロキシのアドレスと実際の待受ポートを確認し、ルールを変更するのは後にします。

port: 7891
socks-port: 7892
mixed-port: 7890
redir-port: 7893
tproxy-port: 7894

allow-lan: false
bind-address: "*"
mode: rule
log-level: info
ipv6: false

redir-port と tproxy-port は主にLinuxゲートウェイ、ルーター、透過プロキシ向けです。OSの転送ルールとの連携が必要で、YAMLに記述するだけではトラフィックは自動的にコアへ入りません。デスクトップユーザーがこの2つのポートを手動で有効にする必要は通常ありません。より多くのアプリの通信を取り込む場合は、対応クライアントでTUNモードを設定する方が適しています。Linuxクライアントとコアの入口はダウンロードページのLinuxセクションで確認できます。

LANアクセスとバインドアドレス

allow-lan は、本機以外のデバイスからの接続を受け付けるかどうかを決めます。false なら主に現在のデバイスだけで使い、true にした場合は bind-address、OSのファイアウォール、LANアドレスを合わせて実際の到達範囲を判断する必要があります。LAN待受を有効にする前に、自宅やオフィスネットワークの境界を確認し、コントロールAPIを信頼できないネットワークへ公開しないでください。

bind-address は待受アドレスを指定します。アスタリスクはコアのルールに従って利用可能なインターフェースで待ち受けることを示しますが、具体的な動作はプラットフォームやクライアント実装にも左右されます。本機だけで使う場合はクライアントの既定値で問題ありません。スマートフォンからPCのプロキシを使う場合は、同じLANに接続し、スマートフォンのプロキシ設定にPCのLANアドレスと mixed-port を入力し、対応するファイアウォールの受信ルールも許可してください。

rule、global、directモード

mode: rule は rules を上から順に照合するモードで、日常利用では最も一般的です。global はトラフィックをグローバルプロキシグループへ渡すため、特定ノードに接続できるかを一時的に確認するのに適していますが、既存の振り分けを迂回します。direct は直接接続するため、障害がプロキシ経路に起因するか確認するのに便利です。切り分け時は比較のため一時的に切り替え、結論が出たらルールモードへ戻してください。

モード切り替えで変わるのはトラフィック判断の入口だけで、ノードパラメータやDNS応答が修正されるわけではありません。globalでも接続できない場合は、ノード、ネットワーク、時刻設定を引き続き確認してください。globalでは使えるのにruleでは使えない場合、問題はルール順、対象プロキシグループ、ルールプロバイダーにある可能性が高いです。モードを診断スイッチとして使う方が、ノードフィールドを繰り返し書き換えるより明確な結論を得やすくなります。

ログと外部コントローラー

log-level の主な値は silent、error、warning、info、debug です。日常利用では info にするとルールの適用状況を確認しやすくなります。複雑な問題の切り分け時だけ debug を一時的に使い、完了後は戻してください。ログに現れる「適用ルール—選択プロキシグループ—実際のノード」は一連の校正手掛かりなので、順番に確認します。

external-controller は、GUIとコアが通信するためのフィールドです。たとえば本機のループバックアドレス上のポートで待ち受けます。クライアントが通常この項目を自動管理するため、画面との接続方式を理解しないまま変更するのはおすすめしません。パネルがプロキシグループを読み込めない一方、プロキシ自体は動作している場合は、まずAPIアドレス、ポート、クライアント設定を確認し、ノードを削除しないでください。

CHAPTER / 03

DNSフィールド、拡張モード、名前解決チェーン

DNSセクションが扱うのは単一のサーバーアドレスではない

ClashのDNS設定には複数の役割があります。どのリゾルバーへ問い合わせるか、アプリが送信するDNSリクエストを取り込むか、ルール照合用にドメイン情報を保持するか、プロキシ接続前にノードサーバーのドメインをどう解決するかを決めます。nameserver を1行置き換えるだけでは解決しないことが多いのは、ノードのサーバーアドレス、直接接続ドメイン、プロキシ対象ドメインが異なる名前解決段階を通る場合があるためです。

dns.enable は内蔵DNSモジュールの有効・無効を制御します。listen は待受アドレスとポートを指定し、GUIクライアントでは通常TUNやシステム設定と連携して自動管理されます。ipv6 はDNSモジュールがIPv6の結果を返すかどうかを決めます。トップレベルの ipv6 と関係はありますが、前者は名前解決結果、後者はコア全体のIPv6利用に関わります。ネットワークに安定したIPv6経路がない場合、利用できるか不明なAAAAレコードを返すと接続待ちが発生することがあります。

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

default-nameserverとnameserverの役割分担

nameserver は主要なリゾルバーのリストで、通常のUDPアドレスやコアが対応する暗号化DNSアドレスを指定できます。暗号化DNSをドメイン名で指定する場合、コアはまずそのDNSサービスのドメインに対応するIPを知る必要があります。この起動段階を通常 default-nameserver が補助します。そのため default-nameserver には直接アクセスできるIPアドレスを指定し、先に解決が必要なドメインを再度指定しないでください。循環依存になるためです。

proxy-server-nameserver はプロキシノードのサーバードメインを解決するために使います。ノードアドレスをドメイン名で指定した場合、コアはプロキシ接続を確立する前にIPを取得する必要があり、まだ確立していないプロキシトンネルには依存できません。「ノードがすべてタイムアウトするが、ノードサーバーをIPアドレスにすると復旧する」場合は、このフィールドとローカルネットワークからDNSへ到達できるかを重点的に確認してください。

一部のmihomo設定では nameserver-policy も使われ、ドメインごとに指定したリゾルバーへ問い合わせを振り分けます。同じドメインに対してネットワーク内外で異なる結果が返る環境に有効ですが、ポリシー自体も明確に保つ必要があります。重複するドメインポリシーを大量に記述すると、DNS層とルール層の両方が振り分けを担うため、結果がどちらによるものか判断しにくくなります。通常はまずDNSを安定させ、その後ルールでトラフィックの行き先を制御します。

fake-ipとredir-host

fake-ip はアプリに予約アドレスプール内のマッピングアドレスを返し、コアがドメインとの対応関係を保持できるようにします。これにより、ドメインルールやスニッフィング後のトラフィック判断を実行しやすくなります。このアドレスは対象サイトが実際に使うIPを意味しません。アプリが偽アドレスへ接続すると、コアがマッピングを照会して実際の接続を確立します。現代のデスクトップ・モバイルクライアントに適しており、先に名前解決してから照合することで情報が失われる問題も減らせます。

redir-host は従来の名前解決に近く、アプリが実際の解決結果を受け取ってから接続します。ローカルネットワーク機器、LAN探索、特殊なDNS動作に依存するアプリはこのモードの方が互換性を保ちやすい場合がありますが、コアが得られるドメインの文脈はfake-ipより少なくなる可能性があります。どちらにも状況を無視した絶対的な優先順位はありません。クライアントの既定値、TUN実装、アプリ互換性を基準に選び、異なる設定片の間で頻繁に混在させないでください。

fake-ip-filter は偽アドレスを返すのに適さないドメインを除外します。LAN機器、時刻同期、一部のログインや接続性確認用ドメインでは実際の結果が必要になる場合があります。フィルタールールを無制限に増やすのは避けてください。一般的なドメインを大量に追加すると、fake-ipのドメインマッピングの利点が弱まります。項目を追加するたびに対応する障害現象を記録し、アプリの更新やネットワーク変更後に再検証してください。

CHAPTER / 04

プロキシノードのフィールドと接続パラメータ

すべてのノードは4つの基本情報から始まる

proxies はローカルノードのリストです。各項目には少なくとも名前、タイプ、サーバーアドレス、ポートが必要で、プロトコルに応じて認証、トランスポート、TLSのフィールドを追加します。ノード名は設定内部で参照する識別子で、プロキシグループは名前でノードを見つけます。サーバーアドレスは実際の接続先、ポートはリモートサービスの待受ポートであり、本機の mixed-port とはまったく異なります。この2種類のポートを混同することは、設定を手入力するときによくあるミスです。

ノードパラメータはサーバー側の設定と一組で一致していなければなりません。プロトコル、暗号化方式、認証情報、トランスポート層、ホスト名、パスのいずれかが一致しないと、タイムアウトやハンドシェイク失敗として現れることがあります。プロキシグループを何度変更しても、ノード自体のパラメータミスは直りません。校正時はプロトコルの基本フィールドから始め、TLS、WebSocket、その他のトランスポート項目を段階的に追加し、ログで失敗した段階を毎回確認してください。

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

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

例にあるアドレスと認証文字列は構造を示すためのものです。実際に使用する際は、正規のサービス設定から取得してください。udp はノードがUDPトラフィックを転送できるかどうかを示しますが、プロトコル実装、サーバー、ネットワーク経路にも左右されます。フィールドを true にしても、サーバー側に対応機能がなければ利用可能なUDP転送にはなりません。ゲーム、音声、一部のDNS通信に異常がある場合は、ノードの対応状況とプロキシグループがそのノードを選択しているかを別々に確認してください。

TLS、SNI、証明書検証

TLSを使うプロトコルでは、正しいサーバー名が必要になることがあります。sni はハンドシェイク時に送信する対象ホスト名で、接続に使う server フィールドと同じとは限りません。ただし、サーバー証明書とデプロイ構成には一致している必要があります。証明書名の不一致がログに出た場合は、まずサービス提供元が指定するSNIを確認し、証明書検証を無効にしないでください。

skip-cert-verify は証明書検証をスキップするかどうかを制御します。安定した設定では false を優先し、端末時刻、証明書チェーン、SNI、ネットワークによる干渉の問題を修正してください。端末時刻のずれにより、まだ有効でない証明書や期限切れ判定が誤ることがあります。システムのルート証明書環境も接続に影響します。このフィールドを true にするのは短時間の比較テストに限り、根本原因の確認の代わりにしないでください。

トランスポート層のフィールドは1つのオブジェクトとして読む

WebSocketなどのトランスポート方式には、通常パスとリクエストヘッダーが含まれます。パスのスラッシュ、大文字・小文字、エンコードはサーバー側と一致させる必要があり、Host ヘッダーがリバースプロキシのルーティングに使われることもあります。インデントを誤ると ws-opts 配下のフィールドがノードオブジェクトから外れ、コアに設定を無視されます。「TCP接続後すぐ切断される」場合は、TLSハンドシェイク、HTTPアップグレード、アプリケーションプロトコルの3段階に沿ってログを確認してください。

  - name: "WSサンプル"
    type: vmess
    server: edge.example.net
    port: 443
    uuid: "00000000-0000-4000-8000-000000000000"
    alterId: 0
    cipher: auto
    tls: true
    servername: service.example.net
    network: ws
    ws-opts:
      path: /gateway
      headers:
        Host: service.example.net

コアやプロトコルによって sni、servername などフィールド名が異なります。意味が近いからといって置き換えられるとは限りません。mihomoコアへ移行する前に、現在のクライアントが対応する範囲と照合してください。コアの関係と互換性の境界については、mihomoコアと原版Clashの違いも参照できます。

ノード名、重複項目、ヘルスチェック

ノード名は一意にしてください。同じ名前のノードが2つあると、プロキシグループの参照先が意図しないオブジェクトになったり、クライアント画面で区別できなくなったりします。サブスクリプションプロバイダーの重複名は更新後に再発することもあるため、上書き段階で接頭辞、接尾辞、フィルタールールを加える方法が適しています。名前には地域、回線、用途を含め、リアルタイムの遅延値は入れない方がよいでしょう。更新後に実態と合わなくなりやすいためです。

ノードが一覧に表示されるのは、YAMLが読み込まれたことを示すだけで、接続可能とは限りません。クライアントの接続テストを使った後、実際のウェブページや対象アプリでも確認してください。テスト先、DNS、ノードプロトコル、対象サイトは異なる経路を通ることがあるため、1つのテスト結果ですべての状況を判断できません。すべてのノードが同時に失敗する場合は、まずローカルネットワーク、DNS、システム時刻を確認します。1つのノードだけ失敗する場合に、そのノードのフィールドを重点的に調べてください。

CHAPTER / 05

プロキシグループのタイプ、参照、選択ロジック

プロキシグループはノードとルールの組版台

proxy-groups は新しいプロトコル接続を確立するものではなく、既存のノードや他のプロキシグループを、選択、テスト、フェイルオーバーに使える論理単位としてまとめます。ルールの最後の列は通常プロキシグループを指し、グループが使用するノードを決めます。プロキシグループ名には「用途」を入れ、「ノード選択」「ストリーミング」「直接接続」のようにすると、プロトコル名を並べるより読みやすくなります。

プロキシグループはノードだけでなく、前に定義した他のプロキシグループも参照できます。多層参照は地域選択と用途別の振り分けを分離するのに便利ですが、深くしすぎると切り分けが難しくなります。2〜3層を目安にし、最下層を実ノードまたはプロバイダー、中層を地域・テストグループ、最上層を用途別ポリシーにするとよいでしょう。問題が起きたら、ルールの対象から順に展開し、最終ノードまで確認します。

proxy-groups:
  - name: "自動選択"
    type: url-test
    proxies:
      - "ノード A"
      - "ノード B"
    url: "https://www.gstatic.com/generate_204"
    interval: 300
    tolerance: 80

  - name: "ノード選択"
    type: select
    proxies:
      - "自動選択"
      - "ノード A"
      - "ノード B"
      - DIRECT

  - name: "フェイルオーバー"
    type: fallback
    proxies:
      - "ノード A"
      - "ノード B"
    url: "https://www.gstatic.com/generate_204"
    interval: 300

select、url-test、fallbackの違い

select はユーザーがメンバーを手動で選択します。結果が安定して説明しやすいため、最上位の入口に適しています。クライアントが選択状態を保存する場合、設定を再読み込みしても通常は前回の選択が復元されますが、名前が変わったりグループが再作成されたりすると既定の項目に戻ることがあります。初回読み込み時の意図しない経路を減らすには、最も使いたいメンバーをリストの先頭に置いてください。

url-test はテストURLへ定期的にアクセスし、結果に基づいてメンバーを自動選択します。これはノードからテスト先への接続性と応答状況を示すもので、すべてのサイトでの実速度と同じではありません。interval はテスト間隔を制御し、短すぎるとバックグラウンドリクエストが増えます。tolerance は結果が近いときの頻繁な切り替えを抑えます。自動グループは日常の選択に適していますが、重要な用途では実際のアクセス状況も確認してください。

fallback は利用可能なメンバーをリスト順に使い、現在のメンバーが失敗すると次へ切り替えます。最短の応答時間より安定性を重視する方式です。そのためリスト順には実際の意味があり、優先回線を先頭に置きます。テストURLに現在のネットワークからアクセスできないと、すべてのノードが利用不可と誤判定される可能性があります。テスト先は安定して短い内容を返し、ノードが到達できるネットワーク範囲に合うものを選んでください。

load-balanceと通信の継続性

load-balance は複数のメンバーに接続を分散します。具体的な方式はコアの対応状況とグループ内パラメータによって異なります。1つのダウンロードを単純に複数ノードへ分割するものでも、すべてのリクエストをランダムに切り替えるものでもありません。ログイン状態や送信元アドレスに敏感なサービスでは、同一セッションで出口が変わると再認証や接続切断が発生するため、ノード間の分散に向かない場合があります。

負荷分散を選ぶ前に、サービスが出口の変化を許容するか確認してください。ウェブ閲覧や複数接続のダウンロードにはメリットがありますが、リモート管理、決済ログイン、長時間接続では経路の安定性が重要です。プロキシグループは機能数ではなく、用途の制約から設計します。明確な要件がなければ、select と1つの url-test グループで十分わかりやすい構成になります。

useでプロバイダーのノードを取り込む

ノードが proxy-providers から提供される場合、プロキシグループで use を使ってプロバイダー全体を参照でき、各ノード名を proxies に書く必要はありません。サブスクリプション更新で追加・削除されたノードもグループに反映されるため、長期運用に適しています。コアが対応していれば proxies と use を組み合わせられますが、最終メンバーに重複ノードがないか確認してください。

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

  - name: "自動速度測定"
    type: url-test
    use:
      - provider-main
    url: "https://www.gstatic.com/generate_204"
    interval: 600
    tolerance: 100

プロキシグループが空だと、それを参照するルールは有効なノードを得られません。よくある原因は、プロバイダーのダウンロード失敗、フィルター式ですべてのノードを除外、プロバイダー名の綴り違い、存在しないローカルノードの参照です。クライアント画面で空のグループが表示されたら、まずプロバイダーの状態と元のノード数を確認し、その後フィルター条件を調べてください。すぐにルールを変更する必要はありません。

CHAPTER / 06

ルール構文、順序、マッチ範囲

ルールは上から順に、最初にマッチしたものだけを使う

rules は順序を持つリストです。リクエストがルールモードに入ると、コアは先頭から確認し、マッチした時点で指定されたポリシーへトラフィックを渡して処理を終えます。より広い範囲のルールより先に、限定的なルールを置いてください。例外は、それを覆う一般ルールより前に置き、フォールバックルールは末尾に置きます。同じルールでも順序が違えば、最終的な動作は正反対になることがあります。

各ルールは通常、ルールタイプ、マッチ内容、対象ポリシーで構成され、半角の英語カンマで区切ります。対象にはプロキシグループのほか、DIRECT、REJECT などの組み込みアクションも指定できます。全角カンマは見た目が似ていますが、フィールド区切りとして認識されません。ルールをコピーした後は、句読点、前後の空白、対象名を確認してください。特に文書からコピーすると全角文字が混入しやすいので注意が必要です。

rules:
  - DOMAIN,api.example.com,DIRECT
  - DOMAIN-SUFFIX,example.com,ノード選択
  - DOMAIN-KEYWORD,example,ノード選択
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - PROCESS-NAME,example.exe,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,ノード選択

ドメインルールの精度の違い

DOMAIN は完全一致のドメインだけを対象とし、単一ホストの例外に適しています。DOMAIN-SUFFIX は指定ドメインとサブドメインに一致し、サイト全体をカバーするのに適しています。DOMAIN-KEYWORD はドメイン名に指定文字列が含まれていればマッチする可能性があり、範囲が広い分、似た名前の無関係なドメインまで誤って対象にすることがあります。まず完全なドメインとサフィックスを優先し、対象ドメインが頻繁に変化し、規則性が明確な場合だけキーワードを使ってください。

たとえば先に DOMAIN,internal.example.com,DIRECT、次に DOMAIN-SUFFIX,example.com,ノード選択 と書けば、内部ホストを直接接続にできます。サフィックスルールが先にあると、完全一致ルールは実行されません。ドメインの振り分けミスを調べるときは、ログで実際のリクエストドメインを確認し、ルールの先頭から最初にマッチし得るルールを探してください。期待するルールが存在するかだけを見るのは不十分です。

IP-CIDRとno-resolve

IP-CIDR はネットワーク範囲で対象のIPv4アドレスを照合します。IPv6には対応するIPv6ルールタイプを使います。CIDRのサフィックスはネットワークプレフィックス長を示し、範囲を広くしすぎると大量のアドレスを覆います。ルーター、プリンター、ストレージ機器へのアクセスが遠隔ノードへ送られないよう、LANのネットワーク範囲は通常、プロキシルールより前に直接接続へ設定します。

no-resolve は、このIPルールを照合する際、ドメインしかないリクエストに対して追加の名前解決を行わないことを示します。既存の対象IPだけを確認すればよいルールに適しており、不要なDNS問い合わせを減らせます。追加するかどうかはルールの目的によって決めてください。ドメインを解決して対象IPを得る必要があるルールに機械的に追加してはいけません。パラメータを写すより、名前解決のタイミングを理解することが重要です。

プロセスルールとプラットフォーム差異

PROCESS-NAME や PROCESS-PATH などのプロセスルールは、OSの権限、コアの機能、クライアントの取り込み方式に依存します。Windows、macOS、Linux、Androidではプロセス情報を取得できる条件が異なり、あるプラットフォームでマッチしても別のプラットフォームで同じ結果になるとは限りません。TUNモードでプロセスを識別できるかどうかも、クライアント実装と権限設定に左右されます。

プロセスルールが機能しない場合は、まずデバッグログでコアが認識しているプロセス名やパスを確認し、その実際の値でルールを作成します。実行ファイルの更新後はパスが変わることがあり、大文字・小文字や拡張子もプラットフォームごとに確認が必要です。複数プラットフォームで共有する設定では、ドメインルールの方が一致を保ちやすくなります。プロセスルールはプラットフォーム固有の上書きとして使い、全端末共通のサブスクリプション本文へ直接入れない方がよいでしょう。

GEOIP、ルールセット、フォールバック

GEOIP は対象IPが属するデータベース上の地域で照合します。結果はデータベースの内容と更新時期に左右されます。地域レベルの判断として後方に置くのに適していますが、明確なドメインルールの代わりにはなりません。DNSで得られるアドレスはネットワークやCDNの振り分けで変化し、同じサービスが複数地域に分散することもあります。重要な用途では、より明確なルールセットやドメインルールを使ってください。

MATCH はそれまでにマッチしなかったすべてのリクエストに一致し、末尾にしか置けません。途中に置くと、その下のルールはすべて機能しなくなります。フォールバックを直接接続にするかプロキシにするかは、設定の目的で決めます。リストにある対象だけをプロキシにするなら未分類トラフィックを直接接続にし、既定でプロキシを使うなら全体選択グループへ渡します。どちらの場合も、グループ名から結果が明確にわかるようにしてください。

rules:
  # ローカルと明示的な例外
  - DOMAIN,printer.lan,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve

  # 用途別ルール
  - RULE-SET,private-domain,DIRECT
  - RULE-SET,proxy-domain,ノード選択
  - RULE-SET,private-ip,DIRECT

  # 地域判定と最終フォールバック
  - GEOIP,CN,DIRECT
  - MATCH,ノード選択

カスタムルールの詳しい切り分けは、Clashカスタムルール構文詳解も参照してください。変更後は設定が読み込まれたかだけでなく、完全一致ドメイン、サブドメイン、IP、フォールバックを代表する対象をいくつか選び、ログのマッチルールと最終ポリシーを1つずつ確認します。

CHAPTER / 07

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

proxy-providersで更新可能なノードソースを管理する

proxy-providers は、リモートまたはローカルのノード集合をメイン設定から分離します。メイン設定はプロキシ構造、プロバイダーはノード内容を担当し、更新周期を別々に管理できます。これによりサブスクリプション更新のたびにルール全体を書き換える必要がなくなり、複数のプロキシグループで同じノード群を共有できます。クライアントが対応している場合は、大量のノードを proxies に直接展開するより、この階層構造の方が保守しやすくなります。

各プロバイダーには、一意の名前、タイプ、ソースアドレス、キャッシュパス、更新間隔が必要です。リモートタイプでは通常HTTPでYAMLを取得し、path がローカルキャッシュの場所を指定します。相対パスの基準ディレクトリはクライアントによって異なる場合があります。設定移行後にファイルを作成できない、キャッシュが更新されないといった問題が出たら、クライアントの作業ディレクトリとファイル権限を確認してください。

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

プロバイダーのヘルスチェックは内部のノードを定期的にテストしますが、プロキシグループの url-test とは別の階層です。前者はノードの利用可能状態を管理し、後者はグループ内で選択を行います。両方の間隔を短くしすぎると重複リクエストが発生するため、ノードの変化頻度と利用状況に合わせて設定してください。サブスクリプションURLが無効でも、クライアントがローカルキャッシュを使い続ける場合があります。「今は接続できる」ことは、リモート更新が正常である証拠にはなりません。

rule-providersでルールをまとめて管理する

rule-providers は大量のドメインやネットワーク範囲のルールを独立ファイルに置き、メイン設定から RULE-SET で参照できるようにします。代表的な behavior には domain、ipcidr、classical があります。domainはドメイン照合、ipcidrはネットワーク範囲、classicalはルールタイプを含む従来形式の項目に使います。behaviorとファイル内容の形式が一致しないと、ダウンロードに成功しても解析できない場合があります。

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

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

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

domain形式のファイルには通常、ドメインの値だけを記述し、対象ポリシーは書きません。ポリシーはメイン設定の RULE-SET 行で指定します。classical形式では DOMAIN-SUFFIX など完全なルールプレフィックスを含めることがあります。2つの形式を混同すると、「ルールセットはダウンロード済みなのにマッチしない」という状態になります。校正時は、プロバイダーの状態、解析された項目数、メインルールの参照名を同時に確認してください。

サブスクリプション更新とローカル設定の境界

Profileには通常、リモートサブスクリプションとローカル設定の2種類が含まれます。リモートサブスクリプションはノードの変化を受け取るのに適し、ローカル設定は端末固有のポート、DNS、ルールを保存するのに適しています。サブスクリプションから生成されたファイルを直接編集すると、次回更新時に変更が失われる可能性があります。一方、すべてのノードをローカルへコピーすると自動更新の利点がなくなります。サブスクリプションを材料として残し、クライアントの上書き機能または独立したメイン設定でポリシーを組む方法がより安全です。

複数のProfileを管理する場合は、「デスクトップ日常」「モバイル回線」「ルール実験」など用途を明記し、インポート日だけで命名しないでください。設定を切り替えた後は、現在の有効項目、システムプロキシの状態、プロキシ選択を確認します。クライアントがProfileごとに状態を保存する場合があるためです。インポート、切り替え、整理の詳しい方法はClash Profile設定ファイルの基礎をご覧ください。

更新失敗を階層別に切り分ける

プロバイダーの更新に失敗したら、まずネットワークエラー、HTTPステータスエラー、ファイル形式エラー、キャッシュ書き込みエラーを分けて考えます。ネットワークエラーはアドレスへの接続を確立できない状態、HTTPエラーはリモートが想定外のステータスを返した状態、形式エラーはダウンロード後の解析段階で発生する状態、キャッシュエラーはパスや権限に関係する状態です。ログに記録された段階情報は、更新ボタンを何度も押すより有効です。

リモートアドレスへのアクセスにプロキシが必要な場合は、コアがプロバイダーを更新するときに使うネットワーク経路も確認してください。起動直後はポリシーがまだ完全に利用できないため、コア設定の取得までプロキシに依存すると起動ループになることがあります。直接初期化できる基本設定を残し、プロバイダーが失敗しても明確なログと利用可能なローカルキャッシュがある状態にしてください。

CHAPTER / 08

上書き、マージ、最終設定の校正

実際に有効なのはマージ後の結果

多くのGUIクライアントでは、リモートサブスクリプションに対して上書き、スクリプト、マージ設定を適用できます。ユーザーが編集した断片は入力の1つにすぎず、コアが最終的に読むのはクライアント処理後の完成設定です。元のサブスクリプションや上書きファイルだけを見て最終設定を確認しないと、フィールドが有効になったと誤判断する可能性があります。クライアントから実行設定をエクスポートできる場合は、その結果を優先して確認し、想定と段階ごとに照合してください。

マージには通常、置換、追加、削除の3種類の操作があります。mixed-port のようなスカラー値は後の値が前の値を上書きすることが多く、dns のようなマップオブジェクトはキー単位でマージされる場合と全体置換される場合があります。rules や proxy-groups のようなリストは差が最も大きく、追加、名前単位の処理、完全上書きなどクライアントごとに異なります。すべてのクライアントが同じアルゴリズムだと考えず、設定を移行する前に小さなサンプルでテストしてください。

# base.yaml
mode: rule
dns:
  enable: true
  enhanced-mode: fake-ip
  nameserver:
    - 1.1.1.1

rules:
  - GEOIP,CN,DIRECT
  - MATCH,ノード選択

# override.yaml
dns:
  ipv6: false

rules:
  - DOMAIN,internal.example.com,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,ノード選択

クライアントが dns を深くマージする場合、最終結果には enable、enhanced-mode、nameserver、追加した ipv6 が同時に残る可能性があります。全体置換ならDNSセクションが ipv6 だけになり、期待どおり動作しません。ルールリストでは、末尾に追加した精密な例外が既存のGEOIPやMATCHに先取りされることがあります。そのため、前方挿入にするか全体を並べ替えるかを明確にしてください。

プロキシグループを名前でマージするリスク

一部の上書きツールは同名のプロキシグループを同じオブジェクトとみなし、メンバーをマージします。既存の「ノード選択」にローカルグループを追加できる一方、重複メンバーや不要な古いフィールドが残ることもあります。別のツールでは新しいオブジェクトで古いグループを完全置換するため、上書き片に type、proxies、use が揃っていないと最終グループが不完全になります。

プロキシグループを処理するときは、上書き片の目的を明確にしてください。グループ全体を置き換えるのか、メンバーだけを追加するのかを示します。クライアントの意味を確認できない場合は、新しいグループ名を使い、まずルールが正しく参照できるか検証してから既存グループを置き換えます。名前が変わるとクライアントに保存された手動選択にも影響します。更新後に選択が突然既定値へ戻ったら、マージ処理でグループ名が変わっていないか確認してください。

ルールの上書きでは順序の意図を保つ

ローカルルールは通常、端末固有の直接接続、プロセスルール、用途別の例外を追加するために使います。サブスクリプションの広範なルールより前に置く必要があるため、単純に末尾へ追加しても機能しないことがあります。安定した方法は、ルールを「ローカル例外、リモートルールセット、地域判定、最終フォールバック」の4ブロックに分け、最終設定で順序を固定することです。クライアントに前置きと後置きの入口がある場合は、例外を前置き、追加のフォールバックを後置きにします。ただし、本当の最終MATCHは全体で1つだけにしてください。

ルールの重複排除は行全体のテキストだけで判断できません。2つのルールが重なる範囲を持ちながら異なる対象を指定することがあります。たとえば完全一致ドメインの直接接続とサフィックスのプロキシは両方残し、順序で例外を表現する必要があります。後から現れた項目だけを残す自動重複排除スクリプトでは、元の意図が変わる可能性があります。ルール生成ロジックを変更するたびに、代表的なドメインを選んでログを確認し、ファイルの行数だけを比較しないでください。

解析エラーから実行エラーまでのチェックリスト

第1層はYAML構文です。インデント、コロン、ハイフン、引用符、データ型を確認します。第2層は構造参照で、プロキシグループ、ノード、プロキシプロバイダー、ルールプロバイダーの名前を確認します。第3層はリソース読み込みです。リモートファイルのダウンロード成功、キャッシュへの書き込み、behaviorとの形式一致を確認します。第4層は実行環境で、ポートの未使用、権限、システムプロキシまたはTUNが現在のコアを指しているかを確認します。第5層になって初めてリクエスト判断を調べ、DNS結果、ルール適用、プロキシグループの選択、最終ノードを確認します。

この階層化により、下流の変更で上流のエラーを隠すのを防げます。たとえばポート競合のときにDNSを変更しても解決しません。プロキシグループが空のときにルールを増やすと、より多くのトラフィックが空グループへ送られるだけです。ノードのTLSパラメータが誤っている場合、globalモードへ切り替えても失敗します。各段階では現在の層に関係する情報だけをログから取り出し、確認できてから次へ進むと、障害範囲を段階的に絞れます。

ロールバック可能な変更手順を作る

変更前に、動作していた設定を必ず1つ残し、今回解決する問題を1つだけ記録してください。ファイル名には用途と改訂番号を含めても構いませんが、複数のディレクトリに同じ名前で内容の異なるコピーを保存しないでください。変更後はまず構文読み込みを行い、直接接続の対象、プロキシ対象、LAN対象、特殊ルールが必要な対象を1つずつテストします。この4種類で大半の設定チェーンを確認できます。

クライアント更新後に動作が変わった場合は、まず最終設定とコアログを比較し、すぐにサブスクリプション内容が変わったと判断しないでください。クライアントが既定DNS、TUNスタック、マージの意味、設定ディレクトリを変更している可能性があります。重要なフィールドをローカル上書きに明示し、用途を記録すると、既定値の変化による不確実性を減らせます。ただし、根拠を失った古い例外は定期的に削除してください。

設定の校正が終わったら、使い方ガイドの接続確認手順に戻り、システムプロキシ、プロキシ選択、ウェブアクセスまで一連の流れを実行してください。GUIクライアントを変更する場合、ダウンロードページに掲載しているClash Plus、Clash Verge Rev、FlClash、Clash NyanpasuなどはYAMLの対応範囲が完全に同じではありません。移行前に現在の設定が依存するコアフィールドを確認してください。デスクトップ・モバイル向けの入口はClashダウンロードセンターで確認できます。

信頼できるClash YAMLとは、フィールドが多い設定ではなく、各フィールドの用途が明確で、すべての参照を追跡でき、更新のたびに説明可能な最終結果を得られる設定です。構造、共通フィールド、DNS、ノード、プロキシグループ、ルール、プロバイダー、上書きの順に確認することは、文字からレイアウトへ段階的に校正する作業に相当します。まず文字が正しいこと、次に組み合わせが正しいこと、最後に実際の出力結果が期待と一致することを確認してください。