Clash設定応用ガイド：プロキシグループ・DNS・TUN設定

プロキシ選択 / proxy-groups

プロキシグループの種類と実際の接続先

プロキシグループは、ルールに一致した通信をどの接続先に渡すかを決めます。ルール内の Proxy は単なる名前で、コアに標準搭載されたプロキシ接続先を意味するものではありません。ノードまたはプロキシグループとして定義されている必要があります。接続は業務ルールに一致したあと、手動選択グループを経由し、自動テストグループ内のノードに到達する場合があります。この参照関係を理解することは、グループをむやみに増やすより重要です。変更前に、サブスクリプションのノード名、既存グループ名、ルールからの参照先を整理し、名前の重複や参照先の欠落による読み込みエラーを防ぎましょう。

手動選択・自動測定・フェイルオーバー

select は手動選択用の入口で、接続先を明示的に管理したい場合に向いています。url-test は指定したテストURLへの応答をもとに候補を選ぶため、日常的な自動選択に適しています。ただし、測定するのは特定のネットワーク経路であり、すべてのサイトの表示速度を示すわけではありません。fallback は設定順に利用可能な候補へ切り替えます。優先順位の維持と障害時の切り替えが目的で、最も遅延の小さい候補を選ぶ機能ではありません。3種類は入れ子にできますが、構造はシンプルに保ち、グループ同士が相互参照しないようにしてください。

load-balance は複数の接続を候補ノードに振り分けます。1つのダウンロード接続の帯域を合算する機能ではありません。アカウントのセッション、接続元の地域、サーバー側の制限が関係する用途では、接続先を固定するほうが適しています。振り分け方は strategy にも左右されます。たとえば consistent-hashing は同じ宛先が近い接続先に割り当てられるようにしますが、候補が変われば結果も変わることがあります。利用者の識別情報やグローバルIPアドレスが長期間変わらない保証ではありません。

config.yaml · 既存のproviderを参照するプロキシグループの例

proxy-groups:
  - name: Proxy
    type: select
    proxies:
      - 自動選択
      - フェイルオーバー
      - DIRECT

  - name: 自動選択
    type: url-test
    use:
      - サブスクリプション元
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50

  - name: フェイルオーバー
    type: fallback
    use:
      - サブスクリプション元
    url: https://www.gstatic.com/generate_204
    interval: 300

ノードの取得元・測定・選択状態

上の例では、proxy-providers に「サブスクリプション元」という名前のproviderが定義されている必要があります。use はprovider内のノードを取り込み、proxies はノード名、プロキシグループ名、または組み込みのポリシーを直接参照します。サブスクリプションでノードが追加・削除される場合、providerを使うと個別の管理を減らせますが、providerファイルが正常に読み込まれているか確認してください。クライアントにグループを含む完全な設定を読み込んでいる場合、同名の proxy-groups をトップレベルにそのまま追加してはいけません。オーバーライドまたは有効な設定の編集でリストを統合してください。

interval は測定間隔で、単位は秒です。tolerance は自動選択で許容する遅延差で、単位はミリ秒です。小さな変動による頻繁な切り替えを抑えられます。テストURLは安定して到達可能で、実際の通信経路に近いものを選びましょう。ノードのテスト成功は、そのテスト通信が完了したことを示すだけです。特定のサイト、UDP、すべての地域で利用できる証明にはなりません。問題を調べる際は、テスト通信と実際のアクセスを分けて確認してください。

providerのヘルスチェックとプロキシグループのテストは、別の設定箇所で行います。前者はノードの可用性を管理し、後者はグループ内の選択に使われます。原因を特定しやすくするため、調整を始めるときはテストURL、間隔、フィルター条件、グループの種類を同時に変更しないでください。まず利用可能な候補を1つ残し、自動選択グループから参照できることを確認します。候補が空の場合は、全体モードを何度も切り替えるのではなく、providerとフィルター式を確認してください。

種類	主な用途	注意点
`select`	手動で選択	DIRECTを選ぶと直接接続
`url-test`	測定結果に基づく自動選択	テストURLが選択結果に影響
`fallback`	設定順にフェイルオーバー	優先順位は候補の順番で決まる
`load-balance`	複数の接続を分散	1接続の帯域は合算されない

ルールとプロキシグループの参照関係を確認

変更後はまず、接続の詳細で一致したルールとプロキシの経路を確認します。ルールが業務用グループに一致しているのに最後はDIRECTになる場合、ドメインルールではなくグループ内の選択肢を確認しましょう。ノードが切り替わったのにページの表示が変わらない場合は、既存の長時間接続を閉じてから再試行します。既存のTCPセッションは、グループを手動で選び直しても別の接続先へ自動で移行しません。ブラウザーの接続プール、アプリのバックグラウンド接続、キャッシュによって結果の反映が遅れる場合もあるため、新しい接続で検証してください。

