設定を体系的に解説 mihomo · YAML

Clashの高度な設定

プロキシグループ、ルールプロバイダー、DNS、TUNによる通信の取り込みを、設定が反映される流れに沿って解説します。各レイヤーの役割を理解してから、変更する項目を判断しましょう。

このページは、設定のインポートが完了している方向けです。初回インストール、VPNの許可、接続確認については、まず使い方ガイドをご覧ください。複数のProfileを整理する場合は、設定ファイルと複数設定の切り替え・管理も参考になります。Clashクライアントを選ぶ際は、まずClash Plusをご確認ください。各プラットフォームのダウンロード先はダウンロードページにまとめています。

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

プロキシグループは「この種類の接続に、どの出口を使うか」を決めます。ルールは通信を判別し、グループは接続先を選び、ノードは実際の接続を確立します。この3つは分けて考える必要があります。ルールが正しく一致してもアクセスできない場合は、グループ内の選択肢やノードに問題があるかもしれません。ノードには接続できるのに通信が意図しない出口を通る場合は、ルールの順序やグループ名の参照を確認しましょう。まず「接続」画面で一致したルール、ポリシーチェーン、最終出口を記録すると、どのレイヤーを変更すべきか判断できます。

手動選択、自動テスト、障害時の切り替え

selectはメンバーを手動で選ぶタイプで、出口を固定したい通信に適しています。メンバーにはノードだけでなく、別のプロキシグループも指定できます。手動選択を最上位の入口として残し、自動グループも選択肢の一つにしておくとよいでしょう。自動テストの結果と実際の使い勝手が異なる場合でも、すべてのルールを編集せずに一時的に出口を固定できます。選択状態はクライアントまたはコアに保存されることがあるため、設定を再読み込みした後は実際の選択先を確認してください。

url-testはテスト用URLに定期的にアクセスし、その結果に基づいてメンバーを選びます。toleranceはわずかな差による頻繁な切り替えを抑えるための設定です。測定結果が示すのは指定URLへのアクセス状況であり、あらゆるWebサイト、ダウンロード、通話の品質を保証するものではありません。fallbackはメンバーの順序に従って利用可能な出口を選ぶ方式で、プライマリとバックアップの構成に適しています。先頭のメンバーが復旧すると再び選ばれる場合があるため、現在のノードを常に維持する粘着性のあるグループとは考えないでください。

load-balanceは複数の接続をメンバーに振り分けます。よく使われる方式にはconsistent-hashingやround-robinがあります。1つの接続を複数ノードに分散して帯域を合算する機能ではありません。ログインセッション、決済認証、長時間接続のサービスなど、出口の変化に敏感な通信は、固定選択のほうが適している場合があります。一貫性ハッシュでも、メンバーの追加や削除によって割り当てが変わるため、出口の安定性が常に保証されるわけではありません。

種類選択基準利用上の注意
selectユーザーがメンバーを選択選択中のメンバーを手動で確認
url-test測定結果と許容差テストURLの結果はすべての通信を示すものではない
fallbackメンバーの順序と利用可能な状態プライマリ／バックアップ向け。接続の引き継ぎではない
load-balance接続の振り分け方式単一接続の帯域は合算されない

意図を把握しやすいポリシーチェーンを作る

次の最小構成例では、参照関係を理解しやすいよう、組み込みの直結先だけを使用しています。実際に使う場合は、すでに登録されているノードや自動グループを「手動出口」のメンバーに追加してください。通信グループから出口グループを参照し、ルールから通信グループを参照します。名前は完全に一致させる必要があります。名前に空白や特殊文字が含まれる場合は、引用符で囲むことをおすすめします。通信グループと出口グループが互いを参照する構成は避けてください。循環参照があると設定の検証に失敗したり、画面上の選択チェーンが意味をなさなくなったりします。

proxy-groups:
  - name: 手動出口
    type: select
    proxies:
      - DIRECT
  - name: 日常利用
    type: select
    proxies:
      - 手動出口
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.com,日常利用
  - MATCH,手動出口

ノードがproxy-providers由来の場合、グループ内では購読URLをproxiesに記述するのではなく、useでプロバイダー名を参照します。自動グループには通常、urlとintervalも必要です。たとえば、テストURLにはhttps://www.gstatic.com/generate_204、間隔には300秒を指定できます。このURLは疎通確認用であり、ネットワーク環境に合わない場合は変更してください。1回のテスト結果だけを根拠に、サブスクリプション全体を削除しないでください。

切り替え後の確認とトラブルシューティング

グループ内の選択を変更したら、新しいアクセスを発生させてから接続の詳細を確認してください。既存の接続はグループを切り替えても通常は移行されず、ブラウザーの接続再利用によって古い出口が維持される場合もあります。確認する際は対象の接続を閉じるか、テストするアプリを再起動してください。接続を閉じると進行中の作業が中断されるため、ダウンロード、会議、リモートセッションを終了できることを先に確認しましょう。既存接続に変化がないことを、設定の再読み込み失敗と誤解しないでください。

