Clash 設定ファイル
フィールドリファレンス

01 · DOCUMENT MODEL

YAML 構造と設定の読み込み順

トップレベルフィールドは実行手順ではない

Clash の設定ファイルは通常 config.yaml という名前で、複数のトップレベルキーから構成されます。主な項目にはポート、動作モード、DNS、プロキシノード、プロキシグループ、ルール、外部 Provider があります。ファイル内の並び順は主に可読性のためであり、コアが記述順に1行ずつ厳密実行することを示すものではありません。パーサーはまず YAML 全体を読み込み、設定オブジェクトを構築してから、プロキシグループの参照、ルールの送信先、Provider の定義を検証します。そのため、rules を proxies より前に書いても直ちにエラーになるとは限りませんが、目視確認は難しくなります。「基本動作設定 → DNS → ノード → プロキシグループ → Provider → ルール」の順に整理するのがおすすめです。

YAML はインデントで親子関係を表し、スペースの代わりにタブを使うことはできません。同じ階層ではインデント幅を統一し、通常は2スペースを使います。リスト項目はハイフンで始まり、ハイフンの後に続くオブジェクトもインデント規則に従います。文字列は多くの場合引用符なしで書けますが、値にコロン、シャープ記号、波括弧、前後の空白が含まれる場合や、真偽値として解釈されやすい語を使う場合は、引用符を付ける方が安全です。たとえばノード名を "HK: Premium" と書けば、コロンがキーと値の区切りとして解釈されるのを防げます。パスワードに # が含まれる場合も引用符が必要です。

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

dns:
  enable: true
  enhanced-mode: fake-ip

proxies:
  - name: "Example-SS"
    type: ss
    server: 203.0.113.10
    port: 443
    cipher: aes-128-gcm
    password: "your-password"

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

rules:
  - MATCH,ノード選択

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

mode: rule はスカラー、rules の複数行項目はリスト、dns 配下の複数のキーと値の組み合わせはマッピングです。設定エラーは、これら3種類の構造を混同することで起こりがちです。たとえば nameserver はリストを要求するため、ハイフンのない単一文字列にすると、一部のコアでは読み込みを拒否されます。proxy-groups はオブジェクトのリストであり、各プロキシグループに独自の name と type が必要です。「フィールドの型が正しくない」と表示されたら、綴りだけでなく、文字列、数値、真偽値、リスト、オブジェクトのどれであるべきかも確認してください。

YAML の true と false には引用符を付けないでください。真偽値と文字列では意味が異なります。ポートは通常、数値で記述します。ドメイン名、ノード名、正規表現、パスワードは文字列として扱うのが適切です。空の値にも注意が必要です。キーだけを書いて値を省略しても、空のリストとは限りません。項目を明示的に空にする場合、オーバーライドシステムでは対象フィールドの型に応じて [] または {} が必要になることがあります。

参照関係と最終設定

プロキシグループはノードや他のプロキシグループを名前で参照し、ルールの末尾でもプロキシグループ名を参照します。名前は完全一致で判定され、空白、大文字・小文字、全角記号も名前の一部です。ルールが DOMAIN-SUFFIX,example.com,海外ノード となっていても、実際のプロキシグループ名が「国外ノード」なら、コアは同じ意味だと推測できません。サブスク更新後にノード名が変わると、手書きのプロキシグループが参照先を失うこともあります。

グラフィカルクライアントに表示される設定が、そのままコアの最終読み込み内容とは限りません。元のサブスク設定は、クライアントのグローバルオーバーライド、スクリプト処理、プロキシグループ生成、互換変換を経て、実行時設定として生成される場合があります。トラブル対処では、サブスクエディターだけでなく、「最終設定を表示」「実行設定」やログに記録された読み込みパスを優先して確認してください。クライアントに構文チェック機能がある場合は、まず解析エラーを解消してから、ルールやネットワークの挙動を確認します。インデント1か所の誤りでファイル全体を読み込めなくなるため、その後のネットワークテストには意味がありません。

02 · RUNTIME

ポート、モードと共通フィールド

受信ポートの役割分担

port は HTTP プロキシポート、socks-port は SOCKS5 プロキシポート、mixed-port は同じポートで HTTP と SOCKS5 のリクエストを受け付けます。デスクトップクライアントでは、システムプロキシとコマンドラインツールが同じ入口を使えるため、混合ポートだけを有効にする構成が一般的です。複数のフィールドに同じポートを割り当てたり、他のプロキシソフト、開発サーバー、起動中の Clash インスタンスと競合させたりしないでください。ポート競合が起きると、クライアント画面では設定の読み込みが成功したように見えても、ログにはリッスン失敗が記録され、システムプロキシは正常に動作していない入口を指すことがあります。

