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

YAMLの構造と設定の基本

設定ファイルでは、待ち受けポート、名前解決の方法、利用可能な送信先、通信の振り分け順序を定義します。YAMLとして解析できても、書式が正しいことを示すだけで、ノードへの接続や、現在のコアによる全項目のサポートまでは保証されません。トラブル時は、構文エラー、項目の意味に関する誤り、実行環境の問題を順に切り分けましょう。ネットワークのタイムアウトをインデントのせいにしたり、プロキシグループ名の誤りをサブスクリプションの不具合と混同したりしないことが大切です。

トップレベルのマッピングと階層

よく使われるトップレベルの項目には、mixed-port、mode、dns、proxies、proxy-groups、rulesがあります。トップレベルのキーは行頭に置き、子項目は一定のスペース数でインデントします。通常は半角スペース2つに統一し、タブは使いません。リスト項目はハイフンとスペースで始めます。ノード名、プロトコル、アドレス、ポートは、同じリスト項目に記述してください。

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

proxies: []

proxy-groups:
  - name: デフォルトの出口
    type: select
    proxies:
      - DIRECT

rules:
  - MATCH,デフォルトの出口

これは、直接接続を確認するための最小構成で、リモートプロキシサービスは含みません。待ち受け、グループ参照、ルール読み込みが正常かを確認する用途であり、リモートノードが利用可能かどうかは判断できません。proxies: []はノードリストが空であることを示します。プロキシグループは組み込みの送信先DIRECTを参照し、最後のルールは定義済みのグループ名を指定しています。実際にノードを追加する場合は、先にノードを登録し、その名前をグループに追加してください。

文字列、リスト、真偽値

ポートや間隔などの数値は通常、引用符で囲みません。有効・無効の指定にはtrueまたはfalseを使います。ノードのパスワード、特殊文字を含む名前、ルール文字列、URLは、コロンやシャープ記号、パーサー間の違いによる誤解を避けるため、引用符で囲むことができます。シャープ記号は位置によってコメントとして扱われるため、パスワードに含まれる場合は文字列として明示しましょう。シングルクォートで囲んだ文字列内のシングルクォートは2つ続けて記述します。ダブルクォート内のバックスラッシュは、エスケープとして解釈されることがあります。

ブロック形式とインライン形式のどちらもYAMLとして有効ですが、長い設定を保守するなら、行ごとに確認しやすいブロック形式がおすすめです。ノードは波括弧を使って記述することもできますが、項目が多い場合は展開して書きましょう。行数を減らすために複数の書式を混在させないでください。キーと区切り記号の間に全角コロン、全角カンマ、Webページからのコピーで混入したノーブレークスペースを入れないよう注意してください。

ファイルの場所と有効な設定

クライアント画面に表示されるサブスクリプションの内容、エディターで開いたローカルファイル、コアが最終的に読み込む設定は、それぞれ別の内容である場合があります。サブスクリプションの更新後、クライアントが待ち受けポートやコントロールインターフェース、上書きルールを追加することもあります。ファイルを確認する前に、現在有効な設定名、更新日時、マージ用スクリプトの有無を確かめてください。その後、クライアントの実行設定を表示する機能で、最終的な内容を確認しましょう。

同じ階層で同一のキーを重複して定義しないでください。パーサーによっては重複キーを拒否し、後の値を残すものもあるため、予測できない結果につながります。ルールを追加する場合は、既存のリストを編集するか、クライアントが明示的にサポートするマージ機能を使いましょう。ファイル末尾に別のrulesを追記する方法は避けてください。設定同士は、コピーして貼り付けるだけで自動的に意味のある形に統合されるわけではありません。

ファイルはUTF-8で保存し、拡張子が.yamlまたはクライアントが対応する形式になっていることを確認してください。拡張子の後ろに別のテキスト用拡張子が隠れていないかにも注意が必要です。構文エラーが発生した場合は、まずログに示された行と、その直前のリストを確認しましょう。直前の行で引用符が閉じていない、インデントが変わっている、リスト項目が正しく閉じられていないといった原因がよくあります。

ポート、モード、通信の取り込み範囲