自動グループに選択可能なメンバーが表示されない場合は、プロバイダーの読み込み、厳しすぎるフィルター式、メンバー名の一致、ヘルスチェックの実行状況を順に確認してください。メンバーがいるのに頻繁に切り替わる場合は、測定のタイムアウト、テストURLへの到達性、許容差の設定を確認します。不要な重複測定は減らしましょう。複数の自動グループが同じノードを高頻度でテストすると、接続数と消費電力が増えます。特にモバイル端末での常時運用には適しません。

ルールプロバイダーによる管理

ルールプロバイダーを使うと、「どの通信を識別するか」というルールをメイン設定から分離できます。メイン設定にはポリシーの順序と適用先グループを残し、プロバイダーファイルでドメインやIPレンジの一覧を管理します。これにより、ある通信カテゴリを更新するときに、ノードやDNS設定全体を変更せずに済みます。一方で、ルールの取得元、ダウンロード先、ローカルキャッシュ、ファイル形式が一致している必要があります。ルールのダウンロードに成功しただけでは、通信の判定に使われません。rulesでRULE-SETを指定する必要があります。

behaviorとファイル形式を選ぶ

behavior: domainはドメインの一覧、ipcidrはIPレンジの一覧、classicalはルールタイプを含む完全なエントリーを対象にします。ファイルの拡張子だけでbehaviorを判断することはできません。同じYAMLでも、ドメインリストには+.example.com、classical形式にはDOMAIN-SUFFIX,example.comが記載されていることがあります。形式を取り違えると、解析に失敗したり、意図どおりに一致しなかったりします。インポート前に、提供元が説明する形式を確認してください。

formatはファイルの読み込み形式を指定します。提供元に合わせてyaml、text、または対応するバイナリ形式を選びます。YAML形式のルールセットは通常、payloadの下にエントリーを並べます。テキスト形式は1行ごとに保存します。バイナリ形式にはbehaviorの制限があるため、任意のclassicalファイルの拡張子を変えただけで使えるわけではありません。変換が必要な場合は、コアがサポートする変換ツールを使い、変換前後の意味を確認できるよう元データも残してください。

まずローカルのルールセットで一連の動作を確認する

まずファイル型のプロバイダーを定義し、リモート取得の問題とルールの照合問題を切り分けます。例にある./rules/local-sites.yamlは設定の作業ディレクトリからの相対パスであり、画面からファイルをインポートした場所と同じとは限りません。デスクトップクライアントでは、コア用の独立したディレクトリに実行設定が生成される場合があります。実際の作業ディレクトリを確認し、その場所にルールファイルを作成してください。ディレクトリがない、またはファイルを読み取る権限がない場合は、ルールの内容を調べる前に読み込みエラーを解消しましょう。

rule-providers:
  local-sites:
    type: file
    behavior: domain
    format: yaml
    path: ./rules/local-sites.yaml

rules:
  - RULE-SET,local-sites,DIRECT
  - MATCH,手動出口

対応するlocal-sites.yamlに次の内容を記述します。+.example.comは、mihomoのドメインリストでよく使われるサフィックス指定で、ドメイン本体とサブドメインに一致します。これはrulesで使う、カンマ区切りの完全なルールとは別の形式です。保存して設定を再読み込みした後、対象ドメインにアクセスして接続ルールを確認してください。この節の「手動出口」は前章で定義したグループを指します。個別にテストする場合は、同じ名前のプロキシグループを先に作成してください。

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

ローカルでの照合に成功したら、type: httpに変更して実際のurlとintervalを追加し、キャッシュ用のpathは他と重複しないようにします。更新間隔の単位は秒です。頻繁に更新しても「最新」になるとは限らないため、提供元の更新頻度に合わせて設定してください。ルールの取得にプロキシが必要な場合は、使用中のコアが対応する方式でダウンロード時のポリシーを指定します。ただし、そのポリシーがまだ読み込まれていない同じルールに依存しないようにし、初期化時の相互待ちを避けてください。

分類の数よりルールの順序が重要

通信は通常、上から順にルールと照合され、最初に一致した項目が適用されます。明確な例外を少数だけ先頭に置き、業務別の分類を中ほどに、最後にフォールバックのMATCHを置きます。広範囲のIPレンジや範囲の広いドメインリストを前に置くと、後続の細かいルールに到達しません。複数のルールセットに重複があること自体は問題ではありませんが、重複時にどちらを優先するかを明確にしてください。順序の変更だけで同じドメインの出口が変わると、ノードが不安定になったように見えることがあります。

