高度な設定 · MIHOMO

Clash 高度な設定ガイド

プロキシの選択から通信の取り込みまで、設定の層ごとに動作を確認します。

まず基本の接続を確認してから、ルール、DNS、通信の取り込み方法を調整します。はじめにでは、サブスクリプションの追加、ノードの選択、接続確認までの基本手順を案内します。このページでは、パラメーターの関係や長期的な設定管理、変更後のトラブルの切り分けを扱います。初めて使う場合はClash Plusを選ぶと簡単です。他のクライアントやシステムのアーキテクチャ別オプションはクライアントのダウンロードページをご覧ください。

以下では主にmihomoの設定仕様を扱います。クライアントの画面、コアの機能、設定の生成方法はそれぞれ異なるため、画面上の名称をそのままYAMLのキーとして扱うことはできません。各設定例には適用範囲を記載しています。実際のプロキシノードは含まれておらず、そのまま通信できる完全な設定ではありません。変更前に現在の設定をエクスポートし、コアの種類、通信の取り込み方法、再現するURLを記録してください。一度に変更するのは1つの設定層だけにして、複数の問題が重ならないようにします。

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

プロキシグループが決めるのは「ルールに一致した後、どの出口を使うか」であり、「どのリクエストをプロキシするか」ではありません。ルールが接続をグループに渡し、グループが手動選択、ヘルスチェック、振り分けアルゴリズムに応じて次の接続先を決定します。問題を切り分ける際は、まず接続の詳細で一致したルールを確認し、その後に最終的なノードを確認してください。リクエストが対象グループに入っていないなら、測定間隔を調整しても解決しません。グループ名は設定内の参照先でもあります。名前を変更した場合は、ルール、ネストされたグループ、クライアントに保存された選択状態も確認してください。

用途に合わせてグループの種類を選ぶ

selectは出口を明示的に選びたい場合に適しています。グループにはノードだけでなく、他のプロキシグループも指定できます。url-testは疎通テストの結果から状態のよい候補を選びますが、テスト結果は指定したURLへの接続状況を示すもので、あらゆる通信が速くなることを保証するものではありません。fallbackはリストの上位にある候補のうち、チェックに合格したものを優先します。出口の優先順位が決まっている環境に適しています。load-balanceは複数の接続を候補に振り分ける方式で、1つのダウンロード接続を分割して帯域を合算するものではありません。

種類選択基準主な注意点
selectユーザーが明示的に選択選択した出口が使えなくなった場合、通常は手動対応が必要
url-test候補のテスト結果テスト先と実際の通信先で結果が異なることがある
fallbackリストの順序と接続可否テスト時間の短さより優先順位が重視される
load-balance接続の振り分け方法通信ごとに異なる出口IPが使われる場合がある

まず手動選択できる構成を用意する

最上位に手動選択グループを1つ残し、その中に自動選択グループを入れる構成がおすすめです。各ルールから自動選択グループを直接参照するのは避けましょう。問題が起きた際、出口を一時的に固定すれば、「自動切り替えによる変化」と「ルールの記述ミス」を切り分けられます。以下は参照関係だけを示す例で、候補は組み込みのポリシーであり、利用可能なプロキシノードではありません。実際に使う際は、インポート済みで接続可能なノードまたはグループに置き換え、名前が完全に一致していることを確認してください。

mode: rule

proxy-groups:
  - name: 出口選択
    type: select
    proxies:
      - DIRECT
      - 故障時の遮断
  - name: 故障時の遮断
    type: select
    proxies:
      - REJECT

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

自動選択グループの主なパラメーターは、テスト先URLのurl、チェック間隔のinterval、切り替え許容差のtoleranceです。テスト先は安定して応答し、現在のネットワークからアクセスできるものを選んでください。間隔が短すぎるとテストリクエストが増え、長すぎると障害状態が長く残る可能性があります。許容差は候補の性能が近いときに頻繁に切り替わるのを抑える設定です。単位や具体的な意味は、使用するコアのドキュメントを確認してください。ヘルスチェックの失敗を、ノードが完全にオフラインだと決めつけないでください。テスト先の名前解決、接続先の制限、プロキシ経路なども失敗の原因になります。

切り替えが実際の接続に反映されたか確認する

グループを切り替えたら、新しいリクエストを作成して確認してください。ブラウザーの接続プール、HTTP/2の長時間接続、継続中のダウンロードでは、古い接続が使われ続けることがあります。出口がすぐに変わらなくても、切り替えに失敗したとは限りません。テストページを閉じて新しい接続を作成し、接続詳細でプロキシグループを含む経路全体を確認します。古い接続を切断する必要がある場合は、クライアントの接続管理機能を使ってください。役立つログを失わないよう、状態を更新するためだけにシステム全体を再起動するのは避けましょう。

