Clash 設定ファイル完全ガイド

1. YAML の構造と設定の読み取り順序

Clash の設定ファイルは、キー、値、リスト、マッピングで構成されるデータツリーです。トップレベルには通常、ポート、動作モード、ログレベル、DNS、プロキシノード、プロキシグループ、ルールなどが含まれます。コアは起動時にまず YAML 構文を解析し、次に項目の型を検証してから、待ち受けポート、DNS モジュール、送信プロキシを初期化し、最後にルールを読み込みます。前段の構文解析に失敗すると、後続のノードやルールは動作状態になりません。トラブル対応では、まずファイル全体を正常に解析できることを確認し、その後で個別ルールのマッチングを確認しましょう。

YAML はインデントで階層を表現するため、半角スペース2個に統一し、タブを混在させないことを推奨します。コロンの後には通常スペースを1つ入れ、リスト項目はハイフンで始めます。コロン、シャープ記号、波括弧、特殊な空白を含む文字列は引用符で囲むと安全です。引用符で囲まれていないシャープ記号はコメントを表し、その後の内容は解析されません。真偽値は true または false を使い、ポートなどの数値を誤って引用文字列にしないでください。クライアントによって保存時に項目の順序が並べ替えられることがありますが、階層と型が変わらなければ、順序は通常トップレベル項目の意味に影響しません。

最小構成を拡張する方法

理解しやすい設定は、待ち受けポート、モード、ノード、プロキシグループ、ルールの5つから始められます。次の例は構造の関係だけを示しています。ノードをまず proxies に定義し、プロキシグループでノード名を参照し、最後にルールで通信をプロキシグループへ渡します。参照名は大文字・小文字、スペース、記号を含めて完全に一致させる必要があります。存在しないプロキシグループをルールが指定すると、コアは通常、検証時に参照先がないと報告します。

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

proxies:
  - name: "example-node"
    type: socks5
    server: 192.0.2.10
    port: 1080

proxy-groups:
  - name: "手動選択"
    type: select
    proxies:
      - example-node
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.com,手動選択
  - MATCH,DIRECT

例にあるアドレスはドキュメント用であり、実際の接続にはサブスクリプションが提供するサーバー情報を使用します。ノードを手動で記述する場合は、まずプロトコルの種類と必須項目を確認してから、プロトコル固有のパラメーターを追加してください。サブスクリプションから生成された設定が長くなるのは、DNS、スニッフィング、ルールプロバイダー、複数のプロキシグループも含むためです。読むときは先頭から末尾まで追う必要はなく、まずトップレベルのキーを探し、「ルールの宛先 → プロキシグループ → ノード」の参照関係をたどると効率的です。

アンカー、エイリアス、重複キー

YAML はアンカーとエイリアスによるパラメーターの再利用に対応していますが、すべてのクライアントのビジュアルエディターがこの記法を完全に保持できるとは限りません。サブスクリプション変換、GUI での保存、リモート上書きを経ると、アンカーが通常の項目へ展開されることがあります。複数のクライアント間で頻繁に設定を移行するなら、項目を直接記述する方が安全です。もう1つの典型的な問題が重複キーです。同じマッピング階層に mode や dns が2つあると、パーサーが後者を採用する場合もあれば、処理を拒否する場合もあります。上書きの挙動に依存せず、マージ前にトップレベルの重複キーを解消してください。

ファイルのエンコーディングには UTF-8 を推奨します。プロキシグループ名やノード名に日本語を使うことはできますが、外部スクリプトで設定を処理する場合は、短い英語名の方がマッチングしやすくなります。改行形式は通常解析に影響しませんが、Web ページやチャットツールから設定をコピーすると、全角コロン、曲線引用符、不可視スペースが混入しやすくなります。「マッピング値をここに置けません」といったエラーが出たら、設定全体を削除するのではなく、まずエラー行とその直前の行でインデント、コロン、引用符の閉じ忘れを確認してください。

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

共通項目は、コアが本機や LAN からどのように通信を受け取り、実行情報をどう出力するかを決めます。最もよく使われる入口は mixed-port で、同じポートで HTTP と SOCKS のプロキシリクエストを受け付けるため、ブラウザー、ターミナル、システムプロキシを共通利用できます。port と socks-port を個別に設定することもできますが、ポート管理の手間が増えます。クライアント画面に表示される「システムプロキシポート」は通常これらの項目に由来します。ファイルを変更した後は、GUI クライアント側の設定で再び上書きされていないかも確認してください。

allow-lan は、他のデバイスが現在のデバイスのプロキシポートへ接続できるかを制御します。false は単独利用に適しています。true にする場合は、bind-address と組み合わせて待ち受け範囲を制限し、OS のファイアウォールも確認してください。LAN 接続を許可しても認証が自動的に設定されるわけではなく、ルーターが通信をそのポートへ転送するわけでもありません。スマートフォンとパソコンでそれぞれクライアントを動かすだけなら、LAN 待ち受けを有効にする必要はありません。