IP系ルールでは、対象アドレスを得るために名前解決が行われることがあります。対象となるルールにはno-resolveを指定して照合のための名前解決を抑制できますが、接続にドメイン名しかなく、対象IPがまだ分からない場合はルールに一致しないことがあります。すべてのルールを高速化する汎用設定ではありません。まず、その分類がドメインとIPレンジのどちらで行われるのか確認してからbehaviorを選びましょう。ドメイン、IP、プロセスのルールを、追跡しにくい一つの集合にまとめないでください。

更新エラーとキャッシュの確認

リモート更新に失敗する場合は、取得URLが有効か、応答が本当にルールファイルか、既存ルールがダウンロード通信を遮断していないか、ローカルキャッシュに書き込めるかを確認します。ブラウザーでURLを開いてログイン画面が表示されても、コアがルールデータを取得できるとは限りません。古いキャッシュによって既存の分類が動作し続けることもあれば、提供元の失効が見えにくくなることもあります。ページにアクセスできるかだけで判断せず、プロバイダーの更新日時とログを確認してください。

DNS設定の最適化

DNS設定では、アプリからの問い合わせをどこで受けるか、接続先ドメインをどこで名前解決するか、リゾルバーへの通信をどの経路にするか、という3点を考える必要があります。クライアントでDNS機能を有効にしても、すべてのアプリがそのDNS入口を使うとは限りません。ブラウザー内蔵の暗号化DNS、システムキャッシュ、LAN内のリゾルバー、TUNによる取り込み範囲などが実際の経路に影響します。信頼性を期待してリゾルバーを大量に登録するのではなく、まず問い合わせ元と経路を確認しましょう。

通信先の名前解決とノードアドレスの名前解決を分ける

nameserverは一般的な接続先の名前解決に使います。default-nameserverは主にリゾルバーのドメイン名を最初に解決するためのもので、あらゆる問い合わせが失敗した際の共通の代替先ではありません。プロキシノードのサーバーがドメイン名の場合、解決はプロキシ接続の確立前に行われるため、proxy-server-nameserverで個別に設定できます。そうしないと、まだ確立していないプロキシ経由でノードのアドレスを解決しようとする循環依存が発生します。接続には問い合わせが必要なのに、問い合わせには接続が必要、という状態です。

nameserver-policyでは、特定のドメインに使うリゾルバーを指定できます。内部ドメインや、明確な名前解決要件がある通信に適しています。LAN内の名前は、そのネットワークを認識できるDNSサービスに問い合わせましょう。すべてを公共DNSに送るのは避けてください。以下は設定例で、アドレスはパラメーター構成の一例です。実際にはネットワークから到達できるものを選びます。待ち受けアドレスはローカルに限定しています。DNSだけをテストする場合、他のデバイスにポートを公開する必要はありません。

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  default-nameserver:
    - 1.1.1.1
  nameserver:
    - https://cloudflare-dns.com/dns-query
  proxy-server-nameserver:
    - https://cloudflare-dns.com/dns-query
  nameserver-policy:
    '+.home.arpa':
      - system

home.arpaは家庭内ネットワークで使われる特別なドメインです。この例ではシステムの名前解決経路に渡しますが、システム側のリゾルバーがその名前に対応している必要があります。どのLANでも同じドメイン構成だと考えないでください。企業内ネットワークでは専用の内部DNSアドレスが必要な場合があります。変更前に現在のシステム設定を記録しましょう。VPNとローカルネットワークの両方に接続している場合は、内部リゾルバーへの経路がプロキシルールや別のトンネルに奪われていないかも確認してください。

暗号化DNSの通信経路を理解する

DoHやDoTが保護するのはリゾルバーまでの問い合わせ通信であり、最終的な通信がプロキシ経由になるかどうかは決まりません。暗号化DNSを使う場合も、リゾルバーへの到達性、システム時刻、証明書チェーンが正常である必要があります。respect-rulesを有効にすると、リゾルバーへの通信にもルールが適用されます。ノードのドメイン名解決を適切に設定し、循環依存を避けてください。むやみに最初から有効にせず、まず基本の名前解決を確認してから、リゾルバーへの接続がどのルールに一致するかを調べましょう。

fallbackとfallback-filterを使うと、ドメインや応答アドレスに応じて名前解決結果を選べますが、問い合わせや依存先も増えます。同じドメインでもリゾルバーによって異なるアドレスが返るのは、CDNの振り分け、キャッシュ期間、アクセス元の場所などが原因の場合があります。結果が異なるというだけで異常と判断しないでください。まず失敗したドメイン、DNS応答、実際の接続先アドレスを記録し、必要に応じて名前解決をポリシーで分けましょう。あらゆる差異を代替リゾルバーに任せるのは避けてください。

パラメーター役割確認するポイント
listen問い合わせを受け付けるローカルアドレスポートの競合と問い合わせの取り込み口
default-nameserverリゾルバーのドメイン名を解決するための初期問い合わせ起動時にリゾルバーへ直接到達できるか
proxy-server-nameserverノードサーバーのドメイン名解決プロキシへの循環依存が発生していないか
nameserver-policy特定ドメインの名前解決ポリシー内部リゾルバーとネットワーク経路

