Clashの応用設定
プロキシグループ・DNS・TUN

ルーティングと出口

プロキシグループの種類と使い方

プロキシグループは、ルールとプロキシノードの間に置く中間層です。ルールが接続の出口を指定し、プロキシグループがその出口で使うノードを決めます。ルールを特定のノードに直接結び付けると、ノード名が変わるたびに複数のルールを修正する必要があります。安定したグループ名を参照すれば、サブスクリプションが更新されてもルールを維持できます。まず手動選択、自動選択、デフォルトのフォールバックなど用途別の出口を整理し、その後にグループ内の候補を決めましょう。地域別グループをむやみに増やすのは避けてください。

選択方式でグループの種類を使い分ける

selectは手動選択を保持するため、出口を明示的に指定したい場合に適しています。url-testは候補を定期的にテストし、その結果からノードを選びます。テストするのは指定先への到達性と応答状況であり、すべてのサイトで速いことを示すものではありません。fallbackは設定順に利用可能な候補を探すため、プライマリ／バックアップ構成に向いています。load-balanceは複数の接続を振り分ける機能で、1つのダウンロード接続に複数ノードの帯域を合算するものではありません。

グループをネストすると設定の重複を減らせますが、階層が増えるほど原因の切り分けが難しくなります。用途別グループが手動グループを参照し、さらにその手動グループが自動グループを参照する場合、パネルに表示される最初のグループ名が最終ノードとは限りません。トラブル時は選択経路を最後までたどり、実際の出口を確認してください。ログイン状態や長時間のセッションが重要な用途では、出口を安定させるのが基本です。自動切り替えが起きると、新しい接続は別のアドレスを使い、既存の接続は元のノードに残るため、短時間に複数の出口が併存することがあります。

プロキシプロバイダーでサブスクリプションの変更を分離

以下の例では、トップレベルにproxiesリストを含むプロキシプロバイダーファイルがローカルにあることを前提とします。ファイルパスはブラウザーのダウンロード先ではなく、コアの作業ディレクトリからの相対パスです。自動選択グループはuseでプロバイダーを参照し、外側のプロキシグループは自動選択グループと組み込みのDIRECT出口だけを参照します。既存サブスクリプションのノードをファイルにエクスポートするか、クライアントのサブスクリプション管理機能で対応するプロバイダーを生成してください。通常のWebページをYAMLとして保存しても参照できません。

proxy-providers:
  ローカルノード:
    type: file
    path: ./providers/nodes.yaml

proxy-groups:
  - name: 自動選択
    type: url-test
    use:
      - ローカルノード
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    lazy: true
  - name: プロキシ
    type: select
    proxies:
      - 自動選択
      - DIRECT

intervalの単位は秒、toleranceは候補間の差が小さいときに頻繁な切り替えを防ぐための許容値です。lazyを有効にすると、未使用時のテストを減らせます。「常に最速」を目指して間隔を極端に短くするのは避けましょう。頻繁なテストはリクエストを増やし、モバイル端末のバッテリーも消費します。すべての候補がテストに失敗した場合は、まずテスト先に各ノードからアクセスできるかを確認し、その後ノード自体を調べてください。パネルの表示だけで、すべてのサブスクリプションが無効だと判断することはできません。

フィルター、命名、検証の手順

filterでプロバイダーのノードを絞り込む場合、通常は名前に対する正規表現の照合が行われ、地理的な場所が自動判定されるわけではありません。サブスクリプション側で名前や記号、大文字・小文字が変わると、候補がゼロになることがあります。まずパネルでプロバイダーにノードが読み込まれているかを確認し、次にフィルター式を検証してから、プロキシグループに候補が表示されるかを確認してください。グループ名はルール内の指定と完全一致させます。全角スペース、似た記号、コピー時に混入した不可視文字にも注意してください。

検証では、まず利用可能だと分かっているノードを選び、ルールモードで対象サイトにアクセスします。接続の詳細で、ヒットしたルール、プロキシグループ、最終ノードを確認してください。クライアントの全体スイッチだけを見ても判断できません。手動選択は正常で自動選択だけ失敗する場合は、テスト先、フィルター条件、自動選択の仕組みを調べます。すべてのグループで失敗する場合は、サブスクリプションとネットワーク経路に戻って確認してください。取得や解析の問題はサブスクリプション更新失敗時のチェックリストも参照し、読み込みの問題とルーティングの問題を混同しないようにしましょう。

ルールとメンテナンス

ルールプロバイダーでルールを管理

