Clash設定ファイルの書き方｜YAML・DNS・プロキシグループ・ルール上書き

01 YAMLの構造と参照関係

Clashの設定ファイルは、順番に実行するコマンド列ではなく、ネットワークの動作を定義するデータです。ファイルの最上位には通常、待ち受けポート、動作モード、DNS設定、ノード一覧、プロキシグループ、ルールを記述します。コアは設定を読み込んで各オブジェクトを作成し、接続に一致したルールに応じて通信の出口を選びます。そのため、ファイルを保存できてもノードに接続できるとは限らず、構文が正しくても参照先の名前が正しいとは限りません。

インデントで項目の階層を表す

YAMLではスペースによるインデントで階層を表します。スペースは2つに統一し、タブは使わないようにしましょう。値を続けるコロンの後にはスペースを1つ入れ、リスト項目はハイフンとスペースで始めます。同じ階層の項目は位置をそろえてください。見た目ではわずかなずれでも、最上位に置くべきルール一覧がDNSの中に入り、項目が無視されたり型エラーになったりすることがあります。空白文字を表示する設定にすると、目視で推測するより確実です。

# 単独で読み込める最小限の直結設定。プロキシノードは含まない
mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - 223.5.5.5

proxies: []
proxy-groups: []

rules:
  - MATCH,DIRECT

上の例では設定が正常に読み込まれるか確認できますが、すべての接続が直結となり、プロキシ経由にはなりません。空のリストを表す [] は、項目がないという意味であり、フィールド自体がない状態とは異なります。エディターやフォルダーのアクセス権を調べる場合は、まずこの最小構成で読み込みを確認してから、ノードやプロキシグループを追加してください。最初からサブスクリプション全体や外部ルール、上書きスクリプトを一度に組み込むのは避けましょう。

文字列、真偽値、リスト

真偽値は true または false、ポートは整数で記述します。ノード名やルール文字列は必要に応じて引用符で囲みましょう。特にコロンやシャープ記号などを含む名前には注意が必要です。シャープ記号はコメント、コロンの後のスペースはマッピングの区切りとして解釈されることがあります。数字だけのパスワードも、読み込み後に型が変わらないよう引用符で囲むのがおすすめです。

複数行形式は読みやすく、波括弧で囲むインライン形式はコンパクトですが、どちらも同じオブジェクトを表せます。このページでは各項目の階層がわかりやすい複数行形式を使います。YAML全体をMarkdownのコードフェンスで囲まないでください。Webページ上の例を示す記号は設定内容ではありません。コピーする際はコード本文だけを選び、リッチテキスト形式ではなく通常のテキストとして保存してください。

名前をたどって参照先を確認する

ノードの name はプロキシグループから参照され、グループの name はルールから参照されます。参照には名前全体が一致する必要があるため、スペース、大文字・小文字、句読点もそろえてください。グループ名を変更してルール側を直さないと、読み込み時にプロキシが見つからないというエラーが出ることがあります。ルールの転送先から逆にたどり、同じ名前のグループがあるか、そのグループの各メンバーが存在するかを確認しましょう。

最上位に同じキーを重複して書かないでください。rulesを2つ書いても自動で連結されず、dnsを2つ書いても自動で統合されません。パーサーによっては重複キーを拒否したり、一方だけを残したりします。ルールを追加する場合は既存のリストを編集し、サブスクリプションの構造を保つ場合は、クライアントが正式に対応する上書き機能を使ってください。YAML自体が「2つの設定をつなげる」という意図を判断することはありません。

サブスクリプションを使う場合は、元の内容と実行時の設定を区別しましょう。ダウンロード後、クライアントがポートやDNSの上書き、ルールの統合を適用することがあります。Profiles内の元ファイルを編集しても反映されない場合、コアが読み込んでいないのではなく、後段の設定で再び上書きされている可能性があります。有効な設定の名前と参照元を記録し、変更後は実際に動作している設定とログを確認してください。

02 ポート、動作モード、アクセス範囲

ポート項目は、クライアントがローカルで接続を受け付ける場所を指定します。リモートサーバーのポートではありません。ブラウザーやコマンドラインツールがこの入口にリクエストを送ると、コアがルールに応じて通信を振り分けます。ポートを変更しても、旧ポートを使っていたアプリの設定は自動では更新されません。Windowsのシステムプロキシ、ブラウザー独自の設定、ターミナルの環境変数をそれぞれ確認してください。

個別の待ち受けと混合ポート

項目	用途	間違えやすい点
`port`	HTTPプロキシの入口	CONNECTでトンネルを確立できますが、HTTPサイトしか利用できないという意味ではありません。
`socks-port`	SOCKSプロキシの入口	アプリ側がSOCKSに対応している必要があります。ポートが同じだからといってHTTPとして使えるわけではありません。
`mixed-port`	HTTPとSOCKSで共用する入口	入口側でプロトコルを判別しますが、アプリには正しいプロキシの種類を設定してください。
`allow-lan`	LANからのアクセスを許可するか	待ち受けアドレスとOSのファイアウォール設定にも左右されます。