ルール、グローバル、直接接続モード

rule は日常利用で最も一般的なモードです。コアは rules を上から順に照合し、マッチすると対応するプロキシグループまたは送信先へ接続を渡します。global は個別ルールの判定を迂回し、通信をすべてグローバルプロキシへ送ります。特定ノードの利用可否を一時的に確認するには便利ですが、ルールが正しいかを判断する方法には向きません。direct は通信を直接接続し、問題がプロキシ経路にあるのかローカルネットワークにあるのかを切り分けるのに使えます。モード切り替えで変わるのはルーティング判断だけで、DNS、証明書、権限、システムプロキシの未設定などが自動修復されるわけではありません。

GUI クライアントの「ルール」「グローバル」「直接接続」ボタンは、通常コントロールインターフェースを通じて実行中の状態を変更しますが、元の YAML を書き換えるとは限りません。再起動後にどのモードになるかは、クライアントが実行状態を保存するか、設定内の mode を使うかによって異なります。「再起動するとモードが戻る」場合は、設定ファイル、クライアント設定、サブスクリプション更新の動作を同時に確認してください。更新のたびにサブスクリプションが元ファイルを置き換えるため、サブスクリプションファイルへ共通項目を直接書き込むと次回更新で失われます。クライアントの上書き機能を使う方が適切です。

システムプロキシと TUN の違い

待ち受けポートはコアがプロキシリクエストを受け付ける準備ができたことを示すだけで、すべてのアプリが自動的に通信を送るわけではありません。システムプロキシは OS が公開するプロキシアドレスで、この設定を読み取るアプリだけが利用します。TUN モードは仮想ネットワークインターフェースを通じて、より広範な IP 通信を引き受けます。どちらも同じルールやプロキシグループを使えますが、通信の入口は異なります。取り込み範囲、互換性、トラブル対応の違いは、TUN モードとシステムプロキシの仕組みの比較を参照してください。

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

上の例ではコントロールインターフェースをループバックアドレスに制限し、本機の GUI クライアントからの呼び出しに適した構成にしています。allow-lan が false でも、それぞれの待ち受けアドレスの用途を明確に理解しておくことを推奨します。ポートが競合したら、まず重複起動しているクライアントを終了するかポートを変更し、その後システムプロキシが新しいポートを指していることを確認してください。YAML だけを変更してシステムプロキシを更新しないと、コアは正常に動作しているのにブラウザーだけ接続できない状態になります。

3. DNS 設定と名前解決の経路

DNS は Clash 設定の中でも誤解されやすい部分です。ドメインへアクセスするとき、アプリ自身が解決する場合もあれば、ドメインをプロキシプロトコルへ渡す場合もあります。システム DNS、ブラウザーのセキュア DNS、Clash の DNS モジュール、リモートプロキシが関与することもあります。設定の dns.enable はコアの DNS モジュールを有効にするかだけを制御し、すべてのアプリが問い合わせをそこへ送ることを保証しません。システムプロキシ利用時も、独自の名前解決経路を使うアプリがあります。TUN では通常、統一的に取り込めますが、DNS ハイジャックやシステム権限にも左右されます。

nameserver は主要な名前解決サーバーのリストで、default-nameserver は DNS サーバー自身のドメイン名を解決するために使います。これにより「リゾルバーのアドレスを先に解決する」という循環依存を避けられます。nameserver に IP アドレスを直接書けば依存関係は少なくなりますが、暗号化 DNS のドメイン名を書く場合は default-nameserver に直接到達できる基礎的な名前解決先を指定してください。fallback などのフィルター項目は、より複雑な DNS 振り分けに使えます。仕組みを理解しないまま機械的に追加すると、複数の経路によって結果が予測しにくくなります。

redir-host と fake-ip

enhanced-mode の代表的な値は redir-host と fake-ip です。redir-host は実際の名前解決結果を保持するため直感的ですが、透過プロキシ環境では IP 通信だけからドメインを復元しにくいことがあります。fake-ip はドメインに対して予約アドレスプール内の一時アドレスを返し、コアがドメインと接続の対応関係を作ってから、ドメインルールで処理します。実際にその一時アドレスへ接続するのではなく、マッピングを利用してルーティングします。fake-ip はルールマッチングや透過的な取り込みと相性がよい一方、一部の LAN サービス、デバイス検出、ゲームプラットフォーム、実 IP に依存するアプリではフィルターへの追加が必要です。

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:
    - 1.1.1.1
    - 8.8.8.8
  nameserver:
    - https://1.1.1.1/dns-query
    - https://dns.google/dns-query
  fake-ip-filter:
    - "*.lan"
    - "localhost.ptlogin2.qq.com"
    - "+.stun.*.*"
    - "+.stun.*.*.*"