ルールプロバイダーを使うと、ドメイン、IPアドレス範囲、個別ルールをメイン設定から分離できます。メインファイルには参照関係と照合順序だけを残します。これは管理対象を整理する仕組みであり、「最初に一致したルールが出口を決める」という基本原則は変わりません。ルールプロバイダーに多数の項目があっても、それより前の広範なルールに一致すれば実行されません。まずLAN向けルールと明確な例外を配置し、用途別ルール、地域ルール、最後のフォールバックの順に整理しましょう。順序の誤りを大量の重複ルールで補うのは避けてください。

内容の意味を確認してから形式を選ぶ

behaviorはルールセットの内容の種類を示します。domainはドメインのリスト、ipcidrはIPアドレス範囲のリスト、classicalはルール種別を含む項目に使えます。これはファイルの拡張子とは別の概念です。YAMLファイルでも、ノードサブスクリプションや完全な設定ファイルの場合があります。読み込む前にファイルを開き、トップレベルの構造と各項目を確認してください。ダウンロードURLの拡張子だけで互換性を判断することはできません。

ファイル形式と内容の意味は対応させる必要があります。YAML形式のルールセットでは通常、トップレベルにpayload配列を置きます。テキスト形式は1行ごとに項目を読み込みます。MRSはコンパイル済みのルール形式で、対応範囲はコアの実装によって異なります。DOMAIN-SUFFIX,example.orgのような完全なルール項目を使う場合は、単純なドメイン一覧ではなく、適切なclassical形式を選んでください。参照元を変更するときはbehaviorとformatも確認し、URLだけを差し替えないようにしましょう。

ローカルで検証してからリモート更新に切り替える

まずはローカルファイルで検証することをおすすめします。次のメイン設定では、2つのローカルルールセットを参照します。業務ドメインはドメイン一覧、ローカルネットワークはIPアドレス範囲の一覧です。どちらのファイルも実際にディスク上に存在する必要があります。プロキシグループプロキシはあらかじめ定義してください。no-resolveは、アドレスルールの照合時に余分なDNS問い合わせを避けるための設定です。常にDNSを省略するわけではなく、後続ルールで必要な名前解決を妨げるものでもありません。

rule-providers:
  業務ドメイン:
    type: file
    behavior: domain
    format: yaml
    path: ./rules/business.yaml
  ローカルネットワーク:
    type: file
    behavior: ipcidr
    format: yaml
    path: ./rules/private.yaml

rules:
  - RULE-SET,ローカルネットワーク,DIRECT,no-resolve
  - RULE-SET,業務ドメイン,プロキシ
  - MATCH,プロキシ

たとえばbusiness.yamlは、次のような構造にできます。例示用に予約されたドメインを使用しており、実際のルーティングには使えません。必要なドメインに置き換えたら、まずコアが読み込めることを確認し、その後に対象リクエストを観察してください。ドメインルールではURLのパスを指定できません。スキーム、ポート、ページパスを含む完全なURLは使えません。同じドメイン内でパスごとに振り分ける条件も、通常のドメインルールでは表現できません。

payload:
  - "+.example.org"
  - "example.net"

HTTPプロバイダーに切り替える場合は、信頼できる配布元のurl、ローカルキャッシュのpath、更新間隔のintervalを追加します。複数の配布元が同じファイルを上書きしないよう、キャッシュのパスはそれぞれ別にしてください。更新間隔はルールの変更頻度に合わせて設定すればよく、ノードの速度テストと同じ間隔にする必要はありません。ダウンロードに失敗した後も既存のキャッシュを使えるかどうかは、キャッシュの有効性とコアの状態によります。新しい端末に導入する前に、初回ダウンロード先へアクセスできることを個別に確認してください。

更新結果とルールの照合結果を分けて確認

プロバイダーの更新成功は、ファイルの取得と解析が完了したことを示すだけで、対象リクエストがルールに一致したことを意味しません。まずルールセットの項目を確認し、次にメインルール内の位置を確認してから、接続がドメイン名とIPアドレスのどちらを使っているかを調べます。ブラウザーキャッシュ、既存の長時間接続、アプリ内の独自名前解決によって、テスト結果が予想と異なることがあります。ルール変更後は、クライアント全体を何度も再起動するより、対象アプリの接続を閉じて再リクエストする方が、比較可能なログを保ちやすくなります。

複数の配布元を管理する場合は、それぞれの役割を明確にし、説明できる範囲のローカル例外だけを残してください。同じ用途を網羅する大規模ルールセットをいくつも同時に購読し、どれが有効になるか順序から推測するのは避けましょう。配布元を削除する前に、すべてのRULE-SET参照を確認してください。統合するときは、利用条件、更新の安定性、内容の違いを確認します。想定どおりに一致しない場合は、対象ドメインに一時的な完全一致ルールを追加して出口を検証し、検証後に削除してください。一時的な修正が既存のルールを隠したままにならないよう注意します。

名前解決

DNS設定の最適化

