Clash設定上級ガイド

プロキシグループの種類と実践的な組み合わせ

まず「ノードを選ぶ」と「判定する」を分ける

プロキシグループはルールとプロキシノードの間に位置します。ルールは接続を特定のプロキシ名へ渡すだけで、実際にどの経路を使うかを決めるのはプロキシグループです。両者を混同すると、設定内に大量のノード名を重複して記述することになり、ノードを調整するたびにルールも変更する必要が生じます。より堅牢なのは、「ノード選択」「自動選択」「ストリーミング」「メッセージング」「漏れた通信」のように用途別の安定したプロキシグループを先に作り、ルールではこれらの名前を長期的に参照する構成です。ノードの変化はサブスクリプションとプロキシグループに任せられます。

selectは手動選択グループで、出口を明確に管理したい場面に適しています。クライアント画面でノード、別のプロキシグループ、またはDIRECTを選択すると、設定の再読み込みや永続化状態の変更まで選択が維持されます。経路の品質を自動検査する機能はないため、最上位の入口として使うのが適しています。下位には「自動選択」「フォールバック」や地域別グループを同時に配置できます。自動化を保ちながら、特定サイトで互換性の問題が起きたときはすばやく切り替えられます。

url-testは指定したアドレスへ定期的に接続テストを行い、結果のよいノードを選択します。Web閲覧やソフトウェア更新など、応答時間に敏感で接続を再確立できる通信に適しています。テスト結果が示すのはテスト先への接続状況であり、すべてのサイトの実速度と同じではありません。テスト先までは高速でも、目的のサービスへは遠回りになる場合があります。検査間隔を短くしすぎず、1回のテストを経路品質の永続的な結論とみなさないでください。

fallbackはリスト順に最初の利用可能な項目を選びます。毎回最低遅延を追求するのではなく、安定した優先順位を重視します。主回線を固定し、障害時だけ予備回線へ切り替える構成に適しています。load-balanceは複数ノードへ異なる接続を振り分けます。大量の同時接続や互いに独立したリクエストには使えますが、同じサービスから複数の出口IPが見えると、ログイン状態の変化やリスク制御を招く可能性があります。ネットバンキング、アカウント管理、継続的なセッションを負荷分散グループに安易に任せないでください。

providerで動的なノードを管理する

サブスクリプションのノードは頻繁に追加・削除されるため、各プロキシグループに完全なノード一覧を直接書くと、設定の保守性はすぐに失われます。mihomoではuseでproxy-providersを参照し、filterやexclude-filterでノード名を絞り込めます。フィルター式が処理するのは名前だけで、ノードの実際の場所は検証しません。そのため、サブスクリプション内で安定した命名規則を使うことが重要です。提供元が頻繁に名前を変更する場合は、全ノードを含む自動グループを1つ作り、少数の特殊な経路だけを専用グループへ手動で入れる方法が適しています。

proxy-providers:
  primary:
    type: http
    url: "https://example.com/subscription"
    path: ./providers/primary.yaml
    interval: 86400
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 600

proxy-groups:
  - name: ノード選択
    type: select
    proxies:
      - 自動選択
      - フォールバック
      - DIRECT

  - name: 自動選択
    type: url-test
    use:
      - primary
    url: https://www.gstatic.com/generate_204
    interval: 600
    tolerance: 80

  - name: フォールバック
    type: fallback
    use:
      - primary
    url: https://www.gstatic.com/generate_204
    interval: 600

toleranceは、小さな変動による頻繁な切り替えを抑えます。2つの経路に数ミリ秒しか差がない場合、出口を繰り返し変更するほうが現在の経路を維持するより不安定になりがちです。検査先は軽量で安定し、到達可能な応答を返す必要があります。検査先自体がルールで直接接続になっている、DNSで誤って解決される、または利用中のネットワークから到達できない場合、グループ全体の健全性判定が歪みます。トラブル対処では、まず検査リクエストが実際にどの経路を通ったかを確認し、次にノードが本当に利用不能かを判断してください。

プロキシグループの並び順も操作性に影響します。最上位の手動グループはルールが直接参照する位置に置き、地域グループや自動グループは下位の機能として扱い、循環参照を作らないでください。たとえばAグループがBを含み、BもAを含むと、コアは有効な出口を取得できません。変更後はまずクライアントのプロキシグループ画面で、各グループに選択可能な項目があることを確認します。続いて接続ログの「ルール名—プロキシグループ—実際のノード」という3段階の情報を確認してください。ルールの上から順に行われる照合をさらに理解したい場合は、カスタムルール構文と優先順位の詳しい解説を参照してください。

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

個別ルールからrule-providerへ分離する

少数のカスタムルールはrulesに直接書けますが、ドメイン、ネットワーク帯、アプリ分類が数百件に達すると、メイン設定の確認が難しくなります。ルールセットはルール内容を独立したファイルに分離し、rule-providersにダウンロード、キャッシュ、定期更新を任せる仕組みです。メインのルール一覧には参照順だけを残せます。広告フィルタ、プライベートネットワーク、特定サービス、地域ネットワークのルールを個別に管理でき、ある提供元に問題が起きてもサブスクリプション全体を置き換えずに停止できます。

providerのbehaviorはファイル内容の解釈方法を決めます。domainはドメインの集合向けで、ドメインだけの分類に適しています。ipcidrはIPv4およびIPv6のネットワーク帯向けです。classicalはDOMAIN-SUFFIX、PROCESS-NAME、IP-CIDRのようなタイプ付きの完全なルールを受け取ります。3種類は自由に置き換えられません。domainと宣言したファイルに完全なルール構文を入れると、読み込み時に形式エラーが出たり、想定どおりに一致しなかったりします。