例は項目間の関係を示すもので、すべてのネットワーク環境で同じ DNS サービスを使うべきという意味ではありません。企業、学校、家庭のネットワークでは内部ドメインの解決にローカル DNS が必要な場合があります。そのときは LAN の名前解決経路を残すか、内部ドメイン向けに専用の nameserver-policy を設定してください。fake-ip-range には定められた予約アドレス帯を使い、家庭内 LAN、VPN、コンテナネットワークと重複させないでください。LAN デバイスに接続できない、プリンター検出がおかしい、ゲームへログインできない場合は、DNS モジュール全体を無効にする前に、そのドメインを fake-ip-filter に入れるべきか確認します。

ドメインごとにリゾルバーを選ぶ

nameserver-policy を使うと、特定のドメインに指定したリゾルバーを割り当てられます。たとえば内部ドメインはルーターへ、ローカルドメインは LAN DNS へ、それ以外は主要 nameserver へ送れます。これは「誰が解決するか」を決める項目であり、ルールの DOMAIN-SUFFIX が決める「どこから接続するか」とは別の段階です。リゾルバーの選択が正しくても、後続の接続が同じポリシーを通るとは限りません。逆にプロキシルールが正しくても、すでに誤ったアドレスを返した DNS 結果は修復できません。

dns:
  enable: true
  enhanced-mode: fake-ip
  default-nameserver:
    - 1.1.1.1
  nameserver:
    - https://1.1.1.1/dns-query
  nameserver-policy:
    "+.home.arpa":
      - 192.168.1.1
    "+.internal.example":
      - 192.168.1.1

DNS を調べるときは3層に分けて観察します。まずシステムやアプリが問い合わせをどこへ送っているかを確認し、次に Clash のログでドメインとルールのマッチングを確認し、最後に接続がどのプロキシを通ったかを調べます。ブラウザーが独自のセキュア DNS を有効にしていると、システム設定を迂回することがあります。ルールが IP-CIDR だけを記述していて、接続ログにはドメインが残っている場合も、マッチング順序が想定と異なる可能性があります。DNS モード、ルール、ノードを同時に変更せず、1項目ずつ変えると原因を特定しやすくなります。

IPv6 と名前解決結果

dns.ipv6 は DNS モジュールが AAAA レコードを返すかを制御し、トップレベルの ipv6 はコア全体の IPv6 処理に影響します。端末のネットワーク、リゾルバーの IPv6 応答、プロキシノードの対応がそろって初めて、接続が正常に完了します。ローカルの IPv6 経路が不安定だと、アプリが AAAA アドレスを優先してタイムアウトを待ち、プロキシが遅くなったように見えることがあります。ネットワーク条件を確認したうえで有効化を判断し、スイッチを常に固定の答えとして扱わないでください。

4. プロキシノードの項目とプロトコルパラメーター

proxies は静的なノードのリストです。各項目には少なくとも名前、プロトコル種別、サーバーアドレス、ポートが必要で、その他の項目はプロトコルによって異なります。サブスクリプションには通常、完全なノード情報が生成されています。手動管理では名前からプロトコルのパラメーターを推測しないでください。同じサーバーが複数のプロトコル入口を提供していても、認証方式、トランスポート層、TLS 設定は互換とは限りません。コアの検証に通るのは項目の形式が受け入れられたことを示すだけで、リモートサービスへの到達性を保証するものではありません。

name は設定内部で使う参照キーであり、クライアントのプロキシ画面に表示される文字列でもあります。プロキシグループからノードを参照するときは、この名前を使用します。名前が重複すると選択や上書きが難しくなるため、導入時から一意にしてください。server にはドメイン名または IP を指定でき、ドメイン名なら DNS 解決が発生します。port は整数でなければなりません。udp、skip-cert-verify、servername などは、プロトコルやトランスポートが必要とする場合だけ使い、あるノードのパラメーターを別のプロトコルへ丸ごとコピーしないでください。

SOCKS と HTTP の上流プロキシ

SOCKS5 と HTTP のノードは、既存の上流プロキシへ接続する際によく使われます。項目が比較的シンプルなので、ノード構造を理解する出発点に適しています。上流側で認証が必要ならユーザー名とパスワードを入力し、不要なら省略します。UDP 対応は、プロトコル、コア、上流サービスの3者の能力によって決まります。ドキュメントのアドレスは形式の説明用です。

proxies:
  - name: "office-socks"
    type: socks5
    server: 192.0.2.20
    port: 1080
    username: "example-user"
    password: "your-password"
    udp: false

  - name: "upstream-http"
    type: http
    server: 192.0.2.30
    port: 8080
    username: "example-user"
    password: "your-password"
    tls: false

パスワードなどの機密項目を公開リポジトリやスクリーンショットに含めないでください。複数の端末で設定を同期する場合は、管理された非公開の経路を使用し、クライアントのログに認証情報が完全な形で出力されないことを確認します。ノードへ接続できないときは、まずサーバーとポートへのネットワーク到達性を検証し、その後で認証とトランスポートの項目を確認します。最初からプロキシグループやルールを変更すると、ノードの問題とルーティングの問題が混ざってしまいます。

TLS、SNI、証明書検証