全体をリセットする前に、単一ドメインでテストする

digが使えるシステムでは、次のコマンドでローカルの待ち受けポートに直接問い合わせできます。Fake-IPモードでマッピング用アドレスが返るのは正常です。このテストで確認できるのはローカルDNSが応答することまでで、実際の通信が成功するかは分かりません。アプリからアクセスを試し、接続にドメイン名が保持されているか、ルールが正しいか、出口が利用できるかを確認してください。応答がない場合は、待ち受け状態、設定の反映、ポートを使用している別プロセスの有無を確認します。

dig @127.0.0.1 -p 1053 example.com A

コマンドでの問い合わせは正常なのにブラウザーだけ失敗する場合は、ブラウザーのセキュアDNS、拡張機能、キャッシュを確認します。すべてのアプリで失敗する場合は、システムDNSと通信の取り込み設定を確認してください。モードを切り替えた後も古いDNSキャッシュが残り、新しい経路に合わないアドレスが使われることがあります。対象アプリの接続を閉じ、システムの方法に従ってキャッシュを消去しましょう。HTTPS証明書のエラーを隠すために証明書検証を無効にしないでください。証明書エラーとプロキシの関係を参考に、時刻、証明書チェーン、ネットワーク経路を切り分けてください。

TUNとFake-IP

TUNは通信を取り込む入口、Fake-IPはDNS応答と接続を結び付ける方式です。併用できますが、同じ機能ではありません。システムプロキシの影響を受けるのは、プロキシ設定に従うアプリが中心です。TUNは仮想ネットワークインターフェースとルートを使い、より多くのIP通信をコアに取り込みます。Fake-IPでは、問い合わせに対してドメインとマッピングアドレスを対応付け、接続がコアに入った後にドメインに基づいて処理します。この2つのレイヤーを理解すると、「TUNを有効にしたのに一部のアプリが取り込まれない」「マッピング用アドレスが返ったのにアクセスできない」といった状況を説明できます。

権限、仮想インターフェース、デフォルトルート

TUNを有効にする前に、Clashクライアントがインターフェースの作成とルート変更に必要な権限を持っているか確認してください。デスクトップでは、管理者権限、サービスモード、特権ヘルパーが必要になることがあります。モバイルではVPNの許可によって通信を取り込むインターフェースを作成します。画面のスイッチがオンでも、クライアントが起動を試みていることしか示さない場合があります。コアのログでインターフェースとルートの状態を確認しましょう。複数のVPN、仮想マシンのネットワーク、セキュリティソフトが同時にルートを変更している場合、クライアントを繰り返し再起動するだけでは競合の原因を特定できません。

以下は一般的な初期設定例です。auto-routeは通信を取り込むルートを自動設定し、auto-detect-interfaceは出口インターフェースの選択を試みます。dns-hijackは指定したDNS通信をコアのDNSモジュールに渡します。stack: mixedの対応状況や動作は、実際に稼働するコアに従います。クライアントが独自のTUN設定を生成する場合は、元のサブスクリプションだけでなく最終的な実行ファイルの値も確認してください。

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

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - '*.lan'
    - '*.local'
    - '+.home.arpa'

DNSのハイジャック対象は、ここで指定した従来型DNSポートの通信です。アプリ内蔵のDoHを自動的に復号するものでも、すべてのマルチキャスト名前解決を取り込むものでもありません。LAN内のデバイス検出、印刷、機器の制御には別のプロトコルが使われることがあるため、システムのルートを確認してください。モバイルのVPN実装とデスクトップのTUN設定項目は完全に同じではありません。クライアント側で制御される項目もあるため、デスクトップ用YAMLのすべてのフィールドがスマートフォンの画面にあるとは限りません。

Fake-IPのマッピングと例外ドメイン

マッピング用アドレスはWebサイトの実サーバーアドレスではないため、ブラウザーに入力する恒久的なアクセス先として使わないでください。アプリがドメインを問い合わせてマッピングを受け取り、コアがその対応関係に基づいて実際の接続を確立します。問い合わせがコアで行われても、接続がコアを迂回すると、アプリはマッピング用アドレスを実際の接続先として扱い、タイムアウトする場合があります。そのためFake-IPモードでは、関連するDNS問い合わせと実際の通信の経路を一致させる必要があります。特に一部のアプリだけを取り込む場合は注意してください。

fake-ip-filterは、特定の名前についてフィルターモードに応じて実アドレスを返すための設定です。実アドレスを必要とするローカルサービスや互換性の例外によく使われます。この例はデフォルトのブラックリスト方式を前提としています。別のフィルターモードを設定する場合は、リストの意味を改めて確認してください。このフィルターは「対象ドメインを直接接続する」ルールではなく、DNS応答の方式だけを変えます。最終的な出口は引き続きrulesで決まります。例外を追加した後は、キャッシュや既存の接続も確認してください。アプリが古いマッピングを使い続ける場合があります。