formatは通常、yaml、text、またはバイナリ形式のルールです。YAMLは人が確認しやすく、テキスト形式は1行1ルールの単純なソースに適しています。どの形式を選ぶ場合も、宣言とリモートファイルの実際の内容を一致させてください。pathはローカルキャッシュの保存先です。異なるproviderで同じファイルを共有すると、後からダウンロードした内容が先の内容を上書きします。デスクトップクライアントは通常、設定ディレクトリを管理するため、特定ユーザーのディレクトリを固定するより相対パスのほうが移行しやすくなります。

rule-providers:
  private-network:
    type: http
    behavior: classical
    format: yaml
    path: ./rules/private-network.yaml
    url: "https://example.com/rules/private-network.yaml"
    interval: 86400

  service-domains:
    type: http
    behavior: domain
    format: yaml
    path: ./rules/service-domains.yaml
    url: "https://example.com/rules/service-domains.yaml"
    interval: 86400

  regional-cidr:
    type: http
    behavior: ipcidr
    format: yaml
    path: ./rules/regional-cidr.yaml
    url: "https://example.com/rules/regional-cidr.yaml"
    interval: 86400

rules:
  - RULE-SET,private-network,DIRECT
  - RULE-SET,service-domains,ノード選択
  - RULE-SET,regional-cidr,DIRECT,no-resolve
  - MATCH,漏れた通信

順序、解析、no-resolve

Clashのルールは上から下へ順に照合され、一致すると後続の確認を停止します。そのため「ルールセットにすでにドメインが含まれている」からといって、必ずそのルールセットが使われるとは限りません。より前のルールが一致すれば、後続のproviderは実行されないためです。通常は範囲が狭く意図が明確なローカルルールを前に置き、業務用ルールセットを中央に、地域ネットワークやフォールバックルールを後ろに配置します。特定サイトを一時的に修正する場合も、大規模なリモート集合をすぐ変更するのではなく、メイン設定の先頭に分かりやすいルールを1行追加するのが先です。

IP系ルールではドメイン解決が発生する場合があります。接続が最初はドメインだけを持ち、ルールエンジンが対象IPが特定のネットワーク帯に属するか判定する必要がある場合、コアは先にアドレスを取得しなければなりません。no-resolveは、一致判定のためにこのルールが自発的な解決を行わないことを示します。ドメインルールの後に置くIPルールに適しており、余分なDNS問い合わせを減らし、解決処理による元の判定の変化を防げます。ただし、通信入口がIPしか提供しない場合、IPルールは通常どおり直接一致します。no-resolveはルール自体を無効にする設定ではありません。

リモートルールセットが利用できない場合は、「更新に失敗した」状態と「ローカルキャッシュが利用できない」状態を区別します。有効なキャッシュが残っていれば、一時的なネットワーク障害で全ルールが直ちに消えることは通常ありません。一方、初回読み込み、キャッシュファイルの破損、形式変更ではproviderを準備できない可能性があります。ログでは最終的な接続失敗だけでなく、provider名、HTTPステータス、解析エラー、ローカルパスを重点的に確認してください。リモートURLには安定したHTTPSアドレスを使い、更新頻度に応じて間隔を設定します。1日に1度しか変わらない集合を数分おきにダウンロードする必要はありません。

ルールのサブスクリプション管理は、すべてのルールを第三者に任せるという意味ではありません。LAN内のドメイン、家庭内サーバー、社内テスト環境、個人的な例外はローカル固有の情報なので、自分の上書きファイルに残すのが適切です。公開ルールセットは広範な分類を担当し、ローカルルールは正確な補正を担当します。ルールソースを大規模に入れ替える前に、古いキャッシュとメイン設定のコピーを保存し、いくつかの明確な対象で直接接続、プロキシ、拒否の3種類を検証してください。各テスト接続がなぜ現在の出口へ進んだのか説明できて、初めて移行は完了です。

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

リクエストがどこから発生したかを理解する

DNS設定の難しさはサーバーを増やすことではなく、各問い合わせを誰が発行し、どのネットワーク経路を通り、返却結果がルール判定へどう入るかを明確にすることです。システムアプリはOSのDNSへ問い合わせることもあれば、独自に暗号化DNSを使うこともあります。TUNとDNS hijackを有効にすると、通常の53番ポートの問い合わせはmihomoへ渡せますが、アプリ内蔵の暗号化名前解決は迂回する場合があります。「ブラウザーは開けるのに他のアプリは開けない」場合は、ノードを何度も変更する前に、両者が実際にどの方式で名前解決しているかを比較してください。

nameserverは通常のドメイン解決を担う主要な上流サーバーです。default-nameserverはDoHやDoTの上流サーバー自体のドメインを解決するために使われるため、通常は直接アクセスできるIPアドレスを指定します。そうしないと、「ドメイン形式のDNS上流へ接続するには、まずその上流ドメインを解決する必要があるが、その解決もまだ接続していない上流に依存する」という循環が起きます。proxy-server-nameserverはプロキシサーバーのアドレスを専用に解決できます。ノードのホスト名を安定した解決経路でIPに変換したい場合に適しています。