TLS を使うプロトコルでは、正しいサーバー名が必要になることがあります。servername などの SNI 項目は、ハンドシェイクでリモート側が使うホスト名を指定します。この値は server と異なる場合があります。IP で接続しても証明書がドメイン名向けに発行されている場合、正しい SNI がないとハンドシェイクに失敗します。skip-cert-verify は証明書検証をスキップするため、あらゆる TLS エラーに使う汎用スイッチではありません。システム時刻、サーバー名、証明書チェーン、中間ネットワークを確認する方が適切です。サブスクリプション提供元が明示している場合に、実際の環境と照らして判断してください。

WebSocket や gRPC などのトランスポート層には、パス、Host ヘッダー、サービス名が含まれることもあります。YAML の階層はプロトコルが求める位置に置く必要があります。たとえば ws-opts の下に path と headers を記述します。階層を間違えると、未知のキーとして無視するパーサーもあり、設定は読み込めてもハンドシェイクのパラメーターが欠落します。その場合は、クライアントにノード名が表示されるかだけで判断せず、コアのログとプロトコル項目の仕様を照合してください。

proxies:
  - name: "example-tls-node"
    type: trojan
    server: edge.example.net
    port: 443
    password: "your-password"
    sni: edge.example.net
    udp: true
    skip-cert-verify: false
    network: ws
    ws-opts:
      path: /gateway
      headers:
        Host: edge.example.net

ノードプロバイダーと静的ノードの違い

静的な proxies はノードをメイン設定へ直接記述するため、1ファイルで確認しやすくなります。一方、proxy-providers はローカルファイルやリモートリソースからノード集合を読み込み、サブスクリプション更新や複数ソースの統合に適しています。プロキシグループから provider を参照するときは use、静的ノードを参照するときは proxies を使います。両方を併用できますが、重複ノード名、更新間隔、キャッシュファイルのパスに注意してください。クライアント標準のサブスクリプション管理は通常これらを処理するため、見た目を簡潔にする目的で provider へ変更する必要はありません。

Windows、macOS、Android、iOS、Linux の GUI クライアントでは、ノードパラメーターは通常サブスクリプションが管理します。Clash Plus をはじめ、Clash Verge Rev、FlClash、Clash Nyanpasu、Clash Meta for Android、ClashX Meta などは、設定の表示方法が異なる場合でも、基盤となる参照関係は似ています。プラットフォームとクライアントの位置付けを比較するなら横断比較を参照し、画面上の名称だけから特定プロトコルの項目が必ず対応すると判断しないでください。

5. プロキシグループの種類と組み合わせ設計

プロキシグループはルールとノードの間に位置します。ルールから特定ノード名を直接指定する代わりに、「手動選択」「自動選択」「アプリ別振り分け」などのプロキシグループへ通信を渡し、グループが実際の送信先を決めます。これによりノード一覧を更新してもルールを書き換える必要がなく、クライアント画面からもすばやく切り替えられます。設計で重要なのは数ではなく、各層の役割を明確にすることです。最上位はユーザーの選択、中間層は自動テストやフェイルオーバー、最下層はノードと DIRECT を担当させます。

select は最も分かりやすいタイプで、ユーザーがノードや子プロキシグループを選びます。速度の速いノードを自動選択する機能はありません。url-test は指定したアドレスへ候補ノードを定期的にテストし、結果が適切なものを選びます。ただしテストは指定先への接続性能を示すだけで、すべての Web サイトでの体感を意味しません。fallback は可用性を重視し、現在の候補が使えないとき次の候補へ切り替えます。load-balance は複数ノードへ通信を振り分けるため、ログインセッション、出口 IP の一貫性、リスク判定に影響することがあります。デフォルトグループとして無造作に有効化するのは避けてください。

2層プロキシグループの一般的な構成

実用的な構成では、最上位の「プロキシ選択」に select を使い、配下に「自動選択」、複数の地域グループ、DIRECT を置きます。「自動選択」では url-test を使って具体的なノードを参照します。ルールはすべて最上位グループへ向け、安定した手動操作が必要なら直接ノードを選び、手間を減らしたいときは自動グループを選びます。2つのプロキシグループを相互参照すると循環するため避けてください。各ルールを別々のノードへ向けると、サブスクリプション更新後の保守コストが急増します。

proxy-groups:
  - name: "プロキシ選択"
    type: select
    proxies:
      - 自動選択
      - 手動ノード
      - DIRECT

  - name: "自動選択"
    type: url-test
    proxies:
      - node-a
      - node-b
    url: "https://www.gstatic.com/generate_204"
    interval: 300
    tolerance: 50

  - name: "手動ノード"
    type: select
    proxies:
      - node-a
      - node-b

interval はテスト間隔を表します。短すぎるとリクエスト数と端末の消費電力が増え、長すぎるとネットワークの変化を反映できません。tolerance は結果が近い場合の頻繁な切り替えを抑えます。テスト先には安定していて応答が小さく、確認したい接続経路を代表する URL を使います。クライアント画面のテスト結果は参考値にすぎず、ノードの混雑、接続先の経路、無線ネットワークの変化も実際のアクセスに影響します。

