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

01 / YAML STRUCTURE

YAML構造の概要

設定ファイルはどのような領域で構成されるか

Clashの設定ファイルはYAMLマッピングです。トップレベルのキーで、待ち受けポート、動作モード、DNSの挙動、プロキシノード、プロキシグループ、ルール、外部Providerを定義します。カーネルはファイルを読み込む際、まずYAML構文を解析し、次に項目の型と参照関係を確認し、最後にプロキシ、プロキシグループ、ルールの実行経路を構築します。構文が正しいことはYAMLを読み取れることを示すだけで、すべてのノードに接続できることや、プロキシグループの参照が完全であることを意味しません。そのため、トラブル対処では「テキスト構文」「項目構造」「名前の参照」「ネットワーク接続」の4層に分けて確認します。

よく使われるトップレベルの領域には、mixed-port、allow-lan、mode、log-level、external-controller、dns、proxies、proxy-groups、rules、proxy-providers、rule-providersがあります。すべての設定でこれらを記述する必要はありません。クライアントの画面からシステムプロキシを管理する場合、ポートやコントローラーのアドレスがクライアントによって生成されることがあります。サブスクリプション提供元が設定を生成する場合、ノードやプロキシグループは通常サブスクリプションの更新に合わせて変わります。手動設定では、どの項目が基本的な動作パラメーターで、どの項目がサブスクリプション更新時に置き換わるのかを明確にすることが重要です。

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

external-controller: 127.0.0.1:9090

dns:
  enable: true
  ipv6: false
  enhanced-mode: fake-ip
  nameserver:
    - https://1.1.1.1/dns-query

proxies:
  - name: Example-Trojan
    type: trojan
    server: proxy.example.com
    port: 443
    password: "your-password"
    sni: proxy.example.com

proxy-groups:
  - name: ノード選択
    type: select
    proxies:
      - Example-Trojan
      - DIRECT

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

上の例は最小限の関係が完成した状態です。ルールがリクエストを「ノード選択」に渡し、プロキシグループがさらに具体的なノードまたはDIRECTへ渡します。ルール末尾の宛先名は、プロキシグループ名と完全に一致していなければなりません。プロキシグループ内のノード名も、proxies項目の名前と一致する必要があります。名前の比較では、文字、空白、全角・半角の違いが区別されるのが一般的です。「ノード選択」と「ノード選択 」は似て見えても、実際には別の名前です。名前を変更する場合は、すべての参照箇所も同時に変更してください。

インデント、シーケンス、スカラー

YAMLではインデントで階層を表します。半角スペース2つに統一し、タブは使用しないことをおすすめします。ハイフンで始まる項目はシーケンスです。たとえばproxies配下の各ノードや、rules配下の各ルールが該当します。コロンの後には必ず空白を入れ、文字列にコロン、シャープ、角括弧、前後の空白が含まれる場合は、引用符で囲むと曖昧さを減らせます。パスワード、UUID、ドメイン、ノード名は文字列として扱い、ポート、間隔、同時実行数は通常数字にします。スイッチにはtrueまたはfalseを使用します。

引用符で囲まれていないシャープは、コメントの開始を示します。たとえばpassword: abc#123では、値がabcだけとして扱われる可能性があります。正しくはpassword: "abc#123"と記述します。真偽値も明確なtrueとfalseを使い、YAMLパーサーによって真偽値と解釈される可能性のある単語は避けてください。ノード名にカンマが含まれていてもノードオブジェクト自体が直ちに壊れるわけではありませんが、その名前をカンマ区切りのルールや一部の短縮記法に書くと解析が曖昧になることがあります。ノード名とプロキシグループ名は、短く一意で、制御文字を含まない名前にするのが安全です。

解析順序と参照チェック

設定ファイルの記述順は主に読みやすさのためのもので、トップレベルの領域を固定順に並べる必要はありません。ただし、ルールリスト内の順序には実行上の意味があります。ノードをプロキシグループより前に書くことも、プロキシグループをルールより前に書くこともできます。カーネルは設定全体を解析してから参照を構築します。「プロキシが見つからない」「プロキシグループが存在しない」と表示されたら、まずエラーに出た名前を定義箇所と1文字ずつ照合し、その名前がProviderによって動的に提供されていないか確認してください。Providerの読み込みがまだ成功していない場合、それに依存するプロキシグループが一時的に空になることがあります。

設定テストは、特定のYAML断片だけでなく完全なファイルから始めてください。断片が構文チェックを通っても、元のファイルに戻した際に階層が正しいとは限りません。クライアントが設定を無効と表示したら、まず元ファイルのコピーを保存し、最近追加した領域をブロック単位で取り除きながら二分法で原因を特定します。サブスクリプション更新後に問題が起きた場合は、サブスクリプションURLと設定インポートの解説を参考に、インポートしたものがサブスクリプションアドレス、完全なYAML、ノード情報だけを含む内容のどれなのかを確認してください。

02 / GENERAL FIELDS

共通項目：ポート、モード、制御インターフェース

待ち受けポートの選び方

portはHTTPプロキシ、socks-portはSOCKS5プロキシに使用します。mixed-portなら、同じポートでHTTPとSOCKS5のリクエストを受け付けられます。デスクトップクライアントでは通常、1つのmixed-portだけを使い、アプリケーションのプロキシアドレスを127.0.0.1と対応するポートに設定します。ポートはローカルの待ち受け口であり、リモートノードのポートではありません。ノードオブジェクト内のportはリモートサーバーのポートを示します。同じ名前でも階層と用途が異なります。