nameserver-policyでは、ドメインごとに指定した上流へリクエストを振り分けられます。たとえば内部ドメインはLAN内DNSへ、特定サービスは別のリゾルバーへ送れます。これは「どのドメインを誰が解決するか」を決める機能であり、「解決後の接続をどのプロキシグループへ送るか」を決めるものではありません。後者は引き続きルールが決定します。ポリシーの範囲が広すぎると、多くのドメインがメインのnameserverを迂回する可能性があります。変更後は、ポリシーに一致するドメイン、通常のドメイン、ノードのドメインを個別にテストし、3つの経路が独立して機能することを確認してください。

dns:
  enable: true
  listen: 0.0.0.0:1053
  ipv6: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  default-nameserver:
    - 223.5.5.5
    - 1.1.1.1
  nameserver:
    - https://dns.alidns.com/dns-query
    - https://cloudflare-dns.com/dns-query
  proxy-server-nameserver:
    - https://dns.alidns.com/dns-query
  nameserver-policy:
    "+.lan":
      - 192.168.1.1
    "+.internal.example":
      - 192.168.1.1
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "time.*.com"
    - "time.*.gov"

上流サーバーの同時利用は単純な数の競争ではない

上流サーバーを増やせば必ず信頼性が上がるわけではありません。複数のリゾルバーは異なるCDNアドレス、IPv6の結果、地域別経路を返すことがあり、同じドメインの挙動が短時間で変わる原因になります。さらに重要なのは、上流ごとに問い合わせ経路が異なる場合、最速の応答が最終出口に適しているとは限らないことです。たとえば直接接続用DNSが返すアドレスはローカルネットワークには適していても、その後に遠隔ノード経由で接続すると、目的のCDNにとって最適とは限りません。設定時はまず主な出口を決め、そのネットワークモデルに合う上流の組み合わせを選んでください。

ipv6はDNSモジュールがAAAAレコードを返すかどうかを制御しますが、実際にIPv6で接続できるかは物理ネットワーク、TUNスタック、ルーティング、プロキシノードにも左右されます。返却を有効にしてもIPv6経路が使えない場合、アプリが完了しない接続を先に試し、IPv4へフォールバックするため、初回表示が遅くなることがあります。IPv6を無効にするのはトラブル対処の手段であり、経路の能力を確認する代わりにはなりません。家庭用回線、サーバー、ノードがすべてIPv6に対応しているなら、有効のまま直接接続とプロキシ接続を個別に検証できます。

名前解決のキャッシュは重複リクエストを減らしますが、誤った結果を一定時間残すこともあります。hosts、nameserver-policy、fake-ip-filterを変更した後も、古いキャッシュがアプリ、システム、コアで使われる場合があります。標準的な確認順序は、設定を再読み込みし、クライアントのDNSキャッシュを消去し、必要ならOSのキャッシュも消去してから、対象アプリを再起動することです。Webページの更新だけではすべてのキャッシュ層を更新できないことがあります。ブラウザーは独自の接続プールやDNSキャッシュを持つ場合もあるため、テストでは新しいウィンドウを使うか、完全終了して再起動するほうが確実です。

ローカルドメインと特殊サービスのフィルタリング

Fake-IPモードでは、一部のデバイス検出、LANサービス、時刻同期、実アドレスによる検証に依存するアプリはマッピングアドレスに適さないため、fake-ip-filterへ追加します。フィルター範囲はできるだけ狭くしてください。広すぎるワイルドカードを直接追加すると、多くのドメインが実IPモードへ戻り、ドメインルールの安定性が低下します。フィルター項目を追加するたびに、画面キャストでデバイスが見つからない、LANホスト名へアクセスできない、時刻サービスが応答を拒否するなど、対応する現象を記録してください。後で例外がまだ必要か判断しやすくなります。

DNSのリスニングアドレスにも境界があります。デスクトップクライアントを本機だけで使うなら、ポートをLAN全体へ公開する必要はありません。ルーターをゲートウェイとして他の端末へサービスする場合は、到達可能なアドレスで待ち受け、ファイアウォールで送信元を制限します。リッスンに成功しても、システムが実際にそのDNSを使っているとは限りません。システムDNS、TUNのリダイレクト、ポートの使用状況も確認してください。起動ログにbindエラーが出た場合は、ポート競合の特定手順を参照し、既存プロセスを確認してから待ち受けポートを変更します。

TUNモードとFake-IPの連携

TUNでシステムプロキシが取り込めない接続を処理する

システムプロキシが有効なのは、プロキシ設定を自ら読み取るアプリだけです。コマンドラインプログラム、ゲーム、一部のストアアプリ、UDPを直接開始するソフトウェアは完全に無視することがあります。TUNモードは仮想ネットワークインターフェースを作り、システムルートを通るトラフィックをIP層で取り込むため、対象範囲が広がります。ただし「より強いグローバルモード」ではありません。ルールモード、グローバルモード、直接接続モードが、取り込んだ後の振り分け方を決めます。TUNが担うのは、通常なら見えない接続をコアへ届けることです。

TUNを有効にするには、通常、管理者権限またはシステムの許可が必要です。仮想インターフェース、ルーティングテーブル、DNS設定の実装はプラットフォームごとに異なります。クライアントは自動設定を試みますが、スリープ復帰、ネットワーク切り替え、VPNの併用、セキュリティソフトの遮断によって古いルートが残ることがあります。有効化後に完全にネットワークへ接続できなくなったら、まずTUNを無効にして基本ネットワークが復旧することを確認し、その後ログでインターフェース作成、ルート追加、DNSリダイレクトのエラーを確認します。関連するスイッチを複数同時に切り替え続けると、どの操作がシステム状態を変えたのか分からなくなります。