# ローカル利用向けの共通設定
mixed-port: 7890
allow-lan: false
bind-address: 127.0.0.1
mode: rule
log-level: info
ipv6: false

LAN内で共有しない場合は、ローカルからのみアクセスできる設定にしておきましょう。上の例では待ち受けアドレスとアクセス許可の両方がローカル利用向けです。スマートフォンや別のPCから使う場合は、Allow LANを有効にするだけでは不十分です。対象のネットワークアダプターで待ち受けるようにし、ファイアウォールで信頼できるネットワークからのアクセスを許可したうえで、別の端末にはこのPCのLAN内アドレスを設定してください。自分自身のループバックアドレスを入力しても接続できません。

待ち受けに失敗する原因として、ポートの競合がよくあります。クライアントを重複して起動していないか確認し、競合するプロセスを調べてください。ポートを次々に変更した結果、アプリ側の設定との不一致が起きないよう注意しましょう。Windowsのターミナルで次のコマンドを実行すると、該当ポートの待ち受け状態とプロセスIDを確認できます。競合元を調べるためのものであり、IDを見ただけでプロセスを終了してはいけません。タスクマネージャーでプログラム名と用途を確認してください。

netstat -ano | findstr :7890

ルール、グローバル、直結モード

mode: ruleはルールの順序に従って通信の出口を決めるモードで、日常的な振り分けに適しています。グローバルモードでは全体のポリシーで出口を選びますが、通信がコアに届いていることが前提です。直結モードでは、コアが受け取った通信を宛先へ直接送ります。動作モードはシステム全体の通信を捕捉する設定ではありません。ルールモードからグローバルモードに変えても、システムプロキシを無視するアプリが突然プロキシを使うようにはなりません。

GeneralのSystem Proxyは、クライアントからWindowsのシステムプロキシを設定する操作です。YAMLの動作モードとは別の機能です。通常はシステムプロキシに従うアプリに影響します。TUNは仮想ネットワークアダプターとルーティングで通信を捕捉するため、対応するコア、権限、サービスが必要です。旧版Clash for WindowsのService ModeやTUN Modeと、現在のMihomoクライアントの実装は、同じボタン配置や動作だと考えないでください。

ログと制御インターフェースを混同しない

log-levelは、通常の利用ならinfoで十分です。問題の調査中は一時的にdebugへ上げてもよいでしょう。デバッグログには宛先ドメイン、接続情報、設定ファイルのパスなどが含まれる場合があります。共有する前にサブスクリプションURLや認証情報、個人のアクセス履歴を削除してください。ログの量を増やせば原因究明が速くなるわけではありません。問題を一度再現し、時系列に沿って該当する接続を確認するほうが効率的です。

外部制御インターフェースは、クライアントの画面やダッシュボードからコアを管理するためのものです。アプリの通信に使うプロキシの入口ではありません。external-controllerを設定する場合は、まずループバックアドレスにバインドしてください。リモートからのアクセスが必要なら、認証とアクセス制限を別途設計しましょう。制御インターフェースのポートをブラウザーのプロキシ設定に入力したり、LAN内の端末を接続するために管理用インターフェースをネットワーク全体へ公開したりしないでください。

最上位のipv6とDNSモジュール内のIPv6項目は、適用範囲が異なります。一方を無効にしても、OSのネットワークアダプターでIPv6が無効になったり、すべてのアプリの名前解決経路が変わったりするわけではありません。特定のネットワークで一部の宛先に接続できない場合は、システムのアドレス、DNSの応答、ルールの適用状況、出口の接続性を確認しましょう。すべての問題をポートやプロキシのスイッチだけに結びつけないでください。

この章の項目を変更したら、まずコアが正常に待ち受けているか、次にアプリのプロキシアドレスが正しいか、最後に動作モードと出口を確認してください。この順に調べると、「入口に接続できない」場合と「リモート接続に失敗した」場合を切り分けられます。操作方法はシステムプロキシの使い方を参照してください。クライアント終了後もインターネットに接続できない場合は、FAQでシステムプロキシ設定が残ったときの対処法を確認できます。

03 DNSとドメインの名前解決経路

DNSはドメイン名をIPアドレスに変換しますが、プロキシ設定では毎回同じ場所で名前解決されるとは限りません。システムが先に解決する場合、アプリが独自のリゾルバーを使う場合、コアがリクエストを処理する場合、リモートプロキシが最終的に解決する場合があります。DNS設定が有効か判断するには、見慣れたサーバーがファイルに記載されているかではなく、「この問い合わせはどこから入り、誰が応答したか」を確認しましょう。

ローカルで待ち受けても自動的に通信を捕捉するわけではない

# 基本的な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"
    - "localhost"
  nameserver:
    - 223.5.5.5
    - 119.29.29.29