待ち受けポートはアプリが接続を渡す先を決め、動作モードはコアが送信先を選ぶ方法を決めます。システムプロキシとTUNは、通信がコアに入る経路を決めます。これらは相互に関係しますが、互いの代わりにはなりません。modeだけを変更しても、すべてのアプリが自動的にプロキシを使うわけではありません。システムプロキシを有効にしても、その設定を参照しないアプリの通信がコアに入るとは限りません。

HTTP・SOCKS・混合ポート

portはHTTPプロキシの待ち受けに、socks-portはSOCKSプロキシの待ち受けに使います。mixed-portは1つのポートでHTTPとSOCKSの両方を受け付けます。通常のデスクトップ利用では、混合ポートだけで足りることが多く、アプリごとにポートを分ける必要がある場合に限り、個別の待ち受けを追加します。複数の待ち受けを同じアドレスの同じポートに割り当てると、ポート競合が発生します。

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

ポートが使用中の場合は、占有しているプロセスが以前のクライアント、別のプロキシツール、システムサービスのどれなのかを先に確認してください。正体の分からないプロセスを終了しないでください。ポートを変更したら、システムプロキシ、ブラウザー拡張機能、ターミナルの環境変数、アプリ内で手動指定したプロキシアドレスも合わせて変更します。詳しくは7890ポートの競合確認とmixed-portの変更手順をご覧ください。

ルールモードとグローバルモード

ruleはルールリストを上から順に照合するため、通常の設定の基本として適しています。globalはグローバルのプロキシグループを選択し、送信先の一時的な確認に使えます。directは直接接続で通信します。モードを切り替えても、すでにコアに入った接続の処理方法が変わるだけで、OSのルーティング方式は変わりません。クライアントの画面にあるモード切り替えボタンが、ファイルの設定を上書きすることもあります。実行中の状態を確認してください。

LAN内でプロキシを共有するには、LANからの接続を許可し、実際のネットワーク環境に応じて、たとえばbind-address: "*"のように待ち受けアドレスを設定します。プロキシにアクセスできる範囲が広がるため、ファイアウォールで接続元を制限し、必要に応じてプロキシ認証を設定してください。ポートをインターネットに公開するのは避けましょう。他の端末でホストのIPアドレスをプロキシとして指定しただけでは、待ち受けは自動的に公開されません。

システムプロキシとTUN

システムプロキシは、アプリがOSのプロキシ設定に従うことを前提とします。対象範囲が分かりやすいため、初回接続の確認方法として適しています。TUNは仮想ネットワークインターフェースを使って通信を取り込み、管理者権限やルート設定、DNSとの連携が必要になることがあります。アプリ側でプロキシを設定した状態でTUNを有効にすると、通信の取り込みが重複する可能性があります。まず現在の状態を記録し、取り込み方法は一度に1つだけ変更してください。

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

このTUN設定は項目同士の関係を示す例であり、リモート管理サーバーでそのまま有効にしないでください。自動ルーティングによって、リモート接続、コンテナネットワーク、企業VPNに影響する場合があります。dns-hijackは、取り込み対象の範囲に入った特定のDNS通信を処理する設定です。暗号化DNSをすべて横取りするという意味ではなく、OSのルート設定、アプリの挙動、コアの対応状況にも左右されます。

トップレベルのipv6とDNS内の同名項目では、適用範囲が異なります。一方だけを無効にして、端末のIPv6通信がすべて停止したと考えないでください。IPv6を使う場合は、上位ネットワーク、ノードの対応状況、通信を取り込むルートを合わせて確認します。詳しくはTUNモードとシステムプロキシの仕組みをご覧ください。

DNS名前解決とアドレスマッピング

DNS設定では、まず名前解決の経路が単独で起動できることを確認し、その後に通信の振り分けや拡張モードを検討します。リクエストのタイムアウトが必ずしもノードの問題とは限りません。DNSサーバーに到達できない、暗号化DNSのホスト名を引くための名前解決ができない、ノードサーバーのドメイン名の解決が循環するといった原因で、接続前に失敗することがあります。トラブル時は、接続先のドメイン、プロキシサーバー、DNSサービス自体のドメインの名前解決を切り分けてください。

主な項目と起動までの流れ

