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

1. YAML構造の概要

Clashの設定ファイルは通常、config.yamlをエントリーポイントとします。これは独立したスイッチの羅列ではなく、階層を持つマッピング構造です。トップレベルの項目がリッスンポート、動作モード、ネットワーク機能を決め、proxiesが利用可能なプロキシを定義します。proxy-groupsはプロキシを手動選択、自動テスト、フェイルオーバーに対応するグループへ整理し、rulesがリクエストごとに利用するグループを指定します。この参照関係を理解することは、個々の項目を暗記するより重要です。存在しないプロキシグループをルールが参照したり、未定義のノードをグループが参照したりすると、設定の読み込みに失敗したり、想定外の動作になったりします。

インデント・シーケンス・マッピング

YAMLではスペースで階層を表します。インデントは2スペースに統一し、タブを混在させないことをおすすめします。コロンの左側がキー、右側が値で、ハイフンから始まる行がシーケンス項目です。dnsの下にあるインデントされた項目はDNSマッピングに属し、rulesの下の各ハイフン行は1つのルールです。文字列は通常、引用符なしで記述できますが、コロン、シャープ、カンマを含む場合や真偽値として解釈されやすい内容には、引用符を付けると安全です。シャープで始まるコメントは閲覧用で、実行には影響しません。

# トップレベルのマッピング
mixed-port: 7890
mode: rule
log-level: info

# ネストしたマッピング
dns:
  enable: true
  listen: 0.0.0.0:1053

# オブジェクトのシーケンス
proxies:
  - name: "サンプルノード"
    type: socks5
    server: 127.0.0.1
    port: 1080

# 文字列のシーケンス
rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - MATCH,ノード選択

上記は構文上の関係を示す例であり、ローカルの SOCKS ノードを必ず使うという意味ではありません。実際のサブスクリプションでは通常、proxiesまたはproxy-providersが完全な形で提供されます。手動編集では、プロキシグループが名前でノードを参照するため、ノード名の綴りを正確に保ってください。名前の途中にあるスペースは有効ですが、前後のスペースは見落としやすい差異になります。そのため、ノード名とプロキシグループ名にはダブルクォートを付け、末尾にスペースを残さないことをおすすめします。

最小構成と読み込み順序

ルールモードで動作する完全な設定には、少なくともリッスン用の入口、利用可能な出口、プロキシグループ、フォールバックルールが必要です。パーサーはまずYAMLを読み込み、次に項目の型と参照関係を検証し、最後にリッスンポート、DNSモジュール、プロキシグループを作成します。YAMLとして解析できても、動作ロジックが正しいとは限りません。たとえばmode: ruleを有効にしていても、ルール末尾にMATCHがなければ、どのルールにも一致しない通信の行き先が不明確になります。また、ノードだけを定義してプロキシグループに入れていない場合、ルールから共通のポリシー名で切り替えることもできません。

mixed-port: 7890
mode: rule
allow-lan: false

proxies:
  - name: "ローカルテスト"
    type: socks5
    server: 127.0.0.1
    port: 1080

proxy-groups:
  - name: "ノード選択"
    type: select
    proxies:
      - "ローカルテスト"
      - DIRECT

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

構造を確認するときは、「ルールの宛先 → プロキシグループ → ノードまたは別のプロキシグループ」の順にたどります。各名称が存在し、意味のない循環参照を形成していないことが必要です。エディターがYAML構文チェックに対応していれば、インデントや重複キーを早期に発見できます。クライアントのログは、未対応項目、ポート競合、プロバイダーのダウンロード失敗など、実行時の問題を見つけるのに適しています。具体的なエラーはトラブルシューティングの設定読み込みに関する分類も参照してください。

2. ポート・モード・共通項目

共通項目は、クライアントがシステムの通信をどのように受け取るか、またプロキシプロトコルの詳細に入る前の基本動作を決めます。GUIクライアントではこれらの値を画面から管理することが多いため、手動で変更する前に上書き機能が使われているか確認してください。そうしないと、ファイル内の設定が起動時に画面上の設定で上書きされる場合があります。最も一般的な入口はmixed-portです。1つのポートでHTTPとSOCKS5のリクエストを受け付けるため、ブラウザー、コマンドラインツール、システムプロキシをまとめて設定できます。

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

