Clash YAML設定ガイド

1. YAMLの構造と設定が反映される仕組み

Clashの設定ファイルは、上から順に実行するスクリプトではなく、階層構造を持つデータです。トップレベルの項目で、リスニング方法、プロキシの参照元、プロキシグループ、ルールを定義します。カーネルはファイル全体を読み込んで、対応するオブジェクトを作成します。この違いを理解しておきましょう。ファイル末尾にルールを書いても、そのルールが最後に作成されるわけではありません。判定順を左右するのは、rulesリスト内の並び順です。ファイル名や拡張子はさまざまで、拡張子が.ymlの場合もあります。クライアントが実際に読み込む設定は、現在選択されているプロファイルで確認してください。

マップ・リスト・文字列を見分ける

コロンは項目名と値を区切る記号で、通常はコロンの後に半角スペースを入れます。ハイフンはリスト項目を表し、インデントは親子関係を示します。インデントは半角スペース2つに統一し、Tabは使わないのがおすすめです。次の例のproxiesはプロキシグループ内の候補であり、トップレベルのプロキシノード一覧ではありません。同じ名前でも階層が異なります。解析エラーが出たら、該当行だけでなく、その前後のインデントも確認してください。

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

proxy-groups:
  - name: "出口選択"
    type: select
    proxies:
      - DIRECT

rules:
  - MATCH,出口選択

これは構造を理解するための、直結のみを行う設定例です。混合プロキシポートを開きますが、すべての接続は最終的に直結し、リモートプロキシ機能はありません。最初から複雑なルールを読み込むより、この設定でカーネルがファイルを読み込めるか確認するほうが、構文上の問題を切り分けやすくなります。リスト内のDIRECTは組み込みの出力先なので、別途定義する必要はありません。プロキシグループ名はルールで参照する名前と完全に一致させてください。スペース、記号、大文字・小文字の違いでも参照に失敗することがあります。

サブスクリプションの元データと実行時設定を区別する

Clash PlusやClash Verge Revなどのクライアントでは、リモートサブスクリプションは設定の元データとして使われることが多く、ポート設定、TUNの有効・無効、全体拡張、選択中のサブスクリプションに対する上書きが重ねられ、カーネル用の設定が生成されます。そのため、一時的に生成されたファイルを直接編集しても、恒久的な変更にはなりません。サブスクリプションの切り替え、設定の保存、再起動などで再生成される可能性があります。編集中のファイルがサブスクリプションのコピーなのか、永続的な上書きなのか、確認用の実行結果なのかを先に確かめてください。

一般的なYAMLファイルとして構文検査に通っても、mihomoが求める項目の形式を満たすとは限りません。たとえばproxy-groupsを文字列にすると、汎用パーサーでは受け付けても、カーネルが必要とするのはリストです。一方、構文と構造が正しくても、ノードに接続できるとは限りません。ドメイン名、認証情報、接続先サービスは別途確認が必要です。トラブル対処では「読み込める」「起動できる」「接続できる」を分けて考えると、関係のない項目を何度も変更せずに済みます。

保存前に確認する3つのポイント

1つ目は、UTF-8で保存することです。エディターによる文字コード変換で、日本語のグループ名が文字化けするのを防げます。2つ目は、コロンとスペース、シャープ記号、特殊な記号を含む文字列を引用符で囲むことです。コメントは引用符の外にあるシャープ記号から始まり、値には含まれません。3つ目は、同じ階層で同じ名前のキーを重複させないことです。重複キーの扱いはパーサーによって異なり、エラーになる場合もあれば、最後の値だけが残る場合もあります。これを信頼できるマージ方法として使わないでください。

変更前に、正常に動作している設定を保存し、テスト用の設定にコピーしてから編集してください。単体のmihomo実行ファイルがある場合は、mihomo -t -f config.yamlで設定を検査できます。クライアントと同じカーネルを使い、相対パスの参照先がどのディレクトリかも確認してください。検査に通った後も設定を再読み込みし、ログで現在の設定が受理されたことを確認しましょう。サブスクリプションの取得内容に問題がある場合は、サブスクリプションの解析失敗チェックリストも参照してください。

2. 共通項目：リスニングポートと動作モード

共通項目では、カーネルがローカル接続を受け付ける方法と、接続後にルールに基づいて出力先を選ぶかどうかを設定します。これらはWindowsのシステムプロキシ設定の代わりにはなりません。カーネルがポートをリッスンしているのは、アプリから接続できる状態というだけです。アプリから通信が届くかどうかは、クライアントのシステムプロキシ設定、アプリ独自のプロキシ設定、TUNによる取り込みなどに左右されます。ブラウザーの挙動が変わらない場合、ノードのプロトコルをすぐに変更せず、まず通信の入口を確認してください。