filter で provider のノードを管理する

ノードが proxy-providers から提供される場合、use で provider 全体を参照し、filter で名前を絞り込めます。通常は正規表現でフィルターするため、地域名の表記が統一されていないときは略称、英語、記号に対応した式が必要です。結果が空になるとプロキシグループに候補がなくなるため、変更後は必ず検証してください。広すぎる式を最初から作るより、実際のノード名を確認してからマッチ条件を段階的に増やす方法が適しています。

proxy-groups:
  - name: "地域選択"
    type: select
    use:
      - primary-subscription
    filter: "(?i)Hong Kong|HK|香港"

  - name: "可用性優先"
    type: fallback
    use:
      - primary-subscription
    url: "https://www.gstatic.com/generate_204"
    interval: 600

プロキシグループ名自体がルールの宛先になるため、改名は構造的な変更です。「プロキシ」を「プロキシ選択」に変えたら、rules、rule-providers の宛先、他のプロキシグループ内の参照も検索して更新してください。クライアントが前回の選択を記憶していることもあります。古いノードが消えたりグループの内容が変わったりすると、実行時の選択が先頭項目へ戻る場合があります。複数の端末へ配布する設定では、先頭を偶然並んだ単一ノードではなく、説明可能で利用できるデフォルトにしてください。

DIRECT と REJECT の配置

DIRECT は直接接続を表し、LAN、信頼できるローカルサービス、明確にローカル回線から接続したい宛先に適しています。REJECT は接続を拒否し、確認済みのドメインやアドレスをブロックするために使えます。どちらもルールの宛先として直接指定でき、select グループに入れて一時的に選択することもできます。総合プロキシグループに DIRECT を入れると柔軟性は高まりますが、本来プロキシを通すルールをユーザーが一時的に直接接続へ変えられることにもなります。残すかどうかは利用目的で判断してください。

6. ルール構文、マッチング順序、カスタムルール

rules は順序を持つリストです。接続が来ると、コアは通常1行目から判定し、最初にマッチした結果を直ちに適用して、後続のルールを確認しません。そのため「ルールの内容は正しいのに効かない」原因は、構文エラーではなく、前にある広すぎるルールが先にマッチしていることが少なくありません。正確なドメイン、特定プロセス、LAN アドレスは前に置き、広いドメインサフィックス、IP 範囲、地域ルールは後ろに置き、最後に MATCH で残りの通信を処理します。

基本的なルールは、ルールタイプ、マッチ対象、宛先ポリシーで構成され、英字カンマで区切ります。たとえば DOMAIN,api.example.com,プロキシ選択 は完全一致のドメインだけにマッチします。DOMAIN-SUFFIX,example.com,プロキシ選択 はルートドメインとサブドメインを対象にできます。DOMAIN-KEYWORD,example,プロキシ選択 はより広く、キーワードを含むあらゆるドメインにマッチする可能性があるため、慎重に使ってください。宛先にはプロキシグループ、ノード、DIRECT、REJECT を指定できます。

ドメイン、IP、プロセスのルール

DOMAIN 系ルールは、コアがドメインを把握しているとき最も明確に動作します。IP-CIDR は IPv4 ネットワーク、IP-CIDR6 は IPv6 ネットワークに使い、ネットワークは CIDR プレフィックスで表します。IP ルールが名前解決を発生させることもあります。既存の宛先 IP だけを使い、追加の名前解決を避けたい場合は、コアの対応方法に従って no-resolve を追加してください。GEOIP は IP の所属地域で判定し、結果は使用するデータベースに依存します。PROCESS-NAME と PROCESS-PATH は OS が提供するプロセス情報に依存し、プラットフォーム、権限、TUN の実装で挙動が変わるため、クロスプラットフォームの唯一のルール方式には向きません。

rules:
  - DOMAIN,api.example.com,プロキシ選択
  - DOMAIN-SUFFIX,example.org,プロキシ選択
  - DOMAIN-KEYWORD,streaming,メディアサービス
  - 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
  - PROCESS-NAME,example-app.exe,プロキシ選択
  - GEOIP,CN,DIRECT
  - MATCH,取りこぼし

上の例は順序と形式を示すだけです。LAN のネットワーク範囲は実際の環境に合わせて調整し、プロセス名はシステムのタスク情報に合わせてください。MATCH は末尾に置き、それまで処理されなかった接続にマッチさせます。MATCH を途中に置くと、後続ルールが実行される機会はありません。設定に MATCH を複数置いても実益はないため、最終出口を明確にする1つだけを残してください。

カスタムルールを追加する方法

サブスクリプション設定を更新すると、元ファイルへ直接追加したルールは通常上書きされます。より安全なのは、クライアントの上書き、拡張スクリプト、ルール前置機能を使い、カスタムルールをサブスクリプションのルールより前に挿入する方法です。前置は、特定の内部ドメインを常に直接接続にするような明確な例外に適しています。後置は、サブスクリプション末尾の MATCH より前に実行できる場合に限って使えます。サブスクリプションがすでに MATCH で終わっているなら、新しいルールをファイル末尾へ単純に追加しても効果はありません。