ruleモードはrulesを上から順に照合するため、常用に適しています。globalモードは通信を一括してグローバルプロキシグループへ渡し、特定の出口を一時的にテストするときによく使います。directモードは通信を直接接続し、問題がプロキシ経路に起因するか確認するのに利用できます。モードは全体設定のスイッチにすぎず、既存のルールを削除するものではありません。ルールモードに戻せば、ルールは元の順序で引き続き適用されます。3つのモードの使い分けはルール・グローバル・直接接続の3モードの選び方も参照してください。

LANリッスンとコントロールAPI

allow-lanを有効にしても、他のデバイスが接続できるかどうかは、リッスンアドレス、ファイアウォール、接続中のネットワークにも左右されます。項目をtrueにするだけでは接続を保証できません。本体だけで使う場合は無効のままにしてください。同じ信頼できるLAN内のデバイスにプロキシを提供する場合は、リッスンアドレスを明示的に設定し、OSのファイアウォールを確認します。external-controllerはGUIや外部パネルからコアを管理するためのもので、プロキシポートとは用途が異なります。コントロールポートをシステムプロキシに設定しないでください。

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"

log-levelの代表的な値にはsilent、error、warning、info、debugがあります。通常はinfoで十分です。接続確立、DNSクエリ、ルール一致の問題を調べるときだけ一時的にdebugへ切り替え、完了後に戻すとログの急増を防げます。ipv6を有効にするかは、利用中のネットワーク、DNSの応答、プロキシノードの対応状況を基に判断してください。IPv6経路が安定していないのにDNSがIPv6アドレスを返すと、アプリが到達不能なアドレスを先に試し、初回接続が遅くなることがあります。

GUIクライアントの「システムプロキシ」は通常、OSのプロキシアドレスをClashのリッスンポートへ向けるだけです。一方、「TUNモード」は仮想ネットワークデバイスを通じて、より広い範囲の通信を引き受けます。両者は同じ項目ではありません。ブラウザーやシステムプロキシに対応したソフトだけを使うなら、通常はシステムプロキシで十分です。ゲーム、コマンドラインプログラム、システムプロキシを参照しないアプリを分流に含める場合は、TUNを検討してください。TUNの設定には権限、ルーティング、DNSリダイレクトも関わるため、1つのスイッチだけで成功とは判断できません。

3. DNS設定と名前解決の流れ

DNS設定は、ドメインを最初にどこで解決するか、どの形式のアドレスを返すか、ルールエンジンが適切な段階でドメイン情報を取得できるかを決めます。「Webページが時々開けない」「ルールは正しそうなのに誤ったポリシーへ進む」といった問題は、プロキシノードの障害ではなく、DNSリクエストがクライアントを迂回していたり、解決結果がキャッシュで汚染されていたり、fake-ipが特定のLAN機器と互換性を持たなかったりすることが原因かもしれません。調査では、アプリがクエリを発行する段階、Clashがクエリを受け取る段階、上流リゾルバーが結果を返す段階、接続を確立する段階を分けて確認してください。

基本項目と上流サーバー

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:
    - 223.5.5.5
    - 119.29.29.29
  nameserver:
    - https://dns.alidns.com/dns-query
    - https://doh.pub/dns-query
  fallback:
    - https://1.1.1.1/dns-query
    - https://dns.google/dns-query

default-nameserverは主にDoHやDoTなど、上流サーバー自身のドメイン名を解決するために使われます。そのため、通常は直接アクセスできるIPアドレスを指定し、「DNSサーバーのドメイン名を解決するために、そのDNSサーバーへ先に接続する」という循環を避けます。nameserverは主な名前解決元で、通常のUDPアドレスにも、対応する暗号化DNSアドレスにもできます。fallbackを使うか、結果をどのように絞り込むかは、コアの機能と後続のフィルター項目によって異なります。上流サーバーを大量に並べるだけでは、どのサーバーの回答か判断しにくくなり、結果の不一致も増えるため避けてください。