port・socks-port・mixed-port

「設定を一通りそろえる」ために、3種類のプロキシポートをすべて有効にする必要はありません。一般的なデスクトップ用途なら、混合ポートを1つ設定すれば十分です。ポート番号は有効な範囲内で、他のプロセスと重複せず、アプリ側の設定と一致していれば変更できます。ここで使う7897は例であり、すべてのクライアントの初期値ではありません。変更した場合は、以前のポート番号を手動設定しているブラウザー拡張、コマンドラインツール、ダウンローダーも更新してください。

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

この設定は、まずPC上のアプリだけからアクセスする場合に適しています。allow-lan: falseは、LAN内のデバイスからの接続を許可しない設定です。ループバックアドレスを明示すれば、用途がこのPC内に限定されます。スマートフォンからPCのプロキシを使う場合は、関連する制限を変更し、PCのLANアドレスを使ったうえで、信頼できるネットワークの範囲内でWindowsファイアウォールを設定してください。トラブル対処のためにファイアウォール全体を無効にしたり、ローカルプロキシのポートをインターネットに公開したりしないでください。

ルールモードとプロキシグループは別の設定

mode: ruleでは、接続がルールに順番に照合されます。globalはグローバルな出力先の選択を使い、directは接続を直接行います。グローバルモードに切り替えても、既存のルールは変更されず、現在のルーティング方法が変わるだけです。ルールモードでは、ルールが選ぶグループの出力先が直結の場合もあります。そのため、ルールモードであることだけでは、リモートプロキシを経由しているとは判断できません。実際に一致したルールと、最終的な出力先まで確認してください。

クライアント画面のモードボタンが、実行時にファイルの値を上書きしたり、設定の再生成時に値を書き戻したりする場合があります。再起動のたびに別のモードへ戻る場合は、サブスクリプションを繰り返し編集するのではなく、クライアントの永続設定を確認してください。トラブル対処のため、log-levelを一時的にdebugに上げ、作業後にinfoへ戻す方法もあります。デバッグログにはドメイン名や接続の詳細が記録される場合があるため、共有前にサブスクリプションURL、認証情報、個人のアクセス履歴を削除してください。

トップレベルのIPv6と管理インターフェース

トップレベルのipv6は、カーネルのIPv6関連機能を制御します。後述するDNS内の同名項目とは階層が異なります。この設定を無効にしても、WindowsのネットワークアダプターでIPv6が無効になるわけではなく、すべてのアプリの通信が取り込まれている証明にもなりません。IPv6が必要なネットワークでは、入口、ルーティング、名前解決、ノードの対応状況をまとめて確認し、経路の不一致を無効化スイッチで隠し続けないようにしてください。

external-controllerは管理用インターフェースであり、ブラウザー用のHTTPプロキシポートではありません。通常はクライアント側でアドレスやアクセス認証が管理されるため、サブスクリプション内で安易に変更しないでください。接続パネルが突然表示されなくなってもプロキシが使える場合は、管理インターフェースの切断とプロキシのリスニング停止を区別します。ポートの使用状況は、PowerShellでGet-NetTCPConnection -LocalPort 7897 -ErrorAction SilentlyContinueを実行し、プロセス情報と照らし合わせてください。正体のわからないシステムプロセスを終了しないでください。

3. プロキシノードとサブスクリプションプロバイダー

ノード定義では、リモートプロキシサービスへの接続方法を指定します。トップレベルのproxiesは通常、ノードのリストで、各項目に名前、プロトコル、サーバーアドレス、ポート、プロトコル固有の認証情報を記述します。名前はプロキシグループから参照するためのローカルな識別子で、サーバーアドレスになるわけではありません。画面上で区別しやすいようノード名を変更する場合は、そのノードを明示的に参照するグループも変更してください。サブスクリプション更新で名前が再生成されるなら、プロバイダーや安定したグループ構成で管理するほうが適しています。

共通項目とプロトコル固有の項目

serverにはドメイン名またはIPアドレスを指定し、portには接続先サービスの実際のリスニングポートを設定します。共有リンク内の数字を任意に選んで使えるわけではありません。認証方法はプロトコルによって異なります。Shadowsocksでは通常、暗号化方式とパスワードを使い、TrojanではパスワードとTLSが関係します。VLESSには独自の識別情報や伝送方式の設定があります。typeを書き換えるだけで別のプロトコルに変換することはできません。サーバー側も一致する方式に対応している必要があります。

proxies:
  - name: "ローカルSOCKS入口"
    type: socks5
    server: 127.0.0.1
    port: 1080
    udp: false

proxy-groups:
  - name: "出口選択"
    type: select
    proxies:
      - "ローカルSOCKS入口"
      - DIRECT