実際の設定では、全体の入口となるグループを1つ用意し、明確な違いがある用途だけ少数のサブグループに分けるのがおすすめです。用途ごとに地域、通信方式、障害時の動作を変える必要がある場合に、グループ分けが役立ちます。ノード選択、測定結果、地域判定の違いについてはプロキシノードの選び方をご覧ください。画面の操作とコアの動作が一致しない場合は、よくある質問でプロキシモードとシステムプロキシの違いを確認してください。

ルール管理 / rule-providers

ルールセットの購読管理と評価順

ルールリストは「この接続をどのプロキシポリシーに振り分けるか」を決めます。Ruleモードでは通常、コアは rules を上から順に評価し、最初に一致したルールで後続のポリシーが決まります。より具体的な別のルールを探して評価し続けることはありません。そのため、順番も設定の意味の一部です。個別の例外は広い範囲を対象とするルールより前に、最後のフォールバックは末尾に配置します。見た目を整えて並べても、論理的に正しいとは限りません。例外、用途別分類、フォールバックの優先順位を管理することが重要です。

管理元のルールとローカルポリシーを分ける

rule-providers で再利用可能なルールセットを定義し、メインのリストから RULE-SET で参照します。ルールセットは一致対象を定義し、どのポリシーを使うかは参照する行で指定します。同じドメイン一覧を使いながら、端末ごとに異なる接続先を設定でき、上流のルールファイルを編集する必要もありません。定期更新が必要な大きなリストでは、内容をすべてサブスクリプションにコピーするより、確認やロールバックが容易になります。

まずローカルファイルで一連の動作を確認してから、リモートの取得元に切り替えるとトラブルを特定しやすくなります。以下は実際に利用できるローカルルールセットの例です。メイン設定とルールファイルは、mihomoの作業ディレクトリを基準に配置します。実際の作業ディレクトリは起動方法やクライアントの管理方式で異なり、ダウンロードフォルダーとは限りません。パスが間違っていると、ファイルの内容が正しくてもコアはルールセットを読み込めません。

config.yaml · ローカルのclassicalルールセット

mode: rule
rule-providers:
  development:
    type: file
    behavior: classical
    format: yaml
    path: ./rules/development.yaml

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - RULE-SET,development,Proxy
  - GEOIP,CN,DIRECT
  - MATCH,Proxy

rules/development.yaml

payload:
  - DOMAIN-SUFFIX,github.com
  - DOMAIN-SUFFIX,githubusercontent.com

内容に合わせてbehaviorとformatを指定

behavior: classicalは、例のDOMAIN-SUFFIXのようにルールタイプを含む項目を受け付けます。ルール項目にProxyを記述する必要はありません。適用するポリシーはRULE-SETの参照行で指定します。domainはドメインのリスト、ipcidrはIPアドレス範囲のリストに使います。内容の記述形式をclassicalと混在させることはできません。formatはYAMLやプレーンテキストなど、データの形式を指定します。ファイルの拡張子だけでは、正しい形式指定の代わりになりません。

HTTPの取得元に切り替える場合は、type を http に変更し、実際にアクセスできる url と秒単位の interval を設定します。キャッシュには独立した path を指定してください。各providerで異なるファイルパスを使い、内容が上書きされないようにします。ダウンロードしたページのエラーメッセージ、アクセス認証ページ、ログインページはルールファイルではありません。ブラウザーでURLを開けても、コアが想定どおりのデータを取得できているとは限りません。

リモートルールを初めて導入するときは、キャッシュのない状態から起動してもファイルを取得できるか確認してください。ルールを取得するドメインへのアクセスに、そのルール自身が必要だと起動時の依存関係が発生します。先にダウンロード経路を確保し、検証済みのローカルキャッシュを残しておくと安心です。ルールproviderの取得失敗とプロキシノードの利用不可は別の問題です。更新ログと接続ログを分けて確認し、サイトが開かないという理由だけで原因の箇所を判断しないでください。

少数のリクエストでルーティングを検証

新しいルールを検証するときは、対象に確実に含まれるドメインを1つ選び、新しい接続を作成して、接続の詳細から一致したルール、ルールセットの内容、プロキシ経路を確認します。より前にあるDIRECTルールに一致した場合は優先順位を調整します。期待したルールセットが表示されない場合は、provider名、読み込み状態、ファイル内容を確認してください。IP系ルールは名前解決や宛先アドレス情報にも依存するため、常にドメインルールの代わりになるとは限りません。