fake-ipとredir-host

fake-ipモードでは、実際のアドレスをすぐにアプリへ渡さず、予約済みアドレス範囲からマッピング用アドレスを割り当てます。アプリがそのアドレスへ接続すると、コアが元のドメイン名を復元し、ルール照合と実アドレスの解決を行います。より多くのドメイン情報を保持でき、ルールの一致も安定しやすい方式です。一方、実際のLANアドレス、LAN探索、特殊なDNS動作に依存するソフトウェアでは、フィルターリストへの追加が必要になる場合があります。redir-hostは従来の名前解決に近く、互換性を考えやすい反面、接続段階によってはIP情報しか残らないことがあります。

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "time.*.com"
    - "time.*.gov"
    - "+.stun.*.*"
    - "localhost.ptlogin2.qq.com"

フィルター項目は多ければよいわけではありません。実アドレスが必要だと確認できたドメインだけを追加し、理由を記録してください。LANプリンター、画面ミラーリング、ルーター管理用ドメインに異常がある場合は、まずログでクエリされたドメインを確認し、正確なサフィックスを追加して検証します。長大なフィルターリストを一度にコピーすると、本当の互換性のポイントが見えにくくなり、本来はドメインルールで処理できるリクエストまで別の名前解決経路へ進む可能性があります。

ドメイン別にリゾルバーを指定

nameserver-policyに対応するコアでは、ドメインの集合に応じて上流サーバーを選択できます。LANドメインをルーターへ、特定地域のドメインを対応するリゾルバーへ渡したり、ルールセットとDNSポリシーを一致させたりする用途に適しています。キーの記法とコアの対応状況はバージョンによって異なるため、設定を移行するときは少数のドメインで先にテストし、古い構文がすべてそのまま動くと決めつけないでください。

dns:
  enable: true
  enhanced-mode: fake-ip
  nameserver:
    - https://dns.alidns.com/dns-query
  nameserver-policy:
    "geosite:cn":
      - https://dns.alidns.com/dns-query
    "+.internal.example":
      - 192.168.1.1

DNSが有効かどうかを、最終的にWebページが開くかだけで判断してはいけません。クライアントログで、そのドメインのクエリが出ているか、どのDNSポリシーに一致したか、接続時にドメインとIPのどちらが使われたか、OSが別のネットワークアダプターのDNSへ直接リクエストしていないかを確認します。TUNを有効にしている場合は、DNSリダイレクトの設定とシステム権限も確認してください。変更後はOSとブラウザーのキャッシュを消去し、新しいドメインまたはプライベートウィンドウでテストして、古い回答の影響を避けます。

4. プロキシノードの項目

proxiesは静的なノード一覧です。各シーケンス項目には、少なくとも名前、プロトコル種別、サーバーアドレス、ポート、そしてそのプロトコルに必要な認証項目が含まれます。サブスクリプション生成ツールは通常この部分を作成済みなので、手動管理はローカルテスト、固定出口、項目の理解に向いています。ノードごとにプロトコルが異なれば、必要な項目も異なります。typeを置き換えるだけで、あるプロトコルのノードを別のプロトコルへ変更することはできません。サービス提供元の認証情報、トランスポート設定、TLSパラメーターは一体として確認してください。

共通項目と名前による参照

ノード名は表示用であるだけでなく、設定内部の主キーでもあります。同名のノードが2つあると、クライアントが読み込みを拒否したり、プロキシグループの参照結果が判断しにくくなったりします。名前には地域、回線の用途、プロトコルのヒントを含められますが、頻繁に変わる情報は入れないでください。サブスクリプション更新のたびに固定参照が無効になる可能性があります。より安定した方法は、プロバイダーをフィルターで絞り込み、プロキシグループへ動的に追加することです。

SOCKS5とHTTPの例

proxies:
  - name: "ローカル SOCKS"
    type: socks5
    server: 127.0.0.1
    port: 1080
    username: "user"
    password: "your-password"
    udp: true

  - name: "オフィス HTTP プロキシ"
    type: http
    server: proxy.example.com
    port: 8080
    username: "user"
    password: "your-password"
    tls: false