auto-routeはコアが自動でルートを書き込む設定で、一般的なデスクトップ環境に適しています。auto-detect-interfaceは現在のデフォルト出口を識別し、プロキシ接続が再びTUNへ送られてループするのを防ぎます。複数のネットワークカード、仮想マシン、テザリング、または有線と無線の同時接続環境では、自動識別が意図しないインターフェースを選ぶことがあります。その場合はインターフェース名を推測せず、ルーティングテーブルとログに記録された実際のインターフェースを確認してください。strict-routeはバイパス通信をより厳格に制限し、迂回を減らせますが、LANアクセスや他の仮想ネットワークに影響することもあります。

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

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

Fake-IPでドメインの意味を保持する

従来のredir-host方式では、まず実IPを取得してから接続をルールエンジンへ渡します。複数のドメインが同じCDNアドレスを共有している場合、IPだけでは元の対象を判断しにくくなります。Fake-IPは問い合わせたドメインに予約済みアドレス範囲のマッピング値を割り当てます。アプリがそのマッピングアドレスへ接続すると、コアは元のドメインを逆引きし、ドメインルールとリモート解決を適用できます。主な価値はドメインの意味を保持することであり、すべてのDNS問い合わせを高速化することではありません。

マッピングアドレスは通常、実行中のコアとそのキャッシュ内でのみ意味を持ちます。アプリが198.18.0.0/16のようなアドレスへ接続していても、対象が実際にそのネットワーク帯にあるとは限りません。DNS問い合わせがmihomoを通らないまま、アプリが以前のマッピングアドレスを取得したり、接続がTUNに取り込まれなかったりすると、「解決はできるが接続できない」状態が起きます。Fake-IP、DNSリダイレクト、トラフィックの取り込みは同じ経路として確認する必要があります。enhanced-modeだけを有効にし、システムが別のDNSを使い続けていると、設定は完全には機能しません。

UDPはTUNのトラブル対処で見落とされやすい層です。音声通信、ゲーム、QUIC、一部のDNS問い合わせはUDPに依存するため、ノードのプロトコル、クライアント設定、対象サービスがその経路に対応している必要があります。Webページが開けても、一部のTCP通信が正常だと確認できるだけで、TUNのUDP経路全体が機能している証拠にはなりません。まず通常のTCPをテストし、次にDNS UDP、QUIC、実際のアプリを確認します。UDPだけが失敗する場合は、TUN設定全体を否定する前に、ノードの能力、ルールポリシー、システムファイアウォールを調べてください。

MTU、LAN、他のトンネル

一部のネットワークでは、小さなリクエストは正常なのにアップロード、動画、大きなページだけが止まることがあります。MTUやフラグメントが原因かもしれません。TUNによるカプセル化は追加のオーバーヘッドを生み、下位ネットワークがそのサイズのパケットを通せないと、特定の負荷で接続が停止します。MTUは少しずつ調整し、再現可能な大容量ファイルのリクエストで検証してください。あらゆる切断をMTUのせいにしてはいけません。特定のノードだけで起きる場合は、そのノードのプロトコルとトランスポート層の追加オーバーヘッドも比較します。

LANアクセスに失敗したら、まずプライベートネットワーク帯のルールが前方にありDIRECTを指していることを確認し、次にstrict-route、ファイアウォール、対象デバイスが現在のインターフェースからのアクセスを許可しているかを確認します。他のVPNと同時に動かすと、両方のプログラムがデフォルトルートやDNSを変更する可能性があり、最終結果はルートの優先順位で決まります。最も確実なのは、まずClashだけを有効にし、他のトンネルを1つずつ戻す方法です。併用が必要なら、どのネットワーク帯をどのインターフェースが担当するかを明確にし、起動順に頼らないでください。

ドメインスニッフィングと対象の復元

スニッフィングは「IPしか見えていない」接続を処理する

ルールエンジンはドメインを取得するのが理想です。ドメインは共有IPよりもサービスの意味を表しやすいためです。しかし、独自DNSを使うアプリ、システムが実アドレスをキャッシュしている場合、透過プロキシの段階でドメインが付いていない場合など、接続が対象IPだけでコアへ入ることがあります。ドメインスニッフィングは接続初期に見えるプロトコル情報を読み取り、HTTP HostやTLS SNIなどから対象ドメインを復元して、ドメインルールの判定へ渡します。不足情報を補う機能であり、DNSの代替ではありません。

スニッフィングの能力はプロトコル自体の制約を受けます。平文HTTPのHostは通常確認でき、TLSハンドシェイクのSNIも一般的な状況ではドメインを提供します。一方、ドメインを含まない接続方式、識別できないプロトコル、ハンドシェイク情報を隠す暗号化方式では復元できません。UDPプロトコルの可視性も異なるため、すべての通信からドメインを取得できるとは考えないでください。設定では、適切なIPルールとフォールバックポリシーも残しておく必要があります。

override-destinationは、ドメインを識別した後に、それを元の対象に置き換えて接続処理へ使うかどうかを決めます。有効にするとドメインルールとリモート解決を適用しやすくなりますが、固定IPに依存するアプリ、証明書の挙動が特殊なアプリ、接続アドレスと対象ドメインが意図的に異なるアプリでは互換性の問題が起きることがあります。まず一般的なポートに限定して有効にし、skip-domainや既知の問題があるアプリの送信元を対象外にして、小さな例外を作るのが安全です。