LAN内の端末、プリンター、ローカルサービスには、明確な直接接続の範囲を設定し、広範囲のプロキシルールに先回りして一致しないことを確認してください。REJECTルールを追加する前に、対象ドメインが複数の用途で共用されていないか確認します。コンテンツ配信に使われるドメインを誤って拒否すると、ログイン、画像表示、更新に問題が発生することがあります。調査中は、疑わしいルールを一時的に結果を確認しやすいポリシーへ変更し、結果を記録してください。手掛かりを失わないよう、ルールセット全体をすぐ削除するのは避けましょう。

ルールセットの更新は外部入力の変更として扱い、サブスクリプションのノード更新とは分けて管理します。更新後に一部のサイトだけで問題が出た場合は、DNSやTUNを同時にリセットせず、該当するルールファイルを戻すか、対象のRULE-SETを一時停止してください。個人用の例外はローカルオーバーライドに保存し、理由と対象をコメントに残すと、上流リストの更新後も設定を維持できます。コアと旧版のルール対応の違いは、mihomoとオリジナル版Clashコアの比較をご覧ください。

名前解決の経路 / dns

DNS設定の最適化と名前解決の経路

DNS設定では、まず3点を整理します。誰が問い合わせを行い、どの経路でリゾルバーに到達し、結果がどの接続に使われるのか。システムDNS、ブラウザーのセキュアDNS、アプリ内蔵のリゾルバー、mihomoのDNSが同時に動作することがあります。nameserver を変更しただけでは、すべてのアプリの問い合わせがコアを経由するとは限りません。サイトが開くことだけで、想定どおりに名前解決されているとも判断できません。まず実際の問い合わせ経路を整理してから項目を変更すると、リゾルバーを複数登録するより効果的です。

起動時の名前解決と通信先の名前解決を分けて考える

default-nameserver はDNSサーバー自体のホスト名を解決します。暗号化されたリゾルバーを起動するとき、「接続先のアドレスが分からないと問い合わせを送れない」という問題を解消します。nameserver は通常のドメイン問い合わせに使う上流リゾルバーです。proxy-server-nameserver はプロキシノードのホスト名を解決し、プロキシ接続に必要な名前解決と通信先ドメインの名前解決を分けるのに役立ちます。3つの項目は異なる段階で使われるもので、単純な第1・第2・第3の予備サーバーではありません。

まず、プロキシ経由の通信に依存しない基本設定を示します。待ち受けアドレス、上流リゾルバー、ドメインのポリシーが機能しているか確認できますが、すべてのネットワークでプライバシーや接続性が保証されるわけではありません。リゾルバーのアドレスは、実際のネットワーク環境と運用方針に合わせて選んでください。あるネットワークで使えるパブリックリゾルバーが、すべての接続環境で利用できるとは限りません。

config.yaml · 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
  proxy-server-nameserver:
    - https://dns.alidns.com/dns-query
  nameserver:
    - https://dns.alidns.com/dns-query
  nameserver-policy:
    '+.example.com':
      - https://dns.alidns.com/dns-query

ドメイン別の上流リゾルバー選択とルールによる接続先選択

nameserver-policy はドメインに応じて上流リゾルバーを選びます。例の +.example.com は、ドメインとそのサブドメインに適用されます。これは「どのリゾルバーに問い合わせるか」を決める設定であり、「サイトへの接続をどの経路にするか」とは別です。接続先はプロキシモード、ルール、プロキシグループで決まります。企業内ドメインでは組織内DNSが必要な場合があり、パブリックリゾルバーには該当するレコードがないこともあります。現在のネットワークから内部リゾルバーに接続できるか、先に確認してください。

DNSの上流への接続にもルーティングルールを適用する場合は、respect-rules の利用を検討できます。有効にする前に、プロキシノードのホスト名を解決する方法を確保してください。ノードの解決にプロキシが必要で、そのプロキシへの接続にはノードの解決が必要という循環が起こる可能性があります。「DNS漏れ対策」として紹介されたスイッチの組み合わせをコピーするだけでは不十分です。ノードの名前解決、上流リゾルバーへの接続、通常のドメイン問い合わせをそれぞれ確認し、特にキャッシュなしの初回起動時の動作を検証してください。

fallback と fallback-filter には独自の応答フィルターの仕組みがあります。「最初のサーバーが失敗したら次に問い合わせる」という単純な設定ではありません。上流リゾルバーを増やせば信頼性が上がるとも限りません。異なるアドレスが返され、コンテンツ配信の接続先や障害の現れ方に差が出ることがあります。明確なフィルター要件がなければ、説明しやすい少数の上流リゾルバーから始め、問い合わせ経路を記録してから設定を複雑にしてください。

待ち受け・キャッシュ・IPv6の注意点