DNS設定では、少なくとも3つの経路を考える必要があります。アプリの問い合わせを受け取るのはどこか、接続先ドメインを解決するのはどこか、プロキシサーバー自身のドメインをどう名前解決するかです。すべてを同じ上流に任せると、依存関係が循環することがあります。たとえば、プロキシサーバーへの接続に先立って名前解決が必要なのに、その名前解決にもプロキシ接続が必要になるケースです。最適化の前に3つの経路を整理し、初期の名前解決が独立して完了することを確認してから、暗号化DNS、ドメイン別のリゾルバー、キャッシュの動作を検討しましょう。

初期の名前解決と通常のDNS問い合わせを分ける

default-nameserverは主にDNS上流サーバー自身のドメインなどを解決するために使い、通常は明示的なIPアドレスを指定します。nameserverは通常の名前解決に使う上流サーバーです。nameserver-policyは、特定のドメインやルールに対して名前解決経路を指定します。proxy-server-nameserverはプロキシノードのサーバードメインを解決するための項目です。各項目がクライアントに保持されるかどうかは、実際に生成された実行設定で確認してください。サブスクリプション編集画面に記述があるだけでは判断できません。

以下は各項目の役割を把握するための基本例です。上流サーバーのアドレスを明示し、例の中に余分なドメイン解決の依存関係を持ち込まないようにしています。待ち受けポートはローカルの標準外ポートに設定していますが、これだけでシステムのDNS問い合わせがこのポートに送られるわけではありません。有効にする前に、ローカルでポートが使用されていないことを確認してください。TUNで問い合わせを横取りする場合は、次の章を参考に内核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
    - 1.1.1.1
  nameserver:
    - https://1.1.1.1/dns-query
  proxy-server-nameserver:
    - 223.5.5.5
  nameserver-policy:
    "+.lan":
      - 192.168.1.1

例にあるLAN用リゾルバーは、現在のネットワークで実際に使えるルーターまたは社内DNSに置き換えてください。内部ドメインを使わない場合は、該当するポリシーを削除します。社内ドメインにパブリックDNSを使うと、名前が見つからないことがあります。反対に、内部レコードしか解決できないサーバーにすべてのパブリックドメインを任せても、広範な失敗につながります。リゾルバーが特定のドメインに適しているかは、レコードが返るかだけでなく、返されたアドレスと接続経路を確認して判断してください。

fallbackは、どんな失敗にも対応する万能策ではない

fallbackとfallback-filterは、条件に応じてどのDNS応答を採用するかを決めるもので、ネットワーク出口のプライマリ／バックアップ用プロキシグループではありません。フィルター条件には地理情報、IPアドレス範囲、ドメインなどを指定できます。条件が広すぎると多くの問い合わせが予備の上流に回り、狭すぎると適切でない応答を使い続ける可能性があります。選択条件を理解できていない場合は、まずnameserver-policyで必要なドメインだけを明確に振り分け、fallbackを導入する必要があるか検討してください。

respect-rulesを使ってDNS上流への接続にルーティングルールを適用する場合は、プロキシサーバーのドメインを別経路で解決できるようにしておいてください。そうしないと、名前解決とプロキシ接続が互いに待ち合う状態になりやすくなります。暗号化DNSは問い合わせの通信方式を変えるだけで、プロキシ経由を保証するものでも、現在の出口に適したアドレスが返ることを保証するものでもありません。ドメインの名前解決に成功しても接続がタイムアウトする場合は、返されたアドレスが適切なネットワークに対応しているかを確認し、その後にルールとルーティングを調べましょう。上流サーバーのアドレスをむやみに追加しても解決にはなりません。

問い合わせ・応答・接続の順に切り分ける

トラブル対処では、まずアプリの問い合わせがコアに届いているか、次にコアが想定した上流へ問い合わせているか、最後に対象接続でどのアドレスが使われているかを確認します。システムのDNS問い合わせツールでローカルの待ち受けアドレスとポートを指定できます。ポートを指定できないツールの場合は、システムのリゾルバーへの問い合わせ結果をコアの結果と取り違えないでください。内部ドメイン、パブリックドメイン、プロキシノードのドメインを1つずつテストすると、同じWebページを何度も再読み込みするより問題箇所を見つけやすくなります。

DNSを変更すると、OS、ブラウザー、コアがそれぞれキャッシュを保持している場合があります。まず対象アプリの既存接続を閉じ、必要に応じてクライアントの機能でDNSキャッシュを消去してから、新しいリクエストを送ってください。IPv6アドレスが返っても、ネットワークに利用可能なIPv6経路がなければ接続できません。DNSの応答と実際のルーティング能力を分けて考えましょう。DNSスイッチを1つ切り替えるだけでは、すべてのアプリに反映されないこともあります。IPv6を有効にするかどうかは、OSのルーティング、コアの設定、ノードの対応状況を合わせて確認してください。特定のサイトが開けるだけで、全体が正常だと判断しないようにしましょう。