sniffer:
  enable: true
  force-dns-mapping: true
  parse-pure-ip: true
  override-destination: true
  sniff:
    HTTP:
      ports:
        - 80
        - 8080-8880
      override-destination: true
    TLS:
      ports:
        - 443
        - 8443
    QUIC:
      ports:
        - 443
  skip-domain:
    - "Mijia Cloud"
    - "+.push.apple.com"

force-dns-mappingとparse-pure-ip

force-dns-mappingは、DNSマッピングに関連する接続へスニッファーの注意を向けます。Fake-IP経路に適しています。parse-pure-ipは、対象が純粋なIPとして現れる通信の解析を試みます。両方を有効にすると対象範囲は広がりますが、より多くの接続が識別処理に入ります。最新のデバイスなら通常この負荷に対応できますが、ルーターなどリソースが限られた環境では接続数、CPU、ログ量を観察してください。設定項目があるからといって、すべてを有効にする必要はありません。

ポート範囲はスニッフィングの精度を制御する重要な境界です。HTTPスニッフィングを全ポートに適用すると、HTTP以外のプロトコルの初期データまで繰り返し解析され、負荷と誤判定の可能性が増します。まず80、8080など明確なWebポートから始めてください。TLSは通常443と少数のカスタムポートに集中します。特定のアプリが特殊なポートを使う場合だけ、接続ログを見て追加します。設定を具体的にするほど、後で一致結果を説明しやすくなります。

スニッフィングとFake-IPはいずれもドメインの復元に役立ちますが、発生する段階が異なります。Fake-IPはDNS問い合わせ時にマッピングを作り、アプリはそのマッピングアドレスへ接続します。スニッフィングは接続が到達した後、プロトコルのハンドシェイクから情報を抽出します。前者は通常より安定し、後者はコアのDNSを迂回する通信、実IP接続、透過プロキシ環境を補う重要な手段です。同じ接続にマッピング由来のドメインとスニッフィング由来のドメインがある場合は、ログで最終的にどちらが採用されたかを確認してください。特にCDNリダイレクトや証明書が汎用ドメインを使うケースに注意が必要です。

誤判定時にスニッフィング全体を無効にしない

特定のアプリがスニッフィング有効化後に異常を起こした場合は、まず具体的な接続を特定します。ログで元の対象IP、復元されたドメイン、一致したルール、最終ポリシーを確認してください。復元されたドメインが対象サービスと明らかに無関係なら、そのドメインをスキップリストへ追加するか、該当プロトコルのポート範囲を狭めます。LANサービスが1つだけ異常なら、そのドメインやネットワーク帯に例外を設定できます。スニッフィングを全体的に無効にすると、ドメイン識別を必要とする他の接続がIPルールへ戻り、気づきにくい振り分けの変化を招く可能性があります。

スニッフィングをテストする際は、ルール結果が明確なドメインを選びます。直接接続すべきサービスとプロキシ接続すべきサービスを1つずつ用意し、アプリの接続キャッシュを消去してからアクセスします。その後、接続詳細にドメインが表示されるかを確認してください。IPしか表示されない場合は、通信がTUNを通っているか、プロトコルを識別できるか、ポートがsniffの範囲に含まれているかを確認します。ドメインが表示されているのにポリシーが誤っているなら、問題はルール順序またはプロキシグループにあり、スニッフィングではありません。「対象の識別」と「出口の選択」を分けて判断すると、誤った層のパラメーターを繰り返し変更せずに済みます。

ドメインスニッフィングでも、誤ったDNSを修正することはできません。アプリが接続前に到達不能なアドレスを取得していると、スニッフィングでドメインを識別できても、下位ルーティング、証明書、対象サービスに影響が残る可能性があります。安定した設定では、正しいDNS取り込みを基本とし、スニッフィングで純粋なIP接続を補い、復元できない通信をIPルールで処理します。3つの層がそれぞれ1つの問題を担当し、重なって初めて完全な判定チェーンになります。

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

上流設定を更新可能な入力として扱う

サブスクリプション設定はサービス提供元が管理しており、更新時にプロキシノード、プロキシグループ、ルールが置き換わることがあります。サブスクリプションから生成されたファイルを直接編集すると、次回の更新でローカルの変更が上書きされるのが一般的です。サブスクリプションを入力として扱い、ローカルの要件を独立した上書き層に置くのが正しい考え方です。サブスクリプションはノードと基本構造を担当し、ローカル層はポート、DNS、TUN、ルールの優先順位、専用プロキシグループを担当します。Clash PlusなどのGUIクライアントには通常、設定上書き、スクリプト、マージの入口があります。名称は異なる場合がありますが、目的はいずれもローカル変更を繰り返し適用できるようにすることです。

上書きには「置換」と「マージ」の2つの意味があります。mixed-portやmodeのようなスカラー項目は通常そのまま置き換えます。dnsのようなマップ項目はキー単位でマージされることもあれば、全体が上書きされることもあります。rulesやproxy-groupsのような配列項目は特に曖昧になりやすい部分です。クライアントによって、新しい配列を末尾に追加するもの、名前でマージするもの、完全に置き換えるものがあります。マージスクリプトを使う前に最終設定を書き出し、入力断片だけでなく実際の結果を確認してください。