redir-port、tproxy-port、TUN 受信は透過プロキシ向けで、主にルーター、Linux ゲートウェイ、またはクライアントが自動管理します。通常の macOS や Windows ユーザーは、「より広く対応する」ためにすべてのポートを手動で有効にする必要はありません。システムプロキシモードは、システムプロキシ設定に従うアプリの通信を処理します。TUN モードは仮想ネットワークインターフェースを通じて、より広い範囲の通信を取り込みます。両者はクライアントがプラットフォームの機能に応じて設定できますが、ポートフィールドだけで TUN ドライバーやルーティング設定を代替することはできません。

allow-lan とリッスン範囲

allow-lan: true は LAN からのアクセスを許可する設定ですが、他のデバイスから実際に接続できるかどうかは、bind-address、OS のファイアウォール、ネットワークインターフェース、ルーターの分離ポリシーにも左右されます。本機だけで使う場合は、無効のままにしておく方が公開範囲を管理しやすくなります。共有する場合は、現在のネットワークが信頼できるか確認し、外部制御インターフェースには認証を設定してください。プロキシの受信ポートと制御インターフェースは別のサービスです。プロキシポートを公開したからといって、Control API まで LAN に公開する必要はありません。

external-controller は、127.0.0.1:9090 のような外部制御インターフェースを定義します。グラフィカルパネルはここを通じて接続情報を読み取り、プロキシグループの切り替えや設定の更新を行います。ループバックアドレスにバインドした場合は本機からのみアクセスできます。すべてのインターフェースにバインドする前に、secret の認証機能を理解し、ファイアウォールを確認してください。画面は起動するのにノードや接続が表示されない場合は、制御アドレスの使用状況、クライアントに入力した制御ポートの一致、認証値の一致を順に確認します。

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

動作モード、ログと IPv6

mode の代表的な値は rule、global、direct です。ルールモードでは rules を上から順に照合し、グローバルモードでは通信をグローバルプロキシグループに渡し、ダイレクトモードではプロキシを経由しません。日常利用はルールモードを基本とし、グローバルモードは「ルールの問題かノードの問題か」を一時的に切り分ける場合に適しています。ダイレクトモードは、アプリ自身のネットワークが正常か確認する際に使えます。グローバルモードを常用すると、細かな分岐を回避し、ルールの誤りを隠してしまいます。

log-level でログの詳細度を制御できます。通常の運用には info が適しており、ルールの適用、DNS、ハンドシェイクの問題を調べるときは一時的に debug へ変更できます。詳細ログは急速に増加するほか、アクセス先のドメイン名やノード名を含む場合があります。原因を特定したら通常のレベルに戻してください。ipv6 は IPv6 の名前解決と接続機能を有効にするか決めますが、単独でネットワークを修復するスイッチではありません。ローカルネットワーク、DNS の応答、プロキシノード、ルールがすべて対応している必要があります。IPv6 の経路が不安定な場合は、まず無効にして比較テストを行い、長期的に変更するか判断してください。

設定を変更した後は、「保存に成功した」「再読み込みに成功した」「通信が新しい設定を経由している」の3つを区別してください。クライアントによってはテキストを保存するだけで、すぐには再読み込みません。また、構文エラー時に以前の実行可能な設定を保持する場合もあります。最も確実なのは、再読み込みログを確認し、現在のモードとポートを照合したうえで、判定しやすいアクセスを1回行い、ルールの適用を観察することです。ポート設定がまだ不明な場合は、よくある質問のシステムプロキシとポートに関する項目も確認してください。

03 · NAME RESOLUTION

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

DNS モジュールの位置づけ

Clash DNS を有効にすると、ドメイン解決は OS が特定のサーバーへ問い合わせを送るだけの処理ではなくなります。コアはルールに応じて上流を選び、結果をキャッシュし、Fake-IP モードではドメインと予約アドレスの対応関係を管理できます。これにより、問題を「上流 DNS にアクセスできない」「ドメインが不適切なアドレスへ解決される」「アプリが Clash を迂回して暗号化 DNS を直接利用する」の3種類に分けて考えられます。プロキシ接続は正常なのにWebページを開けない場合、原因をすぐノードに求めず、DNS のリッスン、システム DNS の向き先、ルール経路も確認してください。

dns.enable はモジュールの有効・無効を制御し、listen はリッスンアドレスとポートを指定します。デスクトップのグラフィカルクライアントがシステム DNS を自動的に引き受ける場合、リッスンポートを手動で変更するとクライアントの管理処理と競合することがあります。リッスンアドレスを明示的に設定する必要があるのは、主にルーターや LAN 内サービスの利用時です。LAN インターフェースにバインドする場合は、ポートが OS の名前解決サービスと競合していないか確認し、アクセス可能な範囲も制限してください。