enableはコアのDNSモジュールを有効にし、listenは待ち受けアドレスを指定します。上の例ではループバックアドレスと一般ユーザー権限で使えるポートを使用しているため、テストに適していますが、WindowsのすべてのDNSリクエストが自動的に変更されるわけではありません。通常、ネットワークアダプターのDNS設定にはサーバーアドレスを指定します。このようなカスタムポート付きの文字列は設定できません。通信を完全に捕捉するには、クライアントやTUNの関連設定も必要です。

nameserverは上流のDNSサーバー一覧です。単純に優先・予備の順番を指定するものではありません。並列問い合わせ、キャッシュ、サーバーの選択方法はコアによって異なります。複数のサーバーを設定しても、失敗の原因が「先頭のサーバーが使えない」とは限りません。検証時は条件を絞り、まず現在のネットワークから利用できるサーバーを1つ設定して基本動作を確認してから、暗号化DNSやドメインごとの振り分けを追加しましょう。

Fake IPと実際のIPアドレス

Fake IPモードでは、まずアプリに対応付け用のアドレスを返し、コアがアドレスとドメインの対応を保持します。接続がコアに入った後、ドメインに基づいて処理できるため、ドメイン情報を維持しやすくなります。ただし、名前解決と接続が同じ捕捉経路を通る必要があります。アプリが対応付け用アドレスを受け取ってもコアを迂回して接続すると、失敗することがあります。クライアント終了後に古いキャッシュが残っている場合も、一時的に接続できなくなることがあります。

fake-ip-filterを使うと、一部のドメインに対応付け用アドレスを割り当てないようにできます。LAN内のデバイス検出、機器のサービス、実際のアドレスが必要なアプリなどで例外が必要になる場合がありますが、リストを長くすればよいわけではありません。よく使うドメインをすべて除外すると、想定していた名前解決経路が変わります。再現した問題に絞って必要最小限の例外を追加し、変更後は該当アプリのキャッシュを消して動作を確認してください。

Redir Hostは通常、実際のIPアドレスを返します。対応付け用アドレスを扱えない一部のケースで役立ちますが、あらゆるアプリの互換性問題が解消するわけではありません。ドメイン情報が保持されるか、システムが先に名前解決しているか、宛先アドレスが変わるかによって、ルールの動作も変わります。モードを選ぶ際は、速度の優劣で決めつけず、対象アプリと通信の捕捉方法に合わせて検証してください。

Mihomoのドメイン別名前解決設定

# Mihomoの設定例。既存のdnsオブジェクトに追加し、dnsを重複して定義しない
dns:
  nameserver-policy:
    "+.example.com":
      - 223.5.5.5
  proxy-server-nameserver:
    - 223.5.5.5

nameserver-policyでは、ドメインごとに名前解決に使うサーバーを指定できます。例は項目の階層を示すものであり、予約済みドメインに特別な処理が必要という意味ではありません。Mihomoのproxy-server-nameserverはプロキシサーバーのドメイン名を解決するための項目です。対象は別々です。Webサイトのドメインと、ノードサーバーのドメインを、どちらも「ドメインだから」と同じ名前解決処理として扱わないでください。

ノードサーバーをドメイン名で指定すると、接続を開始するためにもDNSが必要になる場合があります。そのノードを経由しなければ名前を解決できない設定では、接続開始が循環依存になります。調査するときは、まずノードのドメインが独立して利用できる経路で解決できるか確認し、その後でWebサイトの名前解決をプロキシ経由にするか検討してください。暗号化DNSの上流にドメイン名を使う場合も、初期の名前解決と接続経路を確認しましょう。アドレスを1つ置き換えただけで循環が解消したと思い込まないでください。

DNSリークテストでわかるのは、特定のテスト条件で確認できた名前解決の出口です。すべての通信に共通する結論ではありません。ブラウザーのセキュアDNS、アプリ内蔵のDoH、システムキャッシュ、LAN内のDNSが想定した経路を迂回することがあります。検証時はブラウザーの設定、コアのDNSログ、TUNの捕捉状態を個別に確認してください。Webサイトで一度テストしただけでは、実際の名前解決経路を確認したことにはなりません。

04 プロキシノードの項目とプロトコルの違い

proxiesリストには、プロキシの出口に関する具体的なパラメーターを記述します。各項目には少なくとも、プロトコル、サーバーアドレス、ポートが必要です。認証項目はプロトコルによって異なります。クライアント画面に表示されるノード名はローカルで識別するためのもので、認証情報の代わりにはなりません。ノード名をわかりやすく変えてもサーバーの場所は変わらず、サーバーが対応していないプロトコルを利用できるようにもなりません。

アドレスを確認してから認証情報を確認

# ノードの設定例。予約済みドメインと仮のパスワードでは接続できない
proxies:
  - name: "サンプル SS"
    type: ss
    server: ss.example.com
    port: 443
    cipher: aes-128-gcm
    password: "your-password"
    udp: true

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