認証項目はサーバー側の実際の要件に合わせて設定します。ユーザー名とパスワードが不要なサービスでは、空の項目を残す必要はありません。tlsはHTTPプロキシサーバーへの接続でTLSを使うかどうかを示し、プロキシ経由でアクセスする対象サイトがHTTPSかどうかとは別の話です。サーバーアドレスにドメイン名を使う場合、起動時にはDNSも必要になります。そのため、すべてのプロキシグループで同じドメイン名ノードが利用できない場合は、ノードのサーバー名の解決経路を確認し、ノードを1つずつ変更しないでください。

TLS・SNI・トランスポートパラメーター

TLSを使用するプロトコルでは、サーバー名の検証も関係します。設定のservernameまたは同種の項目は、ハンドシェイクで使用するサーバー名を指定するもので、サーバー証明書とデプロイ設定に一致している必要があります。証明書検証をスキップするとセキュリティ境界が変わるため、接続失敗に対する恒久的な対策として使わないでください。正しい確認順序は、システム時刻、ドメイン解決、サーバー名、証明書チェーン、トランスポートパラメーターを確認し、そのうえでテスト環境固有の証明書かどうかを判断することです。

WebSocketやgRPCなどのトランスポート方式には、パス、Host、サービス名が付くこともあります。これらはサーバー側のルーティング情報の一部であり、1文字抜けただけでもポートには接続できるのにハンドシェイクに失敗することがあります。サブスクリプションをインポートした後、一部のノードだけが使えない場合は、元のノード情報とトランスポート項目を照合してください。すべてのノードが同時に使えなくなった場合は、ローカルネットワーク、システム時刻、DNS、サブスクリプションの有効期限、コアのログを優先して確認します。

クライアントの選択も利用できる項目に影響します。Clash Plus、Clash Verge Rev、FlClash、Clash NyanpasuなどのGUIクライアントは、異なるコアや上書き画面を使う場合があります。開発が停止しているClash for WindowsやClashX Metaは、新しい項目への対応範囲が限られる可能性もあります。mihomo環境の設定を使う場合、古いクライアントがすべての項目を認識できるとは考えないでください。クライアントを変更する場合はダウンロードページで対応プラットフォームを確認できます。

5. プロキシグループと選択ロジック

プロキシグループは、ルールと具体的なノードの間にある中間層です。ルールは、特定ノードではなく「ノード選択」「ストリーミング」「ダウンロード直接接続」のように用途が安定したプロキシグループを参照するのが理想です。そうすれば、ノードの更新、サブスクリプション名の変更、一時的な出口の切り替えがあっても、ルール全体を書き直す必要がありません。プロキシグループにはノードのほか、別のプロキシグループや組み込みのDIRECT、REJECTを含められます。設計時は循環参照を避け、最下層が実際のノードまたは組み込みの宛先へ到達できるようにしてください。

select：手動選択

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

selectは自動テストや自動切り替えを行わず、ユーザーが現在選択している対象を保持します。ルールの共通入口や、地域を手動で指定したい場面に適しています。自動テストグループを手動選択グループに入れれば、自動制御と手動制御を両立できます。ただし、GUIクライアントが保存する選択状態はYAMLとは別に管理される場合があります。再インポート、設定の整理、プロキシグループ名の変更後に、選択状態が先頭へ戻ることもあります。そのため先頭には、トラブルシューティング専用ではなく、妥当なデフォルトポリシーを置いてください。

url-test：テスト結果で選択

  - name: "自動選択"
    type: url-test
    proxies:
      - "ローカル SOCKS"
      - "予備ノード"
    url: "https://www.gstatic.com/generate_204"
    interval: 300
    tolerance: 50
    lazy: true

url-testは指定したアドレスへ定期的にテストを行い、結果に基づいて利用可能なノードを選びます。テスト結果が示すのはノードからテスト先までの接続状況であり、すべてのWebサイトでの実速度と同じではありません。intervalが短すぎると不要なリクエストが増え、長すぎると回線の変化をすぐに反映できません。toleranceを設定すると、数値の小さな変動による頻繁な切り替えを抑えられます。lazyを有効にすると、未使用のプロキシグループで能動的なテストを減らせます。テスト先は安定していて応答本文が小さく、主な利用場面とある程度関連するものを選んでください。