Fake-IP と Redir-Host

enhanced-mode: fake-ip は、まずアプリに予約アドレスを返し、その後 Clash が対応関係から元のドメインを復元してルール照合を行います。ドメイン情報を完全に保ちやすく、ルール判定も速く、実アドレスの解決を待ってから転送する手順を減らせる点が利点です。一方、実アドレス、LAN 検出、特殊プロトコルに依存する一部のアプリでは互換性の問題が起きるため、fake-ip-filter で除外する必要があります。redir-host は従来の実アドレス解決に近い経路で、互換性の考え方が異なりますが、ドメイン認識と接続経路は OS のキャッシュや解決タイミングの影響を受けます。

fake-ip-range は予約アドレスの範囲を指定します。通常はクライアントまたはコアの初期値をそのまま使い、実際の LAN、VPN のアドレスプール、企業ネットワークの経路と重複させないでください。LAN 内ドメインへのアクセスで予約アドレスが返された場合は、アドレス範囲全体を不用意に変更するのではなく、まず対象ドメインを除外リストに追加します。除外ルールはできるだけ正確にし、単一ホストには完全なドメイン名を使い、サブドメインまで対象にする場合は対応するワイルドカード形式を使用してください。変更後はアプリとシステムの DNS キャッシュを削除します。

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"
    - "*.local"
    - "time.*.com"
  default-nameserver:
    - 223.5.5.5
    - 1.1.1.1
  nameserver:
    - https://dns.alidns.com/dns-query
    - https://cloudflare-dns.com/dns-query
  proxy-server-nameserver:
    - https://dns.alidns.com/dns-query

3種類の上流フィールドの使い分け

default-nameserver は主に暗号化 DNS 上流自身のドメイン名を解決するために使うため、直接到達できる IP アドレスを指定するのが一般的です。すべてをドメイン名で記述すると、「DNS サーバーのドメイン名を解決するために、まだ利用可能なリゾルバーが必要」という循環に陥ることがあります。nameserver は通常の問い合わせに使う上流で、UDP、DoT、DoH のアドレスを指定できます。proxy-server-nameserver はプロキシノードのサーバー名を解決するために使い、ノードの名前解決とプロキシ経路が依存関係になるのを避けます。ノードサーバーが IP アドレスなら影響は小さいですが、ドメイン名なら非常に重要です。

nameserver-policy を使うと、ドメインごとに異なる上流を指定できます。企業イントラネットのドメイン、地域別の名前解決、個別処理が必要なサービスに適しています。これは「問い合わせをどこへ渡すか」を決めるもので、最終接続がどのプロキシグループを通るかを直接決めるものではありません。接続の分岐は引き続きルールが担当します。DNS policy とプロキシ rule を同じ構文として扱ったり、解決結果だけでプロキシが有効か判断したりしないでください。

dns:
  nameserver-policy:
    "geosite:cn":
      - https://dns.alidns.com/dns-query
    "internal.example":
      - 192.0.2.53
  fallback:
    - tls://1.1.1.1
  fallback-filter:
    geoip: true
    geoip-code: CN

DNS のトラブル対処は経路に沿って行う

まず Clash DNS が実際にリッスンしているか確認し、次にシステムまたは TUN の通信がそのリッスン先へ送られているか確認します。その後、問い合わせがどの上流を使用したかを観察し、最後に接続ルールを確認します。ブラウザーのキャッシュだけを削除したり、ノードを頻繁に切り替えたりしても、DNS 層の問題は特定できません。ログに上流のタイムアウトが出ている場合は、現在のネットワークからその上流へ直接接続できるかテストします。ドメインは解決できるのに接続できない場合は、ルールの適用、IPv4 と IPv6 の選択、ノードの可用性を確認してください。特定のアプリだけが異常なら、アプリ内蔵の DoH、QUIC、キャッシュ機構も考慮します。

04 · OUTBOUND

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

すべてのノードに共通する識別フィールド

proxies はプロキシノードオブジェクトのリストです。各オブジェクトには少なくとも一意の name、プロトコルの type、サーバーの server、ポートの port が必要で、その他のフィールドはプロトコルによって異なります。ノード名は画面上のラベルではなく、設定内部で参照するキーです。同名のノードが2つあると、プロキシグループからの参照が曖昧になり、サブスクのノードとローカルノードが同名の場合はマージ時に上書きされることもあります。名前には地域、回線、用途などを含めると管理しやすくなりますが、頻繁に変わる状態を名前に入れるのは避けてください。