マッピングには通常、専用の用途に割り当てられたアドレス範囲を使います。家庭内ネットワークで使用中のプライベートIPレンジに安易に変更しないでください。既存ルート、別のVPN、検証用ネットワークと競合する場合は、DNSのマッピング範囲と通信の取り込み経路を両方見直す必要があります。アドレスを一つ変更するだけでは解決しません。IPv6も全体を考慮してください。アプリがAAAAレコードを優先すると、IPv4だけのテストではIPv6通信が取り込まれていないことを見逃す場合があります。IPv6を有効にするかは、ネットワークとクライアントの対応状況に基づいて判断しましょう。

プラットフォームごとの違いと復旧手順

プラットフォーム許可の方法主な確認項目
Windows管理者権限またはサービスモードサービスの状態、ルート、セキュリティソフト
macOS特権ヘルパーまたはシステムの許可ネットワークインターフェース、他のVPN、DNS
Linuxインターフェースとルートを操作する権限権限、ルートテーブル、名前解決サービス
Android / iOSシステムのVPN許可VPNの競合、対象アプリ、バックグラウンド状態

トラブルシューティングでは、まず他のVPNを無効にし、通信を取り込む入口を一つにしてから、コアがインターフェースを作成できたか確認してください。次にDNS応答を確認し、最後に新しい接続を作成してルールへの一致を確認します。特定のアプリだけが失敗する場合は、アプリの除外リスト、プロトコル、内蔵DNSを確認してください。ネットワーク全体が使えない場合は、ルートやDNSの循環依存を優先的に確認します。ノードのタイムアウトを詳しく調べるには、サブスクリプションからDNSまでの確認手順を参考にしてください。設定をすべて削除するのは避けましょう。

ドメインスニッフィング

ドメインスニッフィングは、接続開始時のデータから接続先ドメインを補い、IPアドレスしか分からない通信をドメインルールに一致させるための機能です。アプリが独自に名前解決してIPアドレスへ直接接続すると、コアが対応するDNS情報を持たないことがあります。スニッフィングはプロトコル上可能な範囲で、HTTPのHost、TLSハンドシェイクのサーバー名、対応するQUICハンドシェイク情報を読み取れます。対象は観測可能なプロトコルメタデータです。あらゆるアプリの内容を読み取る機能でも、すべての接続障害を解決する万能機能でもありません。

ドメイン情報を補う必要があるケース

接続の詳細に正しいドメインが表示され、ルールも想定どおりに一致しているなら、通常はスニッフィングの範囲を広げる必要はありません。同じ通信でIPアドレスしか表示されず、ドメイン分類が機能しないうえ、対象プロトコルから名前を取得できる場合は有効化を検討できます。まず具体的な通信を一つ選び、有効化の前後で接続の詳細を比較し、ドメインが実際に補われたか確認してください。ログにスニッフィングの記録があるだけで、出口が意図どおり変わったと判断しないでください。

以下の例では、一般的なHTTPとTLSのポートに限定し、ローカル名の除外リストを残しています。force-dns-mappingとparse-pure-ipは試行範囲を広げるため、マッピング情報の不足やIPアドレスのみの接続を確認できた場合に適しています。最初のトラブルシューティングではこれらを追加せず、デフォルトの範囲で十分か確認してください。通信の取り込み、名前解決、スニッフィングを同時に変更すると、結果を一つの原因に結び付けにくくなります。

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

ドメイン情報の補完と接続先の上書きは別

スニッフィングでドメインが取得されると、コアはルールの照合に利用できます。そのドメインで接続先を上書きするかどうかは、該当する設定で制御します。override-destinationは接続先の処理方法を変えるため、その後の名前解決や接続がアプリの選んだ元のIPアドレスを使わなくなることがあります。CDN、内部ネットワークのマッピング、特定のIPアドレスを意図的に指定する通信では、適さない場合があります。この例では分類結果を先に確認できるよう、HTTPの上書きを無効にしています。すべての接続先をすぐに変更するためではありません。

アプリがあるIPアドレスに接続し、ハンドシェイク中の名前が別のサービスを示す場合は、共有ホスティングや特殊なネットワーク設計による正常な動作かを先に確認してから、上書きするか判断してください。スニッフィング結果がドメインらしく見えるからといって、新しい接続先として適切とは限りません。特定のアドレスを維持する必要がある場合は、ポートを限定する、除外ドメインを追加する、そのケースの上書きを無効にするなどの方法があります。変更後はページが開くかだけでなく、一致したルールと最終接続先アドレスも比較してください。

暗号化プロトコルで観測できる範囲