enableは内蔵DNSを有効にし、listenは待ち受けアドレスを指定します。アプリがその待ち受けに直接リクエストを送信するか、リクエストが内蔵DNSに転送されない限り、関連設定は適用されません。default-nameserverは暗号化DNSサービスのホスト名を解決するための初期DNSとして使えます。コアが対応するIPアドレス形式の上流DNSを指定し、まだ確立していないドメイン名への依存を避けてください。

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:
    - 223.5.5.5
    - 119.29.29.29
  nameserver:
    - https://dns.alidns.com/dns-query
  proxy-server-nameserver:
    - 223.5.5.5
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "localhost"

この例では、ローカルの待ち受け、初期の名前解決、ノードのドメイン名解決の役割を示しています。指定した上流DNSが現在のネットワークに適しているかは、実際にテストしてください。1053はOSの標準DNSポートではないため、ファイルに記述しただけでシステムのDNSリクエストがすべて転送されるわけではありません。標準ポートで待ち受ける場合は、権限、既存サービスとの競合、システムのDNSアドレス設定方法も確認してください。

fake-ipと実アドレスによる名前解決

fake-ipはドメイン名にマッピング用のアドレスを割り当て、コアがドメイン名の情報を保持したまま、接続時に実際の送信先を選べるようにします。ドメイン名に基づく振り分けに便利ですが、LAN内のデバイス検出、アドレス比較、実IPアドレスのみを受け付けるアプリでは例外が必要な場合があります。例のネットワークは内部マッピング用です。リモートプロキシサーバーのアドレスではなく、他の端末のゲートウェイとしても使わないでください。

fake-ip-filterは、指定したドメイン名をこのマッピング処理の対象外にします。マッチ条件は現在使っているコアのドキュメントで確認し、ルーティングルールのDOMAIN-SUFFIXの書き方と混同しないでください。互換性に問題がある場合は、該当ドメインだけを例外にして、アプリが正常に動作するか確認します。すべてのドメインを対象外にすると、選択した拡張モード本来の効果が失われます。

redir-hostは実際の名前解決結果を返すため、実IPアドレスに依存するアプリで使いやすい一方、ドメイン名とIPアドレスの対応は、キャッシュやアプリ独自の名前解決、リクエスト経路の影響を受けることがあります。どちらの方式が速いかを比べるものではありません。通信の取り込み方とアプリの互換性に応じて選んでください。切り替えた後は接続を張り直し、OSやアプリに残っている古いDNSキャッシュも処理しましょう。

ドメイン名ごとの上流DNS指定

nameserver-policyでは、指定したドメイン名に使用するDNSサーバーを選べます。社内ドメインの名前解決には企業DNSが必要なことが多く、パブリックDNSに任せることはできません。LAN内のデバイス名も、ルーターでしか解決できない場合があります。以下では予約ドメインを使って構造を示しています。プライベートアドレスは、現在のネットワークに実在し、到達可能なDNSサーバーに置き換えてください。

dns:
  nameserver-policy:
    "+.corp.example":
      - 192.168.50.1

これは既存のdnsマッピングに追加する設定であり、トップレベルにDNS定義をもう1つ作るものではありません。respect-rulesでDNS通信にもルーティングルールを適用する場合は、依存関係の循環を避け、プロキシサーバーのドメイン名を解決する経路も明確にしてください。初期の名前解決と送信先の依存関係を確認できていないうちは、すべてのDNSリクエストを無理にプロキシグループへ送らないでください。

通常のアプリは動作するのに、セキュアDNSを有効にしたブラウザーだけ挙動が異なる場合は、ブラウザーが独自の暗号化DNSを使っていないか確認してください。想定していたOSのDNS設定を通らずに名前解決している可能性があります。まずテスト用アプリを1つに絞って名前解決の経路を確認し、そのうえでアプリ設定または通信の取り込み方を調整しましょう。複数の条件を同時に変更しないでください。

プロキシノードとプロトコル項目

proxiesでは利用可能なリモート送信先を定義しますが、それらをいつ選択するかは定義しません。ノードには少なくとも、重複しない名前、正しいプロトコル種別、サーバーアドレスと、そのプロトコルで必要な認証情報や通信パラメーターが必要です。サーバーアドレスとパスワードが正しくても、設定が完全とは限りません。通信方式、TLS、サーバー名、パスが一致していないと、ハンドシェイクに失敗することがあります。