server には IP アドレスまたはドメイン名を指定できます。ドメイン名を使う場合は、前章で説明したノードの名前解決経路が利用できる状態でなければなりません。ポートはリモートサービスのポートであり、ローカルの mixed-port ではありません。この2つの混同は手入力時によくあるミスです。プロトコルフィールドはサーバー側の設定と一致させる必要があり、暗号化方式や転送方式を試しに変更して「自動検出」することはできません。認証失敗、TLS ハンドシェイク失敗、ネットワークタイムアウトは異なる段階の問題なので、ログと照合して判断します。

Shadowsocks と VMess の例

Shadowsocks ノードでは、暗号化方式とパスワードが主な確認ポイントです。cipher はコアが対応し、サーバー側と同じ値でなければなりません。パスワードには必ず引用符を付け、特殊文字が YAML として解釈されるのを防ぐのがおすすめです。サーバー側でプラグインも使用している場合は、プラグイン名とオプションも同時に指定してください。サーバー、ポート、パスワードだけをコピーしても動作しません。プラグインパラメーターは通常マッピングオブジェクトなので、階層を誤るとプラグインが読み込まれず、ノードも利用できなくなります。

proxies:
  - name: "SS-Example"
    type: ss
    server: 203.0.113.20
    port: 443
    cipher: aes-128-gcm
    password: "your-password"
    udp: true

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

VMess には認証情報のほか、TLS、WebSocket、HTTP、gRPC などの転送設定が含まれる場合があります。servername は TLS SNI に使われ、WebSocket の Host は HTTP リクエストヘッダーです。両者が同じになる場合はありますが、意味は異なります。パスの先頭スラッシュを残し、サーバー側の入口と一致させてください。古い設定には過去の互換フィールドが含まれていることがあります。新しいコアへ読み込む前に、他のプロトコルテンプレートからつぎはぎするのではなく、サービス提供元が示す現在のパラメーターを基準にしてください。

Trojan、VLESS と TLS 関連フィールド

Trojan は通常、パスワード認証と TLS を使用します。VLESS は UUID を使い、異なる転送方式やフロー制御を組み合わせられます。TLS ノードで最も多い問題は、サーバーアドレス、証明書名、SNI の不一致です。skip-cert-verify は証明書検証の挙動を変更するため、長期的な修復策として使わないでください。証明書検証に失敗したら、まず端末の時刻、サーバー証明書、ドメイン名、servername を確認します。テスト環境で使用している証明書の種類を明確に把握している場合に限り、一時的な変更を行い、理由を記録してください。

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

  - name: "VLESS-Example"
    type: vless
    server: vless.example.com
    port: 443
    uuid: 00000000-0000-4000-8000-000000000001
    tls: true
    servername: vless.example.com
    network: grpc
    grpc-opts:
      grpc-service-name: proxy

UDP、インターフェースとダイヤル動作

udp: true はノードが UDP 転送を許可することを示しますが、サーバー、プロトコル、クライアントモード、ローカルネットワークも対応していなければなりません。このフィールドを追加するだけで、UDP 非対応の回線が対応するわけではありません。ゲーム、音声通話、DNS などでは、ログで通信が UDP を通っているか確認し、プロキシグループが選択したノードに対応能力があるか調べます。一部の設定には interface-name、routing-mark、ダイヤル関連フィールドもありますが、これらは複数 NIC やゲートウェイ環境向けです。デスクトップユーザーは、インターフェース名が分からないまま記述しないでください。

ノードが遅延テストに通過しても、特定のテスト URL へのリクエストをその時点で確立できたことしか示しません。すべてのプロトコルやサイトが正常とは限りません。テストアドレス、TLS 経路、パケットロス、帯域幅が結果に影響します。Clash の遅延テスト結果の見方も確認し、実際のアクセスとログを併せて判断してください。クライアントを替えて比較する場合は、当サイトのダウンロード一覧で各プラットフォームの第一候補として Clash Plus を案内し、Clash Verge Rev、FlClash、Clash Nyanpasu、ClashX Meta などの選択肢も掲載しています。

05 · POLICY

プロキシグループのフィールドと選択ロジック

select：手動で選択するタイプ

プロキシグループは、ノード、組み込みアクション、他のプロキシグループを、ルールから参照できる出口としてまとめます。select は最も直接的なタイプで、ユーザーがクライアント画面から項目を手動選択し、その結果は通常クライアントに保存されます。総合入口、地域選択、固定回線が必要なサービスに適しています。グループ内の proxies では、既存のノードやプロキシグループを名前で参照でき、DIRECT、REJECT などの組み込みアクションも指定できます。参照対象は最終設定内に存在していなければなりません。

プロキシグループは入れ子にできます。たとえば「ノード選択」から「香港自動」「日本自動」「手動選択」を参照する構成です。入れ子にするとルールの重複を減らせますが、階層が深いほどトラブル対処は難しくなります。接続の最終的な経路を確認するときは、ルールの送信先から始め、各階層のプロキシグループを順に展開し、具体的なノードまたは組み込みアクションまで確認します。名前は機能を反映させ、「自動選択」という名前のグループを複数作ってテスト範囲が分からなくなる状態は避けてください。