TLSのサーバー名は、すべての状況で取得できるわけではありません。クライアントハンドシェイク情報が暗号化された接続、名前を含まないハンドシェイク、独自プロトコルでは、有効なドメインを取得できないことがあります。QUICもコアの対応状況、ハンドシェイク形式、通信の取り込み経路に左右されます。スニッフィング設定にQUICを追加しても、該当する通信を識別しようとするだけです。UDPが自動的にTCPへ変換されるわけではなく、ノードが必要なUDP転送に対応することも保証されません。

スニッフィングでは通常、接続開始時のデータを待つ必要があります。ポート範囲を広げすぎると、想定するプロトコル以外の通信も処理対象となり、原因の特定が難しくなります。ゲーム、リアルタイム音声、自作サービスでは、まずプロトコルを確認してから対象に含めるか判断してください。接続に時間がかかる場合は、スニッフィングを無効にした場合と、ポートを限定した場合を比較します。結果を繰り返し確認でき、変化が明確なときに限って原因をスニッフィングに求めましょう。一度たまたまアクセスできたことだけで結論を出さないでください。

除外設定と段階的な検証

skip-domainは、内部ドメイン、元の接続先を維持する必要があるサービス、互換性の問題を確認済みの通信など、スニッフィングに適さない名前を除外するために使います。Fake-IPのフィルターとは役割が異なります。前者はスニッフィングを制限し、後者はDNS応答を変更します。一方のリストにあるドメインが、もう一方にも自動で追加されるわけではありません。両方を調整する場合は、それぞれの理由を記録し、後で片方だけを削除して例外が残ることのないようにしましょう。

検証は3段階で進められます。まず元の設定のまま、ドメインが表示されるかと実際の出口を記録します。次にスニッフィングだけを有効にして、ドメインが補われたか、ルールが変わったか確認します。最後に必要な場合だけ接続先の上書きを試し、接続先アドレスと通信の状態を比較します。各段階で新しい接続を作成し、すぐ戻せる設定ファイルを残してください。ログレベルは確認に必要な範囲で一時的に上げ、調査が終わったら通常のレベルに戻して、不要なドメイン名やアクセス記録の保存を抑えましょう。

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

サブスクリプションの設定とローカルの設定は、更新のタイミングが異なります。提供元はノード、ポリシー、ルールを更新し、ユーザーは待ち受けポート、DNS、通信の例外、取り込み範囲を管理します。ダウンロードしたサブスクリプションを直接編集すると、次回の更新で変更が上書きされることがあります。ローカル設定を上書きレイヤーとして分離すれば、繰り返し利用できます。ただし、上書きはmihomo共通の画面機能ではありません。Clashクライアントによって、ファイルのマージ、スクリプト、GUIの項目、設定テンプレートなど方式が異なります。実際の適用順はクライアント内で確認してください。

元の設定、上書きレイヤー、実行設定

次の3つを分けて管理することをおすすめします。サブスクリプションから保存された元ファイル、ユーザーが管理する上書き設定、クライアントがコアに渡す最終的な実行ファイルです。問題を調べるときは最後のファイルを基準にしてください。画面上のスイッチが生成時にYAMLの値を上書きしたり、同じフィールドがテンプレートで複数回設定されたりすることがあります。元ファイルでDNSが有効でも、実行ファイルに該当ブロックがなければ、元ファイルを編集しても解決しません。生成順序と後から適用される設定元を特定してください。

マップ構造とリスト構造では、マージ方法が異なることがあります。DNSの項目はフィールド単位でマージされても、rules、proxy-groups、ノードのリストは全体が置き換えられる場合があります。一般的なYAMLマージツールの挙動を、そのままクライアントの動作と考えないでください。テストでは、まずログレベルなど変化を確認しやすい項目を一つだけ上書きし、実行ファイルへの反映を確認してからルールリストを追加します。ルールリスト全体が置き換わる場合は、サブスクリプションのルールを明示的に残す必要があります。「一つ追加しただけ」なら追記されるとは限りません。

プロバイダーでノードの取得元を一元管理する

複数のサブスクリプションを統合するために、完全なProfileを2つ連結する必要はありません。対応している複数の取得元をproxy-providersとして登録し、メイン設定ではポリシーとルールを一元管理するほうが扱いやすくなります。以下ではHTTPプロバイダー2つの構成を示しています。URLは説明用の例なので、実際の環境では利用可能で互換性のあるノード取得先に置き換えてください。完全なサブスクリプションをそのままノードプロバイダーとして使えるとは限りません。インポート前に応答形式を確認し、特に使用できるproxiesデータが含まれるか確認しましょう。

proxy-providers:
  source-a:
    type: http
    url: https://example.com/provider-a.yaml
    path: ./providers/source-a.yaml
    interval: 3600
  source-b:
    type: http
    url: https://example.org/provider-b.yaml
    path: ./providers/source-b.yaml
    interval: 3600