この設定例ではSOCKS5の実際の項目を使っていますが、ポート1080で動作するSOCKSサービスがローカルにある場合に限り、通信を中継できます。リモートノードの代わりにはならず、mihomo自身の混合ポートを接続先に指定すると、ループが発生するおそれがあります。サンプルでは架空の認証情報を使わず、データ構造を説明するためにローカルアドレスを指定しています。実際のノード設定はサービス提供元から取得し、各項目を確認してください。サンプルの認証情報を自分の設定に流用しないでください。

udp: trueは、そのノードで該当するUDP通信を扱えるようにする設定です。もともとUDPに対応していないサービスが、この設定だけで対応するわけではありません。プロトコルの実装、サーバー設定、中間ネットワーク、通信の入口が結果に影響します。Webサイトは表示できるのに音声通話やゲームで問題が起きる場合は、まずアプリが使う通信方式を確認し、そのノードが対応できるかを調べてください。Webページが開けるだけで、通信経路全体が正常だと判断しないようにしましょう。

proxy-providersはプロキシの一覧を取得する仕組み

ノード一覧を個別に更新する場合は、proxy-providersを利用できます。プロバイダーの内容は通常、proxiesリストを含むプロキシ一覧です。任意の完全な設定ファイルのURLを、同じ形式として扱わないでください。HTTPプロバイダーはリモートから内容を取得し、fileプロバイダーはローカルファイルを読み込みます。プロバイダー自体はプロキシグループではなく、グループ側でuseを使って参照します。以下では関係を説明するためにローカルファイルを使っています。パスはカーネルが読み込みを許可された設定ディレクトリ内に置いてください。

proxy-providers:
  local-pool:
    type: file
    path: ./providers/local-pool.yaml

proxy-groups:
  - name: "サブスクリプション出口"
    type: select
    use:
      - local-pool
    proxies:
      - DIRECT

対応するlocal-pool.yamlにはノードのリストを記述し、さらにproxy-providersを重ねて記述する必要はありません。相対パスの基準は、実行時のディレクトリまたはカーネルの作業ディレクトリになるのが一般的で、エディターで開いているフォルダーとは限りません。ファイルが見つからない場合は、クライアントに表示されている設定ディレクトリとカーネルログを確認してください。ファイルをむやみにシステムディレクトリへ移したり、パス制限を回避するためにディスク全体へのアクセス権を広げたりしないでください。

接続エラーは段階ごとに確認する

まずサーバーのドメイン名を解決できるか、次に接続先ポートへ到達できるかを確認し、その後に認証情報、TLSのサーバー名、伝送パラメーターを確認します。TLS証明書の検証に使う名前は、接続先アドレスと同じとは限りません。サーバーの指定に従ってください。証明書エラーが出たら、証明書の検証を無効にするのではなく、システム時刻、証明書チェーン、名前を確認します。接続タイムアウトと認証拒否は、問題が起きている段階が異なります。ポートを何度も変えるより、ログに表示されるエラーの種類を確認するほうが有効です。

サブスクリプションURLにはアクセス用の認証情報が含まれる場合があります。スクリーンショット、ログ、公開の質問には完全なURLを載せないでください。クライアントを変更する前にサブスクリプションの取得元を控え、クライアント一覧から対応するプラットフォームを選びます。Clash Plusを第一候補として案内しており、Clash Verge Revなども選べます。GUIクライアントによって拡張項目の扱いは異なるため、移行時はカーネルの対応範囲を確認してください。項目の由来を知るには、mihomoとオリジナルカーネルの違いも参考になります。

4. プロキシグループ：選択・速度テスト・フォールバック

プロキシグループは、ルールと個々のノードをつなぐ役割を持ちます。ルールがグループを指定し、グループがノードを選ぶ構成にできます。また、グループから別のグループを参照して、階層的な出力先を作ることも可能です。こうしておけば、ノード一覧を更新するたびにすべてのドメインルールを変更せずに済みます。グループ名は短く、用途が分かる安定した名前にしましょう。たとえば「仕事用出口」「メディア用出口」などです。名前自体に特別な動作はなく、選択方式はtypeと関連項目で決まります。

selectは手動で選びたい場合に適する

selectは手動選択型のグループです。クライアント画面で使用する候補を選びます。候補にはノード、別のグループ、組み込みの出力先であるDIRECTなどを指定できます。初回読み込み時にどの候補が選ばれるかは、クライアントが選択履歴を保存するかどうかにも左右されます。リストの先頭だけを見て、現在の出力先を判断しないでください。設定を変更した後は、プロキシ画面で実際の選択状態を確認しましょう。特に、直結、古いノード、削除済みの候補を選択した履歴がある場合は要確認です。