url-test、fallback と load-balance

url-test は指定した URL に定期的にリクエストを送り、測定結果に基づいて条件に合うノードを選びます。interval はテスト間隔、tolerance は遅延が近い場合の頻繁な切り替えを抑えるための値です。テスト頻度が高すぎるとリクエスト数とバッテリー消費が増え、間隔が長すぎると回線の変化をすぐ反映できません。テスト URL には安定していて応答データが小さく、実際の出口への接続性を代表するものを選びます。ログインが必要なページ、リダイレクトが複雑なページ、地域制限の強いページは避けてください。

fallback は利用可能性の優先順を重視し、現在のノードが使えないときに後続の項目へ切り替えます。load-balance はポリシーに従って複数ノードへ接続を分配するため、セッションの一貫性を理解している場面に適しています。送信元アドレスを固定したいログイン、決済、長時間接続のサービスでは、負荷分散を安易に使わないでください。自動グループのテスト結果も、実際の閲覧速度ランキングではありません。テスト先と、その時点のネットワーク条件に対応した結果にすぎません。

proxy-groups:
  - name: "ノード選択"
    type: select
    proxies:
      - "香港自動"
      - "手動選択"
      - DIRECT

  - name: "手動選択"
    type: select
    proxies:
      - "SS-Example"
      - "Trojan-Example"
      - "VLESS-Example"

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

Provider からノードを動的に読み込む

ノードがサブスク Provider から提供される場合、プロキシグループは use で Provider 名を参照でき、各ノードを proxies に書く必要がありません。一部のコアでは filter と exclude-filter による名前の絞り込みにも対応しています。絞り込みには通常、正規表現を使うため、文字範囲や括弧を正しくエスケープしてください。サブスクごとに命名規則が違う場合、「港」や「HK」だけではノードを取りこぼしたり、同じ文字を含む説明項目まで選んだりします。実際のノード名を確認してから、フィルター式を作成してください。

proxy-groups:
  - name: "香港ノード"
    type: select
    use:
      - provider-main
    filter: "(?i)香港|港|HK|Hong Kong"
    exclude-filter: "(?i)ゲーム|残り|期限切れ"

  - name: "フェイルオーバー"
    type: fallback
    use:
      - provider-main
    url: https://www.gstatic.com/generate_204
    interval: 600

ヘルスチェックと接続の維持

Provider のヘルスチェックと、プロキシグループ自身の URL テストが同時に存在する場合があります。前者はノードの利用可能状態を維持し、後者はグループ内の選択を行います。重複した高頻度テストは不要なリクエストを生むため、どの層がチェックを担当するかを明確にし、間隔を適切に設定してください。プロキシグループを切り替えても、既存の接続がすぐ移行するとは限りません。ブラウザーの接続プール、QUIC、長時間接続が古い出口を使い続ける場合があります。切り替え結果を確認するときは、画面の選択項目だけで判断せず、元の接続を閉じてリクエストを再実行し、必要ならアプリの接続プールを消去してください。

ルールが参照するプロキシグループは、長期的に存在する名前にしてください。サブスク更新でノード一覧が変わっても、ルールの送信先グループ名まで頻繁に変えるべきではありません。安定した構成には通常、総合入口、自動グループ、手動グループ、直接接続、拒否処理が含まれ、必要に応じて動画配信、メッセージング、開発サービス用のグループを追加します。グループ数が多いほど分岐が正確になるわけではありません。実際にルールから参照され、用途が明確なグループだけが保守する価値を持ちます。

06 · ROUTING

Clash ルール分岐の構文と優先順位

ルールは上から順に照合し、最初に一致したものを使う

rules は順序付きリストです。接続情報があるルールの条件を満たすと、コアはそのルールで指定されたポリシーを使い、後続の通常ルールを確認しません。そのため、具体的なルールを広範なルールより前に置き、フォールバックの MATCH は末尾に置く必要があります。たとえば DOMAIN-SUFFIX,example.com,DIRECT を先に、MATCH,ノード選択 を後に書けば、対象ドメインは直接接続されます。順序を逆にすると、先頭の MATCH がすべての通信を受け取り、後続ルールは実行されません。

典型的なルールは「ルール種別、照合内容、ポリシーの送信先」で構成され、種別によってはパラメーターを追加できます。カンマがフィールドの区切りとなり、プロキシグループ名は設定内と完全に一致していなければなりません。ルールリストの各行は YAML の文字列項目として記述します。ドメインルールにプロトコル、パス、ポートを付けないでください。https://sub.example.com/path に一致させたい場合はホスト名を取り出し、完全一致、サフィックス、キーワードのいずれか適切なルールを選びます。