serverにはホスト名またはIPアドレスを指定してください。プロトコル、パス、クエリパラメーターを含むWebページのURL全体を入れてはいけません。portはサーバー側の待ち受けポートです。ローカルのmixed-portと同じ値にする必要はありません。サービス提供元が指定した値を入力してください。Webサイトでよく使われるポートだからといって、すべてのノードを同じ値に変更しないでください。

Shadowsocksのcipherとpasswordはサーバー側の設定と一致させる必要があります。暗号化方式は、自由に選べる性能設定ではありません。名前の誤記やコアの非対応によって接続に失敗します。プロトコルの世代によって鍵の形式も異なる場合があるため、プロトコル名だけ変更して他の項目を流用することはできません。サブスクリプションから利用可能なノードを取得した場合は、わからない項目を自己判断で削除せず、元のパラメーターを保ってください。

TLS、SNI、証明書の検証

TLSを使うノードでは、サーバー名、証明書、トランスポート層の項目も関係します。SNIはTLSハンドシェイクでサーバー名を伝える仕組みです。直接接続時に指定するIPアドレスとは異なる場合があるため、サーバー側の設定に合わせてください。証明書エラーはパスワードの誤りとは限りません。システム時刻のずれ、名前の不一致、中間ネットワークの干渉なども考えられます。まずログのエラー種別を確認し、該当する項目を調べましょう。

skip-cert-verify: falseは証明書検証を有効にする設定です。ハンドシェイクに失敗しても、検証を無効にすることを常套手段にしないでください。サーバー名や証明書の問題を見過ごすおそれがあります。まずシステム時刻を合わせ、SNIとサービス提供元の説明を確認しましょう。サブスクリプション内の多くのノードで突然証明書エラーが起きた場合は、誤ったファイルを読み込んでいないか、認証が必要なネットワークを経由していないかも確認してください。

VMess、VLESS、Trojan、Shadowsocksなどでは、認証に使う項目が共通ではありません。ユーザーIDが必要なもの、パスワードが必要なもの、トランスポート方式やセキュリティ設定も指定しなければならないものがあります。あらゆる項目を混ぜた「万能ノード」は掲載していません。不要な項目が無視されると、かえって問題が直ったように見えることがあります。プロトコルに合った完全なノード定義を使ってください。

通信方式は両端が対応している必要がある

udp: trueは、そのノードでUDPを使う設定を示すだけです。実際に通信できるかは、プロトコル、サーバー、ネットワーク、入口の捕捉方法にも左右されます。一般的なシステムプロキシのHTTP入口では、すべてのアプリのUDP通信を自動的に捕捉できません。ゲームや音声通話に失敗する場合は、まず通信がコアに届いているかを確認し、次にノードがUDPに対応しているか調べてください。YAMLのこの行だけを何度も切り替えても解決しません。

WebSocket、gRPCなどのトランスポート層を使う場合、パス、Hostヘッダー、サービス名をサーバー側の設定に合わせる必要があります。Webページが開けてもプロキシのハンドシェイク設定が正しいとは限りません。サーバーのポートとTCP接続できても、プロトコルの認証が成功したとは限りません。ログのタイムアウト、認証エラー、ハンドシェイク中断は、それぞれ異なる段階の問題を示します。すべての項目を一度に変更せず、段階ごとに確認しましょう。

新しいプロトコルや拡張項目は、現在のコアが対応している必要があります。Clash for Windowsの旧コアにMihomoの設定を数行追加しても、機能は補えません。移行時はClash Plus、Clash Verge Rev、FlClashなどのクライアントが実際に対応する範囲を比較してください。詳しくはクライアント比較をご覧ください。ファイルを画面に読み込めても、実行するコアがすべてのノード形式を受け付けるとは限りません。

最後に、ノード名が一意か確認してください。同じ名前のノードが複数あると、参照先が不明確になる場合があります。サブスクリプションの更新で名前や順序が変わることもあります。手動で管理する場合、名前には用途だけを記載し、パスワード、サブスクリプションURL、個人アカウントは含めないでください。設定を共有して問題を相談する際は、認証情報と非公開のサーバー情報を削除しましょう。項目の構造とエラー表示が残っていれば、書式の問題かプロトコルの対応範囲かを判断するのに十分です。

05 プロキシグループの選択とヘルスチェック

プロキシグループはルールとノードの間に位置します。ルールから安定したグループ名へ接続を渡し、グループ内で実際の出口を選ぶ仕組みです。ノードを切り替えるたびにルールを書き直す必要がなくなります。この関係を理解してからグループを設計しましょう。手動選択用と自動検出用を分け、特定の用途には専用グループを用意できますが、すべてのWebサイトに同じメンバーのグループを作る必要はありません。

手動選択と自動選択を分ける

# 前章で定義した2つのサンプルノードを使用
proxy-groups:
  - name: "プロキシ選択"
    type: select
    proxies:
      - "自動選択"
      - "サンプル SS"
      - "サンプル Trojan"
      - DIRECT

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