待ち受けポートは、他のプログラムが使用しているポートと重複できません。起動ログにaddress already in use、bind failedなどの表示が出たら、まず残っているプロセスを終了するか、未使用のローカルポートに変更してください。クライアントの画面がポート設定を自動的に書き込む場合は、画面から最終的に生成された実行設定を優先します。サブスクリプションの元ファイルだけを編集しても、クライアントが後からローカル上書きを適用すれば、実行中のポートはファイルの内容と異なることがあります。

allow-lanと待ち受けアドレス

allow-lanは、LAN内の端末が本機のプロキシを利用できるかを制御します。falseでは通常、本機からの接続だけを受け付けます。trueにした場合も、bind-address、OSのファイアウォール、現在のネットワーク種別を確認しなければ、他の端末からアクセスできるとは限りません。LANでプロキシを共有する場合は、管理されたネットワークでのみ有効にし、制御インターフェースとプロキシ入口のアクセス範囲を明確にしてください。公共ネットワークでは、コントローラーやプロキシポートを信頼できない端末に公開しないでください。

mixed-port: 7890
allow-lan: true
bind-address: 0.0.0.0
authentication:
  - "device-user:your-password"

この例の認証はプロキシ入口に適用されます。認証項目の対応方法は、実際に使うクライアントとカーネルの仕様を確認してください。本機だけで使うなら、allow-lan: falseのままにするのが簡単です。LAN内の端末から接続できない場合は、本機のLANアドレス、ポートの待ち受け範囲、ファイアウォールの受信規則、端末が同じネットワークにあるか、モバイル端末でプロキシ種別を間違えていないかを順番に確認します。

modeでよく使う3つの値

mode: ruleは、rulesを上から順に照合する日常利用の基本モードです。mode: globalは接続をグローバルプロキシグループに渡し、特定ノードの利用可否を一時的に確認するのに向いていますが、細かな振り分けを bypass します。mode: directは接続を直接アクセスさせ、問題がプロキシ経路にあるかを確認するのに役立ちます。トラブル対処では比較のため一時的に切り替え、確認後は目的のモードに戻してください。グローバルモードを、ルール不足を修正しないまま長期利用する代替策にしないでください。

モードはトラフィックをどのようにプロキシへ渡すかを決めるだけで、DNS解決、システムプロキシの未有効化、TUNの未接管、アプリによるプロキシ回避を自動的に解決するものではありません。ブラウザーではアクセスできるのにコマンドラインツールでは接続できない場合、ブラウザーはシステムプロキシに従う一方、コマンドラインプログラムがシステムプロキシ設定を読み取っていないことがよくあります。その場合は、プログラムにHTTPまたはSOCKS5プロキシを明示するか、正しく設定したTUNモードを使用します。

ログ、IPv6、コントローラー

log-levelの一般的な値には、silent、error、warning、info、debugがあります。通常の運用ではinfoで十分です。設定や接続の問題を調べるときだけ一時的にdebugへ変更し、確認後は戻してください。ログの情報量が多すぎると判断しにくくなります。ログを読むときは最後の行だけでなく、最初に現れたエラーを探してください。その後に大量の接続失敗が続いていても、最初のDNSエラーや設定エラーの連鎖である場合があります。

ipv6は、カーネル関連のネットワーク動作でIPv6を有効にするかを決めます。ネットワーク自体に安定したIPv6経路がない状態で無理に有効にすると、名前解決はできても接続経路が使えないことがあります。DNS領域には独立したdns.ipv6もあり、AAAAレコードを返すかどうかを制御します。トップレベルのIPv6とDNSのIPv6は、実際のネットワーク条件に合わせて設定し、片方だけを変更しないでください。

external-controllerは、クライアント画面とカーネルが通信する制御インターフェースです。一般的な記述は127.0.0.1:9090です。ループバックアドレスにバインドすれば、本機からのみアクセスできます。secretを設定した場合、制御側は対応する認証情報を送る必要があります。コントローラーポートとプロキシポートは用途が異なるため、システムプロキシをコントローラーポートへ向けてはいけません。GUIクライアントは通常これらの項目を自動管理するため、手動変更前に起動時に上書きされないか確認してください。

03 / DNS PIPELINE

DNS設定と名前解決の経路

DNSモジュールが扱う問題

DNS領域では、ドメインをどのサーバーで解決するか、どの転送方式を使うか、Fake IPを返すか、名前解決リクエスト自体を直接接続とプロキシのどちらで送るかを決めます。ブラウザーで接続に失敗した場合は、ノード経路とDNS経路を分けて確認してください。ノード接続を確立できても、ドメインが正しく解決されたとは限りません。DNSがアドレスを返しても、そのアドレスへの接続経路が到達可能とは限りません。DNS設定の目的は、名前解決元、振り分けルール、実際の接続出口を一致させることです。

dns.enableはカーネルのDNSモジュールを有効にします。TUNやFake IPを使う場合、またはシステムの名前解決経路とプロキシ振り分けの分離を避けたい場合は、通常有効にします。listenはDNSサービスの待ち受けアドレスを指定します。たとえば0.0.0.0:1053です。デスクトップGUIではカーネル内部が処理するため、ユーザーがこのポートへ直接アクセスする必要がないこともあります。ルーターやゲートウェイでは、LAN端末のDNSリクエストをここへ転送する構成がよく使われます。LANアドレスで待ち受ける場合も、ファイアウォールとアクセス範囲を確認してください。

dns:
  enable: true
  listen: 0.0.0.0:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "time.*.com"
  default-nameserver:
    - 223.5.5.5
    - 1.1.1.1
  nameserver:
    - https://dns.alidns.com/dns-query
    - https://1.1.1.1/dns-query
  proxy-server-nameserver:
    - https://1.1.1.1/dns-query
  nameserver-policy:
    "geosite:cn":
      - https://dns.alidns.com/dns-query