DNSの処理とルールによる振り分けには順序上の依存関係がありますが、同じ設定ではありません。ドメインルールはドメイン情報を保持したまま照合できますが、IPアドレスルールでは名前解決が発生する場合があります。no-resolveはその処理を制限します。設定の動作を説明するには、1回のリクエストについてドメイン名、返されたアドレス、一致したルール、出口を記録してください。DNS項目の組み合わせとDNSハイジャックの範囲は、DNS設定項目とハイジャックの解説もご覧ください。

通信の取り込み

TUNとFake-IP

システムプロキシは、アプリがOSのプロキシ設定に従うことを前提とします。TUNは仮想ネットワークインターフェースを通じ、ルーティングされた通信をコアに取り込みます。どちらも通信をクライアントに渡す方法を決めるもので、必ずプロキシ経由にする機能ではありません。TUNを有効にしても、ルールモードではLANや指定したサービスを直接接続できます。グローバルプロキシを選んでも、OS上のすべての通信が取り込まれるとは限りません。取り込みが完全かどうかは、スイッチの状態だけでなく、対象アプリの接続記録とルーティングテーブルで確認してください。

権限とルーティングの前提を整える

デスクトップクライアントでは、インターフェースやルートの作成にサービスコンポーネント、管理者権限、またはOSの許可が必要な場合があります。モバイル端末ではOSのVPNインターフェースを利用するため、設定画面や操作方法はデスクトップ版と同じではありません。初めて有効にする前に、現在のシステムプロキシとDNS設定を記録し、ルートを取り込む可能性のあるほかのVPNを停止してから、クライアントのTUNを有効にしてください。別のコアを手動で同時起動すると、ポート、仮想NIC、デフォルトルートが競合することがあります。

以下はMihomoでよく使われる部分設定です。auto-routeは関連ルートを自動設定し、auto-detect-interfaceは出力インターフェースを検出します。dns-hijackは対象となる従来型DNS問い合わせをコアに渡します。この設定はDNSモジュールと組み合わせて使ってください。クライアントのGUI設定でこれらの項目を管理できる場合は、まずGUIから設定し、最終的に適用された設定を確認しましょう。サブスクリプションの項目と画面上の状態が互いに上書きしないよう注意してください。

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

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

stackはネットワークスタックの実装を選ぶ項目で、すべてのOSに共通する最適な値はありません。互換性の問題が起きたら、この項目だけを変更し、同じ用途で再テストしてください。接続の確立、通信の継続、UDPの動作を記録します。スタック、MTU、DNS、ノードを同時に変えると、問題が解消しても原因を特定できません。インターフェースの自動検出に問題がある場合は、特に有線と無線を切り替えた後に、現在使われている出力インターフェースを確認してください。

Fake-IPはドメインとの対応を保持する仮想アドレスで、実際のサービスアドレスではない

Fake-IPモードでは、アプリに予約済みアドレスプール内の仮想アドレスを返し、コアがそのアドレスとドメインの対応を記録します。その後、接続がコアに届くと、記録をもとにルール照合と出力が行われます。アプリに見えている仮想アドレスを、対応関係を持たない別の端末でそのまま使うことはできません。また、そのアドレスからリモートサービスの実際の所在を判断することもできません。トラブル対処では、対応するドメインと最終的な出口の両方を確認してください。システムツールに表示された接続先アドレスだけでは、ルールが正しく適用されたか判断できません。

LAN内の機器検出、デバイス管理、実アドレスが必要なサービスでは、Fake-IPから除外する必要がある場合があります。対象を明確にしたうえで、fake-ip-filterを設定してください。除外したドメインは実アドレスで名前解決されますが、後続ルールでドメイン情報を保持できるかは、アプリの動作やスニッフィングにも左右されます。1台の問題を解決するために、すべてのドメインを除外するのは避けましょう。まず問題のリクエストで使われるドメイン名を確認し、最小限の範囲でテストしてください。アドレスプールが既存のVPNや検証用ネットワークと競合する場合は、コアの対応範囲内で変更し、マッピングを作り直します。

元に戻せる手順で通信の取り込みを検証する

検証では、既知の正常なルールとノードをそのままにして、TUNだけを有効にします。これまでシステムプロキシに従わなかったアプリを選び、新しい接続を作成して接続一覧に表示されるか確認してください。接続が表示されるのにアクセスできない場合、通信の取り込み自体は完了している可能性が高く、次はルール、DNS、出口を確認します。記録がまったくない場合は、アプリが現在のネットワーク経路を迂回していないか、インターフェースのルートが設定されたか、別のネットワークツールが先に通信を取り込んでいないかを調べてください。