例ではループバックアドレスのポート1053で待ち受けます。ポートを開いただけで、システムが自動的に利用するわけではありません。システムDNSの設定では通常、任意のポートを直接指定できないため、TUNによるDNS横取り、システムの名前解決サービスからの転送、またはポートを指定できるテストツールが必要です。dig を使えば待ち受け先を直接検証できますが、その結果が示すのはコアに明示的に送信した今回の問い合わせだけです。すべてのアプリが接続済みとは限りません。

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

dns.ipv6 はコアのDNSがAAAA問い合わせをどう処理するかを制御し、トップレベルの ipv6 はコアのIPv6対応に関係します。設定階層が異なるため、同じ項目ではありません。どちらかを無効にしても、OSやブラウザーがIPv6を完全に使わなくなるとは限りません。一部のアプリだけが想定した経路を通らない場合は、DNS設定の値を何度も切り替えるのではなく、OSのIPv6ルート、アプリのセキュアDNS、プロキシへの接続方法、既存の接続を確認してください。

名前解決のポリシーを変更した後も、古いキャッシュによって変更前の結果が表示されることがあります。コア、システム、ブラウザーそれぞれのキャッシュを考慮し、必要に応じて既存の接続を閉じて再問い合わせしてください。Fake-IPアドレスが表示されても、実際のサーバーの地域を示すわけではありません。これはコアが割り当てた対応付け用のアドレスです。DNS汚染、接管する範囲、暗号化DNSの経路については、DNS漏れの検査と対処も参照し、検査、設定変更、再検査の順に確認してください。

ネットワーク制御 / tun

TUNモードとFake-IPの連携

TUNは仮想ネットワークインターフェースを通じて、システムのルーティングから渡されるIP通信を受け取ります。システムHTTPプロキシに従わないアプリに適しています。Fake-IPはDNSの動作方式の一つで、ドメインに対応付けるためのアドレスを返します。両方を組み合わせることは多いものの、役割は異なります。TUNは通信がコアに入る経路を決め、Fake-IPはドメインと接続の関連付けをコアに保持するのに役立ちます。TUNを有効にしてもすべてのDNS経路が自動修正されるわけではなく、Fake-IPを使うすべての場面でTUNが必須というわけでもありません。

権限とシステムルートを先に確認

デスクトップクライアントは、サービスモードや権限昇格によって仮想インターフェースとルートを作成する場合があります。モバイル端末では通常、OSのVPNインターフェースを通じて接続し、画面上でVPNモードと表示されることもあります。デスクトップのネットワークインターフェース設定をそのまま適用しないでください。Linuxの実行権限、ルート管理、名前解決サービスも、導入方法によって異なります。初めて有効にしたときは、クライアントでネットワーク制御が成功したことを確認し、その後でルートとDNSを確認してください。スイッチがオンになっているだけで、ネットワークスタックが正常に動作していると判断しないようにしましょう。

次の設定例は、自動ルートとDNS横取りの関係を示しています。前章のDNS設定と組み合わせてください。stack はシステムとコアの対応状況に応じて選べます。mixed がすべての環境で高速とは限りません。ほかのVPN、コンテナネットワーク、企業ネットワークのトンネルを使っている場合、自動ルートが競合することがあります。元に戻せるローカル環境で、項目ごとに検証してください。

config.yaml · TUNとDNSの連携設定

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'

DNS横取りは、すべての名前解決プロトコルに適用されるわけではない

dns-hijack の any:53 は、接管経路に入った通常のDNS通信を対象とします。アプリがHTTPSなどの暗号化プロトコルでリゾルバーに接続する場合、DNSの内容だからといってポート53の問い合わせに自動変換されるわけではありません。ブラウザーのセキュアDNSやアプリ内蔵の名前解決も個別に確認する必要があります。名前解決の経路を統一するには、まずアプリにシステムの名前解決を使わせ、システムからの問い合わせが確実にコアへ入ることを確認してください。

auto-detect-interface は実際の送信インターフェースの選択に役立ちますが、複数のネットワークアダプター、テザリング、ネットワーク切り替え、既存のトンネルによって自動判定が適切でないことがあります。TUNを有効にするとすべての接続がタイムアウトし、無効にするとすぐ復旧する場合が典型例です。実際のデフォルト経路とルートがループしていないか確認し、続けてコアの接続ログを調べてください。ノードを切り替えても、送信経路の選択ミスは解決しません。リモートサーバーを管理する場合は、特に別の復旧手段を確保してください。

一部のシステムでは strict-route によってルートの制約を強められますが、LANへのアクセスに影響したり、ほかのネットワーク機能と競合したりする場合があります。原因を特定できていない段階で、むやみに有効にする項目ではありません。まず最小限の設定で、直接接続、プロキシ、ローカルネットワークの動作を記録し、明確な要件に応じて制限を追加してください。プラットフォームごとにファイアウォールやルーティングの実装が異なるため、同じ設定例でも結果が同じとは限りません。