ログイン、決済、長時間のセッションでは、出口を固定したほうが適している場合があります。負荷分散によって同じサービスへの接続で異なるIPアドレスが使われると、セッション認証や地域判定に影響することがあります。このような通信は専用の手動選択グループに分けられます。また、グループのネストでは循環参照を避けてください。たとえば、グループAがグループBを参照し、グループBがグループAを参照する構成です。設定を読み込めることは最初の確認にすぎません。最終的な出口、障害時のフォールバック、復旧後の優先順位も確認してください。各方式の詳しい比較は自動プロキシグループの種類と設定例をご覧ください。

ルールセットのサブスクリプション管理

ルールセットを使うと、頻繁に変わるマッチ条件と、比較的安定した出口ポリシーを分けて管理できます。メイン設定にはルールセットの宣言、参照順序、最後のフォールバックだけを残し、ドメイン名やIP範囲のリストは別に保存します。業務用ドメインを更新するときにポリシー構成全体を変更せずに済み、差分も確認しやすくなります。ただし、外部ルールセットも設定への入力です。配布元、形式、更新範囲を確認してください。ダウンロードできるという理由だけで、ローカルルールより優先させるのは避けましょう。

宣言・内容・参照を区別する

rule-providersでは配布元と解析方法を宣言し、RULE-SETでルール一覧から呼び出し、実際のファイルにマッチ条件を記述します。behaviorはドメイン、IP範囲、クラシックルールのどの形式として内容を解釈するかを指定します。formatはファイル形式を指定します。この2つは別の設定です。たとえばYAMLファイルには、ドメイン一覧もクラシックルールも格納できます。ファイルの拡張子だけでは、コアが内容を正しく解釈できるか判断できません。

以下ではローカルファイルを使い、ネットワークからのダウンロードの問題を切り離して、最小限の動作確認を行います。ルールファイルをコアの作業ディレクトリ内の適切な場所に置き、宣言を既存の設定に追加してください。パスは通常、編集中のファイルではなくコアの作業ディレクトリを基準にします。GUIクライアントは独自の設定ディレクトリを使う場合があるため、ログまたは設定管理画面で確認してください。サンドボックスやサービスの実行方法によって、アクセス可能なパスが制限されることもあります。

rule-providers:
  ローカルドメイン:
    type: file
    behavior: domain
    format: yaml
    path: ./rules/local-domains.yaml

rules:
  - RULE-SET,ローカルドメイン,DIRECT
  - MATCH,出口選択

対応するrules/local-domains.yamlの内容は以下のとおりです。ここでは予約済みのサンプルドメインを使い、ファイルが読み込まれるか、ルールが一致するかだけを確認します。実際の業務用ルールの代わりにはならず、プロキシノードも追加されません。

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

ルールの順序で適用範囲が決まる

ルールは通常、上から順に評価され、最初に一致した項目が処理を決定します。個別の例外は広い範囲を対象とするルールより前に置き、最後にフォールバックのMATCHを配置してください。対象範囲の広いDIRECTルールをプロキシ対象のルールより先に置くと、後者が一致しなくなることがあります。ルールセット同士の重複はよくあります。すべてのセットを互いに重ならないようにするより、対象の通信がなぜ先行ルールに一致したのかを説明できる状態に保つことが重要です。

ドメインルールは接続から取得できるドメイン情報を利用します。一方、IPルールでは名前解決が必要になる場合があります。このパラメーターに対応するIPマッチルールでは、no-resolveはそのルールに一致させるためだけの名前解決を行わないという意味で、接続全体でDNS問い合わせが発生しなくなるわけではありません。設定するかどうかはルールの目的で判断してください。通常、社内ネットワークの例外に余分な名前解決は不要ですが、接続先IPの地域情報に基づくポリシーでは、名前解決結果の取得元を考慮する必要があります。

type: httpに切り替える場合は、ルールセットのURLを追加し、更新間隔とキャッシュパスを明示してください。まず現在のネットワークから配布元にアクセスできることを確認してから、更新リクエストの出口を決めます。そうしないと、「ルールの配布元にアクセスするために、先にルールが必要」という循環依存になりやすくなります。更新に失敗してもキャッシュが使われる場合がありますが、初回起動時にはキャッシュがありません。キャッシュあり・なしの両方で起動を確認し、一度の更新成功メッセージだけで判断しないでください。

更新に失敗したときの確認手順