ドメイン、アドレスとプロセスのルール

DOMAIN は完全なドメイン名に完全一致し、DOMAIN-SUFFIX は指定ドメインとそのサブドメインに一致し、DOMAIN-KEYWORD はドメイン名に含まれるキーワードで一致します。サフィックスルールは通常、キーワードルールより制御しやすい形式です。短すぎるキーワードは一致範囲を広げます。たとえば一般的な2文字を使うと、無関係なドメインまで誤って対象になることがあります。サービス全体を対象にしたい場合は、まず実際のリクエストドメインを集め、そのうえで完全一致とサフィックスの組み合わせを決めてください。

IP-CIDR と IP-CIDR6 はアドレス範囲で照合します。ドメイン接続がアドレスルールの対象になるかは、名前解決の流れと no-resolve パラメーターによって決まります。追加の DNS 解決を発生させたくないアドレスルールでは、対応する構文で no-resolve を指定できます。GEOIP はアドレスの地理データベースによって分類するため、データベースの出典と更新状況に左右され、サービスの所属地域を絶対的に判定するものではありません。PROCESS-NAME、PROCESS-PATH などのプロセスルールは OS とクライアントの権限に依存し、モバイル端末、サンドボックス環境、TUN 実装では対応状況が異なる場合があります。

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

ルールセットと論理的な組み合わせ

大規模なルールをすべてメイン設定に書くのではなく、RULE-SET でルール Provider を参照できます。ルールセットには照合条件だけを保存し、メイン設定でポリシーの送信先を指定することで、同じセットを複数のデバイスから異なる出口に振り分けられます。使用時は Provider の behavior とファイル内容が一致しているか確認してください。domain はドメイン項目、ipcidr はアドレス範囲、classical は完全なクラシックルールに適しています。型が一致しないと、ファイルのダウンロードには成功しても期待どおりに解析できないことがあります。

一部のコアは AND、OR、NOT などの論理ルールに対応しています。「特定のプロセスが特定のドメインへアクセスする」といった複合条件に適していますが、基本ルールより可読性とクライアント間の互換性が低くなります。基本種別だけでは要件を正確に表せない場合に限って導入し、用途を近くに記録してください。ルールが複雑になったら、目視で推測するより適用ログを確認する方が確実です。

rules:
  - RULE-SET,private,DIRECT
  - RULE-SET,applications,DIRECT
  - RULE-SET,streaming,メディアサービス
  - RULE-SET,global,ノード選択
  - GEOIP,CN,DIRECT
  - MATCH,ノード選択

ルールが適用されない場合の特定方法

まず接続ログから実際のドメイン、接続先アドレス、プロセス、適用されたルールを確認し、その後設定に戻って調べます。ブラウザーのアドレスバーに表示されるメインドメインだけで、ページがそこにしかアクセスしていないとは限りません。スクリプト、画像、認証、API が複数のドメインに分かれていることがあります。ログに IP しか表示されない場合は、DNS が Clash によって処理されているか、アプリがアドレスへ直接接続していないか確認してください。想定したルールが MATCH の後ろにあるなら、順序を移動することで原因を説明できます。ルールの送信先グループが存在しない場合は、参照を修正します。

ルール分岐の目的は、可能な限り多くすることではなく、安定して説明できることです。LAN と予約アドレスは通常、直接接続を優先し、明確なサービスルールを中央に置き、地域別アドレスルールを後ろに配置し、MATCH でフォールバックします。ルールを追加するたびに、正方向の適用と逆方向の影響を確認してください。対象サービスが意図したグループを通り、無関係なサービスが広すぎる条件に巻き込まれていないかを見ます。プロキシ接続後にWebページへアクセスできない場合は、項目別チェックリストでシステムプロキシ、ポート、ノード、DNS、ルールを確認してください。

07 · EXTERNAL SOURCES

Proxy Provider とルールセット

Provider が解決する問題

proxy-providers は外部ノードの提供元とメイン設定を分離します。メイン設定にはプロキシグループとルールの構造を残し、Provider がノード一覧を定期更新します。これにより、サブスクの内容が変わってもプロキシグループ名を安定させられ、複数の自動グループから同じノードソースを参照できます。Provider 名は内部参照キーなので安定させてください。サブスク URL を変更する際も、すべてのプロキシグループを修正する必要はなく、該当する Provider 定義だけを更新します。

一般的な type には http と file があります。HTTP タイプは URL から取得し、file タイプはローカルパスを読み込みます。path はキャッシュまたはローカルファイルの場所を指定し、複数の Provider が同じパスへ書き込まないようにします。interval はリモート更新の間隔を制御します。短すぎるとリクエストが頻発し、長すぎると上流の変更をすぐ受け取れません。クライアント独自のサブスク更新スケジュールがある場合は、コアのフィールドが上書きされないかも確認してください。

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