default-nameserverとnameserver

default-nameserverは主に、暗号化DNSサーバー自身のドメインを解決したり、上流への接続を確立する前の基礎的な名前解決に使われます。ここには直接アクセスできるIPアドレスのDNSを指定するのが一般的で、名前解決が必要なDoHアドレスだけを設定するのは避けてください。「DNSサーバーのドメインを解決するために、そのDNSサーバーへ先に接続する」依存ループになる可能性があります。nameserverは主要な上流DNSで、通常のUDP DNS、DoT、DoHを利用できます。上流を選ぶときは、ローカルネットワークからの到達性と振り分け出口を考慮してください。プロトコル名が複雑であるほど適しているわけではありません。

proxy-server-nameserverはプロキシサーバーのドメインを解決するために使います。ノードのserverにドメインを指定した場合、カーネルはノードへ接続する前にそのドメインのアドレスを取得する必要があります。この処理がまだ確立していないプロキシに誤って依存すると、起動時のループが発生します。プロキシサーバー用に、直接アクセスできる独立した上流DNSを用意すると、この問題を抑えられます。ノードサーバーにIPを直接指定すれば名前解決は不要ですが、サーバーアドレスが変更されてもDNSで自動更新できません。

nameserver-policyでは、ドメインやgeosite分類ごとに上流DNSを指定できます。これは「どの種類のドメインをどのDNSへ問い合わせるか」を決めるもので、「最終的な接続をどのプロキシ経路にするか」を決めるものではありません。接続出口はrulesが決定します。DNSポリシーとトラフィックルールで似たドメイン集合を使うことはできますが、適用される段階は異なります。片方を変更するときは、もう片方も意図どおりか確認してください。

Fake IPとRedir Host

enhanced-mode: fake-ipは、予約済みアドレス範囲のマッピングアドレスをドメインに返します。アプリがそのアドレスへ接続すると、カーネルがマッピングから元のドメインを復元し、ルール照合とプロキシ転送を行います。これによりドメイン情報を維持でき、アプリがシステム層で実アドレスを先に解決して、ドメイン情報を使った振り分けができなくなる問題を減らせます。fake-ip-rangeには専用の予約アドレス範囲を使い、現在のLAN、VPN、その他の仮想ネットワークの範囲と重複させないでください。

一部のLANサービス、デバイス検出、時刻同期、ゲームプラットフォーム、実アドレスの結果に依存するプログラムはFake IPに向きません。その場合はfake-ip-filterに追加できます。フィルターが広すぎると多くのドメインが実アドレス解決へ戻り、Fake IPの一貫性が低下します。狭すぎるとLANサービスを検出できなかったり、アプリが予約アドレスを拒否したりします。ログと実際のドメインを確認しながら個別に追加し、出所不明の長大なリストをそのまま使わないでください。

redir-hostは実際の名前解決結果を返し、その後の接続処理で照合します。従来型の透過プロキシ環境とは比較的互換性がありますが、経路によってはドメイン情報が不足することがあります。拡張モードを選ぶ前に、クライアントがTUN、システムプロキシ、ルーターの透過プロキシのどれを使うかを確認し、実際のアプリとの互換性をテストしてください。モードを切り替えた後は、OSとブラウザーのDNSキャッシュを消去しないと、古い結果がテストに影響し続けることがあります。

DNS障害を切り分ける順序

最初に、カーネルのDNSモジュールが起動しており、ログにポート競合や設定解析エラーがないことを確認します。次に通常のドメインを直接問い合わせ、結果が返るかを確認します。Fake IPモードで予約アドレスが返るのは正常です。続いて、ノードサーバーのドメインをproxy-server-nameserverで解決できるかテストします。その後、対象ドメインがどのルールに一致し、どのプロキシグループを経由するかを確認します。最後に、OSがDNSリクエストを別のインターフェースへ送っていないかを調べます。

いわゆるDNSリークは通常、「どの名前解決リクエストが想定した経路を迂回したか」という問題です。異なるDNSサービスから結果が返ったというだけで、原因を断定することはできません。ブラウザーが独自のセキュアDNSを有効にしていたり、システムが別のネットワークインターフェースを保持していたり、アプリが独自にDoHを実行していることもあります。トラブル対処では、まずブラウザー、システム、カーネルのDNS経路を統一し、その後必要な機能を1つずつ戻します。TUN環境では、DNSハイジャックの設定がUDPとTCPの問い合わせをカバーしているかも確認してください。

04 / PROXY DEFINITIONS

プロキシノード項目

ノードオブジェクトの共通構造

proxiesはノードオブジェクトのシーケンスです。各オブジェクトには少なくとも、一意のname、プロトコルのtype、サーバーのserver、リモート側のportが必要です。その他の認証やトランスポート項目はプロトコルによって異なります。ノード名はローカル設定内の参照識別子であり、サーバー側のパラメーターを変更するものではありません。プロキシグループやルールを管理しやすくするため、地域や用途が分かる名前にしつつ、安定性を保ってください。サブスクリプション更新のたびに名前が変わると、手動で作ったプロキシグループの直接参照が切れやすくなります。

serverにはドメインまたはIPを指定できます。ドメインならサーバー移転に対応しやすい一方、DNSに依存します。IPなら解決処理を1回減らせますが、アドレス変更時に設定の更新が必要です。udpは、そのノードがUDPトラフィックを処理できるかを示します。実際に利用できるかは、プロトコル、サーバー、ネットワーク経路にも左右されます。クライアント側でUDPを有効にするだけで、UDP非対応のサーバーが対応するわけではありません。