まずログで、ダウンロード、ファイル読み込み、形式の解析のどこで失敗したかを確認してください。ダウンロード失敗なら配布元の名前解決、TLS接続、出口を確認します。読み込み失敗ならディレクトリの権限とパスを確認します。解析失敗ならpayloadの構造、インデント、behaviorの種類を確認してください。クラシックルールセットの項目には通常、最終的なポリシーは含めません。ポリシーは外側のRULE-SETで指定します。メイン設定のルールをそのまま移すと、項目数が合わなかったり、意味が混乱したりすることがあります。

更新後は、ルールに確実に含まれるドメインと、含まれないドメインを1つずつ選び、新しい接続で一致結果を確認します。その後、手前のルールが先に一致していないかを調べてください。接続画面に表示されるルール名は、「Webページが開くか」よりも判断材料になります。ページが開いても、フォールバックに一致しただけかもしれません。直前に使えていたルールファイルと配布元の情報を保存しておき、誤分類が起きた場合は、まず範囲を絞ったローカル例外を追加してから上流の変更を調べます。すぐにルール全体をグローバルプロキシに切り替えないでください。

DNS設定の最適化

DNSのトラブルを調べる際は、アプリが誰にドメイン名を問い合わせるかと、コアが最終的なアドレスを誰に問い合わせるかを分けて考えます。アプリはシステムDNS、ブラウザーの暗号化DNS、独自のリゾルバーを使う場合があります。また、プロキシノードのサーバー名も事前に名前解決が必要です。nameserverを変更しても、すべてのアプリの問い合わせがコア経由になるわけではありません。まず特定のアプリだけで問題が起きるか確認し、問い合わせの入口、上流のDNS、接続の出口を順に調べましょう。名前解決エラーを見て、すべてのアドレスを一度に置き換えるのは避けてください。

名前解決の経路を分けて確認する

default-nameserverは主にDNS上流のサーバー名を解決するための設定で、名前解決の起点として使います。nameserverは通常の問い合わせ先、nameserver-policyは特定のドメインに対する名前解決経路を指定します。ノードのサーバー名を別経路で解決する必要がある場合は、使用するコアがproxy-server-nameserverに対応しているか確認してください。まだ確立していないプロキシ経路にノードの名前解決を依存させないようにしましょう。また、暗号化DNSのサーバー名を、そのDNS自身だけで解決する構成も避けてください。

以下はローカルのループバックアドレスでテスト用ポートを開き、実IP形式の上流を設定して経路を確認する例です。OSのDNS設定を自動で変更したり、DNSの横取りを自動で有効にしたりするものではありません。実際のIPアドレスを返して確認できるよう、redir-hostを有効にしています。すでにクライアントがDNSを管理している場合は、ポートの二重待ち受けを避けるため、最終的な設定を先に確認してください。

dns:
  enable: true
  listen: 127.0.0.1:1053
  ipv6: false
  enhanced-mode: redir-host
  default-nameserver:
    - 223.5.5.5
  nameserver:
    - 223.5.5.5
    - 1.1.1.1
  nameserver-policy:
    'example.org':
      - 223.5.5.5

システムにdigがインストールされていれば、この待ち受けポートに直接問い合わせ、システムのデフォルトの名前解決結果と比較できます。ここで確認できるのはコアのDNSサービスの入口が使えることだけで、ブラウザーがそのサービスを使用していることまでは証明できません。問い合わせがタイムアウトする場合は、サービスの待ち受け、ポートの競合、上流への到達性を確認します。アドレスが返るのにWebページが開かない場合は、接続ルール、TLSハンドシェイク、アプリのプロキシ設定を調べてください。

dig @127.0.0.1 -p 1053 example.org A
dig @127.0.0.1 -p 1053 example.org AAAA

上流DNSの選択とドメイン別ルーティング

複数の上流DNSをどう利用し、結果をどう扱うかは、コアの実装と各フィールドの仕様で決まります。リストを単純な優先順位とみなさないでください。上流を選ぶ際は、現在のネットワークから安定して到達できるか、社内ドメインの解決に適しているか、返されたアドレスが実際の出口と整合するかを確認します。社内ドメインは通常、社内のDNSサーバーに問い合わせます。パブリックDNSは社内のゾーンを把握していません。社内ドメインを外部に送ると、名前解決に失敗するだけでなく、ドメイン情報が漏れる範囲も広がります。

DoHやDoTは問い合わせの通信を保護できますが、誤った出口やルーティングを自動で修正するものではなく、対象サービスへの通信をルールによる振り分けから除外するものでもありません。ルールに基づくDNSルーティングを有効にする前に、respect-rulesとノードのドメイン名解決との依存関係を理解し、ノードの名前解決経路を明確にしてください。既存設定にfallbackやフィルター条件がある場合は、それらも併せて確認します。上流DNSの一覧だけ貼り付けて、名前解決先が変わったと思い込まないでください。