selectは手動選択用のグループです。通常、クライアント画面でメンバーを直接切り替えられます。メンバーにはノードだけでなく、別のプロキシグループやDIRECTなどの組み込み出口も指定できます。上の例では自動選択グループも選択肢に加えています。普段は自動検出を使い、必要に応じて特定のノードに固定できます。名前は例なので、変更した場合はルール側の参照も合わせてください。

url-testはテスト用リクエストで候補の出口を比較します。intervalは通常、秒単位で指定するチェック間隔です。toleranceはわずかな差による頻繁な切り替えを抑えるための項目ですが、意味と単位は利用中のコアのドキュメントで確認してください。一般的な実装では、上の例の許容値はミリ秒単位です。画面を頻繁に更新させるためにチェック間隔を短くしすぎないでください。ヘルスチェック自体も接続と通信を発生させます。

テストに成功しても実際の用途で使えるとは限らない

テスト先から成功応答が返るということは、その時点で、その出口から該当アドレスへのリクエストが完了したことを示します。動画、ダウンロード、ゲーム、業務システムでも同じ結果になるとは限りません。遅延の値には接続確立、ハンドシェイク、応答時間が影響しますが、継続的な帯域幅を直接示すものではありません。テストが速いノードでも、混雑やパケットロス、接続先の制限によって実際の用途では性能が出ない場合があります。

テスト先には、安定していて想定どおりの応答を返すアドレスを選び、実際の用途でも確認してください。すべてのノードでテストに失敗する場合は、サーバーがすべて停止したと判断する前に、テスト先への接続や名前解決に問題がないか調べましょう。数値と実際の使用感の違いについては、ノードの遅延テストの仕組みを参照してください。

フェイルオーバーとロードバランシング

fallbackは通常、候補を指定順に確認して利用可能な出口を選びます。主回線と予備回線を使い分ける用途に向いており、遅延が最小の出口を自動選択する機能とは異なります。load-balanceは実装が対応する方式で接続を振り分ける機能です。複数ノードの帯域幅が合算され、1つの接続が速くなるわけではありません。ログイン状態や出口のIPアドレスに敏感なWebサイトでは、振り分け方法がセッションの安定性に影響しないか確認してください。

プロキシグループのネストは、参照の向きを明確に保ちましょう。「業務」グループから「プロキシ選択」グループを参照し、そこから具体的なノードを選ぶ構成にできます。2つのグループが互いを参照する循環は作れません。グループが見つからない、または循環依存のエラーが出た場合は、ルールからノードまでの一方向の経路を書き出し、間接参照を展開してください。グループが増えるほど調査が複雑になるため、最初は用途を説明できる少数のグループに抑えましょう。

自動チェック用グループにDIRECTを含めるかどうかは、用途に合わせて決めてください。テストに成功して選ばれた場合、通信は直結となり、プロキシ経由ではなくなります。プロキシを使う目的のグループでは、直結のテスト値が低いからといって候補に加えるべきではありません。チェック間隔の細かな調整より、候補をどう選ぶかのほうが最終的な動作に大きく影響します。

クライアントがプロキシグループの選択状態を記憶していると、再読み込み後もリストの先頭に戻るとは限りません。ルールが正しく適用されているのに想定外の出口を使う場合は、グループ内で実際に何が選ばれているかを開き、ネストをたどって最終ノードまで確認しましょう。一番外側のグループ名だけでは、現在の経路を判断できません。サブスクリプション切り替え後に同名グループの選択を復元する仕組みも、クライアントの状態保存設定とあわせて確認してください。

プロバイダーからノードを読み込む場合、プロキシグループのuseでノードの集合を参照できます。詳しくは第7章を参照してください。この構成では、ノードのヘルスチェックとグループ内のテストが同時に行われる場合があるため、過度に頻繁なチェックを重複して設定しないようにしましょう。グループを変更した後は、設定が読み込めることを確認し、画面で一度手動切り替えを行ってから、新しい接続の出口を調べ、意図しないメンバーが参照されていないか確認してください。

06 ルールの書式と照合順序

ルールモードでは通常、ルールを上から順に確認し、一致したルールの転送先に接続を渡します。具体的な例外を先に、広い範囲を対象とするルールを後に記述し、最後にデフォルトのルールを置きましょう。ルール一覧は、最も具体的な条件を自動で優先するルーティングテーブルではありません。先に広いルールに一致すると、後ろの詳細なルールはその接続に適用されないことがあります。

明確な例外を先に、最後にフォールバックを記述

# 既存の「プロキシ選択」プロキシグループを使用
rules:
  - DOMAIN,portal.example.com,DIRECT
  - DOMAIN-SUFFIX,example.com,プロキシ選択
  - DOMAIN-KEYWORD,example,プロキシ選択
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,プロキシ選択