カスタムルールを設計する前に、3つの点を決めます。対象はドメインか IP か、宛先は既存のプロキシグループか新しいグループか、既存ルールのどこまでを対象にするかです。1台のホストだけなら DOMAIN、サイト全体のサブドメインなら DOMAIN-SUFFIX を優先し、名前の構造が安定しない場合だけ DOMAIN-KEYWORD を検討します。広すぎるキーワードは無関係なドメインまで巻き込む可能性があり、特に短い語、ブランド略称、一般的な単語では注意が必要です。

rules:
  - DOMAIN,printer.home.arpa,DIRECT
  - DOMAIN-SUFFIX,internal.example,DIRECT
  - DOMAIN-SUFFIX,docs.example.net,プロキシ選択
  - RULE-SET,private-network,DIRECT
  - RULE-SET,service-list,プロキシ選択
  - MATCH,プロキシ選択

ルールマッチングログの読み方

ログには通常、対象ドメインまたは IP、マッチしたルールタイプ、選択されたプロキシグループ、最終ノードが表示されます。調査では再現可能なアクセスを1回行い、時刻から該当する接続を探します。ルールの宛先は正しいのに最終ノードが違う場合は、プロキシグループの現在の選択を確認してください。MATCH にマッチした場合は、想定したルールが読み込まれているか、ドメインが一致しているか、ルールプロバイダーの更新が成功しているかを前方へさかのぼって確認します。IP ルールなのにドメイン情報がない場合は、DNS とスニッフィングの経路を確認します。

ブラウザーでページを1回開くと、メインサイト、画像、スクリプト、外部 API など複数の接続が発生します。最初の1行だけを見てページ全体のルーティングを判断しないでください。明確なドメインを1つ選んでテストするか、開発者ツールで失敗したリクエストのホスト名を確認します。アプリが DNS をキャッシュしたり既存の接続を維持したりすることもあるため、ルールを変更したら新しい接続を作り、必要ならアプリを再起動してください。既存のセッションがすべて直ちにポリシーを切り替えるとは限りません。

ルールの保守性

ルールは LAN、個人の例外、用途別の振り分け、公開ルールセット、最終マッチなど、目的ごとに分けて短いコメントを付けます。「なぜ存在するか」を説明するコメントは、項目の意味を繰り返すより価値があります。長期間使っていない例外は削除し、必要性を判断できなくなるのを防いでください。ルールの宛先には、頻繁に変わるノード名ではなく、安定したプロキシグループ名をできるだけ使います。これによりサブスクリプションでノードが追加・削除されても、ルーティング層を変更せずに済みます。

7. ルールプロバイダー、ノードプロバイダー、外部リソース

ルールが増えると、すべてを rules に詰め込むことでメイン設定の保守が難しくなります。rule-providers を使えば、ローカルファイルやリモート URL からルール集合を読み込み、メインルールでは RULE-SET で参照できます。これはルール内容の整理と更新を解決する仕組みであり、宛先ポリシーを自動決定するものではありません。同じルールセットを異なるプロキシグループへ向けることもできます。同様に、proxy-providers はノードの供給元を管理し、プロキシグループから use で参照します。

ルールプロバイダーでよく使う behavior には domain、ipcidr、classical があります。domain はドメインだけのルール、ipcidr はアドレス範囲、classical はより完全なルール表現に適しています。behavior はファイルの内容と一致させてください。DOMAIN-SUFFIX 形式のクラシカルルールを純粋な domain データとして読み込むと、解析に失敗したりマッチしなかったりします。format は yaml、text、mrs などファイル形式を示します。対応範囲は使用するコアの仕様に従ってください。

リモートルールセットの完全な定義

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

  service-list:
    type: http
    behavior: classical
    format: yaml
    path: ./ruleset/service-list.yaml
    url: "https://rules.example.net/service-list.yaml"
    interval: 86400

rules:
  - RULE-SET,private-network,DIRECT
  - RULE-SET,service-list,プロキシ選択
  - MATCH,プロキシ選択

type: http はリモートから取得することを示し、path はローカルキャッシュの保存先、interval は更新間隔です。初回読み込みにはネットワークアクセスが必要です。リモート更新に失敗した場合、コアは通常、既存のキャッシュを使い続けようとしますが、初回ダウンロードに失敗してキャッシュもなければルール内容を取得できません。保存先ディレクトリには書き込み権限が必要です。デスクトップクライアントでは相対パスが、ターミナルを開いた現在位置ではなく、クライアントの設定作業ディレクトリとして解釈されることもあります。

リモート URL は、信頼でき継続的に保守されている提供元から取得してください。ルールの更新は通信経路を変え、単一ノードより広い範囲に影響する可能性があります。第三者のルールセットを使う前に、分類ロジック、更新頻度、デフォルトの宛先を確認し、名前だけで内容を判断しないでください。社内ドメインや個人用の例外には、公開リストへの収録を待つより、少数のローカル前置ルールを残す方が適しています。