従来型DNSのハイジャックだけでは、暗号化された名前解決をすべて横取りできません。アプリ内蔵のDoHなどは通常の暗号化通信に見えるため、宛先ポートが一般的なDNSポート以外だからといって、ローカルの名前解決モジュールに自動で渡されるわけではありません。ドメイン情報が取得できない場合は、まずアプリのセキュアDNS設定を確認し、次の章で扱うスニッフィングの機能も検討してください。dns-hijackを有効にしただけで、すべての名前解決経路が統一されたと判断しないようにしましょう。

ネットワークに接続できなくなった場合は、まずTUNを無効にし、ルートとDNSが復旧するか確認してから競合の原因を調べます。クライアント終了後も異常が続く場合は、残っているシステムプロキシ、ほかのVPNの状態、OSのネットワーク設定を確認してください。新しいルートを次々追加するのは避けましょう。リモートサーバーを保守する場合は、通信の取り込みで管理接続を失わないよう、復旧用の別経路を確保してください。仕組みの詳細とシステムプロキシとの違いはTUNによる通信の取り込み解説をご覧ください。初回設定は引き続きクイックスタートガイドを参照してください。

ドメイン情報の補完

ドメインスニッフィング

ドメインルールで照合するには接続先のドメイン名が必要ですが、コアに届く接続にはIPアドレスしか含まれないことがあります。アプリがキャッシュ済みのアドレスへ直接接続したり、コアのDNSを介さずに名前解決したりする場合です。スニッフィングは、対応プロトコルのハンドシェイクやリクエストからドメイン名を取得し、ルール照合や接続先の処理に利用します。補完するのは接続のメタ情報であり、暗号化された内容をすべて復号する機能ではありません。適切なDNS経路やルール設計の代わりにもなりません。

識別できる範囲と情報源

HTTPスニッフィングは通常リクエスト内のホスト情報、TLSスニッフィングはハンドシェイク内のサーバー名を利用します。QUICのスニッフィングには、対象通信に対するコアの対応が必要です。非対応プロトコル、参照できないハンドシェイク情報、名前を隠す仕組みなどでは、ドメイン名を取得できない場合があります。パネルにドメイン名が表示されないからといって、クライアントの故障とは限りません。通信自体に利用可能な情報がない可能性もあります。その場合は、スニッフィングのポート範囲をむやみに広げるのではなく、IPアドレスルールと明確なフォールバックを用意してください。

以下の設定例では、一般的なWeb用ポートから始め、TLSとQUICの範囲も指定しています。機能を設定しても、すべての接続でドメイン名を取得できるわけではありません。parse-pure-ipはIPアドレスだけの接続も処理対象にし、force-dns-mappingはDNSマッピングに関わるスニッフィングの動作を指定します。初めて有効にする際はスニッフィングの項目だけを追加し、DNSやルールを同時に書き換えないでください。ドメイン名と照合結果を有効化の前後で比較しやすくなります。

sniffer:
  enable: true
  force-dns-mapping: true
  parse-pure-ip: true
  override-destination: false
  sniff:
    HTTP:
      ports:
        - 80
        - 8080-8880
      override-destination: false
    TLS:
      ports:
        - 443
        - 8443
    QUIC:
      ports:
        - 443

ポート範囲は実際の用途に合わせてください。すべてのポートであらゆるプロトコルを解析すると、不要な処理が増え、対象外の通信まで複雑な判定に入る可能性があります。自前のサービスを標準外ポートで使う場合は、実際のプロトコルを確認し、必要な項目だけにポートを追加してください。QUICは通常UDPを使いますが、プロキシできるかどうかはノードのプロトコル、サーバー、通信経路の対応にも左右されます。QUICスニッフィングを有効にしても、UDPでの通信が可能だとは限りません。

ルール照合と接続先の書き換えを区別する

override-destinationは、スニッフィングで取得したドメイン名を接続先に適用するかを決めます。ルール判定に使う場合と、ドメイン名で再接続する場合とでは効果が異なります。特定のIPアドレスや内部の名前解決結果、アドレス固定に依存するサービスでは、接続先を書き換えることで元の動作が変わることがあります。例では影響を抑えるため、まず書き換えを無効にしてドメイン名の補完状況を確認します。必要な場合はプロトコルや用途ごとに調整し、全体設定とプロトコル別設定の継承ルールを現在のコアで確認してください。

同じIPアドレスで複数のドメインが使われることも、1つのドメインが複数のアドレスに対応することもあります。IPアドレスが変わったかどうかだけでは、スニッフィングの結果を判断できません。元の接続先、取得したドメイン、一致したルール、最終的な出口を確認してください。アプリが別の中間プロキシへリクエストを渡している場合、取得される情報は中間接続のものだけかもしれません。接続一覧の名称すべてを、ユーザーがアクセスしたサイト全体の情報だと解釈せず、対象アプリに近い通信の入口を確認してください。