ルール配列では、前置と後置を特に区別する必要があります。カスタムの直接接続ルールをMATCHの後ろに置いても機能しません。特定のサービスの振り分けを修正するルールは、通常、リモートの汎用ルールより前に挿入します。マージツールがprependとappendに対応しているなら、意図したほうを明確に選択してください。プロキシグループを名前でマージする場合も、ローカルグループと上流グループが同名で種類だけ異なる状態は避けます。更新後に古いフィールドが残り、理解しにくい混在構造になる可能性があります。

# ローカル上書きの例：具体的なマージ方法はクライアントが提供
mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

dns:
  enable: true
  enhanced-mode: fake-ip

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true

rules:
  - DOMAIN-SUFFIX,internal.example,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve

複数サブスクリプションは単純な連結ではない

複数のサブスクリプションを統合すると、まず名前の衝突が起きます。異なる提供元に「自動選択」「ノード選択」やまったく同じノード名が含まれることがあります。クライアントが名前で重複排除する場合、後から追加された項目が先の項目を上書きする可能性があります。重複排除しない場合は、画面に区別しにくい重複項目が並びます。provider層では異なる提供元名を維持し、自分で統一プロキシグループを作り、useで複数のproviderを同時に参照する方法があります。すべてのノードを静的配列へ展開せず、提供元ごとに一時停止することもできます。

2つ目の問題は更新周期です。複数のサブスクリプションを同時に頻繁に更新すると、リクエスト数が増え、設定の再読み込み時に既存接続が中断されることがあります。ノード情報は通常、分単位で更新する必要はありません。providerは長めの周期で更新し、手動更新は提供元による明確な変更やノード異常の確認に使うとよいでしょう。ヘルスチェックとサブスクリプションのダウンロードは別物です。前者は現在のノードを検査し、後者は新しいノード一覧を取得します。極端に短い更新間隔でヘルスチェックを代用しないでください。

3つ目の問題は、提供元ごとの能力差です。UDPに対応するノードもあれば、対応しないノードもあります。特定地域のサービスに適した経路もあれば、一般的な閲覧向けの経路もあります。すべてのノードを1つの自動グループに混ぜると、業務要件に合わない出口が選ばれる可能性があります。安定して確認できる命名や提供元ごとに専用グループを作り、たとえば「提供元A 自動」「提供元B 予備」のように分けます。最上位の「ノード選択」からこれらのグループを参照してください。ノード名で能力を安定して表せない場合は、実際の接続テストと手動グループ分けで管理するしかありません。

ロールバック可能な変更手順を作る

変更するたびに、上書き断片だけでなく、動作していた最終設定を1つ前の状態として保存します。最終設定ならマージ後の実際の順序も反映され、どの部分が変わったか比較しやすくなります。1回に1つのモジュールだけを調整してください。まずプロキシグループ、次にルール、DNS、最後にTUNとスニッフィングの順です。各段階で、設定を読み込めること、基本的なWebページへアクセスできること、直接接続の対象とプロキシ接続の対象が想定どおりであることを最低限確認します。複数を同時に変更すると操作は減りますが、失敗時の切り分けが難しくなります。

サブスクリプション更新後に異常が出たら、まずproviderが成功しているか、プロキシグループが空でないか、ルールが参照する名前が残っているかを比較します。多くの場合、ノードが無効なのではなく、上流がプロキシグループ名を変更したのに、ローカルルールが古い名前を参照しています。コアの読み込み時には、プロキシやproviderが見つからないというエラーが通常記録されます。クライアントが「設定に失敗しました」としか表示しない場合は、詳細ログで具体的なキー名を確認してください。接続を復旧させるためにローカル上書きをすぐ全削除すると、最も重要な差分情報を失います。

ローカル上書きは短く、説明可能な状態に保ちます。モジュールごとにコメントを書き、あるルールがどの問題を解決するのか記録してもよいですが、長期間不要になった試験用パラメーターをファイルに残し続けないでください。定期的に例外項目を見直し、対象サービスがまだ存在するか、リモートルールセットがすでに対応していないか、以前のネットワーク環境が変わっていないかを確認します。設定管理の目的は項目を増やすことではなく、残した各項目の用途と境界を説明できるようにすることです。

外部コントロールパネルとAPIの境界

コントロールポートでできること

mihomoの外部コントロールインターフェースでは、GUIクライアントやWebパネルからプロキシグループの読み取り、ノードの切り替え、接続の確認、providerの更新、実行状態の一部変更ができます。デスクトップクライアントのプロキシグループ画面、接続一覧、ログ画面の多くはこのインターフェースを基盤にしています。これは管理用のコントロール面であり、プロキシの入口ではありません。mixed-port、HTTPポート、SOCKSポートが通信の転送を担い、external-controllerは管理リクエストだけを処理します。

本機だけで使う場合は、コントロールアドレスをループバックインターフェースにバインドするのが最も安全です。127.0.0.1にバインドすれば、LAN上の他のデバイスから直接アクセスできません。別のデバイスからルーター上のコアを管理する必要がある場合は、LANアドレスで待ち受けることもできますが、同時にアクセス資格情報を設定し、ファイアウォールで送信元を制限し、ポートを公開インターネットへ転送しないでください。管理インターフェースは接続先を確認し、出口を変更できるため、本機の管理権限と同等に扱う必要があります。

external-controller: 127.0.0.1:9090
secret: "your-password"

# 任意：ローカルコントロールパネルのファイルをコアでホストする
external-ui: ./ui