ルールセットファイルの内容形式

YAML payload 形式では通常、トップレベルキーに payload を置き、その下にルール項目を記述します。classical の項目には DOMAIN、DOMAIN-SUFFIX、IP-CIDR などのプレフィックスを含められます。domain は通常ドメインパターンだけを保存し、ipcidr はネットワーク範囲を保存します。形式を任意に混在させることはできず、拡張子で format の指定を代用することもできません。

payload:
  - DOMAIN,api.example.com
  - DOMAIN-SUFFIX,example.org
  - IP-CIDR,203.0.113.0/24,no-resolve

メイン設定で RULE-SET を使う場合、宛先ポリシーは参照側に書くため、ルールセット内部には通常「プロキシ選択」のような宛先を記述しません。これにより同じリストを異なる設定で再利用できます。ダウンロードしたファイル自体が完全な3要素ルールを含む場合は、provider の behavior とコアの解析方式が一致しているか確認してください。「ルール項目のパラメーター数が正しくない」と表示されたら、メインルールのプロキシグループではなく、内容形式を重点的に確認します。

ノードプロバイダー、ヘルスチェック、キャッシュ

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

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

provider が返す内容は、完全な Clash 設定ではなく、ノードプロバイダーが要求する構造に適合している必要があります。完全な設定ファイルの URL をそのままノード provider として使うと、トップレベル構造が異なるため失敗することがあります。GUI クライアントの「サブスクリプション」は通常、完全な設定のサブスクリプションであり、proxy-providers と単純に同一視できません。クライアントが完全な設定を更新しているなら、その流れを優先し、さらに provider を入れ子にしないでください。

ヘルスチェックは provider 内のノードへテストを行い、自動グループが可用性を判断しやすくしますが、頻度が高すぎるとリソース消費が増えます。モバイル端末ではバッテリーとバックグラウンド制限も考慮してください。テスト失敗は、すべての宛先でノードが使えないことを意味しません。テスト先がブロックされている、または現在のネットワークから到達できない可能性もあります。実際の接続ログと合わせて判断し、1つのテスト結果だけでノードを削除しないでください。

更新失敗を層別に調べる

外部リソースの失敗は、ダウンロード、書き込み、解析、参照の4層に分けられます。ダウンロード層では URL、DNS、現在の送信経路を確認し、書き込み層ではキャッシュディレクトリの権限を確認します。解析層では format、behavior、ファイル内容を照合し、参照層では RULE-SET や use の名前がトップレベルの定義と一致するか確認します。リモートルールの更新も現在のプロキシを経由することがあり、振り分けを誤ると「ルールをダウンロードするために、そのルールが必要」という依存関係が生まれます。リソース用ドメインに明確な経路を設定するか、初回起動時に基礎的な接続を確保してください。

8. 上書き、マージ、検証、トラブル対応

サブスクリプション設定は定期的に更新したい一方、個人設定は長期的に保持したい。この相反を解決するのが上書きとマージです。サブスクリプションから生成された YAML を直接編集するのが最も分かりやすいものの、更新時に置き換えられます。カスタム内容を独立した上書き層に置けば、「上流のノードと公開ルール」と「ローカルポート、DNS、個人ルール」を分けて管理できます。上書きの呼び方や機能はクライアントによって異なり、項目の上書き、ルール前置、ルール後置、スクリプト処理、YAML マージなどが提供される場合があります。使う前に、項目全体を置き換えるのか、マッピングを再帰的にマージするのかを確認してください。

マッピングはキー単位の再帰マージに向いていますが、リストは最も曖昧になりやすい部分です。dns のようなマッピングでは、子キーを上書きしても他の子キーが残ることがあります。一方、rules、proxies、proxy-groups のようなリストは、ツールによって全体置換、前置、追加など挙動が異なります。リストが自動連結されると思い込むと、サブスクリプションの元ルールがすべて消える可能性があります。逆に置換されると思い込むと、同名のプロキシグループが2つ残ることもあります。クライアントの仕様を理解しないまま、大量のリストを一度に上書きしないでください。

安全な上書き範囲

共通ポート、ログレベル、LAN 許可、少数の DNS 子項目は、通常フィールド上書きに適しています。個人用ドメインの例外にはルール前置が向いています。新しいプロキシグループを追加する場合は、グループ定義、参照するノード供給元、ルールの宛先を同時に処理し、1つの変更として検証してください。ノードの認証パラメーターは、所有する静的ノードを管理している場合を除き、通常サブスクリプションに任せます。上書きファイルはメイン設定より短くし、上流と異なる部分だけを表現してください。

# ローカル上書きの例。具体的なマージ構文はクライアントに従う
mixed-port: 7890
log-level: info
allow-lan: false

dns:
  enable: true
  ipv6: false

prepend-rules:
  - DOMAIN,printer.home.arpa,DIRECT
  - DOMAIN-SUFFIX,internal.example,DIRECT