ShadowsocksとTrojanの例

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

  - name: Example-Trojan
    type: trojan
    server: trojan.example.com
    port: 443
    password: "your-password"
    sni: trojan.example.com
    skip-cert-verify: false
    udp: true

Shadowsocksのcipherはサーバー側と一致させ、パスワードも文字列として扱います。暗号方式ごとに必要な鍵の条件が異なるため、クライアント側の名前だけを変更してはいけません。TrojanはTLSで接続することが多く、sniにはTLSハンドシェイクで使うサーバー名を指定します。通常はサーバーが要求するドメインを入力します。skip-cert-verify: falseは証明書を通常どおり検証する設定です。証明書名が一致しない場合は、サーバーのドメイン、SNI、システム時刻、サーバー側の証明書設定を確認し、検証無効化を恒久的な対策にしないでください。

VMessとVLESSの認証・トランスポート項目

proxies:
  - name: Example-VMess
    type: vmess
    server: vmess.example.com
    port: 443
    uuid: 00000000-0000-4000-8000-000000000000
    alterId: 0
    cipher: auto
    tls: true
    servername: vmess.example.com
    network: ws
    ws-opts:
      path: /proxy
      headers:
        Host: vmess.example.com

  - name: Example-VLESS
    type: vless
    server: vless.example.com
    port: 443
    uuid: 00000000-0000-4000-8000-000000000000
    network: tcp
    tls: true
    servername: vless.example.com
    udp: true

uuidは認証識別子で、標準形式を保ち、サーバー側と一致させる必要があります。例のUUIDは構造を示すためだけのもので、実際の接続パラメーターとして使えません。VMessのalterId、cipherなどは、サーバーから提供された値を入力してください。VLESSのトランスポートやフロー制御項目はサーバー構成に依存します。クライアントがある項目に対応していても、追加するだけでサーバーと互換になるわけではありません。

networkはTCP、WebSocket、gRPCなどのトランスポート形態を表します。WebSocketを使う場合、ws-opts.pathとHostリクエストヘッダーを、サーバー側のリバースプロキシ設定と一致させてください。gRPCではサービス名を確認します。TLS関連のservername、SNI、ALPN、フィンガープリントはハンドシェイクのパラメーターです。どれか1つでもサーバーの入口と一致しないと、接続直後に切断されることがあります。

プロトコル項目を別ノードからそのまま流用しない

ノードオブジェクトには、すべてのプロトコルに適用できる完全な項目一覧はありません。同じ名前の項目でも、カーネルのバージョンやプロトコル実装によって制約が異なる場合があります。最も確実なのは、サーバーまたはサブスクリプションが生成したパラメーターを元に、現在のカーネルが対応する構造へ整理する方法です。別ノードのTLS、WebSocket、プラグイン項目をまとめてコピーすると、項目は存在しても意味が合わなくなることがあります。パーサーが受け入れても、接続は失敗する可能性があります。

サブスクリプションURLは通常、提供元がノードパラメーターを管理します。ユーザーが変更するのは、プロトコルの基礎項目よりも、ノード名、プロキシグループの構成、トラフィックルールであることが多いです。インポート後にすべてのノードが同時に使えない場合は、まずサブスクリプションの有効性、システム時刻、DNS、ローカルネットワークを確認します。1つのノードだけ失敗する場合は、そのノードのサーバー、ポート、認証、トランスポート設定を照合してください。ノードの選び方は遅延、地域、倍率、プロトコルの見分け方も参照できます。

ノードの可用性と遅延テストの限界

遅延テストは通常、テスト用アドレスへリクエストを送り、完了までの時間を記録します。これはある時点の特定経路における応答を示すもので、すべてのWebサイトの品質と同じではありません。テストのタイムアウトは、ノードに到達できない、テスト先が遮断されている、DNSに失敗している、プロキシグループの参照が誤っているなどの原因で起こります。遅延が低くても、帯域、安定性、目的地域へのアクセスが良いとは限りません。ノード選びでは、連続テスト、実際の対象サイト、継続接続時の挙動を総合的に確認してください。

ノードオブジェクトの読み込みに成功したのにプロキシグループに表示されない場合、通常はプロキシグループがそのノードを参照していないか、Providerのフィルター条件で除外されています。サブスクリプション更新後にノード名が変わると、静的なproxiesリストの参照も切れます。長期運用する設定では、proxy-providersとuseを組み合わせ、安定したフィルターでノードを整理するのが適しています。複数のプロキシグループに大量の名前を重複記述する方法は避けてください。

05 / POLICY GROUPS

プロキシグループ項目と選択ロジック

プロキシグループはルールとノードの中間層

proxy-groupsは、ノード、組み込みアクション、他のプロキシグループを、選択可能な出口としてまとめます。ルールは、変化しやすい個別ノード名ではなく、「ノード選択」「ストリーミング」「ダウンロードサービス」のような安定したプロキシグループを指定するのが一般的です。サブスクリプションでノードが変わっても、プロキシグループのメンバーを調整するだけで済み、すべてのルールを書き直す必要がありません。プロキシグループは入れ子にできますが、循環参照は避けてください。AがBを参照し、BがAを参照すると、有効な出口を構築できません。

組み込みの宛先には、DIRECT、REJECT、対応カーネルが提供するその他のアクションがあります。DIRECTは直接接続、REJECTはリクエスト拒否を示します。ルールの宛先にはプロキシグループ、具体的なノード、組み込みアクションのいずれも指定できます。保守性を高めるため、固定的な用途を除き、ルールはプロキシグループを指し、実際の出口はプロキシグループ側で決める構成がおすすめです。

select、url-test、fallback、load-balance