proxy-groups:
  - name: "自動フォールバック"
    type: fallback
    proxies:
      - "ローカルSOCKS入口"
      - DIRECT
    url: https://www.gstatic.com/generate_204
    interval: 300

  - name: "出口選択"
    type: select
    proxies:
      - "ローカルSOCKS入口"
      - "自動フォールバック"
      - DIRECT

この設定例は、前の章で定義したローカルノードを参照しており、単独では設定ファイル全体の代わりになりません。fallbackは候補を順番に確認し、利用可能な出力先を選びます。フォールバックの動作を説明するため、直結は最後に置いています。リモートプロキシが切断されたときに通信を停止したい場合は、DIRECTをフォールバックグループに含めないでください。接続可能性とプライバシーの目的は別です。フォールバックに成功しても、利用可能な候補に切り替わったことを示すだけで、以前と同じ経路が保たれるとは限りません。

url-testとfallbackでは判定方法が異なる

url-testはテスト結果に基づいて候補を選ぶため、応答の速い出力先を自動選択する用途に向いています。fallbackは、候補の順序と利用可能かどうかを重視します。intervalの単位は秒で、テスト間隔を表し、個々の通信のタイムアウトではありません。toleranceは小さな差による頻繁な切り替えを抑えるために使えますが、実際の通信遅延を保証する項目ではありません。グループ内の候補を切り替えても、影響するのは通常、新しい接続です。既存の接続はすぐに移行しない場合があります。

速度テスト用のURLには、期待する応答を安定して返すHTTPSアドレスを使ってください。例にあるアドレスはテスト対象であり、サイトが外部リソースとして依存するものではありません。テスト対象へ接続できても、すべてのWebサイトへ接続できるとは限りません。逆にテスト先がブロックされると、正常なノードも異常と判定される場合があります。1回のテスト結果で回線の帯域を判断したり、テストの所要時間をダウンロード速度とみなしたりしないでください。トラブル対処では同じURLを手動で開き、ログと照らし合わせて、テストがどのノードを経由したか確認しましょう。

グループの参照は一方向にする

グループから別のグループを参照できますが、循環参照は作れません。たとえば「出口選択」が「自動選択」を参照し、「自動選択」が再び「出口選択」を参照しても、判断が賢くなるわけではなく、無効な依存関係になります。プロバイダーはuseで、明示的なノードはproxiesで追加します。必要に応じて組み合わせることもできます。候補一覧が突然空になった場合は、フィルター条件が厳しすぎないか、プロバイダーの更新が成功しているか、設定の上書きでグループ名が置き換わっていないかを確認してください。

ロードバランシングは、1つのダウンロード接続を複数の回線に分けて速度を合算する機能ではありません。振り分け方式によっては、同じサービスの接続ごとに異なる出口を使い、ログイン認証やセッションに問題が起きることがあります。業務アカウント、決済、接続元アドレスの固定が必要なサービスには、単一の出口を明示的に選ぶ方法が適しています。一般的なデスクトップ設定では、手動選択グループを1つと、分かりやすい階層を少数だけ使うほうが、似た名前のグループを大量に重ねるより管理しやすく、接続履歴から実際の経路も追跡できます。

5. ルール構文と上から順に行う判定

ルールモードでは通常、mihomoはrulesリストを上から順に照合し、最初に一致したルールで指定された出力先を使います。そのため、ルールの内容だけでなく配置も重要です。広い範囲に適用される直結ルールを先に置くと、後続の詳細なドメインルールが適用されない場合があります。独自ルールを追加する際は、ドメイン、宛先IP、プロセス、その他のどの属性を判定するのかを先に決め、適切なルール種別を選んでください。似た文面をそのままコピーするだけでは不十分です。

ドメインルールに完全なURLは書かない

DOMAINはドメインとの完全一致、DOMAIN-SUFFIXはドメインとそのサブドメイン、DOMAIN-KEYWORDはキーワードによる一致に使い、通常は後者ほど広い範囲に適用されます。値にはhttps://、パス、クエリーパラメーターを含めません。一般的なドメインルールでは、Webアドレス内のパスを使った振り分けはできません。同じサイトでもログイン、画像、APIで異なるドメインを使う場合があります。アドレスバーに表示されたメインドメインだけで判断せず、実際の接続を確認してください。

rules:
  - DOMAIN,intranet.example.com,DIRECT
  - DOMAIN-SUFFIX,example.org,出口選択
  - 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
  - MATCH,出口選択