proxy-groups:
  - name: "サブスクノード"
    type: select
    use:
      - provider-main

Provider ファイル形式とヘルスチェック

プロキシ Provider の返却内容はコアの要件に適合している必要があり、通常は proxies をキーとするノード一覧を含みます。完全なメイン設定ではありません。通常のサブスク URL、Base64 形式のノード一覧、完全な設定ファイルをそのまま Provider ファイルとして指定しても、現在のコアが認識できるとは限りません。形式変換は信頼でき、管理可能な環境で行い、変換時にノードフィールドが失われていないか確認してください。サブスク形式の違いについては、Clash のサブスクと他のリンク形式を相互変換する方法も参照してください。

health-check は Provider 内のノードを定期的に検証します。テスト URL と間隔の考え方は、自動プロキシグループと同じです。ヘルスチェックの失敗は、必ずしもサブスクのダウンロード失敗を意味しません。前者はノードテスト、後者は Provider ファイルの取得です。ログでは HTTP 更新状態、ファイル解析状態、ノードテスト結果を区別して確認します。更新後にノード数が0になった場合は、まずキャッシュファイルが実際に保存されたか確認し、次に形式とフィルター式を照合してください。

rule-providers の behavior タイプ

ルール Provider は behavior で内容の種類を宣言します。domain ファイルは通常、ドメインまたはドメインセットを保存し、ipcidr は IPv4 と IPv6 のアドレス範囲を保存し、classical は種別付きの完全なルールを保存します。format で YAML、テキスト、コアが対応するバイナリ形式を区別できる場合もあります。参照時は、メインルールで Provider 名とプロキシグループを指定します。例：RULE-SET,private,DIRECT。Provider ファイルにポリシーを固定しないからこそ、外部ルールを再利用できます。

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

  local-network:
    type: file
    behavior: ipcidr
    format: yaml
    path: ./rules/local-network.yaml

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

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

Provider の更新に失敗すると、コアは通常、既存のキャッシュを継続利用しようとしますが、具体的な挙動はクライアントとキャッシュの状態によって異なります。初回読み込みでキャッシュがなく、リモート URL にアクセスできない場合は、該当するノードやルールが直接欠落します。一度正常に動作した端末では、古いファイルを使い続けることがあります。トラブル対処では、「一度もダウンロードに成功していない」のか「以前は使えたが、現在の更新に失敗している」のかを記録してください。両者では対処手順が異なります。

リモートのルールとノードソースには、安定した HTTPS URL を使用してください。URL のクエリパラメーターにはサブスク識別情報が含まれる場合があるため、公開ログ、スクリーンショット、共有設定に記載しないでください。設定構造を共有する場合は、アドレスと認証情報を置き換えつつ、フィールド階層は残します。パスについてもクライアントの作業ディレクトリを考慮してください。相対パスはコアの実行ディレクトリを基準に解決され、ユーザーに表示されるサブスクファイルの場所を基準にするとは限りません。ファイルが見つからない場合は、./ を何度も変更するより、ログに示された絶対パスを確認する方が有効です。

複数の Provider をマージすると、ノード名が重複することがあります。プロキシグループのフィルターは最終的な名前だけを見て、同名ノードがどのソース由来かを区別できません。クライアントのオーバーライドで Provider ごとに異なる接頭辞を付けるか、サブスク管理の段階で命名を統一してください。複数設定を体系的に管理する方法は、Profile 構造の入門と複数設定の管理も参考になります。

08 · MAINTENANCE

設定オーバーライド、マージとシステムのトラブル対処

オーバーライド層が必要な理由

サブスク設定は更新時に上流の内容で置き換えられるため、サブスク本文を直接編集するとローカルの変更が失われやすくなります。オーバーライド層を使うと、ポート、DNS、プロキシグループの追加、ルールの先頭追加など、端末固有の設定をリモート設定から分離できます。クライアントによって呼び方は Override、Mixin、Merge、拡張スクリプト、設定拡張など異なり、マージの意味も完全には同じではありません。利用前に、オブジェクトの再帰マージ、配列置換、配列追加、スクリプト処理のどれを採用しているか確認してください。

マッピング型のフィールドは、キー単位で上書きできることが多く、たとえば dns.enable だけを変更して他の DNS 子項目を残せます。一方、配列型フィールドでは差異が生じやすくなります。rules が全体置換されると、元のサブスクルールは消えます。追加方式では、ローカルルールが MATCH の後ろに置かれて適用されないことがあります。プロキシグループとノードもリストであり、名前でマージするか位置でマージするかによって結果が大きく変わります。そのため、オーバーライド後はテキストの構文が正しいことだけでなく、最終設定そのものを確認してください。