selectは最も分かりやすいタイプで、メンバーの順序が画面上の表示順になり、現在の選択はクライアントに保存されます。url-testは指定URLへ定期的にリクエストを送り、結果に応じて自動選択します。intervalは検出間隔、toleranceは結果が近いときの頻繁な切り替えを抑えるために使います。検出が頻繁すぎるとノードへのリクエストが増え、間隔が長すぎると経路の変化を反映できません。テスト先は安定していて応答サイズが小さく、想定するネットワーク経路を代表するものにしてください。

fallbackはメンバーの順序を優先順位として扱い、現在のノードが使えないときに後続の利用可能なメンバーへ切り替えます。主系と待機系が明確な構成に適しています。load-balanceは複数のノードへ接続を分配し、具体的な分配方法はstrategyなどの項目で決まります。1つのダウンロード接続を複数ノードに分割するものではなく、単一ノードや対象サーバーの帯域制限を超えることもありません。同じ宛先へのセッションで出口を安定させたい場合は、一貫性を維持できる戦略を選んでください。

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

  - name: 自動選択
    type: url-test
    proxies:
      - Example-SS
      - Example-Trojan
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50

  - name: フェイルオーバー
    type: fallback
    proxies:
      - Example-Trojan
      - Example-SS
    url: https://www.gstatic.com/generate_204
    interval: 300

プロキシグループの入れ子と用途別の階層化

明確な階層は通常、「総合入口—地域または自動選択—具体的なノード」で構成します。たとえば、ルールが通常のプロキシ通信を「ノード選択」に渡し、「ノード選択」に「自動選択」「フェイルオーバー」「複数の地域グループ」を含め、地域グループが対応するノードを持つ構成です。これなら自動選択も地域の手動固定も利用できます。入れ子を深くしすぎると、画面上の選択経路も障害の切り分けも複雑になります。

用途別グループは出口の要件を表すもので、ノード一覧を単純に複製するものではありません。たとえば「ストリーミング」は地域グループを参照し、「開発サービス」はメイン選択グループを参照し、「直接接続サービス」はDIRECTだけを含められます。複数の用途別グループが同じ地域グループを参照すれば、ノード管理を1か所に集約できます。各用途別グループに数十個のノードを重複して列挙すると、サブスクリプション更新後にメンバーの差異や漏れが生じやすくなります。

Providerメンバーとフィルター

プロキシグループではuseを使って1つ以上のproxy-providersを参照し、外部のノード集合からメンバーを動的に取得できます。カーネルによってはfilterやexclude-filterなどの絞り込みにも対応しています。フィルターには通常正規表現を使うため、まず少数の名前で検証してください。地域キーワードがプラン説明、倍率表示、別のノード名にも含まれることがあり、表現が広すぎると意図しないノードまで取り込み、厳しすぎると空のグループになります。

proxy-groups:
  - name: 香港ノード
    type: url-test
    use:
      - subscription-main
    filter: "(?i)香港|HK|Hong Kong"
    url: https://www.gstatic.com/generate_204
    interval: 300

  - name: ノード選択
    type: select
    proxies:
      - 香港ノード
      - DIRECT
    use:
      - subscription-main

proxiesとuseを同時に記述すると、プロキシグループはカーネルの対応方法に従って静的メンバーとProviderメンバーを組み合わせます。画面に同じノードが大量に重複して表示される場合は、同じノードが静的に書かれたうえでProviderからも取り込まれていないか確認してください。自動プロキシグループが空の場合は、まずProviderのダウンロード成功を確認し、次にフィルター表現、最後にProvider内のノード名が想定どおりかを確認します。

06 / RULE ENGINE

ルール構文と照合順序

上から順に照合し、ヒットした時点で停止

rulesは順序を持つルールシーケンスです。接続が到着すると、カーネルは最初の項目から確認し、ヒットした時点で指定されたプロキシへ渡して、後続の項目を調べません。そのため、具体的なルールを広範なルールより前に置き、フォールバックルールを最後に置きます。MATCHを途中に置くと、その後のルールは実行されません。広いドメインサフィックスルールを正確なドメインより前に置くと、後続の特別処理が遮られることもあります。

多くのルールは、ルールタイプ、照合内容、宛先プロキシをカンマで区切る構造です。一部のルールには追加パラメーターも指定できます。たとえばDOMAIN-SUFFIX,example.com,ノード選択は、example.comとそのサブドメインを「ノード選択」へ渡します。ルールの宛先名は存在していなければなりません。名前にカンマを含めると区切り構造が壊れるため、プロキシグループ名にはカンマを使わないでください。

rules:
  - DOMAIN,api.example.com,ノード選択
  - DOMAIN-SUFFIX,example.com,ノード選択
  - DOMAIN-KEYWORD,example,ノード選択
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR6,fc00::/7,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,ノード選択

ドメインルールの違い

DOMAINは完全一致のドメインだけを照合し、明確なAPIホストや特別な出口が必要な単一サービスに適しています。DOMAIN-SUFFIXは指定ドメインとそのサブドメインを照合し、サイト全体の振り分けに向いています。DOMAIN-KEYWORDはドメインにキーワードが含まれていればヒットする可能性があり、範囲が広い分、誤検出も起こりやすくなります。正確なドメインを指定できる場合は、設定行を減らすためだけに広いキーワードを使わないでください。

ドメイン照合には、接続段階でカーネルがドメイン情報を取得できることが必要です。システムプロキシ経由のHTTPリクエスト、SNI付きのTLS接続、Fake IPのマッピングでは、通常ドメイン情報を利用できます。純粋なIP接続はIP系ルールにしか入れません。アプリが独自に名前解決してIPへ直接接続すると、ドメインルールがヒットしないことがあります。ログに宛先IPしか表示されない場合は、DNSをカーネルが処理しているか、アプリがシステムプロキシを迂回していないか確認してください。