基本項目と名前による参照

nameは設定内で参照する識別子であり、プロキシグループや画面に表示される名前でもあります。重複せず、安定した名前を付けてください。serverにはサーバーのIPアドレスまたはドメイン名を指定し、パスを含むWebページのURLは指定しません。portはサーバー側の待ち受けポートであり、ローカルの混合ポートではありません。typeによって他の項目の解釈が決まるため、種別だけを変更して別のプロトコルに変えることはできません。

proxies:
  - name: Shadowsocksの例
    type: ss
    server: proxy.example.com
    port: 443
    cipher: aes-128-gcm
    password: "your-password"
    udp: true

  - name: Trojanの例
    type: trojan
    server: proxy.example.net
    port: 443
    password: "your-password"
    sni: proxy.example.net
    skip-cert-verify: false
    udp: true

例にあるドメイン名とパスワードは設定項目の構造を示すためのもので、実際の接続には使えません。Shadowsocksのcipherとパスワードはサーバー側の設定と一致させてください。Trojanのパスワード、サーバー名、証明書の設定も同様です。クライアントの名称からプロトコル項目を推測せず、サービス提供元の接続情報または互換性のあるサブスクリプションを参照してください。

TLSと通信パラメーター

TLSサーバー名は接続先アドレスと異なる場合がありますが、サーバーの構成と証明書に合致している必要があります。プロトコルによってはsniまたはservernameを使うため、機械的に一方へ統一しないでください。証明書エラーが発生したら、まず端末の時刻、ドメイン名のスペル、証明書の適用範囲、サーバーの設定を確認します。証明書の検証を無効にすると接続先の認証機能が弱まるため、通常の対処方法として使わないでください。

WebSocketノードでは特定のパスやHostリクエストヘッダー、gRPCノードではサービス名が必要な場合があります。これらは任意の最適化項目ではなく、ハンドシェイクの一部です。ノード情報に通信方式の指定がある場合は、対応するネスト項目も合わせて確認してください。別のノードのパスをコピーすると、アドレスとパスワードが同じでも接続を拒否されることがあります。

プロトコルの互換性と段階的なトラブル対処

mihomoと初期のClashコアでは、対応するプロトコルや拡張項目が完全には一致しません。あるクライアントにサブスクリプションをインポートできても、別のコアですべてのノードが認識されるとは限りません。まずコアが必要な機能に対応しているかを確認し、クライアントが項目を保持して正しく渡しているかを確かめてください。クライアントが必要な場合はクライアントのダウンロードページをご覧ください。初めて使う方は、Clash Plusから設定を始めるとよいでしょう。

トラブル対処は、ドメイン名の解決、TCPまたはUDPの到達性、プロトコルのハンドシェイク、認証、接続先へのリクエストの順に進めます。名前解決に失敗したらDNS、接続を拒否されたらポートとサーバーの状態、TLSエラーならサーバー名と証明書、認証エラーならパスワードや識別子を確認してください。問題のたびにノード全体を削除して作り直すと、原因特定に役立つログが失われることがあります。

udp: trueは、該当ノードでUDP通信を試みることを許可するだけで、どの通信取り込み方法でもUDPが使えることを保証しません。HTTPプロキシ経由のアプリ通信と、TUNが受け取るUDP通信では経路が異なります。サーバー、プロトコル実装、ネットワークのファイアウォールによって制限されることもあります。テスト時は、ページが開くかだけで判断せず、アプリが実際に使っているプロトコルを確認してください。

プロキシグループの種類と経路選択

proxy-groupsはノードをまとめ、送信先として選択できるグループを定義します。ルールでは通常、安定したグループ名を指定し、グループ側で使用するノードを決めます。これにより、サブスクリプション更新後にルールを1つずつ修正する必要がなくなります。グループを理解する際は、手動選択、ヘルスチェック、実際の通信を分けて考えてください。テストに成功しても、すべての接続先にアクセスできるとは限りません。

手動選択と自動選択