DOMAINは指定したドメインに完全一致し、DOMAIN-SUFFIXはそのドメインとサブドメインに一致します。DOMAIN-KEYWORDは、ドメイン名にキーワードが含まれるかを判定します。キーワードによる照合範囲は想定より広いことがあり、名前が似ている別用途のサービスまで一致する場合があります。対象のドメインがわかっている場合は、説明しやすさを優先し、完全一致またはサフィックスのルールを使いましょう。

この例では、ポータルのドメインを直結する例外を、ドメインサフィックスのルールより前に置いています。そのためポータルへの接続はプロキシ選択に振り分けられません。2行を入れ替えると、サフィックスのルールが先に一致し、例外が機能しなくなります。「ルールを書いたのに反映されない」場合は、同じルールを一覧の末尾に足し続けるのではなく、まず上にある一致ルールを確認してください。

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

IP-CIDRは、接続先のIPアドレスが指定したネットワーク範囲に属するかを判定します。末尾のno-resolveは、このアドレスルールのためにドメインをIPアドレスへ変換しないという意味です。接続に宛先アドレスがすでに含まれる場合は、引き続きアドレス照合が行われることがあります。DNS全体を無効にする設定でも、ドメインルールを無効にする設定でもありません。LAN内アドレスの例外では、不要な名前解決を避けるためによく使われます。

GEOIPはアドレスデータベースを使って、対象IPアドレスの地域を判定します。ドメインの登録地、Webページの言語、サービス会社の所在地で判定するものではありません。複数地域のCDNを使うWebサイトでは、同じドメインでも異なる地域のアドレスが返る場合があります。業務上、明確に通信経路を指定したい場合は、地理的なアドレスデータベースに分類を任せるのではなく、意図がわかるドメインルールを使いましょう。

MATCHは最後のフォールバックとして、通常はリストの末尾に置きます。前のルールに一致しない接続にも、明確な出口を指定できます。一覧の途中に置くと、その後のルールは通常適用されません。デフォルトでプロキシと直結のどちらを使うかは用途によって異なります。例では「プロキシ選択」を指定していますが、すべてのネットワーク環境に適した既定動作とは限りません。

ルールの適用は新しい接続で確認する

ルールを変更しても、確立済みの長時間接続は以前の出口を使い続けることがあります。Webページが既存の接続を再利用したり、リソースをキャッシュしたりする場合もあります。検証時はリクエストを新たに開始し、必要であれば古い接続を閉じてから、Connectionsまたはログで適用されたルール、プロキシグループ、最終出口を確認してください。ページを一度更新しただけでルールが無効だと判断せず、グループ名だけでなく、その中で選択されているノードも確認しましょう。

プロセスルールは、OSとコアがプロセスを識別できるかどうかに左右されます。Windowsでは権限、通信の捕捉方法、アプリの構造が影響します。ブラウザーの子プロセスやシステムサービスの名前が想定と異なることもあります。ルールを書く前に、接続履歴に表示された実際のプロセス情報を確認し、利用中のコアが対応する書式を使ってください。複数のOSで設定を共有する場合は、ローカルのパスを固定するよりドメインルールのほうが管理しやすいでしょう。

ルールが増えすぎたら、まず用途ごとに整理し、外部ルールセットに任せるか検討してください。LAN内の例外、特定サービスの例外、通常の振り分け、最後のフォールバックを明確に分けましょう。出所が不明なルールを複数そのまま連結しないでください。リストが長くなっても網羅性が高まるとは限らず、重複や競合によって接続がどのルールに一致したか判断しにくくなります。

特定のアプリだけでルールが機能しない場合は、通信の入口を確認してください。接続がコアに届いていなければ、ルールが正しくても処理されません。アプリが先にドメインをIPアドレスへ変換すると、ドメイン照合に影響する場合もあります。入口、名前解決、照合、出口を切り分けて考えると、曖昧なルールを増やすより早く原因を特定できます。

07 ノードサブスクリプションと外部ルールセット

プロバイダーを使うと、頻繁に変わる内容をメイン設定から分離できます。ノードプロバイダーはノードの集合を、ルールプロバイダーは照合条件の集合を管理し、メイン設定には参照先とプロキシグループの関係を記述します。ノードを更新するときにローカルの用途別グループを書き直す必要がなく、ルールを更新するときも設定全体を再ダウンロードせずに済みます。一方、ダウンロード、解析、キャッシュ、参照という複数の依存関係が増えます。メイン設定が読み込めただけで、すべて利用可能だと判断しないでください。

設定全体のサブスクリプションとノードプロバイダーは別物

# ローカルノードプロバイダーの例。対応するファイルを先に作成する
proxy-providers:
  local-nodes:
    type: file
    path: ./providers/local-nodes.yaml
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 600

proxy-groups:
  - name: "サブスクリプション選択"
    type: select
    use:
      - local-nodes

上の例では、説明用の設定に個人のサブスクリプションURLを書かないよう、ローカルファイルを使っています。このファイルは、利用中のコアが読み込める形式で、ノードプロバイダーに必要なデータ構造を含んでいる必要があります。相対パスは通常、読み込み先または作業ディレクトリを基準にします。クライアントが独自の作業ディレクトリを指定することもあるため、ログやファイル管理画面で場所を確認し、メイン設定の保存場所だけから推測しないでください。