IP、GEOIP、no-resolve

IP-CIDRはIPv4のネットワーク範囲、IP-CIDR6はIPv6のネットワーク範囲に使います。LAN、ループバック、リンクローカルなどのアドレスは通常直接接続し、リモートプロキシへ渡さないようにします。CIDRのプレフィックス長が範囲を決めるため、1桁間違えるだけで想定を大きく超える範囲になることがあります。ネットワークルールを変更する前に対象アドレスがどのネットワークに属するかを確認し、1回の名前解決結果だけを根拠に広すぎる範囲を追加しないでください。

no-resolveは、そのIPルールを照合するときにDNS解決を積極的に行わないことを示します。対象IPをすでに取得しており、ルール判定のための追加のドメイン解決を避けたい場合に適しています。DNS解決でIPを取得しなければならないルールにno-resolveを追加すると、照合条件が変わります。汎用的な高速化スイッチではなく、ルールタイプと現在の接続コンテキストに応じて使ってください。

GEOIPはIPデータベースに基づいて分類します。照合対象はアドレスの所在地情報であり、ドメインのカテゴリとは異なります。データベースはカーネルのリソース更新に合わせて更新する必要があり、分類結果にも境界の差が生じることがあります。特定のサービスを安定して制御したい場合は、ドメインルールや明確に管理されたルールセットの方が直接的です。GEOIPは大まかな振り分けや終端に近い条件として使うのが適しています。

プロセス、ポート、ネットワーク種別のルール

対応カーネルでは、プロセス名、プロセスパス、宛先ポート、受信タイプなどの拡張ルールを利用できます。プロセスルールはOSの権限と、カーネルがプロセス情報を取得できるかどうかに依存します。モバイルプラットフォーム、コンテナ環境、一部のサンドボックスアプリでは、情報を完全に取得できないことがあります。プロセス名も更新で変わる可能性があるため、実行ログで実際の認識結果を確認してください。

ポートルールはプロトコルの範囲が明確な場面に適していますが、同じポートで異なるサービスが動作することもあり、ポートだけに依存した振り分けは広くなりがちです。ネットワーク種別ルールではTCPとUDPを区別でき、特定のUDPアプリや直接接続したいローカルサービスに使えます。複雑なルールには用途をコメントで記録し、数も抑えてください。半年後に存在理由を理解できることは、設定を極端に短くすることより重要です。

カスタムルールを挿入する位置

カスタムルールが有効になるかどうかは、最終的なルールリストのどの位置に挿入されるかで決まります。サブスクリプションの既定動作を上書きする正確なルールは、対応する広範なルールより前に置いてください。ローカルへの直接接続範囲は、プロキシのフォールバックより前に置き、MATCHは常に最後にします。多くのクライアントには「ルールを先頭に追加」「ルールを末尾に追加」「スクリプト上書き」などの機能があります。先頭への追加は優先度の高い例外に、末尾への追加はサブスクリプションにないルールで、既存のフォールバックに先にヒットしないものに適しています。

ルールを検証するときは、設定テキストだけで判断せず、実行ログのルールヒット情報を確認してください。まず明確な対象へアクセスし、ドメインまたはIP、ヒットしたルールタイプ、対象プロキシグループ、最終的なノードが想定どおりかを確認します。ログでより前のルールにヒットしている場合は、順序を変更するか、前のルールの範囲を狭めます。よくある問題はよくある質問で「使い方のコツ」と「トラブル対処」の分類から続けて検索できます。

07 / PROVIDERS

Proxy ProviderとRule Provider

外部コンテンツをProviderに分ける理由

Providerは、頻繁に更新されるノードやルールの集合をメイン設定から分離するために使います。proxy-providersはノードオブジェクトを提供し、プロキシグループがuseで参照します。rule-providersはルール内容を提供し、RULE-SETから呼び出します。メイン設定は実行フレームワークとポリシー関係を担当し、Providerは外部データの更新を担当します。これにより、ノードやルールが変わるたびにメイン設定全体を置き換える必要がなくなります。

Providerはプロキシグループではありません。ノードProviderのダウンロードに成功しても、どこかのプロキシグループから参照する必要があります。ルールProviderのダウンロードに成功しても、rulesでRULE-SETを使い、対象プロキシを指定する必要があります。Providerを定義するだけでは、トラフィックは自動的に変わりません。逆に、存在しない、または読み込みに失敗したProviderをルールが参照すると、その集合は照合できません。

proxy-providersの構造

proxy-providers:
  subscription-main:
    type: http
    url: "https://subscription.example.com/api/client?token=xxxx"
    path: ./providers/subscription-main.yaml
    interval: 21600
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 300

proxy-groups:
  - name: 自動選択
    type: url-test
    use:
      - subscription-main
    url: https://www.gstatic.com/generate_204
    interval: 300

  - name: ノード選択
    type: select
    proxies:
      - 自動選択
      - DIRECT
    use:
      - subscription-main

type: httpはリモートアドレスから内容を取得することを示し、urlはサブスクリプションアドレス、pathはローカルキャッシュのパス、intervalは更新間隔です。パスはクライアントが書き込みを許可している設定ディレクトリ内に置いてください。複数のProviderで同じキャッシュファイルを共有すると、更新時に互いの内容を上書きする可能性があります。サブスクリプションアドレスはアクセス認証情報にあたるため、クライアント設定と管理されたバックアップに保存し、公開ドキュメントやスクリーンショットに載せないでください。