例では、実在のサービスを示さないドキュメント用ドメインを使っています。「出口選択」はプロキシグループに定義しておく必要があります。最後のMATCHは、それ以前のルールに一致しなかった接続を受けるフォールバックルールで、通常は末尾に置きます。その前にあるプライベートアドレスのルールは、LAN内への直結を説明するためのものです。企業ネットワークでは特定のトンネル経由が必要なセグメントもあるため、実際のネットワークに合わせて確認してください。プライベートアドレスだから必ず直結できるとは限りません。

no-resolveの制限を理解する

IP系のルールでは、宛先アドレスの取得が必要になる場合があります。リクエストがドメイン名を含み、そこで名前解決を行うと、その後のルール判定経路が変わることもあります。no-resolveを付けると、そのルールに一致させるための名前解決を新たに実行しません。すでに宛先IPが分かっている接続は、引き続きルール判定の対象になります。「この接続ではDNSを一切使わない」という意味でも、ドメイン名を特定のアドレスに自動対応させる設定でもありません。ドメイン名で安定して振り分けたい場合は、通常はドメインルールを先に書き、必要なIPルールを補助として追加します。

プロセスルールはWindowsアプリごとの振り分けに便利ですが、カーネルが接続元のプロセスを特定できることが前提です。通信の入口、権限、システム環境によって識別結果は変わる場合があります。ブラウザーは複数の子プロセスで通信し、アプリの更新で実行ファイルのパスが変わることもあります。ルールを書く前に、接続の詳細で実際のプロセス情報を確認してください。プロセスルールはファイアウォール相当の隔離を保証するものではありません。厳密に通信を制限する場合は、OSの制御機能も使用してください。

ルールプロバイダーは形式と動作の両方を確認する

rule-providersは再利用可能なルールセットを管理する項目で、プロキシプロバイダーとは内容が異なります。behaviorはルールセット内の項目の解釈方法を指定します。代表的な値はdomain、ipcidr、classicalです。formatはファイル形式を示します。「どの種類のルールか」と「ファイルがどの形式で記述されているか」をそれぞれ表し、互いに置き換えることはできません。以下では、対応関係を確認しやすいようローカルの従来形式のルールセットを使います。

rule-providers:
  local-domains:
    type: file
    behavior: classical
    format: yaml
    path: ./rules/local-domains.yaml

rules:
  - RULE-SET,local-domains,DIRECT
  - MATCH,出口選択

# ./rules/local-domains.yaml の内容：
# payload:
#   - DOMAIN-SUFFIX,example.com
#   - DOMAIN,intranet.example.org

ルールセット内の項目には出力先を指定しません。参照側のRULE-SETですでに出力先が設定されているためです。ルールセットの読み込みに失敗したら、ルール一覧をすべて削除するのではなく、まずパス、取得した内容、ファイル形式を確認してください。リモートURLからログインページやエラーメッセージが返された場合、HTTPリクエスト自体は成功していても、有効なルールファイルとはいえません。更新間隔は再取得の頻度を決めるだけで、リモートの内容が正しく解析できることを保証しません。

ルールを確認する際は、まずクライアントの接続画面で対象ドメイン、一致したルール、最終的な出力先を調べてから、順序を変更するか判断してください。既存の接続では以前の経路が使われ続ける場合があります。テスト前に対象アプリの接続を閉じるか、アプリを再起動して新しい接続を作成できますが、ページを一度更新しただけで、すべての接続が切り替わったと考えないでください。具体的な操作は接続確認の手順を参照してください。サブスクリプションが定期更新される場合は、独自ルールを永続的な上書きに保存しましょう。マージの詳細は設定の上書き・マージを参照してください。

6. DNS：名前解決の経路とfake-ip

DNS設定では、ドメイン名をどのようにアドレスへ解決するか、また名前解決のリクエストがどの経路を通るかを指定します。プロキシノードの選択と関係はありますが、同じ設定ではありません。ブラウザーがプロキシ経由でWebサイトに接続できても、システムのすべてのDNSリクエストがカーネルを通っているとは限りません。反対に、カーネルのDNS機能を有効にしても、WindowsやアプリがそのDNS機能へ問い合わせているとは限りません。ClashのDNSリークを調べるときは、1つの項目だけで判断せず、リクエストの送信元、リゾルバー、ネットワークの出口を確認してください。

リスニングアドレスを設定しても、システムの名前解決が自動で切り替わるわけではない

dns.enableはカーネルのDNS機能を有効にし、listenはローカルのリスニングアドレスを指定します。システムのサービスとの競合を避けるため、以下の例ではループバックアドレスと標準以外のポートを使います。この設定を追加しただけでは、TUNによるDNSの横取りや明示的な転送設定がない限り、Windowsは引き続きネットワークアダプターに設定されたDNSを使う場合があります。ポート番号を含むアドレスを、IPアドレスだけを受け付けるネットワークアダプターの設定欄へ入力しないでください。設定する場所によって、要求されるアドレス形式は異なります。

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"
  default-nameserver:
    - 1.1.1.1
  nameserver:
    - https://dns.cloudflare.com/dns-query