IPv6は常に有効または無効にするのではなく、実際のネットワーク環境に応じて設定してください。アドレスが解決でき、システムに利用可能なルートがあり、クライアントの通信取り込み方法が対応して初めて、IPv6の通信経路が成立します。Webページが時々停止する場合は、AレコードとAAAAレコードの問い合わせ、IPv4とIPv6の接続をそれぞれ試し、どちらかの種類で繰り返し失敗しないか確認してください。DNS設定でAAAAの応答を無効にしても、アプリがキャッシュや独自の名前解決でIPv6アドレスを取得する可能性は残ります。

キャッシュ、ブラウザーの名前解決、再テスト

名前解決のポリシーを変更しても、コア、OS、ブラウザーの3か所に古い結果が残ることがあります。まず明示的な問い合わせで新しい結果を確認し、クライアントの方法に従ってDNSキャッシュを削除してから、テストするアプリを再起動し、新しい接続を作成してください。同じページを何度も再読み込みするだけでは不十分です。接続プールが新しいDNS問い合わせを発生させていない可能性があります。ブラウザーだけで問題が起きる場合は、セキュアDNS設定や拡張機能の影響を調べ、関連機能を無効にする前後の違いを記録してください。

テストでは問い合わせたドメイン、レコードタイプ、返されたアドレス、所要時間またはタイムアウトの有無、対応する接続ログを記録してください。NXDOMAIN、空の結果、問い合わせのタイムアウトは、それぞれ異なる状態です。前者はドメインが存在しないという応答、空の結果は該当するレコードタイプのデータがないだけの場合、タイムアウトは経路や上流DNSの応答に問題がある場合を示します。アプリ側の確認方法はよくある質問もご覧ください。名前解決のどの段階に問題があるか特定してから、Fake-IPやDNSの取り込み方法を調整しましょう。

TUNとFake-IP

TUNは通信の入口を、Fake-IPはドメイン名とアドレスの対応付けを扱います。併用されることは多いものの、同じ機能ではありません。TUNは仮想ネットワークインターフェースで通信を受け取り、システムプロキシに従わないアプリの通信も取り込めます。Fake-IPは仮想アドレスを返し、コアが対応付けから元のドメインを復元して接続を処理します。システムプロキシはアプリ側が設定を利用しますが、TUNはシステムのルート、権限、ネットワークスタックに関わります。有効にするかどうかは、具体的にどのアプリの通信が取り込まれていないかを基準に判断してください。

まず、どの機能が通信を取り込んでいるか確認する

同じデバイスで複数のVPN、通信高速化ツール、仮想ネットワークアダプターを同時に使うと、ルーティングやDNS設定が互いに上書きされることがあります。まずシステムプロキシの状態、既存の仮想インターフェース、デフォルトルートを記録し、通信を取り込む機能を1つだけ有効にして比較します。デスクトップクライアントはサービスプロセスから権限を得る場合や、ユーザーに許可を求める場合があります。モバイルOSは通常、システム提供のVPN経路を使用します。プラットフォームごとの画面表示が、同じルーティング動作を示すとは限りません。

以下はmihomoでTUN、DNSの取り込み、Fake-IPを組み合わせる例です。プロキシノードは含まれていません。クライアントが一部のフィールドを自動生成している場合があるため、最終的な設定を確認してください。有効化する前に、ローカルの画面からTUNを無効にできることを確認し、ネットワークに依存しない元の設定のコピーを保存してください。

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
  fake-ip-filter:
    - '*.lan'
    - '*.local'
  nameserver:
    - 223.5.5.5

auto-routeは通信を取り込むルートを設定し、auto-detect-interfaceは実際の出口インターフェースの選択を補助します。stackは通信処理の方式に影響します。system、gVisor、mixedの各スタックを利用できるか、互換性があるかは、プラットフォームとコアのビルドに左右されます。特定の名前にこだわって方式を変更しないでください。まずクライアント推奨のデフォルト値で基本的な接続を確認し、問題のあるプロトコルだけを個別に比較して、変更前後のログを記録します。

仮想アドレスの利用範囲を理解する

Fake-IPは接続先サーバーの実IPアドレスではないため、インターネットから到達可能かどうかの判断には使えません。アプリが仮想アドレスを取得した後の接続は、対応付けを保持するコアを再度経由する必要があります。アプリがTUNを迂回して直接接続した場合、対応付けが失われた場合、別のプロキシインスタンスに通信が入った場合は、接続先のドメインを復元できないことがあります。キャッシュに仮想アドレスが残っていると、通信の取り込みを無効にした後もしばらく失敗することがあります。関連するキャッシュを削除し、アプリに再度名前解決させてください。