health-checkはProvider内のノードの可用性を検査します。プロキシグループ自身のurl-testと関係はありますが、同じではありません。Providerのヘルスチェックはノードの状態を管理し、プロキシグループのテストはメンバーを選択します。検査先、周期、ネットワーク環境が結果に影響します。ノード数が多い場合は、リクエストが集中しないよう周期を短くしすぎないでください。

rule-providersのbehavior

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

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

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

behaviorはルールセットの内容タイプを表します。domainはドメイン項目、ipcidrはアドレス範囲、classicalはルールタイプを含む従来形式に使います。Providerファイルの内容はbehaviorと一致していなければなりません。完全なDOMAIN-SUFFIX,example.com項目をドメインだけを受け付ける集合に入れたり、純粋なネットワーク範囲を対応しない形式に入れたりすると、読み込みエラーや項目の無効化が起こります。

ドメインbehaviorのYAMLペイロードは通常、payloadシーケンスとして記述します。具体的な項目形式はカーネルの仕様に従ってください。クラシック形式では完全なルールタイプを保持します。behaviorを選ぶときはファイル名だけで判断せず、ルール提供元が実際に使っている形式を確認してください。リモートアドレスがWebページ、ログインページ、エラーメッセージを返す場合、HTTPリクエストが成功していても有効なルールファイルではありません。

Providerの更新とキャッシュ

リモート更新に失敗しても、カーネルがローカルキャッシュを使い続けることがあります。そのため「現在も動作している」ことは、Providerの今回の更新が完了したことを意味しません。ログでは、ダウンロード失敗、解析失敗、書き込み失敗、キャッシュ読み込み成功を区別してください。ダウンロード失敗ではネットワーク、アドレス、アクセス権を確認します。解析失敗では返却内容の形式を確認します。書き込み失敗ではディレクトリ権限とパスを確認します。キャッシュ破損の場合は設定をバックアップしたうえで該当キャッシュを削除し、クライアントに再取得させます。

更新間隔は秒数で指定します。ノードサブスクリプションとルールセットで同じ周期を使う必要はありません。ノードは比較的頻繁に変わる一方、安定したルールセットは更新頻度を下げられます。クライアント起動時にすぐ更新するか、失敗後にどう再試行するかは、カーネルとGUIの管理方法によって異なります。極端に短い周期を手動のトラブル対処の代わりにしないでください。失敗し続けるとリクエストとログが繰り返し発生するだけです。

複数Providerの整理方法

複数のサブスクリプションを同時に使う場合は、Providerごとに固有の名前、キャッシュパス、ヘルスチェックを設定します。プロキシグループから提供元ごとに直接参照することも、名前でフィルターして地域別に組み合わせることもできます。提供元名はサブスクリプション管理向け、地域ポリシーは日常の選択向けです。両者を同じ命名階層に混在させないでください。たとえばProviderを「subscription-main」、プロキシグループを「香港ノード」「自動選択」とすれば、画面が分かりやすくなります。

ルールProviderも、プライベートネットワーク、開発サービス、メディアサービス、ブロックリストなど用途ごとに分けると管理しやすくなります。分けすぎるとリモートリクエストと順序が複雑になり、まとめすぎると異なるポリシーを指定しにくくなります。「独立した更新、独立したポリシー、独立した優先度が必要か」を判断基準にしてください。複数のRULE-SET間でも、上から順に最初にヒットしたルールを使う原則は変わりません。

08 / OVERRIDE AND MERGE

上書き、統合、設定の保守

まず設定の出所レイヤーを特定する

GUIクライアントの最終的な実行設定は通常、サブスクリプションの元データ、クライアントが生成する基本パラメーター、画面上の設定、ローカル上書きファイル、スクリプト処理結果、実行時に補われる項目など、複数のソースから構成されます。ユーザーが見るサブスクリプションYAMLが、カーネルの最終読み込み設定と一致するとは限りません。変更が反映されない場合は、まずクライアントの「実行設定」「設定プレビュー」やログ出力を確認し、最終値がどのレイヤーに由来するかを特定します。

Clash Plus、Clash Verge Rev、FlClash、Clash Nyanpasuなどは、上書き画面の名称や実行順が異なる場合があります。モバイル版では一部の項目しか変更できないこともあります。デスクトップとモバイルでは、クライアントが提供する上書き入口を優先し、サブスクリプションが管理するキャッシュファイルを直接編集しないでください。サブスクリプションキャッシュは更新時に再生成されることが多く、手動変更は次回更新で失われます。

マッピング、シーケンス、スカラーの統合の違い

YAMLのトップレベル値は、マッピング、シーケンス、スカラーに分けられます。dnsはマッピングで、内部に複数階層のキーがあります。rules、proxies、proxy-groupsは通常シーケンスです。modeとmixed-portはスカラーです。上書きシステムによって、これら3種類の処理方法は異なります。スカラーは直接置き換え、マッピングはキー単位で再帰的に統合し、シーケンスは全体置換、先頭挿入、末尾追加、名前単位の処理になることがあります。

この違いによって、上書きの安全性が決まります。ルールを1つ追加したいだけなのに、上書き機構がrulesを全体置換すると、サブスクリプションのルールがすべて失われます。dns.enhanced-modeだけを変更したいのに浅い置換が行われると、dnsマッピング全体が1項目だけになる可能性があります。操作前に、クライアントがmerge、prepend、append、overrideをどのように定義しているか確認してください。すべてのクライアントが同じアルゴリズムを使うとは限りません。

ルール統合ではMATCHを処理する