Fake-IPの例外とローカルサービス

一部のデバイス検出、LAN内サービス、実アドレスを必要とするアプリはFake-IPとの相性がよくないため、fake-ip-filter で例外を指定できます。例では通常ローカルで名前解決する必要があるドメインのサフィックスを使っていますが、実際の例外は対象アプリに合わせてください。例外にすると、そのドメインは該当モードに応じて実際の名前解決結果を返します。ただし、通信が必ず直接接続されるわけではありません。後続のルールによって、実アドレスへの接続がプロキシに送られる場合もあります。

Fake-IPモードやマッピング範囲を切り替えた後も、アプリが古いアドレスを保持していることがあります。古いマッピングと新しいコアの状態が一致しないと、DNSの応答は正常に見えても接続できない場合があります。関連アプリの接続を閉じ、該当する層のDNSキャッシュを消去してから再接続してください。予約済みアドレス範囲全体をリモートサービスのアドレスとして通常のプロキシルールに追加しないでください。ここで使うアドレスはローカルのマッピング用で、実際の接続先はコアが関連情報から復元します。

トラブル対処は、まず仮想インターフェースと権限、次に通常のDNSが接管されているか、その後に接続がコアへ入っているか、最後にルールとプロキシグループ、という順で進めましょう。UDPアプリだけに問題がある場合は、TUNのスタックを切り替えるだけでなく、ノードのプロトコル、サーバー、ネットワーク経路が必要なUDP通信に対応しているか確認してください。LAN内の端末でプロキシを共有する場合は、待ち受けアドレス、ファイアウォール、接続を許可する範囲も確認が必要です。詳しくはmixed-portとallow-lanの設定をご覧ください。TUNを有効にしても、ほかの端末にプロキシ設定が自動で配布されるわけではありません。

ドメインの関連付け / sniffer

ドメインスニッフィングの用途と注意点

ドメインスニッフィングは、接続先がIPアドレスだけで示され、信頼できるドメイン情報がない場合に、一部のプロトコルのハンドシェイクやリクエストからドメインを取得し、ルール判定を補助します。DNSとは役割が異なります。DNSは名前を解決し、スニッフィングはすでにコアへ入った接続を確認します。また、通信を復号するプロキシではないため、有効にしてもすべてのHTTPS本文を読み取れるわけではありません。機能するかを判断する前に、通信がコアまで届いていることを確認してください。制御されていない接続は処理対象外です。

まずプロトコルとポートの範囲を絞る

mihomoではHTTP、TLS、QUICなどをスニッフィング対象として設定できます。HTTPではHost情報、TLSではハンドシェイクのサーバー名が手掛かりになります。QUICにも対応する処理経路があります。ただし、プロトコルの進化、暗号化ハンドシェイクの方式、クライアントの実装、通信の形式によって結果は異なり、すべての接続でドメインが分かるとは限りません。IPアドレスを直接使うアプリや未対応プロトコルでは、最終的にIP系ルールとフォールバックポリシーが必要な場合があります。

初めて使う場合は、必要なポートだけに絞り、ルールの一致が改善するかを確認してから対象を広げましょう。ポートは絞り込み条件の一つにすぎず、対象通信が必ず特定のプロトコルを使うことを示すものではありません。全ポートを対象にしても、動作を説明しやすくなるわけではありません。次の例ではドメインの取得だけを有効にし、実際の接続先は上書きしません。「何を識別したか」と「接続先を変更するか」を分けて検証できます。

config.yaml · 控えめなスニッフィング設定例

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

ドメインの識別と接続先の上書きを分ける

parse-pure-ip を有効にすると、ドメイン情報のないIPアドレスへの接続でもスニッフィングを試みます。force-dns-mapping はDNSマッピングに関係し、関連する接続の処理範囲を広げます。どちらも必ず成功するわけではなく、DNS設定を省略できるものでもありません。override-destination はスニッフィング結果で接続先を上書きするかどうかを決めます。単に名前を識別するより影響が大きいため、対象サービスの動作を理解したうえで検討してください。

たとえば、アプリが内部の振り分けによってサービスのIPアドレスを選び、TLSハンドシェイクでドメインを送ることがあります。接続先を上書きしてドメインから再接続すると、実際に選ばれるアドレスが変わり、アプリ本来の振り分けや接続性に影響する場合があります。「スニッフィングを有効にしたら一部のサイトで問題が出た」ときは、ドメインルールの変化と接続先の上書きを切り分けましょう。接続ログを残し、同じリクエストで上書きの有無、スニッフィングの有無を個別に比較すると、すべての設定を同時にリセットするより原因を特定しやすくなります。