fake-ip-filterに指定したドメインは通常、実際の名前解決結果を返すようになりますが、自動的に直接接続されるわけではありません。最終的な出口はルールで決まります。LAN内のデバイス検出、実アドレスによる確認が必要なアプリ、特定の機器との通信では、対象を絞って除外し、問題が解決するか確認してください。通信の取り込みに関する問題を隠すために、すべてのドメインをフィルターに追加するのは避けましょう。名前解決の仕組み全体が変わり、問題を比較しにくくなります。

この例でDNSを取り込む対象は、宛先ポートが53の従来型DNSリクエストです。アプリが独自に使うDoHやDoTを直接復号するものではありません。ブラウザー内蔵の名前解決、企業VPNの社内DNS、特殊なネットワークインターフェースは、それぞれ個別に確認してください。LAN内のブロードキャストやマルチキャスト、一部のローカルサービスも通常のインターネット接続とは異なります。TUNを有効にすればすべて正しく転送されると考えないでください。ルーターやプリンターに接続できない場合は、プロキシノードを手当たり次第に変更せず、まずLAN内のルートと名前解決を確認します。

影響の小さい順に元へ戻す

デバイス全体がインターネットに接続できなくなった場合は、まずTUNを無効にし、デフォルトルートとシステムDNSが復旧したことを確認してから、元の設定に戻してください。クライアントが異常終了してルートが復旧しない場合は、クライアントの修復機能を使うか、ネットワークインターフェースを再起動します。システムのルーティングコマンドに詳しくない場合は、ルートをまとめて削除する操作をそのまま実行しないでください。基本のネットワークを復旧した後、システムプロキシとTUNを個別に検証します。通信が不安定な状態でルールをさらに追加しないようにしましょう。

安定したら、ブラウザー、コマンドライン、システムプロキシに従わないアプリの3種類でテストし、通信がコアに入っているか、ドメイン情報があるか、ルールに一致しているかを確認します。UDP通信では、ノードのプロトコルとサーバーが必要な転送方式をサポートしているかも検証してください。TUNで通信を受け取れても、出口が対応しているとは限りません。仕組みの詳しい比較はTUNとシステムプロキシの仕組みをご覧ください。入口で通信を取り込めているかと、出口が対応しているかを分けてから、次の変更を決めましょう。

ドメインスニッフィング

ドメインスニッフィングは接続のドメイン情報を補う機能で、Webページの内容を復号するものではありません。アプリが独自のDNS、キャッシュ済みのアドレス、IPアドレスへの直接接続を使うと、コアが接続先IPしか認識できず、想定したドメインルールを適用できない場合があります。スニッフィングではHTTPリクエストやTLS、QUICのハンドシェイクから確認可能なホスト情報を抽出し、その後の判定に利用できます。ただし、実際にプロトコル上で見える情報が対象です。暗号化されたクライアントハロー、独自プロトコル、IPアドレスだけで動作するサービスからドメインを取得できるとは限りません。

まず、ドメイン情報が取得できていないことを確認する

接続画面で安定して再現できるリクエストを1つ選び、宛先がIPアドレスだけで表示され、ドメインルールにも一致していないことを確認してください。画面に正しいドメインが表示されているのに誤ったルールが適用される場合は、まずルールの順序とポリシーの参照先を確認します。通常、スニッフィングを有効にしても解決しません。ブラウザーが独自の暗号化DNSを使っている場合は、その経路が意図したものかを確認してから、ブラウザーの名前解決方法を変更するか、スニッフィングで情報を補うかを判断します。

以下では対象ポートを絞り、HTTPとTLSのスニッフィングだけを例示します。override-destinationは無効にし、スニッフィング結果で接続先が書き換わる影響を抑えています。取得できる情報や具体的な動作は、使用するコアに応じて確認してください。この設定例は既存設定に追加するもので、単独で接続できる設定ではありません。

sniffer:
  enable: true
  parse-pure-ip: true
  force-dns-mapping: true
  override-destination: false
  sniff:
    HTTP:
      ports:
        - 80
        - 8080
    TLS:
      ports:
        - 443
  skip-domain:
    - '+.lan'
    - '+.local'