fallbackとload-balance

  - name: "フェイルオーバー"
    type: fallback
    proxies:
      - "プライマリノード"
      - "予備ノード"
    url: "https://www.gstatic.com/generate_204"
    interval: 300

  - name: "接続分散"
    type: load-balance
    strategy: consistent-hashing
    proxies:
      - "ノード A"
      - "ノード B"
    url: "https://www.gstatic.com/generate_204"
    interval: 300

fallbackはリストの優先順位に従い、利用可能な最初のノードを使います。明確なプライマリ・バックアップ構成に適しており、数値が最も低いノードを単純に選ぶものではありません。load-balanceは複数のノードへ異なる接続を分散します。複数の出口を許容できる処理に向いていますが、アカウントログイン、セッション固定、送信元アドレスに敏感なサイトでは、出口が頻繁に変わる構成は適さない場合があります。consistent-hashingは同じ宛先を比較的安定したノードへ割り当てる傾向がありますが、1つの接続に帯域を合算する機能ではありません。

プロキシグループの階層設計

保守しやすい構成は通常、3層に分けます。下層は静的ノードやプロバイダーから出口を提供し、中層は地域、用途、テスト方式で整理し、上層はルールから安定して参照できる入口を提供します。たとえば「香港ノード」がサブスクリプションから名前で絞り込み、「自動選択」が複数の地域グループを参照し、「ノード選択」が自動選択と手動地域グループを同時に含む構成です。業務用ルールは「ノード選択」や「ストリーミング」などの上層グループだけを参照します。サブスクリプションが変わっても、フィルターと中層構造だけを保守すれば済みます。

proxy-groups:
  - name: "香港ノード"
    type: select
    use:
      - provider-main
    filter: "(?i)香港|港|HK"

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

正規表現によるフィルターは、広い条件から狭い条件へ段階的に検証してください。ノード名はサブスクリプション提供元が決めるため、絵文字、固定スペース、複雑な接頭辞・接尾辞に依存しすぎると安定性が下がります。プロキシグループが空になった場合は、まずプロバイダーの更新に成功しているか確認し、その後でフィルター式を見直します。フィルターを削除して全ノードを長期的に使うのは避けてください。テスト用、期限切れ通知、特殊用途の項目まで本番ポリシーに混ざる可能性があります。

6. ルール構文・順序・フォールバック

rulesは上から順に照合し、通常は最初に一致したルールで処理を停止します。そのため、ルールは種類やパラメーターを正しく書くだけでなく、正しい位置に配置する必要があります。完全一致のドメインは広いサフィックスより前に、特定の直接接続や拒否項目は対象範囲の広い集合より前に置き、最後はMATCHでフォールバックします。ルールの宛先は、存在するプロキシグループ、ノード、または組み込みの宛先でなければなりません。

ドメインルールの適用範囲の違い

DOMAINは指定した完全一致ドメインだけに適用され、APIドメインや例外処理が必要な単一ホストに適しています。DOMAIN-SUFFIXはルートドメインとサブドメインを対象にするため、Webサイトの分流でよく使われます。DOMAIN-KEYWORDは範囲がさらに広く、短いキーワードでは無関係なドメインまで巻き込む可能性があるため、配置に注意が必要です。api.example.comを直接接続し、それ以外のexample.comをプロキシ経由にする場合は、完全一致ルールをサフィックスルールより前に書きます。

rules:
  - DOMAIN,api.example.com,DIRECT
  - DOMAIN-SUFFIX,example.com,ノード選択
  - DOMAIN-KEYWORD,stream,ストリーミング
  - IP-CIDR,127.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,ノード選択

IPルールとno-resolve