secretが空の場合、コントロールポートへアクセスできるプログラムは認証なしでインターフェースを呼び出せる可能性があります。本機のループバック環境でも、同じ端末上の他プロセスによるアクセスリスクを考慮してください。LANで待ち受ける場合は必ず資格情報を設定します。例にある値は説明用の分かりやすい値にすぎないため、実運用では独自の資格情報に置き換え、サブスクリプションURL、システムアカウント、他のサービスと共有しないでください。パネルに接続できない場合は、アドレス、ポート、プロトコル、資格情報が完全に一致しているか確認します。

external-uiは静的パネルファイルのディレクトリを指定します。コアがこれらのファイルをホストすると、コントロールアドレスから画面を開けます。クライアント内蔵のコントロールパネルを使うこともできます。画面ファイルとコアAPIには互換性が必要です。ページは表示できるのにプロキシグループが空の場合は、ノードのサブスクリプションを再ダウンロードする前に、ブラウザーのネットワークリクエストとコントロールインターフェースの応答を確認してください。静的ファイルの読み込み成功はWebリソースへ到達できたことを示すだけで、API認証の成功を意味しません。

LANアクセスとリバースプロキシ

家庭内サーバーやルーターで使う場合、コントロールポートは本機だけで待ち受け、管理されたリバースプロキシからHTTPS入口を提供する構成が一般的です。アクセス制御と証明書を一元管理でき、管理ポートの直接公開も避けられます。ただし、リバースプロキシの設定を誤るとWebSocketや認証ヘッダーが失われ、パネルのトップページは正常なのに接続一覧がリアルタイム更新されないことがあります。静的ページ、通常のAPIリクエスト、リアルタイム接続チャネルを個別にテストし、問題の層を特定してください。

0.0.0.0で直接待ち受ける場合は、デバイスのファイアウォールを必ず確認します。allow-lanは主にプロキシポートをLAN上のデバイスに許可する設定であり、コントロールインターフェースのファイアウォールではありません。コントロールインターフェースへ到達できるかどうかは、独自の待ち受けアドレスとシステムのネットワークルールで決まります。LAN上の別デバイスからポートをテストできますが、テスト後は送信元ネットワークを制限し、「一時的に便利なアクセス」を恒久的な公開状態にしないでください。

コントロールパネルに表示される接続情報は、コアの現在の状態に基づきます。ポリシーの切り替えは通常、新しく作成される接続にだけ影響し、既存のTCPセッションは切断されるまで古いノードを使い続けることがあります。ノード切り替えをテストする際は、パネルで古い接続を閉じるか対象アプリを再起動してから、新しい接続の経路を確認してください。プロキシグループの現在の選択だけでは、転送中のセッションが移行した証拠にはなりません。

APIのトラブル対処順序

パネルに接続できない場合は、まずコアを実行しているデバイスでコントロールポートが待ち受け中か確認します。次にアクセス側からネットワークへ到達できるかを確認し、最後に認証を確認してください。この順序を逆にしてはいけません。ポートが待ち受けていない状態でブラウザー設定を変えても意味がなく、ネットワークがファイアウォールで遮断されている状態で資格情報を何度変えても成功しません。ポートが他のプログラムと競合している場合は、コントロールポートを変更した後、クライアントやパネルのアドレスも同期して更新します。

パネルは確認作業を効率化できますが、唯一の設定元にしてはいけません。重要な変更は、バックアップ可能なYAML、上書きファイル、クライアント設定へ保存してください。実行時にAPIで切り替えただけの状態は、再起動や再読み込み後にデフォルトへ戻る可能性があります。長期的に使うプロキシ選択はクライアントの永続化機能に任せてもよいですが、構造的な変更は設定ファイルへ戻すべきです。一時操作と永続設定を分けることで、「画面で変更したのに再起動後に消えた」という問題を防げます。

リモート管理ではログの範囲も制御する必要があります。接続一覧には対象ドメイン、送信元アドレス、通信情報が含まれる可能性があり、管理されていないネットワークで公開するのは適切ではありません。通常運用ではトラブル対処に必要な一般的なログレベルにとどめ、問題が起きたときだけ一時的に詳細度を上げ、完了後に戻してください。外部コントロールパネルの価値はルールと接続を把握することであり、すべてのアクセス記録を長期保存することではありません。

設定の検証、連携テスト、障害の特定

まず構文、次に動作を検証する

設定のトラブル対処は2段階に分かれます。第1段階は、YAMLのインデント、フィールドの型、プロキシの参照、providerの形式など、コアが構造を読み取れるかです。第2段階は、読み込み成功後に実際の接続が想定どおりDNS、ルール、プロキシグループを通るかです。構文を通過しても、振り分けが正しいとは限りません。逆に、アプリがネットワークへ接続できない原因も構文エラーとは限らず、単に特定のルールが利用できないノードを選んでいる可能性があります。

YAMLはスペースで階層を表現します。Tab、誤ったインデント、コロン後の形式が構造を変えることがあります。リスト項目のハイフンは正しい階層に置き、真偽値と数字には通常引用符を付けません。特殊文字を含む名前やURLには引用符を付けられます。プロキシグループ名は正確に参照されます。「ノード選択」と「ノード選択 」は似て見えても、末尾の空白によって別の文字列になります。長い設定では、まずログが示す行の周辺を確認し、そこから上へたどって所属モジュールを調べてください。