範囲を絞り、互換性の例外を残す

有効化後に一部のサービスだけで問題が起きた場合は、まず対象の書き換えを無効にして再テストし、次に明らかに互換性のないドメインをskip-domainで除外することを検討してください。特定のドメインを必ず処理する必要がある場合に限り、force-domainを評価します。通常の許可リストとして使うのは避けましょう。例外には業務上の理由を記録し、時間がたっても意図を説明できるようにしてください。社内システムでは、プライベート証明書、標準外のハンドシェイク、固定IPでの接続に特に注意が必要です。パブリックサイト向けの設定をそのまま適用しないでください。

検証には新しい接続を使ってください。ブラウザーの接続プール、HTTP/2の接続再利用、アプリの長時間接続によって、変更後の新しいハンドシェイクがすぐに発生しない場合があります。まず対象アプリの接続を閉じ、再現可能なテストページを開いて、ログに想定したドメイン名が表示されるかを確認します。比較用の環境まで失わないよう、システムのネットワーク設定をすべて消去するのは避けてください。デバッグログを保存する場合は、問題に関係する時間帯だけを残し、アクセス先ドメインやノードアドレスなどの個人情報を隠してください。

スニッフィング後に別のルールへ一致しても、それだけで結果が正しいとは限りません。新しいルールが用途に合っているかを確認してください。特に広範なドメインサフィックスルールは、もともとあったIPアドレスの例外を上書きすることがあります。一時的に対象ドメインの明示的なルールを追加して検証し、その結果を長期的なルール設計に反映してください。DNSの調整だけで安定してドメイン情報を取得できるなら、依存関係の少ないシンプルな構成を優先しましょう。個々の問題を新しい機能スイッチで補うのは避けてください。

識別できない通信は、IPアドレス、ポート、または信頼できるプロセス情報に基づいて処理します。プロセスルールの利用可否は、プラットフォーム、権限、コアの機能に左右され、モバイル版とデスクトップ版でも異なります。判断できない通信は、出口を説明できる明確なフォールバックグループに割り当ててください。用語が分からない場合は、用語集でDNS、ルール、ネットワークスタックを確認し、接続の詳細と照らし合わせましょう。「ドメイン名が表示されない」ことを、そのまま「プロキシが動作していない」原因と決めつけないでください。

設定の生成と更新

ローカルオーバーライドと複数サブスクリプション

サブスクリプションの設定は更新時に再生成されるため、サブスクリプションファイル内のポート、DNS、ルールを直接編集すると、次回の更新で変更が失われることがあります。ローカルオーバーライドを使えば、長期的に管理する設定をリモートの内容と分離できます。ノードはサブスクリプションから更新し、個人用ルール、待ち受け範囲、必要なDNSポリシーはローカル側に保存します。設定する前に、クライアントが提供する機能が項目のマージ、ルールの前置き、後置き、スクリプト処理のどれに当たるかを確認してください。いずれも単純なテキスト追記と同じではありません。

設定の管理元と適用順序を確認する

設定は通常、サブスクリプションのダウンロード、解析、クライアントによる変換、オーバーライド、コアでの実行という段階を経ます。編集画面にある項目が実行設定にない場合、YAMLの構文エラーではなく、後の処理で上書きされている可能性があります。Clash Plusとほかの互換クライアントでは設定画面の名称が異なることがあるため、実際の画面でローカル設定、オーバーライド、実行設定の確認機能を探してください。別のクライアントのメニュー構成を基準に、現在のクライアントにコアの機能がないと判断しないようにしましょう。

マップ形式の項目はキー単位でマージされることがありますが、配列形式の項目は全体が置き換わる場合もあれば、専用の前置き・後置き機能が使える場合もあります。rules、proxy-groups、nameserverはいずれもリストを含むため、項目を追加すればリモートの内容も自動で保持されるとは限りません。オーバーライドを初めて使うときは、影響範囲が小さく結果を確認しやすい変更を1つだけ行い、適用後の動作を確かめてからほかの設定を移してください。

サブスクリプションごとに分離し、出口を共通化する

複数のサブスクリプションを統合するときに、すべてのノードを1つのリストへまとめるのは避けましょう。異なる配布元に同名ノード、同名のプロキシグループ、重複したプロバイダー識別子が含まれることがあり、上書きの順序もクライアントの実装によって異なります。各配布元を独立したプロバイダーとして登録し、まず配布元ごとのグループを作り、その後に共通の出口グループから参照する方法が安全です。以下の例では、2つのローカルファイルがどちらも有効なプロキシプロバイダーファイルであることを前提とします。完全なサブスクリプションはクライアントが対応する方法で変換してください。ファイル名を変えただけでノード一覧にはなりません。