IPルールは接続先アドレスを照合します。コアによっては、IP系ルールを処理する際に、ドメインに最終的に対応するアドレスを確認するため名前解決を行う場合があります。no-resolveを追加すると、そのルールによるドメインの能動的な名前解決を抑止できます。既存のIPだけを処理すればよいローカルネットワークなどに適しています。すべてのルールを高速化する汎用パラメーターではなく、対応していないルール種別の後ろにも追加できません。使用前に、現在のコアがルールをどのように解決するかを確認してください。

GEOIPはローカルの地理データベースに依存し、ドメイン自体の属性ではなく、対象IPを照合します。データベースの有無、更新状況、DNSが返すアドレスの違いが結果に影響します。より細かなドメイン分類が必要なら、GEOIPだけに頼らず、ルールセットやgeosite系の機能を組み合わせてください。中国本土と海外の分流設定や検証手順は、Clashで中国本土・海外向け分流ルールを設定する実践ガイドを参照してください。

PROCESSとポートルール

デスクトップ環境の一部のコアは、プロセス名、プロセスパス、対象ポートで照合できます。プロセスルールはOSの権限と、コアがプロセス情報を取得できるかどうかに依存するため、プラットフォームをまたぐ設定で同じ動作になるとは限りません。ポートルールが示すのはポートであり、アプリの識別情報ではありません。同じポートを複数のプロトコルが使うこともあります。作成時は「特定のアプリを指定ポリシーへ送る」のか、「特定ポートへ接続するすべての通信を指定ポリシーへ送る」のかを確認し、混同しないでください。

rules:
  - PROCESS-NAME,curl,DIRECT
  - DST-PORT,22,ノード選択
  - DOMAIN-SUFFIX,example.net,ノード選択
  - MATCH,ノード選択

ルールはできるだけ「例外、LAN、用途別、地域別、最終フォールバック」に分け、各ブロックの先頭に短いコメントを書きます。少数のルールを変更するたびに再読み込みと検証を行うほうが、数千行を一度に追加してから原因を探すより確実です。拒否ルールにも明確な用途が必要です。REJECTは一致した接続を直ちに終了するため、広すぎるサフィックスを誤って指定すると、ログイン、静的リソース、APIまで同時に使えなくなる可能性があります。

7. プロバイダーとルールセット

プロバイダーproxy-providersは外部ファイルやサブスクリプションURLからノードを読み込み、ルールプロバイダーrule-providersは再利用可能なルールを読み込みます。どちらも「頻繁に変わる大量の内容をメイン設定へ詰め込まない」という課題を解決しますが、データ形式と参照場所は異なります。プロバイダーはプロキシグループからuseで読み込み、ルールプロバイダーはRULE-SETルールから参照します。ノードのサブスクリプションをルールプロバイダーへ指定したり、ルールファイルをプロバイダーへ指定したりすると、解析に失敗します。

プロバイダーの設定

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

proxy-groups:
  - name: "サブスクリプションノード"
    type: select
    use:
      - provider-main
    filter: "(?i)香港|シンガポール|日本|HK|SG|JP"

type: httpはリモートURLから更新することを示し、pathはダウンロード後のローカルキャッシュ先、intervalは更新間隔です。更新に成功しても、すべてのノードが利用できるとは限らないため、ヘルスチェックを別途設定できます。ヘルスチェックのURLと間隔は適切な範囲に抑えてください。サブスクリプションのノード数が多い場合、頻繁すぎるチェックは大量の接続を同時に作成します。サブスクリプションが特殊なリクエストヘッダーを必要とする場合、一部のコアでは対応項目を設定できますが、サービスの要件に従って入力し、機密性の高い認証情報を公開設定へ貼り付けないでください。

プロキシグループのuseでは、1つ以上のプロバイダーを参照し、filterやexclude-filterなどでノードを絞り込めます。フィルター式は通常、正規表現です。まずクライアントに表示される実際のノード名で小さく検証し、その後キーワードを広げてください。地域名の日本語・英語、略称、大文字・小文字は式を組み合わせて対応できます。結果が空になるとプロキシグループは出口を提供できず、ログには通常、該当するプロバイダーまたはプロキシグループの問題が示されます。