これは名前解決の構造を示す例で、すべてのネットワークでこの上流DNSが適切とは限りません。default-nameserverは主に、DNSの上流サーバー自体のドメイン名を解決するために使います。これにより「リゾルバーへ接続する前に、そのリゾルバーの名前解決が必要」という依存関係を避けられます。nameserverは通常の問い合わせに使う上流DNSです。暗号化DNSは問い合わせの伝送方式を変えますが、送信経路まで自動的に変えるものではなく、ローカルネットワークから上流DNSへ接続できない問題も解決しません。

fake-ipでは通信がカーネルに戻る必要がある

fake-ipはドメイン名に合成アドレスを割り当て、カーネルがアドレスとドメイン名の対応を記録します。その後の接続がカーネルに届くと、その対応情報に基づいて処理されます。例のアドレス範囲は、この対応付けに使うものであり、Webサイトの実際のグローバルIPアドレスではありません。アプリが合成アドレスを受け取った後、カーネルを通らず直接接続しようとすると、失敗する場合があります。そのため、DNSの入口と通信の入口を連携させる必要があります。合成アドレスが表示されても、必ずしも名前解決のエラーではありません。後続の接続が同じカーネルインスタンスを通るかどうかが重要です。

fake-ip-filterでは、一部のドメインに合成アドレスを割り当てないよう設定できます。LAN内のデバイス検出や、合成アドレスに対応していないサービスなどに使いますが、問題のあるドメインを何でもフィルターに追加するのは避けてください。アプリが実際のIPアドレスを必要としているか、独自のDNSを使っているか、LAN内のドメインをどのリゾルバーで解決するかを先に確認しましょう。redir-hostは別の方式であり、ルール判定や名前解決の範囲も異なります。モードを切り替えた後は、古いDNSキャッシュが残っていないか確認し、以前の結果を使って新しい設定を判断しないでください。

ドメイン別の上流DNSとプロキシノードの名前解決

nameserver-policyでは、ドメインごとに使用する上流DNSを指定できます。企業ネットワーク内のドメインを社内DNSで解決したい場合に便利です。プロキシサーバー自体のドメイン名は、proxy-server-nameserverで個別に解決でき、通常の業務用ドメインとの依存関係を分けられます。respect-rulesを有効にしてDNS上流への接続にもルーティングルールを適用する場合は、プロキシノードのドメイン名をどう解決するか先に決めてください。「DNSの問い合わせにプロキシが必要で、プロキシの接続にもDNSが必要」という循環が起きるおそれがあります。

DNS項目間の優先順位は実際の動作に影響します。初期設定で、複数の予備DNS、ドメイン別ポリシー、複数のルール依存を一度に追加するのは避けましょう。まず、経路を説明できる名前解決の設定を作り、必要な例外を追加してください。ブラウザーのセキュアDNS、別のVPNのDNS設定、企業向けセキュリティソフト、ルーターによる転送などがあると、テスト用の問い合わせが想定した入口を通らない場合もあります。予備DNSは多ければよいわけではありません。各サーバーの到達性と用途を確認してください。

変更後、必要に応じてipconfig /flushdnsを実行し、WindowsのDNSキャッシュを消去してください。独自のキャッシュを持つアプリは再起動が必要です。システムのキャッシュを消去しても、ブラウザー、カーネル、リモートリゾルバーのキャッシュまで必ず消えるわけではありません。LAN内のプリンターや企業ドメインが使えなくなった場合は、分岐処理全体を無効にするのではなく、まず適切な社内DNSへ戻してください。新しい設定が使えることを確認したら、永続設定として保存し、ローカルDNSで解決する必要のあるドメインを記録しておくと、後から管理しやすくなります。

7. TUN、システムプロキシ、Windowsのルーティング

システムプロキシとTUNは、通信を取り込む代表的な方法です。システムプロキシはWindowsのプロキシ設定に従うアプリで使われ、まずブラウザーの接続を確認する場合に適しています。TUNは仮想ネットワークデバイスとルーティングを使ってより多くの通信を取り込むため、システムプロキシを参照しないアプリに向いています。TUNを有効にしてもノードの認証情報は変わらず、UDPへの対応も自動で追加されません。まず、動作するノードと基本ルールで出力を確認してからTUNを設定すると、通信の入口とリモート接続を同時に調べずに済みます。

設定項目とクライアントの権限が動作を左右する