parse-pure-ipを有効にするとIPアドレスだけの接続も処理対象にできます。force-dns-mappingは特定のDNSマッピングでのスニッフィング動作に関わりますが、どちらも「すべての接続から必ずドメイン名を取得できる」ことを保証するものではありません。ポート範囲は処理を試みる接続の範囲を指定するもので、そのポートの通信が必ず該当プロトコルとは限りません。一般的でないポートでTLSを使うアプリに対して対象を広げるかは、実際の用途に応じて判断してください。1つの問題に対処するために、すべてのポートを対象にするのは避けましょう。

ルール情報の取得と接続先の上書きを区別する

スニッフィングでドメイン名を取得できると、通信の分類に役立ちます。一方、接続先の上書きは、元の接続先の意味をさらに変える可能性があります。固定IP、独自のHost、特殊なリバースプロキシに依存するサービスでは、上書きを無条件に有効にすると、正常だったリクエストまで失敗することがあります。「ドメイン名を取得できたか」と「接続先の上書きを許可するか」を分けてテストしてください。まずログとルールの一致状況を確認し、その後、サービスとのハンドシェイクが正常かを検証します。

1つのIPアドレスで多数のドメインをホストしている場合、アドレスからの逆引きだけでは、今回のリクエストのホスト名を正確に特定できません。TLSで見えるサーバー名も、アプリが後続でアクセスするすべてのリソースを示すとは限りません。WebページではCDN、ログイン、画像、APIなどへの接続が発生する場合があります。トップページが正しいルールに一致したからといって、サイト全体の通信が同じポリシーを通るとは考えないでください。接続一覧でアプリや時間範囲を絞って関連リクエストを確認します。特にログイン時のリダイレクトやリソース読み込みの失敗に注意してください。

QUICは通常UDPを使うため、QUICのスニッフィングを有効にする場合は、コアの対応状況、実際のポート、出口のUDP対応を確認してください。ブラウザーでQUICを無効にして症状が変化しても、それだけでUDP対応ノードが使えないとは判断できません。TLSハンドシェイクの情報を確認できない場合、スニッフィングでドメイン名を復元することもできません。この場合は、アプリのDNS問い合わせをコアに通す、既知の業務用ルールを使う、必要に応じてプロセス単位でルーティングするといった方法が現実的です。スニッフィングの対象を際限なく広げないでください。

除外項目を設定して再テストの記録を残す

LAN内のサービス、デバイスの管理画面、互換性に敏感な一部のアプリには、明示的な除外項目を設定できます。除外範囲はできるだけ絞り、再現可能なドメインまたは対象を1つ選んでテストしてから、必要に応じて広げてください。スニッフィングをスキップするドメイン、送信元アドレス、宛先アドレスなどのフィールドは、コアによって対応状況が異なります。設定チェックで未知のフィールドが見つかった場合は、パラメーターを追加し続けないでください。まずコアの種類と対応範囲を確認し、使用するオプションを決めましょう。

検証時はまずスニッフィングを無効にして接続し、対象ドメイン、ルール、出口を記録します。次に有効にして新しい接続を作成し、同じ3項目を比較します。有効にしたときだけ失敗する場合は、設定を元に戻した後も、アプリのキャッシュや古い接続が残っていないか確認してください。残存状態によって、ロールバックが効かなかったと誤認することがあります。ログに内部ホスト名、接続先アドレス、アプリの識別情報が含まれる場合は、共有前にマスキングしてください。スニッフィングは不足した情報を補う機能として使い、長期的に安定した設定には、分かりやすいDNS経路と説明可能なルールを優先します。

ローカル上書きと複数サブスクリプションの統合

長期的な設定では、リモートから取得する内容とローカルの設定意図を分けてください。サブスクリプションはノードや更新対象の内容を管理し、ローカル上書きは固定ルール、DNS、プロキシグループの構成、デバイス固有の設定を管理します。クライアントが一時的に生成した設定を直接編集すると、サブスクリプションの更新や設定の切り替えで変更が失われることがあります。まず、クライアントに永続的な上書き設定、マージ設定、スクリプト処理のどれが用意されているかを確認し、最終的に生成されたファイルを確認してください。エディター上の内容だけでは、実行中のコアに変更が反映されたかは分かりません。

マージ順序と配列の扱いを確認する

YAMLはデータ形式であり、複数ファイルの統合方法に共通のルールはありません。クライアントによってはマップを再帰的にマージし、配列は全体を置き換える場合があります。前置、後置、名前を指定した更新に対応するものもあります。rulesを全体置換するか追加するかで、結果は大きく変わります。全体置換ではサブスクリプション由来のルールが失われる可能性があり、追加ではローカル例外がMATCHの後ろに配置されることがあります。上書きを適用する前に、対象を絞ったテストルールを1つ使って実際の順序を確認してください。