proxy-groups:
  - name: 統合出口
    type: select
    use:
      - source-a
      - source-b
    proxies:
      - DIRECT

プロバイダーごとに異なるパスを指定し、別の取得元が同じキャッシュファイルに書き込まないようにしてください。更新間隔は取得元に合わせ、必要に応じて手動で更新します。複数の取得元を極端に短い間隔に設定しないでください。ノード名が重複すると、画面での選択やログの確認が分かりにくくなります。クライアントが対応する名前の整理機能やプロバイダーの上書き機能で、取得元を識別できるようにしましょう。名前に実際のサブスクリプション認証情報を含めないでください。また、重複を解消するために名前の文字をすべて削るのも避けましょう。

ローカルルールを適切な位置に追加する

ローカルの例外ルールを追加する場合は、まず挿入位置を決めます。サブスクリプションのMATCHより後に追加しても、通常は照合されません。少数のローカルルールを前方に置き、その後にサブスクリプションの既存ルールやルールプロバイダーを続ける方法が適切です。クライアントに「先頭ルール」と「末尾ルール」の設定がある場合も、最終的な順序を確認してください。特にテンプレートがフォールバックルールを自動追加する場合は注意が必要です。例外を一度に大量に追加すると、通信に問題が起きた際にどのルールが経路を変えたか特定しにくくなります。

統合後は、プロキシグループの参照も確認してください。元のサブスクリプションのルールが「自動選択」を参照している一方で、新しいテンプレートが「統合出口」しか定義していない場合、ノードのインポートに成功しても、未定義のポリシー名によって設定エラーが発生します。ルールプロバイダー名、ノードプロバイダー名、プロキシグループ名は、それぞれ異なる参照関係です。文字列を一括置換するだけでは不十分です。種類ごとに定義を整理し、参照先を一つずつ確認しましょう。名前を変更した場合は、ルール、グループ内のメンバー、コントロールパネルの表示も確認してください。

構文と機能を回帰テストする

コアのコマンドラインを直接使える場合は、設定テストで構造と参照関係を確認できます。次のコマンドを使うには、システム上でmihomoを実行でき、現在のディレクトリに対象ファイルが存在する必要があります。デスクトップクライアントに設定チェック機能がある場合もあります。構文テストに成功しても、ノードの認証情報が有効であること、ルールの取得元からダウンロードできること、すべての通信が正常であることは保証されません。実際の動作も確認してください。まずローカルサービス、よく使うWebサイト、プロキシが必要な通信を一つずつ試し、接続の詳細を確認します。

mihomo -t -f ./config.yaml

サブスクリプションを更新するたびに、実行設定にローカルDNS、例外ルール、通信の取り込み設定が残っているか抜き取り確認してください。変更した項目、目的、復旧方法を短く記録しておくと、内容の分からないバックアップを多数残すより役立ちます。更新後に起動時のクラッシュが発生した場合は、直近の正常な設定に戻してから、起動時クラッシュをログから特定する方法を参考に、構文、パス、権限を確認してください。すべてのProfileをまとめて削除するのは避けましょう。

外部コントローラー

外部コントロールAPIを使うと、稼働状態の確認、ポリシーの切り替え、接続の表示、コアの一部機能の管理ができます。コントロールパネルはAPIを操作するための画面であり、別のプロキシコアではありません。パネルを開けても、現在のClashクライアントに接続できているとは限りません。コントロールアドレス、認証方式、接続先インスタンスを確認してください。パネルが古いプロセスに接続している一方で、システムプロキシは新しいプロセスを指している場合もあります。「切り替えに成功したのに接続が変わらない」ときは、すぐに再インストールせず、まず操作対象を確認しましょう。

まずローカルにバインドし、リモートアクセスはその後に検討する

external-controllerはHTTPコントロールAPIの待ち受けアドレスを設定します。一般的なデスクトップ利用では127.0.0.1にバインドし、ローカルからの接続だけを受け付ける設定がおすすめです。secretはAPIへのアクセスに使う認証用のシークレットです。ローカルで十分に長く、他と共有しない値を設定してください。以下では待ち受け設定とローカルUIのディレクトリだけを示し、公開して使い回せる認証情報は記載していません。外部パネルを使う前に、ご自身の設定に認証情報を追加してください。コントロール用のシークレットをノードのパスワードやサブスクリプションのトークンと共用しないでください。

external-controller: 127.0.0.1:9090
external-ui: ./ui

external-uiは、準備済みのパネル用静的ファイルのディレクトリを指定します。この設定だけで画面一式が生成されるわけではありません。相対パスの基準はコアの作業ディレクトリによって異なり、クライアントがパネルを内蔵してパスを自動設定する場合もあります。入口ファイルが存在し、コアから読み込めることを確認してからアクセスしてください。画面が空白になる、またはリソースの読み込みに失敗する場合は、UIのディレクトリと静的リソースのパスを確認します。フロントエンドの読み込みエラーを、プロキシノードの障害と取り違えないでください。