selectは手動で選択するタイプで、最上位の送信先や用途を明示したい場合に適しています。url-testは定期的な応答テストの結果から候補を選びます。toleranceを設定すると、小さな差による頻繁な切り替えを抑えられます。fallbackは候補のリスト順に従って利用可能なものを選び、応答時間の短さを最優先にはしません。優先する回線を固定したい場合は、この優先順位の違いを考慮してください。

proxy-groups:
  - name: 自動選択
    type: url-test
    proxies:
      - Shadowsocksの例
      - Trojanの例
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    lazy: true

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

  - name: デフォルトの出口
    type: select
    proxies:
      - 自動選択
      - フェイルオーバー
      - DIRECT

この例では、前のセクションで定義したノード名を参照しています。ノードがインポートされていない場合は、追加するか、実在する名前に変更してください。テストURLは実行時の応答確認先であり、ページが読み込むリソースではありません。現在のネットワークや各送信先で適切なURLを使用してください。送信先によって応答の特性が異なるため、テストURLを変更した場合、以前の測定結果とは単純に比較できません。

検査間隔と利用可能性の考え方

intervalの単位は通常、秒です。自動テストを行うグループのtoleranceは、一般に切り替え許容値をミリ秒で指定します。間隔を短くすると検査リクエストやネットワーク通信が増えますが、実際の通信が安定するとは限りません。モバイル端末ではバックグラウンド動作やバッテリーへの影響も考慮してください。まず適切な間隔で様子を見て、実際の障害からの復旧要件に応じて調整しましょう。すべての値をむやみに小さくする必要はありません。

lazyは、対応状況に応じて未使用グループのアクティブな検査を減らせます。そのため、画面を開いた直後に新しい検査結果がなくても、ノードの故障とは限りません。グループの検査、プロバイダーのヘルスチェック、ユーザー操作によるノードの速度測定は、それぞれ異なる仕組みで実行されることがあります。検査対象、最終実行時刻、テストURLを確認し、個別の結果を全体の状態と混同しないようにしてください。

負荷分散とグループの入れ子参照

load-balanceは複数の接続を振り分ける方式です。選択した方式によって、同じ接続先への割り当てを維持したり、候補の送信先を順番に利用したりできます。1つのダウンロード接続を複数の回線に分割して、速度を合算する機能ではありません。送信元アドレスに敏感なログイン、決済、長時間のセッションでは、出口の頻繁な変更によって追加認証が必要になることがあります。安定したグループを使うか、専用ルールを設定してください。

プロキシグループから別のグループを参照できますが、構成はシンプルに保ち、循環参照を避けてください。たとえば、デフォルトの出口から自動選択を参照できますが、自動選択からデフォルトの出口を再び参照する構成にはしないでください。グループ名とノード名を重複させると、設定の確認やログでの切り分けが難しくなります。名前を変更したら、ルール、ネストしたグループ、上書きスクリプトに古い参照が残っていないか確認してください。

画面に以前の手動選択が残っている場合は、クライアントがグループの選択状態を保存しているか、設定のprofile.store-selectedが復元に使われているかを確認してください。ファイルに記載された候補の先頭が、現在選択中の項目とは限りません。種類ごとの比較と設定例は、url-test・fallback・load-balanceの設定ガイドをご覧ください。

ルールの順序とマッチ構文

rulesは通常、上から順に照合され、最初に一致したルールが送信先を決めます。設定が正しくても意図しない経路になる場合は、目的のルールが存在するかだけでなく、その前に広い範囲のルールがないか確認してください。最後のフォールバックには通常MATCHを使います。前のルールに一致しなかったリクエストをすべて受け取るため、リストの途中に置くと、その後の通常ルールは実行されません。

ドメインルールとアドレスルール

DOMAINは指定したドメイン名に一致し、DOMAIN-SUFFIXはそのドメイン名とサブドメインに一致します。DOMAIN-KEYWORDはドメイン名に含まれるキーワードで判定します。キーワードルールは範囲が広いため、対象ドメインが分かっている場合の代用には適しません。ルールの送信先には、組み込みの送信先、ノード名、プロキシグループ名を指定できます。後から経路を変えても振り分け条件を修正せずに済むよう、通常はグループ名を使います。