以下はローカルでの設定意図を示す例です。プロキシグループにはDIRECT候補だけを指定し、名前を固定することとルールの位置を示しています。すべてのクライアントで共通して使える上書き形式ではありません。クライアントの説明に従ってマージ設定の入口に変換または適用してください。このまま完全なプロキシサブスクリプションとして読み込むことはできません。

proxy-groups:
  - name: 通常の出口
    type: select
    proxies:
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.org,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - MATCH,通常の出口

実際にマージする際は、「通常の出口」から既存ノード、ノードプロバイダー、下位の自動選択グループを参照するようにします。メインルールがこの固定された参照先だけを使えば、ノードの提供元が変わっても業務ルールを書き直す必要はありません。サブスクリプションにも同じ名前のプロキシグループが定義されている場合は、どちらを優先するか明確にしてください。重複した名前は、信頼できるマージ方法ではありません。クライアントに保存された古い選択が削除済みノードを指す場合もあるため、更新後にグループの選択先が有効か確認してください。

複数のサブスクリプションは、提供元を分けてから統合する

複数のサブスクリプションはクライアントの統合機能でまとめるか、proxy-providersなどのコア機能で管理できます。ただし、ノードサブスクリプション、完全な設定を含むサブスクリプション、ルールセットは、それぞれ異なる種類の入力です。通常、ノードプロバイダーには対応するノード一覧の構造が必要です。DNS、ルール、コントローラーを含む完全な設定のURLをそのまま指定して、すべてが自動で統合されると期待しないでください。まずサブスクリプションの内容の種類を確認し、必要に応じて信頼でき、内容を検証できるローカルの変換手順を使います。

提供元ごとに名前、キャッシュパス、判別しやすいノード名を分けてください。2つの提供元に「香港」という名前のノードがあると、ログや選択履歴から区別しにくく、名前が衝突する可能性もあります。名前の接頭辞には提供元や用途を示し、サブスクリプションの認証情報はノード名に含めないでください。候補をフィルタリングする場合は、結果が空になっていないかをまず確認します。正規表現、ノード名の変更、地域ラベルの更新によって、正常だったグループから候補がなくなることがあります。

リモートサブスクリプションのURLにはアクセス認証情報が含まれることが多いため、クライアントのローカル設定管理に保存してください。スクリーンショット、問い合わせへの添付、同期リポジトリ、オンライン変換ツールによって情報が漏れる範囲が広がる可能性があります。設定を共有する前に、URLのクエリパラメーター、ノードのパスワード、コントローラーのシークレット、ログに記録された完全なURLを確認してください。ノード一覧だけを隠しても、サブスクリプションのURLが漏れることがあります。これらを含むバックアップは、管理された場所に保管し、閲覧できるアカウントを制限してください。

生成・検証・再読み込みを分けて確認する

変更後はまず最終的な設定を確認し、ルールの順序、グループのメンバー、DNS関連のフィールドを見てから、コアの設定チェックを実行してください。コマンドラインでは、以下の方法で確認できます。config.yamlには、実際に実行する最終ファイルを指定してください。GUIクライアントでは、作業ディレクトリの違いによるパスの食い違いを避けるため、内蔵の検証機能を優先します。検証に合格しても、設定の構造や参照先が受け入れられるというだけで、プロキシノードから対象のサービスに接続できるとは限りません。

mihomo -t -f config.yaml

再読み込み後は、ローカル例外、通常のプロキシ接続、最後のフォールバックを個別にテストします。サブスクリプションを再度更新した後も設定が残っているか確認してください。更新後に以前の動作に戻る場合は、上書きが永続的な生成処理に適用されていないか、後続の設定層で上書きされています。ロールバックするときは、ローカル上書きと対応するサブスクリプションのスナップショットを戻してください。一時的に生成されたファイルをコピーして恒久対応にするのは避けましょう。複雑なマージの問題は、まずサブスクリプションを1つ、最上位グループを1つに減らし、原因となった層が見つかるまで提供元を1つずつ戻します。

外部コントローラー

外部コントローラーはコアの制御インターフェースを通じて状態を取得し、ポリシーの切り替えや接続の管理を行います。通信を転送する機能ではありません。コントローラーパネルが開かない問題と、プロキシでインターネットに接続できない問題は別々に起きている可能性があります。まずコアが動作中か確認し、次に制御インターフェース、認証、ページの配信元を調べてください。日常的な操作の多くはクライアント内蔵の画面で行えます。独立した監視やリモート管理が本当に必要な場合だけ、管理機能を追加で公開し、デバイスの管理用入口を意図せず広げないようにしましょう。

まずローカルホストだけにアクセスを限定する