ルール上書きで最も多い問題は、フォールバックの位置です。サブスクリプションのルールは通常、MATCHで終わっています。ローカルルールを単純に末尾へ追加しても、実行されません。一般的には、ローカルの優先ルールをサブスクリプションルールの前に挿入するか、スクリプトで末尾のMATCHを一時的に取り出し、追加ルールを挿入してから戻します。最終リストには、宛先が明確なフォールバックを1つだけ残してください。

# 先頭ルールの例
rules:
  - DOMAIN,api.example.com,DIRECT
  - DOMAIN-SUFFIX,dev.example.com,ノード選択

# 最終設定ではサブスクリプションルールを続け、最後に1つのMATCHを置く
# - RULE-SET,...
# - GEOIP,...
# - MATCH,ノード選択

先頭に置くルールはできるだけ正確にしてください。最初に広すぎるDOMAIN-KEYWORD、大きなCIDR範囲、地域ルールを追加すると、サブスクリプション内の細かなポリシーが先に打ち切られます。新しいルールを追加するたびに、少なくともヒットすべき対象と、ヒットしてはいけない隣接対象を1つずつ確認し、ログで実際のヒット項目を確認してください。

プロキシグループとノード名の統合

プロキシグループのシーケンスは、オブジェクトの位置だけでは統合結果を判断できません。ツールによってはnameで既存グループを探して変更しますが、別のツールでは新しいオブジェクトを単にリストへ追加します。同名のプロキシグループを追加すると、カーネルが重複名を報告することもあれば、クライアントの前処理で片方だけが残ることもあり、結果が予測しにくくなります。既存グループのメンバーを変更する場合は、クライアントが明示的に提供する名前単位の上書き方法を使ってください。対応していない場合は、目的のプロキシグループシーケンス全体を生成する方が管理しやすくなります。

ノード一覧でも同名の衝突が起こります。サブスクリプションに「香港 01」がある状態で、ローカルにも同名ノードを追加すると、参照元を区別できません。自作ノードには「LOCAL-」や用途名など、安定したプレフィックスを付けてください。Providerのフィルターが名前に依存する場合は、そのプレフィックスが地域の正規表現に誤って選ばれないことも確認します。

DNS上書きでは依存関係を保つ

DNSを変更するときはnameserverだけに注目しないでください。DoHの上流にドメイン形式を使う場合は、動作するdefault-nameserverが必要です。ノードサーバーにドメインを使う場合はproxy-server-nameserverを確認し、Fake IPを使う場合はアドレス範囲とフィルターも維持します。上流アドレスだけを置き換える浅い上書きによって、これらの依存項目が意図せず削除されることがあります。

より安全な方法は、まず最終的なDNSブロックをエクスポートし、ローカル管理用にコピーしてから一括変更し、検証することです。クライアントが再帰的統合を採用していると確認できた場合に限り、最小限のサブキーを上書きします。DNS方式を切り替えた後は、設定を再読み込みし、キャッシュを消去して、ノードのドメインと通常の対象ドメインをテストしてください。クライアントに「設定成功」と表示されただけで完了と判断しないでください。

復元可能な変更手順を作る

変更ごとに1つのテーマだけを扱います。たとえば、まずDNS、次にプロキシグループ、最後にルールを変更します。変更前に現在動作している設定を保存し、変更後は、構文読み込み、Provider更新、プロキシグループのメンバー確認、ルールヒット、実際のアクセスという5項目を検証します。複数の領域を一度に置き換えると、エラー発生時にどの層が原因か判断しにくくなります。

設定ファイルのコメントには、変更目的、出所、依存関係を記録できます。たとえば「サブスクリプションルールの前に置く」「Provider subscription-mainが必要」「LANアドレスのみ直接接続」などです。コメントにサブスクリプションの認証情報やノードのパスワードを書かないでください。長期保守では、行単位の単純な比較より、構造の変化を比較する方が有効です。サブスクリプションはノードの順序や名前を変更することがあるためです。

サブスクリプション更新後に起動異常が発生したら、まず保存しておいた動作可能な設定へ戻し、クライアントとカーネル自体が起動できることを確認します。その後、新旧設定のトップレベル項目、プロキシグループ名、ルールの宛先を比較してください。クライアントが起動直後に終了する、画面が表示されない、更新後にクラッシュするといった場合は、クライアント起動時のクラッシュを切り分ける手順も確認できます。初回接続の確認をやり直す場合は、使い方ガイドに戻り、サブスクリプション、ノード、システムプロキシ、接続状態を順番に確認してください。

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

読み込み前に、YAMLのインデント、コロン後の空白、引用符、シーケンスの階層を確認します。読み込み後は、ポートが正常に待ち受けているか、DNSが起動しているか、Providerが有効な内容を取得したかを確認してください。続いて、すべてのルールの宛先に対応するプロキシグループがあること、各プロキシグループに少なくとも1つの有効なメンバーがあること、入れ子に循環がないこと、最終ルールリストの末尾にMATCHが1つだけあることを確認します。最後に、直接接続するドメイン、プロキシ経由のドメイン、LANアドレス、ノードサーバーのドメイン、UDPが必要なアプリをそれぞれテストします。

1回のテストに通ったからといって、すべてのネットワーク環境で同じ動作になるとは限りません。Wi-Fi、モバイル回線、社内ネットワーク、IPv6環境を切り替えると、DNSの到達性、MTU、ファイアウォール、システムプロキシの挙動が変わることがあります。トラブル対処では同じ設定を保ったまま、環境変数を1つだけ変えて、原因が設定かネットワークかを判断してください。クライアントを変更する場合は、ダウンロードセンターでWindows、macOS、Android、iOS、Linux向けの選択肢を確認できます。一般ユーザーはまずClash Plusを選び、同じサブスクリプションをインポートして比較テストするのがおすすめです。