skip-domain を使うと、指定したドメインをスニッフィング対象から除外できます。上の example.com は書式を示す例で、常に必要な除外設定ではありません。実際に必要な対象だけを残してください。除外範囲が広すぎると、スニッフィングに頼るドメインの振り分けができなくなることがあります。狭すぎると関連するサブドメインを除外しきれない場合があります。例外を追加した後は、新しい接続を作成し、識別されたドメインが想定どおりか確認してください。

検証可能なルーティング経路にスニッフィングを組み込む

検証する際は、再現可能な対象を1つ選び、スニッフィングを無効にした状態で接続先アドレス、ルール、ポリシーを記録します。その後、スニッフィングを有効にして新しい接続を作成してください。ルールがIP系からDOMAIN-SUFFIXに変われば、ドメイン情報が判定に使われています。変化がなくても、すぐに機能していないと判断しないでください。接続に既存のDNSマッピングが使われていたり、スニッフィングで利用可能な名前を取得できなかったりする可能性があります。ページの読み込みに複数のドメインが関係する場合は、トップページのドメインだけでなく、具体的に失敗した接続を確認してください。

スニッフィングで取得した名前は、アドレスバーに表示される名前と一致するとは限りません。リダイレクト、コンテンツ配信、リソース、バックエンドの各サービスで異なるドメインが使われることがあります。特定の地域や固定の接続先が必要な場合は、メインドメインだけから全リソースを推測せず、実際の接続先ドメインを管理してください。ルールに一致した後のノード選択はプロキシグループが行います。スニッフィングでは、ノードの接続不可、アカウントの無効化、サービス側の制限は解決できません。

本番環境では必要最小限の対象に絞り、設定ミスを補う手段としてスニッフィングを使わないようにしましょう。まずシステムDNS、Fake-IPのマッピング、TUNによる接管がそれぞれ正しく動作することを確認し、ドメイン情報が不足する接続をスニッフィングで補います。特定のアプリだけで問題が起きる場合は、そのアプリ向けの例外を明示し、理由をコメントに残してください。原因を確認してから長期的な対応を決めましょう。基本用語は用語集で確認できます。初回読み込み後にインターネットへ接続できない場合は、スニッフィングの対象を広げる前にクイックスタートガイドに沿ってプロキシへの接続とノードを確認してください。

設定のライフサイクル / merge

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

サブスクリプションファイルは外部から取得する入力で、ローカルオーバーライドはユーザーが管理する設定レイヤーです。実際に動作する設定は、クライアントが両者を処理した結果です。この3つを混同しないでください。ダウンロードしたサブスクリプションを直接編集しても、次回の更新で変更が上書きされる可能性があります。オーバーライドのテンプレートだけ編集して現在の設定に適用しなければ、コアの動作は変わりません。変更前に、クライアントで有効な設定、オーバーライドの適用範囲、最終的に生成されるファイルを確認し、対象を間違えたまま操作を繰り返さないようにしましょう。

設定レイヤーごとの管理範囲を決める

クライアントによってオーバーライド画面や統合方法は異なります。すべてのGUIクライアントで使える共通のトップレベルYAML項目 override はありません。利用中のクライアントが提供するオーバーライド、統合、スクリプトの機能を使い、マッピング、リスト、空の値がどのように処理されるか確認してください。ダウンロードページにはClash Plus、Clash Verge Rev、FlClashなどの選択肢がありますが、設定編集画面がすべて同じとは限りません。

管理方法を整理するなら、サブスクリプションはノード情報、ローカル設定レイヤーはプロキシグループ、ルール、DNS、制御インターフェースを担当させるのが分かりやすい方法です。サブスクリプションに一連のルーティング設定がすでに含まれている場合は、上流の構成をそのまま使うか、ノードだけを取り出してローカルで管理するかを決めてください。両方の構成を有効にすると、同名グループ、MATCHルールの重複、設定の上書きが発生しやすくなります。長期的な管理で重要なのは、ファイルを大きくすることではなく、各項目をどの情報源が決めるかを明確にすることです。

複数のノード取得元をproviderで分ける

次の例では、リモートサブスクリプションのURLを使わず、2つのローカルノードproviderの構成を示します。各providerファイルには有効な proxies リストと実際に利用できるノードが必要です。メイン設定から use で読み込みます。まずクライアントから書き出した有効なproviderファイルで検証してからHTTP経由の取得を試すと、取得元の障害とノード設定の問題を分けて対処できます。

config.yaml · 2つの取得元を組み合わせる設定例

proxy-providers:
  source-a:
    type: file
    path: ./providers/source-a.yaml
  source-b:
    type: file
    path: ./providers/source-b.yaml