API認証とブラウザーの制限

一般的なHTTP APIではBearer認証を使い、リクエストにAuthorizationヘッダーを付けます。パネルでは通常、接続設定にコントロールアドレスとシークレットを保存します。設定後、まず基本状態を取得し、次にポリシーの切り替えを試してください。ブラウザーのオリジン間制限とAPI認証は別の仕組みです。シークレットが正しくても、オリジン間ポリシーによってブロックされることがあります。別オリジンのパネルを使う場合は、コアが対応するCORS設定で信頼できるオリジンを限定してください。トラブルシューティングのために、任意のWebサイトからローカルのコントロールAPIへアクセスできるようにするのは避けましょう。

HTTPSのページからHTTPのコントロールアドレスにアクセスすると、特にコントロールAPIがローカルにない場合、混在コンテンツの制限に遭遇することがあります。ブラウザーのセキュリティ機能を無効にした状態で使い続けないでください。クライアント内蔵のパネルを使うか、パネルとコントロールサービスを適切な同一オリジンのパスに配置する方法を優先します。リモート管理が必要な場合は、アクセス可能なユーザーとネットワークを明確に制限し、認証とTLSに対応した管理用経路や制御されたトンネルを使ってください。コントロールポートを通常の公開Webポートのように扱わないでください。

まず読み取り専用で確認する

以下のコマンドは環境変数からローカルのシークレットを読み取り、実際の値を文書に記載しません。実行前に、ご自身のターミナル環境でMIHOMO_SECRETを設定してください。未設定の場合、空の認証情報を送信せず、コマンドはエラーで終了します。成功した場合、そのアドレスのAPIにアクセスできることは分かりますが、現在のインスタンスかどうかも確認が必要です。接続やログを調べる際は、問題の特定に必要な情報だけを残してください。アクセス先のドメインやネットワークアドレスを含む結果全体を公開しないでください。

: "${MIHOMO_SECRET:?コントロール用シークレットをローカルで設定してください}"
curl --fail --silent --show-error \
  -H "Authorization: Bearer ${MIHOMO_SECRET}" \
  http://127.0.0.1:9090/configs

読み取り専用の確認が正常にできたら、パネルで手動選択グループを一つ切り替え、新しい接続を作成してポリシーチェーンを確認します。APIを直接呼び出す場合は、グループ名のURLエンコードも必要です。空白や日本語を含む名前をそのまま連結しても、すべてのツールが正しく変換するとは限りません。変更操作は通常、実行中の状態に影響しますが、サブスクリプションファイルに書き戻されるとは限りません。再読み込みや再起動後に維持されるかは、キャッシュとクライアントの保存方式によります。長期的に反映させる項目は、適切な設定レイヤーで管理してください。

コントロールポートとプロキシポートを分けて確認する

コントロールAPIのポートは管理用です。HTTP、SOCKS、混合プロキシのポートは通信に使うもので、互いに置き換えられません。ブラウザーのシステムプロキシにコントロールポートを指定すると、Webページにアクセスできません。パネルの接続先に混合プロキシポートを指定しても、ポリシー一覧は取得できません。設定を確認するときは各ポートの用途を明記し、別のプロセスが使用していないか確認しましょう。複数のインスタンスを動かす場合は、それぞれ異なる作業ディレクトリとコントロールポートを使い、キャッシュ、ルールファイル、画面操作が互いに干渉しないようにしてください。

パネルに接続できない場合は、応答に応じて原因を切り分けます。接続自体を確立できない場合は、待ち受けアドレス、プロセス、ファイアウォールを確認してください。認証エラーが返る場合は、シークレットとリクエストヘッダーを確認します。ページは表示されてもデータを取得できない場合は、コントロールアドレス、オリジン間制限、ブラウザーの開発者コンソールを確認してください。ポリシーの切り替えが反映されても既存の通信が変わらない場合は、既存接続の再利用を確認します。ローカル接続のエラーを解決するために、すべてのアドレスで一時的に待ち受けないでください。ローカル管理にLAN全体からAPIへアクセスできる設定は必要ありません。

繰り返し使える設定チェック手順を作る

確認手順は毎回同じ順序にします。まず現在のProfileと稼働中のインスタンスを確認し、次に最終的なYAMLを確認します。その後、プロバイダーの読み込み、プロキシグループのメンバー、ルールの一致を確認し、DNSと通信の取り込み経路を検証してから、スニッフィングやパネルの設定を調整してください。一度に変更する要素は一つにして、元の値と確認結果を記録します。基本的な使い方に戻る場合は使い方ガイドをご覧ください。症状から原因を探す場合はトラブルシューティングへ進み、正常に動作している設定レイヤーを最初から作り直す必要はありません。