prepend-rules は標準のメイン設定トップレベル項目ではなく、一部の上書きツールが使う表現です。すべてのクライアントへそのままコピーできるわけではありません。実際には、クライアントが明示的に提供する「ルール前置」の入口を使います。この例の要点は、メイン設定の項目と上書き指示を区別することです。前者はコアが読み取り、後者はクライアントや変換ツールが先に処理します。コアへ渡されるのは、処理後の最終 YAML です。

マージ後の確認リスト

変更するたびに、上書き断片だけでなく最終生成設定を確認してください。トップレベルに重複キーがなく、待ち受けポートが競合せず、DNS の階層が完全で、ノード名とプロキシグループ名が一意であり、すべての参照先が存在し、プロキシグループに循環がなく、ルール末尾の MATCH が1つだけであることを確認します。providers を使う場合は、キャッシュパス、behavior、参照名も確認してください。設定検証に通ってから起動またはホットリロードします。

コアで設定を検証する

mihomo を直接実行する場合は、コアが提供する設定テスト用パラメーターで、サービス起動前にファイルを確認できます。インストール方法によって実行ファイル名と設定ディレクトリは異なるため、例のパスを実環境に合わせて置き換えてください。GUI クライアントも通常、設定のインポートや切り替え時に検証を実行し、ログ画面にエラー行を表示します。クライアントの通知が途中で切れる場合は、ログ画面で詳細な原因を確認してください。

# 現在のディレクトリで config.yaml を確認
mihomo -t -f ./config.yaml

# 設定作業ディレクトリを指定して確認
mihomo -t -d ./clash-profile -f ./clash-profile/config.yaml

検証に成功しても、設定の構造と既知の項目が要件を満たしたことしか分かりません。リモートノード、ルールセット、DNS サービスが利用できるとは限りません。起動後は provider の更新、ポートの待ち受け、接続ログも確認してください。検証で特定の行にエラーが出ても、実際の原因は引用符の閉じ忘れや親階層のインデント不正など、直前の行にある場合があります。エラー行の前後数行を確認してから、範囲を少しずつ絞り込んでください。

典型的な障害への対応順序

「クライアントが開かない」ときは、まず権限、ポート競合、設定構文、コアファイルを確認し、起動クラッシュと強制終了への対処手順を参照してください。「クライアントは起動するがすべての接続に失敗する」ときは、システムプロキシまたは TUN が実際に有効か、ポートが一致しているか、ノードが利用できるかを確認します。「一部サイトの経路がおかしい」ときは、DNS、ルール順序、プロキシグループの現在の選択を重点的に確認します。「サブスクリプション更新後にカスタム内容が消えた」なら、上流ファイルを変更していたということなので、上書き層へ移行してください。

ポートが競合したとき、システムプロキシの同期を忘れたままランダムなポートを次々試さないでください。まず使用中のプロセスを特定して重複したコアを終了するか、明確な新しいポートを1つ選び、すべての入口設定を同期します。ルールにマッチしない場合も、すぐに広い DOMAIN-KEYWORD を追加せず、まずログから実際のドメインを確認してください。DNS に問題があるときは、nameserver の変更、fake-ip の無効化、ルールの書き換えを同時に行わず、一度に1つだけ変数を変更し、元に戻せる設定コピーを残します。

「ホットリロードは成功したのに動作が変わらない」原因として、既存接続、アプリのキャッシュ、クライアントの実行時選択、上書き処理が再実行されていないことが考えられます。新しい接続を作り、最終設定ファイルの更新時刻と内容を確認して、コアが実際に対象ファイルを読み取っていることを確かめてください。複数設定に対応するクライアントには、現在の設定、サブスクリプションキャッシュ、実行時生成設定の3層があることが多く、間違ったファイルを編集するのはよくある原因です。クライアントの設定画面で現在有効な項目を確認し、ログで読み込みパスを調べる方が、ディスク上のファイルを1つずつ推測するより確実です。

元に戻せる保守フローを作る

安定した保守フローには、既知の正常な設定を保存する、1つの対象だけを小さく変更する、検証してから読み込む、ログで実際の動作を確認する、という4段階を含めます。変更に失敗したら、誤った設定へパッチを重ねるのではなく、直前の正常な設定へ戻してください。個人ルール、DNS の例外、プロキシグループの構造は個別に説明を管理し、変更理由と依存関係を記録すると、後で整理しやすくなります。

サブスクリプション更新の前後では、すべてのノードを1行ずつ比較する必要はなく、トップレベルの項目、プロキシグループ名、ルール末尾の構造を比較すれば十分です。上流でノードが追加されても個人ルールには通常影響しませんが、プロキシグループ名、provider 名、ルールの宛先が変わると上書きに影響します。不要になった例外や provider を定期的に削除すると、今後の更新時の競合を減らせます。設定の目的は項目数を増やすことではなく、各項目の役割が明確で、すべての参照を追跡でき、問題発生時にすばやく元へ戻せることです。