ルールプロバイダーの設定

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

  local-network:
    type: file
    behavior: ipcidr
    format: text
    path: ./ruleset/local-network.txt

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

behaviorは集合内ルールの種類を示します。一般的にはドメイン、IPネットワーク、クラシックルールなどがあります。リモートファイルの内容と一致していなければなりません。formatはYAML、テキスト、その他コアが対応する形式を指定します。拡張子を変更するだけでは内容の形式は変わりません。読み込みに失敗した場合は、ファイルを開いて実際の構造を確認してください。リモートのルールセットもpathへキャッシュされるため、各パスは分け、複数の集合が同じファイルへ書き込まないようにします。

ドメイン形式のYAMLルールファイルは、負荷リスト形式で記述できます。

payload:
  - "example.com"
  - "+.example.org"
  - "full:api.example.net"

コアやルールプロジェクトによっては、プレフィックスの意味が異なる場合があります。サードパーティの集合を使うときは、提供元の説明を基準にしてください。完全に制御したいルールは、重要度の高い項目を少数だけ自分で管理し、大規模な公開分類を補助として使う方法が適しています。外部集合が増えるほど更新経路は複雑になります。リモートURLが利用できないときは、ローカルキャッシュの有無が起動結果に影響します。重要な設定では、追加の集合が一時的に更新できなくても、主要な直接接続、プロキシ、フォールバックのロジックが明確に保たれるようにしてください。

更新と永続化の境界

メイン設定、プロキシプロバイダーのキャッシュ、ルールプロバイダーのキャッシュは分けて管理してください。クライアントがサブスクリプションを更新するとメイン設定を書き換えることがありますが、ローカルの上書きまで削除するとは限りません。設定ディレクトリを変更すると、古いキャッシュが読み込まれなくなることもあります。「サブスクリプションは更新されたのにノード一覧が変わらない」場合は、現在有効な設定、集合の更新時刻、実際のキャッシュパス、プロキシグループが参照するプロバイダー名が一致しているか確認します。

GUIのないLinux環境ではmihomoコアを直接実行することが多く、設定ディレクトリとサービスユーザーの権限がプロバイダーのキャッシュ書き込みに直接影響します。systemdで導入する場合は、サービスユーザーに設定ディレクトリの読み取り権限を付与し、providersやrulesetなどのキャッシュディレクトリには必要な書き込み権限を付与してください。導入手順はLinuxコマンドラインでClashコアを導入する方法を参照してください。

8. 上書き・マージ・検証・ロールバック

サブスクリプション設定は更新のたびに再生成されるため、本文を直接編集しても次回更新で失われることがほとんどです。そのためGUIクライアントでは通常、上書き、マージ、スクリプト処理の機能が提供されています。サブスクリプションにはノードと基本設定を任せ、ローカルの上書きでポート、DNS、プロキシグループ、自作ルールを補います。ただし、クライアントによって「マージ」の定義は完全には同じではありません。キーを上書きするもの、配列へ追加するもの、指定位置へルールを挿入できるものがあります。クライアントを移行するときは、小さな設定でマージ結果を先に検証してください。

マッピングの上書きと配列処理

modeやmixed-portのようなスカラー項目では、後から読み込まれた値が通常、前の値を上書きします。dnsのようなマッピングは階層ごとにマージされる場合もあれば、全体が置き換えられる場合もあります。rules、proxies、proxy-groupsのような配列では、追加、先頭への挿入、置換によって結果が大きく変わります。特にルール配列では、カスタム例外をサブスクリプションのMATCHの後ろに追加すると、永遠に一致しません。

# ローカル上書きの例。具体的な入口はクライアントにより異なります
mixed-port: 7890
mode: rule
log-level: info

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-filter:
    - "*.lan"
    - "*.local"

上書きを作成する前に、目的が「サブスクリプション項目の置き換え」なのか「サブスクリプション項目の追加」なのかを明確にしてください。ポートやログレベルは通常、上書きに適しています。カスタムルールはルール配列の先頭へ挿入する必要があることが多く、ローカルのプロキシグループは追加しつつ、参照するプロバイダーが最終設定に存在することを確認します。上書きファイルだけを見ず、マージ後にコアへ渡される最終設定を確認してください。「上書き自体は正しいのに最終順序が違う」ことが、多くの問題の原因になります。