external-controllerは制御インターフェースの待ち受けアドレスを指定し、secretはインターフェースの認証に使用します。external-uiはローカルの静的パネル用ディレクトリを指定します。以下はローカルで管理する設定例です。サンプルのシークレットは説明用のダミー値です。実際の環境ではローカルで生成した十分に強いランダム値に置き換え、公開ファイルに記載しないでください。静的パネルのファイルは、信頼できるローカルディレクトリにあらかじめ用意する必要があります。このフィールドを設定しても画面は自動生成されません。

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

ループバックアドレスでの待ち受けは、ローカルホストからの利用に限られます。他のデバイスから接続できないからといって、すぐに全インターフェースで待ち受けたり、認証を無効にしたりしないでください。デバイス間の管理が必要な場合は、まず認証、アクセス制御、安全な通信方法を設計し、接続元も制限します。実際に公開される範囲には、OSのファイアウォール、コンテナのポートマッピング、クライアントの設定が影響する場合があります。設定ファイルだけで判断せず、待ち受け状態と実際の接続結果を確認してください。

プロキシポートと管理ポートを区別する

mixed-portなどのプロキシ入口はアプリの通信を受け付けるポートで、制御インターフェースはコアの管理に使うポートです。互いに代用できません。ブラウザーのプロキシサーバーに制御ポートを設定しても、通常のプロキシ接続にはなりません。パネルのAPIアドレスにプロキシポートを指定しても、プロキシグループを読み取ることはできません。パネルのAPIアドレスには正しいプロトコル、ホスト、ポートを指定し、シークレットは現在実行中のインスタンスのものを使ってください。特に、同じデバイスで複数のコアプロセスが動作している場合は注意が必要です。

まずローカルAPIにリクエストを送信し、インターフェースが応答するか確認できます。以下のコマンドでは、例と同じダミーのシークレットを使っています。ローカルでの説明用です。実際に操作する際は、ターミナルの履歴や画面共有に注意し、認証ヘッダーを公開しないでください。「未認証」の応答は、インターフェースから応答があり、認証情報が一致しなかったことを示します。接続拒否はアドレス、ポート、プロセスの状態に問題がある場合が多く、タイムアウトする場合はアクセス経路とファイアウォールも確認してください。

curl --fail --silent --show-error \
  -H 'Authorization: Bearer your-controller-secret' \
  http://127.0.0.1:9090/proxies

APIが正常に応答してもページが空白の場合は、静的ファイルが揃っているか、ディレクトリのパスが正しいか、ブラウザーの開発者コンソールにリクエストエラーがないかを確認します。HTTPSのページからHTTPのAPIにアクセスすると、混在コンテンツとしてブロックされることがあります。ページとAPIの配信元が異なる場合は、クロスオリジンのポリシーも関係します。ブラウザーのエラーを消すために、すべての配信元を許可したり、認証を削除したりしないでください。ローカルパネルと管理対象のAPIで、互換性のあるアクセス方法を使うことを優先します。

パネルを使って一連の障害対応を記録する

接続画面では、接続先、ルール、ポリシーの経路、接続状態をまとめて確認してください。最終的なノード名だけでは、業務ルールに選ばれたのか、たまたまフォールバックに入ったのか判断できません。ポリシーを切り替えたら新しい接続を作成し、必要に応じて影響範囲を確認してから、対象の古い接続を閉じます。一度にすべての接続を切断して様子を見るのは避けてください。ログインセッション、ダウンロード、リモートターミナルなどが切断され、障害発生時の情報も失われる可能性があります。

ログの詳細度は、問題を説明できる範囲に設定します。詳細度を一時的に上げた場合は、再テストが終わったら元に戻してください。詳細ログには、内部ドメイン、接続先アドレス、プロセス情報、リクエストのパスが含まれる場合があります。問い合わせを送る前に、問題に関係する時間帯だけを残し、機密情報をマスキングしてください。パネルに表示される情報は、接続先のインスタンスから取得されます。クライアントは正常に動作しているのにパネルのルール一覧が明らかに異なる場合は、サブスクリプションの更新を疑う前に、制御アドレスとプロセスを確認してください。

最終的には、再現可能な障害対応の流れを記録します。どのアプリがリクエストを送ったか、コアに入ったか、ドメイン名をどう取得したか、どのルールに一致したか、プロキシグループがどの出口を選んだか、名前解決・接続・サービス応答のどの段階で失敗したかを整理してください。ブラウザーとターミナルで結果が異なる場合は、システムプロキシとターミナルのトラブルシューティングをご覧ください。初期設定がまだ完了していない場合は、高度なオプションを増やすより、はじめにに戻って基本手順を完了するほうが、確実に原因を特定できます。