proxy-groups:
  - name: Proxy
    type: select
    proxies:
      - 取得元A
      - 取得元B
      - DIRECT
  - name: 取得元A
    type: select
    use:
      - source-a
  - name: 取得元B
    type: select
    use:
      - source-b

rules:
  - GEOIP,CN,DIRECT
  - MATCH,Proxy

完全なサブスクリプションとノードproviderファイルでは構造が異なります。rules、proxy-groupsなどのトップレベル項目を含む完全な設定は、ダウンロードURLにアクセスできるというだけで、有効なノードproviderとして扱うことはできません。クライアントにサブスクリプションの変換やノードの抽出機能がある場合は、変換後の形式を確認してください。個人用サブスクリプションのURLを扱う際は、管理されたローカル処理を優先し、信頼できない変換サービスにアクセス情報を渡さないでください。

マッピング・リスト・名前の競合に対処

YAMLのマッピングはキー単位で統合できますが、リストには共通の統合方法が決まっていません。クライアントによって rules 全体を置き換える、先頭に挿入する、末尾に追加するなどの違いがあるため、実際に生成された設定を確認してください。ローカルの例外が上流のMATCHより後ろに追加されると、ファイルに存在していても機能しません。proxy-groups をすべて置き換えると、上流ルールが参照する古いグループ名が使えなくなる場合があります。設定チェックに通ることは、構造や参照が基本的に受け入れられることを示すだけで、ルーティングの意図が正しい保証にはなりません。

同じYAMLマッピング内で dns や rules を重複して記述し、パーサーが自動で統合することを期待しないでください。重複キーはエラーになることも、後の値で上書きされることもあり、結果はパーサーの実装によって異なります。キーを1つにまとめ、インデントの階層を保ってください。YAMLのインデントにはタブを使わず、コロンの後の空白、リスト項目のハイフン、文字列の引用符も正しく記述します。複雑なドメインパターンや特殊文字を含む値は、明示的に引用符で囲むのがおすすめです。

異なる取得元のノードで同じ名前が使われている場合があります。1つのリストに統合すると、参照先が曖昧になったり、クライアントが名前を変更したりすることがあります。取得元ごとにグループを分けると判別しやすくなりますが、有効な設定内のノード識別子と表示名を確認してください。画面に2つの取得元が表示されているだけで完全に分離できているとは限りません。ヘルスチェック、キャッシュファイル、選択状態の保存先も個別に確認しましょう。

適用・検証・ロールバック

変更前に、動作する設定を保存し、ローカルオーバーライドも別に記録しておきます。mihomoのコマンドラインを使える環境では、次の形式で設定を検査できます。コマンドの実行には、実在する設定ファイルと解析可能な参照リソースが必要です。GUIクライアントがコアを管理している場合は、クライアントの検査・適用機能を優先し、同じポートで別のコアを起動しないでください。

mihomo -t -f ./config.yaml

DNS、プロキシグループ、ルール、TUNの順に、一度に1種類だけ変更し、適用後に有効な設定と新しい接続を確認してください。失敗したら、すべてのサブスクリプションを削除してクライアントを再インストールするのではなく、直近の変更だけを元に戻します。サブスクリプションの更新後は、個人用の例外が残っているか、取得元が更新されたか、フォールバックルールが末尾にあるかも確認してください。設定を共有する前には、サブスクリプションURL、ノードの認証情報、制御APIのパスワードを削除します。トラブル対処に必要なのは通常、項目の構造と機密情報を伏せたログで、個人用設定の全体ではありません。

稼働状態 / external-controller

外部コントローラーと動作確認

外部コントローラーはmihomoの制御APIを使って、状態の確認、プロキシポリシーの切り替え、関連する管理操作を行います。新しいプロキシプロトコルでも、通常の通信を受け付ける入口でもありません。external-controller は管理用インターフェースを定義し、mixed-port はHTTPとSOCKSを兼ねるプロキシの待ち受けを定義します。用途は異なります。ブラウザーのプロキシ先を制御ポートにしても正しく通信できません。制御パネルの接続先を混合ポートにしても、稼働状態は取得できません。

まずローカルのループバックで設定

ローカルで使う場合は、管理機能をLANやインターネットに公開しないよう、127.0.0.1 で待ち受ける設定を優先してください。以下のパスワードは説明用の明示的なダミー値です。実際に使うときは、管理されたローカル設定から別途指定してください。external-ui は準備済みのローカル静的パネルのディレクトリを指定します。パスが存在し、中身が揃っている場合にコアが該当ページを提供できます。パネルのファイルがなくてもAPIで状態を確認できます。ページが表示されないことを、制御インターフェースが起動していない理由と混同しないでください。

config.yaml · ローカル管理インターフェースの設定例