mihomoではコマンドラインから設定ディレクトリを確認できます。実行ファイル名はプラットフォームとインストール方法によって異なります。以下のコマンドは一般的な確認方法を示すもので、設定ディレクトリを指定してテストし、長期稼働するサービスを直接起動するものではありません。GUIクライアントのユーザーは、クライアントの設定検査機能を使い、コアログの最初のエラーを確認することもできます。後続のエラーは最初の構造エラーによる連鎖であることが多いため、最初に出た1件から修正します。

mihomo -t -d /path/to/config-directory

# 必要に応じてフォアグラウンドで読み込み過程を確認する
mihomo -d /path/to/config-directory

最小検証マトリクスを作る

変更するたびに、少なくとも4種類の対象を検証します。LANアドレスは直接接続、明確な一般サイトは想定したポリシー、プロキシ出口でのみ利用できる対象はプロキシ接続、専用ルールに含まれない対象はフォールバックグループに入ることを確認します。TUNを有効にした場合は、システムプロキシを無視するアプリを1つ追加します。IPv6を有効にした場合は、AレコードとAAAAレコードの接続を個別に確認します。テスト対象を固定すると、異なる設定を比較しやすくなります。

接続ログは処理チェーンに沿って読みます。まず入口の種類を見て、HTTP、SOCKS、TUNのどれから接続されたかを確認します。次に対象がドメインかIPかを見て、DNSマッピングやスニッフィングが機能したか判断します。その後、一致したルールとプロキシグループを確認し、最後に実際のノードまたはDIRECTを確認します。入口が想定と違うなら、ルールを調整し続けても意味がありません。ルールが正しいのにノードが違うなら、問題はプロキシグループの選択です。ノードが正しいのに接続できない場合は、ノードの能力、対象サービス、下位ネットワークを確認します。

DNSの問題は個別に検証してください。問い合わせたドメイン、上流、返却されたレコード種別、接続先を記録し、「Webページが開けない」だけでDNSエラーと判断しないようにします。まず単純なnameserver設定で基準状態を作り、その後policy、Fake-IPフィルター、複数上流を段階的に戻します。項目を1つ戻すたびに同じテストを繰り返してください。複雑なDNS設定を一度に置き換えると、上流へ到達できない問題、ポリシー範囲の広さ、キャッシュの残留が一つの問題に混ざりやすくなります。

一度に変更する変数は1つにする

効果的なトラブル対処には再現性が必要です。高度な機能をすべて無効にして基本接続を復旧し、その後DNS、Fake-IP、TUN、スニッフィング、ルールproviderを順番に有効にするほうが、スイッチを無作為に切り替えるより早く解決できます。各段階の変更と結果を記録し、失敗したら直前の利用可能な設定へ戻します。クライアントが設定の複製に対応しているなら、「基本」「TUNテスト」「完全ルール」の3つの独立した設定を作り、同じファイルを上書きし続けないようにしてください。

ポート関連のエラーでは、どのプロセスが待ち受けているかを確認します。mixed-port、DNSリスニング、external-controllerはいずれも他のプログラムと競合する可能性があり、エラーログのポート番号から確認対象を判断できます。ポートを変更したら、システムプロキシ、パネルのアドレス、その他の依存先も同期して更新します。詳しいコマンドとプラットフォームごとの差異は、Clashのポート競合を特定する手順を参照してください。

すべてのノードがタイムアウトする場合は、まずヘルスチェック先へ到達できるかを確認し、次に1つのノードを手動でテストします。すべてのproviderが同時に失敗しているなら、すべてのノードが偶然同時に無効になったというより、ローカルネットワーク、DNS、サブスクリプション更新、システム時刻に問題がある可能性が高くなります。特定の提供元だけが失敗する場合は、そのproviderのURL、キャッシュ、ノードプロトコルを確認してください。初回接続の基本検証は、ノード選択、遅延測定、プロキシ有効化の確認に戻って順番に確認できます。

パフォーマンス調整は正確性の後に行う

ヘルスチェック間隔を短くする、DNS上流を増やす、スニッフィング範囲を広げる、ルールセットを増やすといった変更は処理量を増やしますが、必ずしも使い勝手を改善しません。まずデフォルトまたは保守的なパラメーターで、正しく安定した処理チェーンを作ります。その後、明確な症状に応じて調整してください。Webページの初回表示が遅いなら、DNS時間と接続時間を分けて測定します。ノード切り替えが頻繁なら、toleranceを上げるか検査間隔を延ばします。ルーターの負荷が高いなら、ルールセット数、検査頻度、スニッフィング対象ポートを減らします。

ログレベルも確認性と負荷に影響します。通常利用では一般的な情報レベルにとどめ、問題の再現中だけ一時的に詳細度を上げ、記録後に戻してください。接続の詳細を長期間大量に出力すると、ディスク書き込みが増え、不要なアクセス記録も蓄積します。トラブル対処用のログには問題発生前後の完全な経路を含めますが、無期限に保存する必要はありません。

成熟した設定はフィールド数では測れません。入口、名前解決、照合、決定、出口の5段階を説明でき、どの高度な機能も基本接続を壊さず個別に無効化できることが重要です。このページのモジュール化設定を完了したら、最終YAMLと上書きファイルを書き出し、クライアント内の重要なスイッチを記録してください。別のデバイスへ移行する場合は、まずダウンロードページから対応プラットフォームのクライアントを選び、マルチプラットフォーム対応のClash Plusを推奨します。その後、説明できない巨大な設定をそのままコピーせず、モジュールごとに復元してください。