ルールの先頭挿入とプロキシグループの追加

社内ドメインを直接接続にしたい場合、カスタムルールは広範なプロキシルールとMATCHより前に置く必要があります。クライアントにprependやappendなどの専用領域がある場合は、先頭挿入用の領域へ配置してください。プロキシグループを追加するときは、サブスクリプションに既存の同名グループがないかも確認します。同名オブジェクトの上書き方法は実装次第で、元のグループ全体が置き換えられる場合もあります。意味が明確で衝突しにくい名前を使い、マージ後に参照関係を確認するのが安全です。

# 期待する最終ルール順序
rules:
  - DOMAIN-SUFFIX,corp.example,DIRECT
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - RULE-SET,applications,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,ノード選択

段階的な検証

複雑な設定を変更するときは、DNS、プロキシグループ、すべてのルールを同時に変更しないでください。第1段階ではYAMLを読み込めるかだけを確認します。第2段階でリッスンポートとコントロールAPIの起動を確認します。第3段階でDNSクエリがコアへ入ることを確認します。第4段階でプロキシグループに利用可能なノードがあるか確認します。第5段階で少数のドメインを使ってルール一致を検証し、最後に大規模なルール集合を導入します。各段階で変数を1つだけ増やせば、問題の範囲を絞り込めます。

1. 基準設定を保存：正常に起動して接続できる現在の設定を1つ保管し、現在有効な設定名を記録します。
2. 構文を確認：インデント、コロン、引用符、配列構造を確認し、エディターが示す重複キーを重点的に調べます。
3. ログを読む：まず最初に現れた明確なエラーへ対処します。後続のエラーは、最初のエラーから連鎖した結果かもしれません。
4. 参照を照合：ルールの宛先、プロキシグループ名、ノード名、プロバイダー名、ローカルパスを1つずつ確認します。
5. 動作を検証：Webページの表示速度だけで判断せず、ログで実際に一致したルールと最終的なポリシーを確認します。

よくあるエラーの分岐

「設定ファイルの形式が正しくありません」と表示されたら、まずインデント、タブ、閉じられていない引用符、コロン後のスペースを確認します。「プロキシグループが見つかりません」と表示されたら、大文字・小文字、全角・半角記号、末尾のスペースを照合します。「providerの更新に失敗しました」と表示されたら、URLへの到達性、キャッシュディレクトリの権限、ファイル形式を確認します。「ポートのリッスンに失敗しました」と表示されたら、別のクライアントや古いコアプロセスが使用していないか確認します。「ルールがまったく一致しません」と表示されたら、現在のモード、ルール順序、接続の再利用、ログで取得されているのがドメインかIPかを確認します。

設定を読み込めるのにすべてのノードへ接続できない場合は、一時的にDIRECTを使ってローカルネットワークを確認し、次に静的ノードを1つだけテストして、最後にプロキシグループへ戻します。特定の種類のWebサイトだけに異常があるなら、クライアントの再インストールではなく、ルールログとDNSクエリから調べてください。TUNを有効にしてから問題が起きた場合は、システム権限、仮想NIC、ルーティングテーブル、ファイアウォール、DNSリダイレクトも確認します。Androidのバックグラウンド動作はVpnServiceの許可と省電力設定にも左右されるため、AndroidのVpnServiceとバッテリー最適化の除外設定を参照してください。

最終設定は3点を満たす必要があります。入口が明確で、すべてのアプリが接続先のポートを把握できること。参照関係が閉じていて、各ルールからプロキシグループをたどって実際の出口へ到達できること。更新を制御でき、サブスクリプションの変更でローカルの重要なロジックが上書きされないこと。この3点を満たしてから、地域グループ、DNSポリシー、大規模なルール集合を細かく調整してください。設定の複雑さは項目数ではなく、明確な目的に合わせるべきです。分類できない問題が残る場合はトラブルシューティングを、インポートから接続までの流れをやり直す場合はClash設定チュートリアルを確認してください。