mixed-port: 7890
allow-lan: false
external-controller: 127.0.0.1:9090
secret: "your-password"
external-ui: ./dashboard

ローカルパネルには通常 http://127.0.0.1:9090/ui/ でアクセスし、接続設定に制御エンドポイントとパスワードを指定します。項目名はパネルによって異なるため、実際に提供される設定項目を確認してください。GUIクライアントが制御インターフェースを管理し、設定ファイルの内容を上書きする場合もあります。手動で編集してもポートが変わらない場合は、有効な設定と起動ログを確認してください。ポートを奪い合う別のコアを同時に起動しないようにしましょう。

APIで接続・認証・画面表示の問題を切り分ける

次のリクエストはポリシー情報を取得する例で、認証値は上記の説明用ダミー値に対応しています。トラブル対処の際、実際のパスワードを公開スクリーンショット、共有コマンド、問い合わせチケットに記載しないでください。リクエストはコアが動作している端末から実行します。別のパソコン上の127.0.0.1はそのパソコン自身を指し、プロキシサーバーへ自動的に接続するわけではありません。

curl --noproxy '*' \
  -H 'Authorization: Bearer your-password' \
  http://127.0.0.1:9090/proxies

接続が拒否された場合は、待ち受けアドレス、ポートの競合、コアの起動状態を確認します。認証エラーが返る場合は、パスワードとリクエストヘッダーを確認してください。APIが正常に応答してページだけ表示できない場合は、パネルファイル、ブラウザーの開発者コンソール、フロントエンドの接続設定を確認します。この順番でネットワーク、認証、画面表示を切り分ければ、最初からプロキシルールを変更する必要はありません。ブラウザーでクロスオリジン制限が報告された場合は、すべてのサイトに制御ポートへのアクセスを許可するのではなく、パネルとAPIのオリジンの関係を確認してください。

リモート管理には、認証、通信の暗号化、アクセス範囲を別途設計する必要があります。通常はローカルでの待ち受けを維持し、管理された安全な経路からアクセスする方法が最小限の構成です。待ち受けを全インターフェースに変更して、ポートをインターネットへ公開するのは避けてください。リバースプロキシを経由させる場合は、WebSocket、クロスオリジンポリシー、サーバー側のアクセス制御も検討します。制御APIは稼働状態を変更できるため、一般的な読み取り専用ページと同じリスクではありません。

パネルの状態と永続化された設定は別

パネルで切り替えたプロキシグループは主に稼働状態に反映されます。再起動後も維持されるかは、コアの永続化設定とクライアントの管理方式によります。APIで一時的に変更した値も、サブスクリプションやオーバーライドの再適用後に元へ戻る場合があります。長期的に使うルールやネットワーク設定は、管理対象のローカル設定レイヤーに保存してください。パネルは確認や検証に使い、唯一の設定記録にしないようにします。変更後に設定を再読み込みして確認し、期待した動作を再現できることを確かめてください。

接続を確認する際は、接続先ドメイン、宛先アドレス、一致したルール、プロキシ経路、エラーログを関連付けます。対象の接続がコアに一切入っていない場合は、システムプロキシ、TUN、アプリ独自の接続方式を確認してください。コアに入っているのにルールが違う場合は、評価順を見直します。ルールが正しくても接続先が違う場合は、プロキシグループの選択肢を確認してください。接続先が正しいのに失敗する場合は、ノードの対応機能、DNSの結果、接続先サービスを調べます。これにより、あらゆる設定を手当たり次第に変更せずに済みます。

観測結果	優先して確認	次に行う検証
対象の接続が見つからない	通信の取り込みとシステムルート	アプリが実際に使っているネットワーク経路を確認
一致したルールが想定と異なる	評価順・ルールセット・ドメイン情報	新しい接続を作成してルールの詳細を確認
プロキシ経路が直接接続になっている	グループ内の選択肢と入れ子の参照	検証済みの接続先を1つに固定
制御APIは使えるがページに問題がある	パネルファイルと接続設定	ページのリクエストと認証応答を確認

再現可能な設定検証を行う

最後に、固定のテストを用意してください。直接接続するはずの対象、プロキシを使う対象、LAN内のサービス、実際に利用するUDPアプリをそれぞれ1つ選びます。設定を変更するたびに、同じテストの新しい接続だけを比較し、有効な設定とログを記録します。再起動、サブスクリプションの更新、ネットワークの切り替え後も同じ結果を再現できれば、調整は完了です。一般的な接続問題はよくある質問とトラブル対処をご覧ください。読み込みの手順を確認し直す場合はクイックスタートガイドに戻ってください。検証していないスイッチを増やすより、動作を説明できる設定を保存するほうが、長期的な管理に役立ちます。