proxy-providers:
  ソースA:
    type: file
    path: ./providers/source-a.yaml
  ソースB:
    type: file
    path: ./providers/source-b.yaml

proxy-groups:
  - name: グループA
    type: select
    use:
      - ソースA
  - name: グループB
    type: select
    use:
      - ソースB
  - name: プロキシ
    type: select
    proxies:
      - グループA
      - グループB

この構成では、ルールとサブスクリプションの配布元を分離できますが、同名のノードやグループによる競合は残ります。クライアントがノード名への接頭辞追加に対応している場合は、短く安定していて判別しやすい接頭辞を使ってください。スクリプトで名前を変更する場合は、名前を参照する設定とフィルター式もすべて確認します。配布元を削除する前に、共通の出口グループからの参照を削除し、その後でプロバイダーを削除してください。更新後に候補が空になった場合は、まず配布元が読み込まれているかを確認し、次にフィルター条件を調べます。設定全体をすぐに作り直す必要はありません。

リモートサブスクリプションにはノードだけでなく、ルール、DNS、コントローラーの設定が含まれている場合もあります。マージ時は、どの内容を実行設定に取り込むかを明確にしてください。完全な設定ファイルを2つ結合しても、コアが優先順位を自動判断してくれるわけではありません。特にexternal-controller、allow-lan、待ち受けアドレスはローカルの方針で一元管理してください。サブスクリプション変換サービスを使う場合は、リンクの機密性と、変換サービス側がアクセスできる情報を評価し、自分で管理できる処理経路を優先しましょう。

変更は一度に1つの層だけにし、復元用ファイルを残す

元のサブスクリプション、ローカルオーバーライド、最終的な実行設定を別々のファイルとして保存することをおすすめします。同じファイル名を繰り返し上書きしないでください。まず最終設定の構文を確認し、クライアントに読み込ませてから接続を検証します。Mihomoをコマンドラインで単独利用する場合は、以下のコマンドで設定をテストできます。構文と設定項目間の関係を確認するものであり、サブスクリプションサーバーへの接続、ルールの取得、すべての通信の成功を保証するものではありません。実行後もログを確認してください。

mihomo -t -f ./config.yaml

オーバーライドの変更後にクライアントがクラッシュしたり起動できなくなったりした場合は、まず直近のローカル変更を取り消し、正常に動作していた設定に戻してから、クライアント自体の問題かどうかを判断します。エラーに表示された行番号は、リモートの元ファイルではなく生成後のファイルを指している場合があります。正しい実行ファイルを開き、インデント、重複キー、無効な参照、配列の置き換えを確認してください。起動時のトラブル対処はクライアント起動時のクラッシュ対処もご覧ください。

バックアップファイルにも、サブスクリプションURL、ノードのパスワード、コントローラーの認証情報が含まれます。公開の質問や投稿にそのまま添付しないでください。設定を共有する前に機密情報を削除し、問題を再現できる最小限の構成だけを残して、明らかなテスト用の値に置き換えます。別の端末へ移行するときは、YAMLだけでなく、ローカルプロバイダー、ルールセット、コントローラーパネルのディレクトリ、相対パスも確認してください。設定本文が同じでも作業ディレクトリが異なると、ファイルが見つからなかったり、古いキャッシュが読み込まれたりすることがあります。

動作の確認と制御

外部コントローラーパネル

外部コントローラーインターフェースを使うと、パネルからプロキシグループ、接続、ルール、ログを参照し、選択中のグループを切り替えるなどの操作ができます。パネルはコアを管理する入口であり、別のプロキシ出口でも、コアに代わってTUNルートを作成する機能でもありません。画面に接続できなくても、ブラウザーから通常どおり通信できる場合があります。逆に、パネルが開いてもプロキシ経路が正常とは限りません。画面リソースの読み込み、コントローラーへの接続、認証、実際の通信をそれぞれ分けて確認してください。

まずはローカルアドレスで待ち受ける

ローカルで使う場合は、コントローラーをループバックアドレスにバインドし、専用の認証情報を設定してください。以下のyour-passwordは説明用のテスト値です。実際の環境では、自分で生成した長いランダム文字列に置き換え、サブスクリプションやほかのサービスと使い回さないでください。external-uiはローカルのパネルリソースディレクトリを指定します。ディレクトリ内にパネルのエントリーファイルが必要で、パスはコアの作業ディレクトリからの相対パスです。パネルファイルをまだ用意していない場合は、先にAPIだけをテストしてから画面を設定できます。

external-controller: 127.0.0.1:9090
secret: "your-password"
external-ui: ./ui