rules:
  - DOMAIN,router.lan,DIRECT
  - DOMAIN-SUFFIX,example.com,デフォルトの出口
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
  - IP-CIDR6,fc00::/7,DIRECT,no-resolve
  - MATCH,デフォルトの出口

この例では、よく使われるプライベートアドレス範囲を直接接続にし、それ以外のリクエストをデフォルトの出口へ送ります。ただし、すべての端末に適用できるLAN向けの完全なルールではありません。企業ネットワーク、仮想ネットワーク、特殊なルーティングでは、追加の設定が必要なことがあります。example.comは例示用ドメインです。実際の振り分けでは、接続先と必要な関連ドメインを確認しながら追加してください。広範囲のキーワードをそのまま使うのは避けましょう。

no-resolveとドメイン名の情報

no-resolveは、アドレス種別のルールに一致させるために、ドメイン名の名前解決を自発的に行わないことを示します。接続に利用可能な接続先IPアドレスが含まれていれば、該当するアドレスルールに一致する場合があります。DNSを禁止する設定ではありません。ドメイン名を使うリクエストでは、このオプションの有無によってマッチ処理と名前解決の負荷が変わるため、すべてのルールに付ける固定のオプションとして扱わないでください。

GEOIPはIPアドレスのデータベースに基づいて接続先の地域を判定し、GEOSITEは対応するドメイン分類データとコアのサポートに依存します。データベース上の分類はサービスの実際の提供地域を示すものではなく、1つのサイトに必要なすべてのドメインが同じ分類に含まれるとも限りません。関連データを参照する設定では、ファイルの存在、データソースとの互換性、更新の成否を確認してください。項目が受け付けられたことだけで、データが読み込まれたと判断しないでください。

プロセスルールと通信の取り込み範囲

プロセス名やパスによるルールを使うには、プラットフォームと通信の取り込み方法がプロセス情報を提供している必要があります。通常、ルーターからはLAN内の別端末でリクエストを開始したアプリのプロセス情報を確認できません。モバイルOSでは権限に制限がある場合もあります。こうしたルールを使う前に、接続の詳細画面にプロセス情報が表示されるか確認してください。そのうえで名前とフルパスのどちらで照合するかを判断し、ウィンドウタイトルだけを頼りに設定しないでください。

ルールで処理できるのは、すでにコアに入ったリクエストだけです。接続一覧に対象のプログラムがまったく表示されない場合は、ドメインルールを追加し続けるのではなく、システムプロキシ、アプリのプロキシ設定、TUNのルートを確認してください。リクエストが一覧に表示される場合は、対象ドメイン、接続先IP、適用されたルール、最終的な送信先を確認します。この4つを順に追う方が、ノードを何度も変更するより効果的です。

ルールを検証する際の対象の絞り込み

ルールを1つ検証するときは、まず対象を単一のドメインと明確な送信先に絞り、適用されたことを確認してからサブドメインやルールセットへ広げてください。Webページでは静的リソース、API、認証用ドメインに同時にリクエストすることがよくあります。メインのドメインだけをプロキシにしても、一部のリソースが別の出口を通ることがあります。接続履歴をもとに必要な関連ドメインを追加し、未確認のドメインを広範囲のルールにまとめて追加しないでください。

ルールを変更したら設定を再読み込みし、新しいテスト接続を作成してください。既存のHTTP接続、ダウンロード、リアルタイム通信のセッションは古い送信先を使い続けることがあり、新しいルールの検証には向いていません。よくある接続の問題はFAQ・トラブル対処で確認できます。通信の取り込み方は使い方ガイドの手順をご覧ください。

プロバイダーと更新の仕組み

プロバイダーを使うと、頻繁に更新されるノードやルールをメイン設定から分離し、メインファイルの構造を安定させられます。proxy-providersはノードのリソース、rule-providersはルールのリソースを管理します。内容の形式と設定内の参照先はそれぞれ異なります。プロバイダーのダウンロードに成功しても、ファイルを取得できたことを示すだけです。内容の形式が正しく、グループやルールから参照され、現在の設定で実際に使われていることも確認してください。

ノードのリソースとサブスクリプション形式