Windowsで仮想ネットワークアダプターを作成したり、ルーティングを変更したり、サービスをインストールしたりするには、権限が必要な場合があります。クライアントのサービスモード、管理者としての起動、カーネル設定はそれぞれ役割が異なり、YAMLのスイッチ1つですべてのシステム操作が完了するわけではありません。まず、クライアントに用意されたサービスのインストール機能とTUN設定を使ってください。クライアント画面で管理する項目をサブスクリプション内で手動編集すると、次回の設定生成時に上書きされる場合があります。画面上の状態と実行時設定が一致しているか確認してください。

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

この例ではmihomoのTUN項目を使っています。auto-routeはルートの自動設定、auto-detect-interfaceは出力先インターフェースの検出、dns-hijackはカーネルのDNSで処理するリクエストを指定します。有効なdns設定と組み合わせてください。従来のDNSポートを横取りしても、暗号化DNSをすべて取り込めるわけではありません。アプリがHTTPS経由で独自に名前解決を行う場合は通信の形態が異なるため、その動作を別途確認する必要があります。

ネットワークスタックは万能の高速化設定ではない

stackでは、カーネルが対応するネットワークスタックの方式を選べます。互換性はOS、カーネルの実装、アプリに左右されます。mixedは複数の方式を組み合わせて処理しますが、すべての環境でほかの選択肢より優れているわけではありません。特定のアプリで問題が起きた場合は、動作している設定を基準にして、一つずつ比較してください。ネットワークスタック、MTU、DNS、ノードを同時に変更すると原因を特定できません。原因を見極めるため、一度に変更する条件は1つにしましょう。

MTUはネットワークパケットのサイズに影響します。経路によっては、フラグメント化やトンネルのカプセル化が問題になることもありますが、あらゆる通信の遅延原因ではありません。特定のサイト、通信方式、大きなパケットだけに問題が出るかを確認してから調整を検討してください。ネット上で紹介されている固定値を早い段階で設定すると、正常だった接続の原因が分かりにくくなる場合があります。TUNでだけ問題が起き、システムプロキシでは正常なら、サブスクリプションをすぐに変更するのではなく、ルーティング、通信の入口、DNS、ネットワークスタックを調べましょう。

複数のネットワークアダプターや別のVPNがある場合の確認手順

有線、Wi-Fi、仮想マシン用ネットワーク、企業VPNを同時に使用していると、デフォルトルートとDNSの参照先が別々のインターフェースになる場合があります。複雑なネットワーク構成では、出力先インターフェースの自動検出が期待どおりに動作するとは限りません。Get-NetRoute -AddressFamily IPv4でルーティングを確認し、Get-NetIPConfigurationでインターフェースの設定を調べられます。まず現在の状態を記録し、許可されている環境で競合するソフトを1つずつ停止してください。見覚えのない仮想ネットワークアダプターをいきなり削除しないでください。

システムプロキシとTUNを同時に有効にしても、必ず二重プロキシになるわけではありません。ただし、どの入口を通っているかの判断は難しくなります。トラブル対処では、まず片方だけを有効にし、アプリ内の別のプロキシ拡張も無効にして、条件を明確にして確認してください。会社のデバイスでは管理者のポリシーによる制限がある場合があるため、ネットワーク管理ルールに従ってください。サービスを削除したり、システムのセキュリティ設定を変更したりして制限を回避しないでください。常時使用する場合は、クライアントの自動起動やサービスモードを必要に応じて設定します。

クライアントを終了する前にTUNとシステムプロキシを無効にし、システムのネットワーク接続が復旧したことを確認してください。異常終了後にWebページを開けなくなった場合は、まずWindowsのプロキシ設定が停止済みのローカルポートを参照していないか確認し、その後に残っているルートや他のVPNの状態を調べます。ネットワーク設定全体をすぐにリセットしないでください。白画面やサービス起動エラーなどは、Windowsクライアントの起動トラブル対処を参照してください。接続経路の確認はガイドの接続確認に戻って続けられます。

8. 設定の上書き・マージと、元に戻せる変更手順

サブスクリプションは通常リモートで管理されるため、インポートした内容を直接編集すると、更新時に変更が失われやすくなります。設定を上書きするのは、ローカルの好みとサブスクリプションの取得元を分けるためです。ノードはリモートで更新しながら、必要なルールや設定をローカルに保てます。ただし「上書き」は、mihomoカーネルで共通に定められた編集機能ではありません。クライアントが設定を生成する際に使う処理方式です。Clash PlusやClash Verge Revなどでは、設定画面、構文、処理順が異なるため、それぞれの説明を確認してください。

スカラー・マップ・リストは、それぞれ異なる方法でマージする