ループバックアドレスでの待ち受けは、同じ端末からのアクセスだけを許可します。スマートフォンのブラウザーでパソコンのループバックアドレスにアクセスしても、接続先はスマートフォン自身であり、自動的にパソコンへ転送されるわけではありません。端末をまたいで管理する必要がある場合は、アクセス元、本人確認、利用範囲を制限した安全なプライベート経路を優先してください。利便性だけを理由にコントローラーをインターネットへ直接公開しないでください。プロキシポートのallow-lanとコントローラーの待ち受け設定は別の項目です。LAN向けプロキシを有効にしても、パネルが正しく設定され保護されるわけではありません。

先にAPIを確認してから画面の接続を調べる

まずコアを実行している端末からコントローラーAPIへリクエストを送ります。以下のコマンドは現在の設定概要を取得します。ターミナルに入力する認証情報も例示用です。認証エラーが返る場合は、現在の実行設定にある認証情報を確認します。接続が拒否される場合は、待ち受けアドレス、ポート、プロセスの状態を確認してください。タイムアウトする場合は、ルートとファイアウォールも調べます。APIに到達できない状態でパネルを何度も再インストールしても解決しません。画面ファイルで、起動していないコントローラーを修復することはできません。

curl --fail \
  -H "Authorization: Bearer your-password" \
  http://127.0.0.1:9090/configs

APIが正常でもブラウザーのパネルから接続できない場合は、パネルに設定したバックエンドのアドレス、プロトコル、ポートを確認してください。HTTPSで開いたページからHTTPのバックエンドへ接続すると、ブラウザーのセキュリティ機能が混在コンテンツとしてブロックする場合があります。オリジンの異なるアクセスでは、オリジン制限も関係します。ローカルパネルと管理対象のインターフェースで、明確かつ一貫した接続経路を使うのが基本です。オリジンをまたぐ必要がある場合に限り、コアの対応状況を確認して必要なオリジンだけを許可してください。すべてのオリジンを許可する設定を、万能な解決策として使わないようにしましょう。

パネルはバックエンドのアドレスや認証情報をブラウザーのストレージに保存することがあります。ブラウザーを変更した場合は再設定が必要です。共用端末を使った後は、保存内容も削除してください。スクリーンショットを共有する際は、接続先ドメイン、サブスクリプションの配布元、ノードアドレス、認証情報が映っていないか確認します。デバッグ情報をコピーする場合も、障害に関係する項目だけを残してください。ログを共有する前にはファイル名だけでなく本文も確認しましょう。接続の詳細には、メイン設定より具体的なアクセス履歴が含まれることがあります。

接続の詳細を使って動作を検証する

グループ選択ページでは選択経路、接続ページでは一致したルールと最終出口、ログページでは名前解決の失敗、プロバイダーの更新、ルーティングエラーを確認できます。ルールを調整するときは、テストリクエストの時刻と接続先を記録してから、該当する接続情報と照らし合わせてください。更新され続ける一覧の中で、別のプロセスの記録を取り違えないようにしましょう。変更前に確立した接続は、グループを切り替えただけではすぐにルートが変わりません。必要に応じて該当する接続だけを閉じ、新しいリクエストを送ることで、ほかの通信への影響を抑えられます。

パネルの自動テストと実際のサービスへの接続テストは、分けて考えてください。テストに成功しても、その時点でテスト用の通信が完了したことを示すだけです。対象サービスに接続できるかは、プロトコル、ポート、UDP対応、サービス側の制限、出口経路にも左右されます。特定のサイトで問題が起きた場合は、一時的にノードを手動選択して自動切り替えの影響をなくし、名前解決、一致したルール、接続エラーを確認します。頻繁な速度テストを具体的な障害記録の代わりにしたり、1回の結果だけでルール全体の順序を変えたりしないでください。

コントローラーからの変更と設定ファイルの変更では、設定の保持方法が異なる場合があります。パネルの操作でメモリ上の状態だけが変わる場合もあれば、コアやクライアントに選択状態が保存される場合もあります。再読み込み後に保持されるかどうかは実装次第です。長期的に使う設定はローカル設定またはクライアント設定に保存し、再読み込み後に確認してください。一時的な診断変更は記録して、終わったら元に戻します。設定ファイルと異なる状態のまま次のトラブル対処を始めないようにしましょう。

応用設定の変更後は、設定が解析できること、プロバイダーが読み込まれること、DNS経路を説明できること、対象接続がコアに届くこと、想定したルールに一致すること、目的に合った出口が選ばれることの順に確認します。主要な条件は一度に1つだけ変更し、正常に動作する設定を復元用に残してください。日常的なインストールと初回接続にはクイックスタートガイドを参照してください。プラットフォームやクライアントを変更する場合はダウンロードページから選び、設定用語は用語集で確認できます。