# providers/local-nodes.yamlの内容例
proxies:
  - name: "ローカルのサンプル SS"
    type: ss
    server: ss.example.com
    port: 443
    cipher: aes-128-gcm
    password: "your-password"

設定全体のサブスクリプションには、ポート、DNS、プロキシグループ、ルールが含まれる場合がありますが、ノードプロバイダーに必要なのは通常ノードの集合だけです。サブスクリプションURLをそのままproxy-providersに指定すればコアが理解すると考えてはいけません。サービス提供元が出力する形式と、利用中のコアの対応状況を確認してから、設定全体を読み込むか、ノードの集合として参照するかを決めましょう。形式が合わない場合、メイン設定のエラーではなく、プロバイダーが空になることがあります。

ルールプロバイダーはルール形式ごとに設定

# Mihomoのローカルルールプロバイダー設定
rule-providers:
  local-direct:
    type: file
    behavior: classical
    format: yaml
    path: ./rules/local-direct.yaml

rules:
  - RULE-SET,local-direct,DIRECT
  - MATCH,サブスクリプション選択

# rules/local-direct.yamlの内容例
payload:
  - DOMAIN-SUFFIX,example.com
  - IP-CIDR,192.168.0.0/16,no-resolve

このルールファイルでは、payloadでルール項目をまとめ、実際の出口はメイン設定のRULE-SETで指定します。通常のrulesリストをそのまま入れたり、各項目にプロキシグループを追加したりしないでください。ルールセットは照合対象を定義し、メイン設定はそのルールセットを出口につなぎます。この分担により、同じルールを異なる環境で再利用しやすくなります。

behaviorの値はルールの内容に合わせる必要があります。ドメインの一覧、IPアドレスの一覧、従来形式のルール項目は、それぞれ書式が異なります。従来形式のルールを単なるドメイン一覧として扱うと、解析エラーや意図しない照合が起きることがあります。Mihomoが対応するルール形式でも、旧コアが対応するとは限りません。共有用の設定を作る場合は、自分のクライアントで一度試すだけでなく、対象のコアが共通して受け付ける形式を選びましょう。

更新に失敗したら4段階で確認

リモートプロバイダーには、アクセス可能なダウンロードURL、更新間隔、キャッシュ先も必要です。まずネットワークリクエストが成功したか、次に応答が想定するYAMLまたはルールデータか、さらにコアが解析できるか、最後にプロキシグループやルールから実際に参照されているかを確認します。Webページにログイン画面、サブスクリプションの利用上限、エラーが返った場合は、HTTP応答があっても使える設定を取得できたとは限りません。

更新間隔は通常秒単位で設定します。頻繁に再読み込みしても問題は解決しません。サーバー側がリクエスト数を制限していたり、複数のクライアントから同時に更新して制限に達したりする場合があります。まず使えるキャッシュを残し、手動で一度更新してエラーを確認してください。原因がわからないままキャッシュをすべて消すと、一時的なダウンロード障害が、利用可能なノードを失う問題に変わるおそれがあります。

サブスクリプションURLには個人用の認証情報が含まれることが多いため、パスワードと同じように管理してください。スクリーンショット、ログ、エクスポートした実行時設定にURL全体が含まれる場合があります。相談するときは予約済みのドメインに置き換え、応答ステータス、解析エラー、関連項目の構造を残しましょう。出所のわからないオンライン変換ツールに個人用URLを渡したり、他人のサブスクリプションURLを公開設定の例に使ったりしないでください。

ノード集合を更新すると、名前の変更によって手動選択やフィルター条件に影響することがあります。プロバイダーの項目数が想定どおりか、プロキシグループに選択候補が残っているかを確認してから、新しい接続の出口を調べましょう。「ダウンロードは成功したのにグループにノードがない」場合は、参照名、データ形式、フィルター条件を重点的に確認してください。エラー内容はサブスクリプション更新に関するFAQも参考にして、順に切り分けられます。

08 上書き、統合、実行時の検証

サブスクリプションはリモートの内容を更新し、ローカルの上書き設定は個人の設定を保持します。両者の境界が曖昧だと、更新のたびにルールが消えたり、元ファイルの変更が画面の設定で上書きされたりします。まずクライアントの設定管理画面を開き、対象がサブスクリプションの元データ、上書き用の設定、最終的な実行ファイルのどれか確認してから編集場所を決めましょう。Clash for WindowsのMixinと、他のクライアントにある統合・スクリプト機能は、名称だけで同じ仕組みだと判断できません。

設定の統合方法はクライアントの実装を確認する