ノードプロバイダー用のYAMLリソースは、通常proxiesを主要な構造として使います。Clashの完全な設定ファイル、ノードだけのリソース、Base64でエンコードされたノードリンクのリストは、互いに置き換えられません。クライアントでインポート時に変換できても、コアのHTTPプロバイダーが同じ元データを直接解析できるとは限りません。インポート前にサブスクリプションURL・ローカルYAML・Base64形式の解説でリソースの種類を確認してください。

proxy-providers:
  リモートノード:
    type: http
    url: "https://subscription.example.com/nodes.yaml"
    path: ./providers/nodes.yaml
    interval: 3600
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 300

proxy-groups:
  - name: サブスクリプションの選択
    type: select
    use:
      - リモートノード

例のアドレスは、サービス提供元が指定する互換性のあるリソースに置き換えてください。pathはローカルのキャッシュ保存先です。相対パスは通常、コアの作業ディレクトリまたはクライアントが指定するデータディレクトリを基準とし、Webページのあるディレクトリを基準とするものではありません。保存先に書き込めない場合や、複数のプロバイダーが同じパスを使う場合、更新やキャッシュに問題が発生します。リソースごとに異なるファイル名を付けると、誤上書きや原因の切り分けを防ぎやすくなります。

外側のintervalはリソースの更新間隔を、health-check.intervalはノードの応答確認間隔を指定します。どちらも通常は秒単位ですが、用途が異なります。サブスクリプションがまだ更新されていなくても、ヘルスチェックは実行されていることがあります。ヘルスチェックが成功しても、サブスクリプションの内容が更新されたとは限りません。画面に表示される更新時刻と検査結果をそれぞれ確認し、一方から他方の状態を推測しないでください。

ルールリソースとbehavior

ルールプロバイダーでは、内容の形式、format、behaviorを一致させる必要があります。domainはドメインの集合、ipcidrはアドレス範囲の集合、classicalはルール種別を含む項目に適しています。形式が異なるファイルに合わせるために、behaviorの名称だけを変更しないでください。内容が異なる場合は、正しい形式に変換するか、対応する形式を選ぶ必要があります。

rule-providers:
  ローカル直接接続:
    type: file
    behavior: classical
    format: yaml
    path: ./rules/local-direct.yaml

rules:
  - RULE-SET,ローカル直接接続,DIRECT
  - MATCH,デフォルトの出口

対応するlocal-direct.yamlにはマッチ条件だけを記述し、各項目に送信先を繰り返し指定しません。送信先はメイン設定のRULE-SET行で指定します。以下はclassical形式のYAMLの基本構造です。宣言したパスに実際にファイルを保存してください。ルールセット内の順序と、メイン設定で参照する位置の両方を明確に保ちましょう。

payload:
  - DOMAIN,router.lan
  - IP-CIDR,192.168.0.0/16,no-resolve

更新の依存関係とオフラインキャッシュ

リモートリソースの更新にも、利用可能な名前解決とネットワーク経路が必要です。初回起動時に、まだ取得できていないノードを使わないとリソースをダウンロードできない場合、起動時の依存関係が循環することがあります。到達可能な更新経路または有効なキャッシュを残し、クライアントとコアの対応状況に合わせてダウンロードの送信先を設定してください。リモートリソースを取得できると確認する前に、唯一利用可能なローカルノードやキャッシュファイルを削除しないでください。

更新に失敗した場合は、HTTPステータス、レスポンスのContent-Type、解析エラー、ローカルへの書き込み権限を分けて確認してください。サーバーがログインページやエラーページを返した場合、ファイルはダウンロードされても有効なノードやルールのリソースではありません。サブスクリプションURLにはアクセス情報が含まれるため、信頼できるクライアントまたは管理下の環境だけで使用してください。出所の分からないオンライン変換サービスに送信してはいけません。

上書き、マージ、反映の確認

サブスクリプションはリモートの内容を提供し、上書き設定はローカルで維持したい内容を管理します。両者はできるだけ分けてください。サブスクリプションから生成されたファイルを直接編集すると、次回更新時に変更が失われることがあります。完全に独立したローカル設定にコピーすると、ノードの変更を自分で保守しなければなりません。サブスクリプションが管理する項目とローカル設定で上書きする項目を明確にし、最後に実行時の設定が意図どおりか確認しましょう。