# 例：概念的なオーバーライド内容。実際のマージ方法はクライアントによって異なります
mode: rule
log-level: info

dns:
  enable: true
  enhanced-mode: fake-ip

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

ルールの先頭追加、末尾追加と削除

ローカルルールは通常、サブスクのルールより前に置く必要があります。特に、広範なルールを上書きしたい場合は重要です。prepend と append に対応するクライアントでは、明確な例外を prepend に置き、補足的なフォールバックを append に置きます。クライアントが配列全体の置換にしか対応していない場合は、その後のルール保守を自分で担う必要があります。リモートルールを削除する場合、反対のルールを追加して「打ち消す」ことは通常できません。より具体的なルールを前に追加するか、クライアントが提供するフィルタースクリプトを使用します。

フィールドを空にするときは、正しい型を使ってください。リストを空にする場合は通常 []、マッピングを空にする場合は {} と書きます。キーを削除できるかどうかはオーバーライドの実装によって異なります。null は削除を意味する場合もあれば、空値としてコアに渡され、型エラーを起こす場合もあります。慣れていないマージャーを使う場合は、まず影響の小さいフィールドでテストし、マージ前後の結果を比較してから、完全なルールやプロキシグループを処理してください。

構文からネットワークまでの4層チェック

第1層は YAML の解析です。インデント、コロン、リスト記号、引用符、フィールド型を確認します。この層で失敗すると、クライアントは通常行番号を示しますが、実際の原因が前の行にあることもあります。たとえば引用符が閉じていない場合です。第2層は設定の参照です。プロキシグループが存在するノードや Provider を参照しているか、ルールの送信先が存在するか、Provider のパスが競合していないかを確認します。第3層は実行時のリッスンです。プロキシポート、制御ポート、DNS ポート、TUN が正常に起動しているか確認します。第4層で初めてネットワークの挙動、つまりノードのハンドシェイク、DNS 上流、ルールの適用、アプリがシステムプロキシを使っているかを確認します。

最小構成で特定する方法

複雑な設定で問題が起きた場合は、ローカルのテスト設定を1つコピーし、既知のノード1つ、select プロキシグループ1つ、MATCH ルール1つ、必要なポートフィールドだけを残します。まずプロキシ経路を検証し、その後 DNS、Provider、ルールセットを段階的に追加します。追加するたびに再読み込みとテストを行い、初めて障害が発生した箇所を主な調査範囲とします。この方法は複数のノード、DNS、動作モードを同時に切り替えるより少し時間がかかりますが、結果を再現しやすく、偶然復旧した後に原因を説明できなくなる事態も避けられます。

mixed-port: 7890
mode: rule
log-level: debug

proxies:
  - name: "Test-Node"
    type: ss
    server: 203.0.113.30
    port: 443
    cipher: aes-128-gcm
    password: "your-password"

proxy-groups:
  - name: "TEST"
    type: select
    proxies:
      - "Test-Node"
      - DIRECT

rules:
  - MATCH,TEST

テストが完了したら、ログレベルを通常に戻し、検証済みの変更を安定したオーバーライド層へ戻します。問題が特定のプラットフォームだけで起きる場合は、システムプロキシの実装、権限、TUN ドライバー、アプリのネットワークスタックの違いも考慮してください。Windows の完全なインストール手順とシステムプロキシの問題はWindows に Clash をインストールする全手順を参照してください。一般的な問題はよくある質問で、基本知識、インストールと設定、利用のコツ、トラブル対処の分類から引き続き確認できます。

長期的に更新できる設定を維持する

安定した設定では、上流データとローカルの意図を分離します。サブスクまたは Provider でノードを管理し、メイン設定でプロキシグループとルールを管理し、オーバーライド層に端末ごとの差異を保存します。プロキシグループには安定した名前を付け、カスタムルールには理由を記録し、ポートと DNS の重複定義を避けてください。サブスク更新後は、最終設定のノード数、プロキシグループの参照、MATCH の位置を確認します。クライアントを更新した後は、フィールドの互換性とオーバーライドのマージ結果を重点的に確認してください。

端末を移行するときは、単一の YAML だけをコピーしないでください。Provider キャッシュを再ダウンロードできるか、クライアントがプロキシグループの選択状態を保存しているか、システムプロキシと TUN の権限をどう設定するかも記録します。設定ファイルが記述するのはコアの挙動であり、OS の権限やクライアント画面の状態がすべて含まれるわけではありません。この境界を意識して管理すれば、問題が起きたときに YAML、クライアント設定、システムネットワークのどれを変更すべきか判断できます。