ポートやモードなどのスカラー値は、通常、後の値が前の値を置き換えます。DNSなどのマップは子項目ごとにマージされる場合も、全体が置き換わる場合もあります。ルールやプロキシグループなどのリストは、置き換え、追加、先頭への挿入など、クライアントによって扱いが異なります。クライアントの説明がない場合、「このルールをすべてのルールより先に追加してくれる」と決めつけないでください。以下は最終的に必要なルールの例で、すべてのクライアントで使える上書き指示ではありません。

rules:
  - DOMAIN,intranet.example.com,DIRECT
  - DOMAIN-SUFFIX,example.org,出口選択
  - MATCH,出口選択

サブスクリプションに既存のルールがある場合、上記のリストで置き換えると、サブスクリプション内のほかのルールが失われます。末尾に追加しても、元のリストにMATCHがあると、新しいルールが判定されない場合があります。クライアントが対応する先頭挿入機能を使うか、スクリプトで挿入位置を明確に指定し、生成された設定を確認してください。グループを変更する場合は、同じ名前のグループを編集しているか、誤って重複した名前を追加していないかも確認します。

生成順を整理してから、追加位置を決める

設定生成では、リモートサブスクリプション、サブスクリプション専用の拡張、全体拡張、GUIの設定、実行時の選択が順番に適用される場合があります。実際の順序はクライアントによって異なるため、ここでは特定のクライアントの処理順をすべての環境に当てはめていません。上書き保存後に反映されない場合は、まず最終的な実行ファイルに該当項目が存在するか確認してください。項目がない場合は、上書きが適用されていないか、後の処理で置き換えられた可能性があります。項目があるのに動作が違う場合は、参照関係、ルールの位置、通信の入口を確認します。

すべてのサブスクリプションで共通に使うローカルのリスニング制限などは、全体の上書きに適しています。特定のプロバイダーやグループ名に依存するルールは、サブスクリプション単位の上書きにしてください。1つのサブスクリプションにしかないグループ名を全体ルールに書くと、別のサブスクリプションへ切り替えたときに参照先が見つからなくなります。移行時は、旧クライアント独自の解析スクリプトとカーネルのYAMLを分けてください。スクリプトファイル全体を設定に貼り付けないでください。関連情報はClash for Windowsからの移行メモを参照してください。

保存・テスト・読み込み・確認の4段階で変更する

保存前に、正常に動作する現在の設定元と上書き内容をバックアップしてください。バックアップにサブスクリプションの認証情報が含まれる場合は、安全に保管します。テストではYAMLの構文、ノードの参照、ルールの出力先を確認します。独立したカーネルでテストできる場合は、断片だけでなく最終的な設定全体を検証してください。読み込み後は、クライアントが古い設定に戻っていないか確認し、ログに構文エラーやプロバイダーのエラーがないか調べます。最後に、変更対象の通信を新たに発生させ、一致したルールと最終的な出力先が意図どおりか確認してください。

# 対応するカーネルをインストールしたターミナルで指定ファイルをテスト
mihomo -t -f config.yaml

# PowerShell：サンプルのプロキシポートがリッスンしているか確認
Get-NetTCPConnection -LocalPort 7897 -ErrorAction SilentlyContinue

# WindowsのDNSキャッシュを消去
ipconfig /flushdns

各コマンドで確認できる内容は異なります。設定テストではリモートの認証情報を検証できず、ポートがリッスンしていても接続先のWebサイトに到達できるとは限りません。DNSキャッシュの消去でルールの誤りも直りません。これら3つを、常に実行すれば直る定番手順と考えないでください。コマンドが見つからない場合は、出所不明のツールをダウンロードする前に、実行ファイルのパスやターミナルの環境を確認します。クライアントに設定の検査機能がある場合は、独立したカーネルとクライアントでカーネルのバージョンが異なるのを避けるため、そちらを優先してもよいでしょう。

更新後は起動確認だけでなく、依存関係も見直す

サブスクリプションの更新で、ノード名の変更や削除、プロキシグループの調整が行われる場合があります。クライアントの更新で、拡張の処理方法が変わることもあります。更新後は、ローカルルールが参照するグループが残っているか、ルールプロバイダーを正常に読み込めたか、TUNとDNSが意図した状態かを確認してください。起動できても、業務ルールが以前の目的に合っているとは限りません。重要なアプリで新しい接続を試し、よく使う社内リソースと一般のWebサイトに想定どおりアクセスできることも確認しましょう。

項目の用語を確認する場合は用語ガイドを参照してください。サブスクリプションをまだインポートしていない場合は、サブスクリプションのインポート手順に戻れば十分です。高度な機能を一度に設定する必要はありません。設定を管理するうえで大切なのは、各項目の用途が明確で、例外の理由を説明でき、更新後に元へ戻せることです。短く検証しやすいローカル上書きのほうが、サブスクリプション全体を長期的にコピーするより安定して管理できます。