項目の管理元とマージ順序

クライアントはサブスクリプションを読み込んだ後に画面の設定をマージし、その後ルールパッチやスクリプトを適用する場合があります。処理順序はクライアントによって異なります。すべてのクライアントが同じ上書きファイルに対応すると思い込まないでください。また、別のクライアント用のスクリプト構文をYAMLにそのまま書かないでください。Clash PlusやClash Verge Revなどの設定場所は、実際の画面で確認してください。コア自体がクライアント独自のすべてのマージ拡張を解釈するわけではありません。

スカラー、マッピング、リストはそれぞれ別に扱う必要があります。ポートのようなスカラー値は、後から指定した値に置き換わるのが一般的です。DNSマッピングはキーごとに統合される場合も、全体が置き換わる場合もあります。ルールやプロキシグループのリストは、上書き、追加、先頭への挿入のいずれかになることがあります。マージツールが明確に保証していない限り、配列が自動的に重複排除されるとは考えないでください。同じ名前のノードが安全に統合されるとも限りません。

先行ルールと安定した参照

カスタムルールは通常、サブスクリプションのフォールバックより前に挿入します。ファイルの末尾に追加するだけでは不十分です。クライアントに先頭挿入用のルール設定欄がある場合は、以下の2行でLANの直接接続を指定できます。これはルールリストの項目であり、汎用の上書きファイル形式ではありません。外側の構造は、現在のクライアントが採用するマージ方式に合わせてください。

- DOMAIN,router.lan,DIRECT
- IP-CIDR,192.168.0.0/16,DIRECT,no-resolve

ローカルルールでは、できるだけ安定したグループ名を参照してください。サブスクリプションの更新でグループが削除または改名されると、既存のルールが読み込めなくなる場合があります。変更されやすいノード名をルールに直接書くと、保守の手間が増えます。ローカルの固定した入口が必要な場合は、クライアントが対応する上書きレイヤーに独自のグループを作り、サブスクリプションのプロバイダーを参照できます。プロバイダー名も安定していることを確認してください。

保存、確認、再読み込み

変更を適用する前に、現在使える設定と上書き設定を複製して保存してください。一度に変更する機能は1つに絞り、まずポートを変更して検証し、その後DNSを調整します。コアのコマンドラインを使える場合は、テストモードで設定を検証できます。デスクトップクライアントに設定検査機能がある場合もあります。以下のコマンドで指定する作業ディレクトリは、リソースの相対パスが実際に基準とする場所に合わせてください。

mihomo -t -d ./profile -f ./profile/config.yaml

テストに合格した場合でも、現在のテスト環境で設定が受け付けられたことを示すだけです。すべてのリモートサービスへの接続や、クライアント実行時に項目が再度上書きされないことまでは保証されません。外部リソースを使う場合は、ファイルの場所と利用可能性を確認してください。その後クライアントで設定を再読み込みし、起動ログでポートの待ち受け、DNSの初期化、プロバイダーの読み込みにエラーがないか確認してから、新しい接続を試してください。

ロールバックと問題の記録

設定の再読み込みに失敗した場合、クライアントは古い設定のまま動作を続けることがあります。画面からインターネットに接続できても、新しいファイルが反映されたとは限りません。エラー通知と現在有効な設定を確認してください。原因を特定できない場合は、直近の正常なバックアップに戻し、変更を1つずつ再適用しましょう。TUN、システムプロキシ、DNSを変更した場合は、ロールバック時にOS側の設定も元に戻っているか確認してください。ファイルだけを戻して通信の取り込み方が変更後のまま残ることがあります。

問題を報告する際は、使用中のクライアントとコアの名称、通信の取り込み方法、問題が起きた項目の抜粋、ログに記録された最初の関連エラー、再現前後の変更点を含めてください。「接続できない」とだけ書いたり、機密情報を含むサブスクリプション全体を投稿したりしないでください。よくある問題はFAQを確認してください。インストールやインポートの手順をやり直す場合はクイックスタートガイドに戻り、トラブル対処のために環境全体を何度も再インストールする必要はありません。