YAMLはデータを記述する形式であり、複数ファイルの統合方法は定めていません。クライアントによってはマッピングを再帰的に統合し、リストはそのまま置き換えたり、ルールを前後に挿入する専用機能を用意したりします。似た名前の「統合」ボタンでも、ツールごとに動作が異なります。短いrulesリストを適用する前に、元のルールへ追加するのか、リスト全体を置き換えるのかを確認してください。確認せずに使うと、自分で追加した2件だけが残ることがあります。

# 上書きの設定例。対応する統合方法をクライアントがサポートする場合のみ使用
mixed-port: 7890
allow-lan: false
log-level: info

dns:
  ipv6: false

上の例は、ローカルの入口と一部の名前解決オプションを固定するもので、単独で実行できる完全な設定ではありません。独立したファイルとして読み込むと、他のネットワーク設定が不足します。DNSオブジェクト全体を浅く統合して置き換えると、既存の上流サーバーが削除されるおそれもあります。まずコピーに適用して生成結果を確認し、既存のnameserver、ノード、プロキシグループ、ルールなどが残っていることを確かめてください。

個人用ルールを追加する場合は、クライアントが明示的に用意しているルールの挿入位置を使いましょう。用途別の例外は前に置き、最終的なフォールバックは末尾に残します。既存のMATCHより後ろに追加しても、意図どおりには動作しません。リストの安定した統合機能がないクライアントでは、サブスクリプション全体のルールを繰り返し編集するのではなく、ローカルのメイン設定からノードプロバイダーを参照する方法を検討してください。

ファイル、画面表示、実行状態を区別する

設定の反映までには、サブスクリプションのダウンロード、ローカル設定の適用、スクリプトの実行、実行ファイルへの書き込み、コアへの再読み込み通知など、複数の段階がある場合があります。処理順序はクライアントによって異なるため、画面の設定が必ず最後に反映されるとは限りません。「保存したのに変わらない」場合は、まず最終的な実行設定を確認し、次に再読み込みが成功したか、最後に古い接続が以前の状態を使い続けていないかを調べましょう。

Mihomoのコマンドライン版を使っている場合は、次のテストコマンドで設定を検証できます。コマンド内のファイル名は実際のものに置き換え、作業ディレクトリには関連するプロバイダーファイルも含めてください。テストに成功すれば、そのコアが設定を受け付けることは確認できますが、ノード認証、リモートからのダウンロード、実際の通信まで成功するとは限りません。旧環境では対応するコアのヘルプを確認し、実行ファイル名をそのまま使い回さないでください。

mihomo -t -f config.yaml

検証は段階的に進めます。まず構文と参照先、次に入口の待ち受け、続いてDNSとプロバイダー、最後に実際の接続を確認してください。エラーに行番号が示されていても、その行より上のインデント、引用符、リストの境界も調べましょう。パーサーがエラーを検出した行が、最初に誤りを記述した場所とは限りません。1か所直すたびに再テストし、使用中の設定へ推測に基づく変更をまとめて加えないでください。

復元用のバックアップを取り、実際の通信を確認

本格的に変更する前に、現在使えている設定をエクスポートし、有効な上書き項目とプロキシグループの選択状態を記録してください。変わり続ける可能性のあるサブスクリプションURLだけに頼らず、復元可能なローカルコピーを保管しましょう。変更後にネットワークが切断されたら、最後に使えた状態へ戻してください。接続がないまま新しい項目を追加し続ける必要はありません。バックアップにも個人の認証情報が含まれる場合があるため、安全な場所に保管し、公開スペースへアップロードしないでください。

プロキシ設定に対応したツールでリクエストを実行すると、ポートを検証できます。ただし、入口への接続と宛先へのアクセス成功は別々に確認してください。Windowsで次の例を実行する際は、ターミナルによって同名のエイリアスが使われるのを避けるため、curl.exeを明示して実行します。宛先には例示用の予約済みWebサイトを使っています。現在のネットワークからアクセスできない場合は、エラーがどの段階で発生したかを確認してください。コマンドの終了結果だけで、すべてのノードの状態を判断しないようにしましょう。

curl.exe -I --proxy http://127.0.0.1:7890 https://example.com/

次に接続履歴で宛先、一致したルール、最終出口を確認し、直結が必要な用途とプロキシが必要な用途をそれぞれテストしてください。TUNを検証する際は、システムプロキシを自動で読み取らないアプリも使い、捕捉範囲が想定どおりか確認します。複数のクライアントを同時に動かしてシステムプロキシ、仮想ネットワークアダプター、待ち受けポートを取り合わないようにしてください。動作が不安定な場合は、ネットワークを捕捉する方法を1つだけ有効にして確認しましょう。

管理しやすい設定なら、次の4点を説明できます。通信の入口はどこか、ドメインをどこで名前解決するか、どのルールで経路を選ぶか、最終的にどの出口を使うか。変更はこのうち1つの段階に絞り、用途をコメントに残し、不要になった一時的な例外を削除しましょう。サブスクリプションの更新、システムの切り替え、クライアントの変更後も、同じ経路をたどって問題を調べられます。設定をさらに長く作り直す必要はありません。