Clash 高度な使い方：プロキシ、ルール、トラフィックの取り込み

設定の読み方と変更手順

まず設定を5つの処理レイヤーに分ける

接続がmihomoに入っても、すぐに特定のノードへ送られるわけではありません。カーネルはまず宛先アドレスを取得します。アプリがIPだけを送信した場合は、ドメインスニッフィングでドメインを補えることがあります。DNSモジュールは名前解決の方法を決め、実アドレスまたはFake-IPとの対応を管理します。ルールシステムは上から順に調べ、最初に一致したルールを採用します。その結果がプロキシグループを指し、グループが具体的なプロキシ、直接接続、拒否のいずれかを選びます。TUNはシステムネットワークに近い位置で動作し、通常はシステムプロキシを通らない通信をカーネルへ送ります。この流れを理解すると、トラブル対処は「取り込みがあるか、ドメインがあるか、名前解決できたか、どのルールに一致したか、最終的に誰を選んだか」の順に進められます。

設定ファイルは通常、ポート、動作モード、DNS、TUN、プロキシプロバイダー、プロキシグループ、ルールプロバイダー、ルールで構成されます。フィールドの配置自体が実行順を決めるわけではありませんが、YAMLの階層とインデントによって正しいモジュールに属するかが決まります。一般的なインデントは半角スペース2つで、リスト項目にはハイフンを使います。ブール値は true または false と記述し、引用符は付けません。ポートは整数で記述し、コロン、シャープ記号、特殊文字を含む通常の文字列には引用符を付けるのが安全です。保存前にクライアントの設定検査機能を使い、まず形式エラーを除外してからネットワーク動作を確認しましょう。

mixed-port: 7890
mode: rule
log-level: info
ipv6: false

profile:
  store-selected: true
  store-fake-ip: true

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

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - MATCH,ノード選択

上の骨格は階層関係を示すだけで、完全なサブスクリプションではありません。mixed-port はHTTPとSOCKSの接続を同時に受け付けるため、ローカルアプリで1つのポートを共通指定したい場合に適しています。mode: rule はルールに従って処理することを示します。store-selected はプロキシグループの選択を記憶するために使います。MATCH は最終的なフォールバックです。クライアントがサブスクリプションからプロキシとプロキシグループを生成している場合、例に合わせるために既存部分を削除しないでください。調整したいフィールドだけを上書き領域に追加します。

元に戻せる変更手順を作る

安定した設定変更では、サブスクリプションの元設定、現在利用できる設定、テスト中の変更という3つの状態を残します。元設定は上流の内容を確認するため、現在の設定は復元ポイントとして使い、テスト設定には「開発用ドメインを直接接続にする」「TUNでコマンドラインツールを取り込む」といった明確な目的だけを持たせます。クライアントが上書きに対応している場合は、ローカル変更を上書きファイルに記述し、サブスクリプションのダウンロード結果を直接編集しないのが基本です。サブスクリプションの更新でメイン設定は置き換えられることが多く、直接編集した内容は消える可能性があります。独立した上書きのほうが確認や移行も容易です。

変更後は、設定を読み込めるか、ログに解析エラーがないか、システムプロキシまたはTUNが正常に起動したか、直接接続の対象とプロキシ接続の対象がそれぞれ動作するかを、まず低コストで確認します。その後にルールの一致とDNSを検証します。「Webページが開いた」だけを成功基準にしないでください。ブラウザーキャッシュ、既存接続、OSのDNSキャッシュが問題を隠すことがあります。ルールのテストでは新しいドメインを使うか対象アプリを再起動し、DNSのテストではアプリの接続を閉じて、カーネルログの問い合わせと一致記録を確認します。

ログレベルは通常 info を推奨します。ルールやDNSを追跡するときだけ一時的に debug へ切り替え、完了後に戻してください。大量のログが原因特定を妨げることがあります。画面の表示とカーネルログが一致しない場合は、カーネルが設定を読み込んだか、実際に接続が発生したかを基準に判断します。それでも確認できない場合は FAQで基本的なトラブル分類を確認してください。システムプロキシとTUNの選択に関する問題なら、TUNモードとシステムプロキシの仕組みの違いも参照できます。

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

選択、自動テスト、フェイルオーバー

プロキシグループは、ルールの結果と具体的なプロキシの間にある中間層です。ルールは、サブスクリプション更新で変わるノードを直接指定せず、「ノード選択」「ストリーミング」「開発サービス」のように業務上の意味を持つグループ名へ向けるのが適切です。サブスクリプション更新、ノード削除、一時的な経路変更があっても、グループだけを調整すればよく、多数のルールを修正せずに済みます。最もよく使う select はユーザーがメンバーを明示的に選ぶため動作が安定し、総入口や固定出口が必要な用途に適しています。グループには具体的なプロキシだけでなく、別のプロキシグループも指定できるため、「業務グループ → 地域グループ → 自動速度テストグループ」のような階層を作れます。

url-test は指定したURLへグループ内のプロキシを定期的にテストし、結果の良いメンバーを選択します。日常の自動選択に適していますが、結果が示すのはテスト先までの接続状況であり、目的のWebサイトが同じ経路を使えるとは限りません。fallback は可用性の順序を重視し、通常は先頭から最初に利用できるメンバーを選ぶため、主回線と予備回線の構成に向いています。load-balance は複数メンバーへ接続を分散します。接続を分散する必要がある場面には有効ですが、短時間に出口が変わる可能性があるため、ログイン、決済、セッションの一貫性に依存するサービスでは安易に使わないでください。

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

  - name: 自動選択
    type: url-test
    use:
      - provider-main
    url: https://www.example.com/
    interval: 600
    tolerance: 80
    lazy: true

  - name: フェイルオーバー
    type: fallback
    use:
      - provider-main
    url: https://www.example.com/
    interval: 600
    lazy: true

use はプロキシプロバイダーを参照するため、サブスクリプションのノードが頻繁に変わる場合に適しています。proxies は固定メンバーまたは別のグループ名を列挙します。interval はテスト間隔です。短すぎるとネットワーク要求とモバイル端末の消費電力が増え、長すぎると利用できない経路の発見が遅れます。tolerance は数値のわずかな変動による頻繁な切り替えを抑えます。新しい結果が十分に異なる場合だけ選択が変わります。lazy を有効にすると、長期間使われていないグループで不要な能動テストを減らせます。

ルール数ではなく用途でグループを作る

プロキシグループ名は、ルールの出所ではなく意思決定を表すべきです。「動画ルールセット」という名前ではルールとプロキシが密結合しますが、「ストリーミング」とすれば、ドメインルールからの一致でもルールセットからの一致でも出口の意味が明確です。基本構成は通常、総入口、自動選択、フェイルオーバー、直接接続だけで十分です。明確な差がある用途にだけグループを追加しましょう。グループが増えるほど、サブスクリプション更新後に確認すべき選択肢が増え、循環参照も起きやすくなります。mihomoは循環するプロキシグループから最終プロキシを決定できません。たとえばAがBを参照し、BがAだけを参照する構成は設計段階で避けてください。

地域グループはプロキシプロバイダーをフィルタリングして作れますが、フィルタリングはノード名に依存します。名前はサブスクリプションの上流から提供されるため、日本語の地域名、英語の略称、記号などが混在することがあります。狭すぎる正規表現ではノードを取りこぼし、広すぎると意図しないノードまで含めます。設定後は構文が通るかだけでなく、クライアントでグループを開いてメンバー一覧を確認してください。固定出口を優先するサービスには select を使って手動で固定し、通常の閲覧では総入口のデフォルトを自動選択にするとよいでしょう。

proxy-groups:
  - name: 開発サービス
    type: select
    proxies:
      - ノード選択
      - フェイルオーバー
      - DIRECT

  - name: ローカル直接接続
    type: select
    proxies:
      - DIRECT
      - ノード選択

rules:
  - DOMAIN-SUFFIX,internal.example,DIRECT
  - RULE-SET,development,開発サービス
  - GEOIP,LAN,DIRECT,no-resolve
  - MATCH,ノード選択

DIRECT と REJECT もルールの宛先にできる組み込みプロキシです。直接接続はカーネルを迂回することを意味しません。ルールモードでは接続がいったんClashに入り、カーネルが直接接続を確立する場合があります。LAN機器へのアクセスに問題がある場合は、ルールが直接接続を指定しているか、TUNが競合するルートを作成していないか、OSのファイアウォールがどうなっているかを同時に確認します。拒否は明確に不要なドメインに適していますが、ルールセットが広すぎるとページのリソースが欠落することがあります。変更後はトップページ、ログイン、画像、APIリクエストをテストし、トップページが開くだけで判断しないでください。

プロキシグループを調べるときは、まずグループ内にメンバーがあるか、次に現在のメンバーが接続を確立できるか、最後にルールが本当にそのグループを指しているかを確認します。サブスクリプション更新後にグループが空になった場合、よくある原因はプロキシプロバイダーの読み込み失敗、または新しいノード名にフィルターが一致していないことです。グループが動作しても再起動のたびにデフォルトへ戻るなら、profile.store-selected が有効か、クライアントが一時設定で永続化ディレクトリを上書きしていないかを確認します。クライアントはダウンロードページでプラットフォーム別に比較できます。GUIユーザーにはまずClash Plusを推奨し、システム要件に応じてClash Verge RevまたはFlClashを選んでください。

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

ルールの順序が最終結果を決める

Clashのルールは上から下へ評価され、最初に一致した時点で処理を停止します。ルール数よりも優先順位が重要です。通常は、単一ドメイン、特定のサフィックス、LANアドレスなど、範囲が明確なカスタムルールを先頭に置きます。その後に用途別のルールセット、後方に地域IP、通常の直接接続、最終フォールバックを配置します。MATCH を途中に置くと、後続のルールは永遠に実行されません。広いドメインサフィックスを精密なルールより前に置くと、精密なルールで上書きする機会も失われます。

DOMAIN は完全なドメイン名に一致し、単一ホストに適しています。DOMAIN-SUFFIX はドメインとサブドメインに一致し、1つのサイト体系に向いています。DOMAIN-KEYWORD は範囲が広く誤一致しやすいため、ドメイン構造が実際に一定しない場合だけ使用します。IP-CIDR と IP-CIDR6 はアドレス範囲を処理します。IPルールは名前解決を発生させる場合があります。前段でドメインによる判定が済んでいる場合や、既存の宛先IPだけを対象にしたい場合は、状況に応じて no-resolve を付けて余計な問い合わせを減らせます。

rule-providersの動作タイプ

ルールプロバイダーを使うと、外部ルールファイルをメイン設定から分離して管理できます。behavior: domain はドメイン項目だけを含む集合に適し、behavior: ipcidr はアドレス範囲の集合に使います。behavior: classical はルール種別とパラメータを含む完全な項目に対応し、表現力が最も高いタイプです。動作タイプはファイル内容と一致させる必要があります。DOMAIN-SUFFIX,example.com をドメインのペイロードだけを受け付けるファイルに入れたり、純粋なアドレス範囲をclassicalとして扱ったりすると、読み込み失敗や不一致につながります。

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

  local-network:
    type: file
    behavior: ipcidr
    format: yaml
    path: ./ruleset/local-network.yaml

rules:
  - DOMAIN,build.internal.example,DIRECT
  - RULE-SET,development,開発サービス
  - RULE-SET,local-network,DIRECT,no-resolve
  - MATCH,ノード選択

type: http はURLから更新し、type: file はローカルファイルだけを読み込みます。path はキャッシュまたはローカルファイルの場所です。各プロバイダーに固有のファイル名を設定し、複数のルールソースが互いに上書きしないようにしてください。interval の更新周期の単位は秒です。ルール内容の変化が少ない場合、短い周期にする必要はありません。1日1回の更新にすればリクエスト量を管理しやすくなります。リモートURLには安定したHTTPSの提供元を使い、組織内ルールは管理下のサービスに置いて、一時的なリンクへの依存を避けてください。

payload:
  - DOMAIN,api.example.com
  - DOMAIN-SUFFIX,developer.example
  - PROCESS-NAME,git
  - IP-CIDR,192.0.2.0/24,no-resolve

これはclassical形式のYAMLルールファイルでよく使われる構成です。プロバイダーファイルには一致条件だけを記述し、最終的なプロキシは指定しません。プロキシはメイン設定の RULE-SET,development,開発サービス で指定します。同じルールセットを、デスクトップでは「開発サービス」、サーバーでは固定出口というように、端末ごとに異なるプロキシへ向けられます。プロキシを変更するときはメイン設定だけを修正し、2つ目のルールデータをコピーして管理する必要はありません。

サブスクリプション化したルールの管理範囲

ルールセットを無制限に分割しないでください。プロバイダーごとにダウンロード、解析、キャッシュ、障害特定のコストが発生します。独立したセットに向くのは、担当者が異なる、更新頻度が違う、複数設定で再利用する、個別に有効・無効を切り替えたいなど、責任範囲が明確な内容です。3〜4件程度で長期間変わらないローカルルールなら、メインルールの先頭に直接置くほうが明快です。名前は work-services、private-network のように用途を示し、意味のない rules1 は避けます。

更新に失敗したら、まず「リモートダウンロードの失敗」と「ファイル解析の失敗」を分けます。前者はURLへの到達性、DNS、プロキシ経由で更新が必要なプロバイダーかどうかを確認します。後者は動作タイプ、形式、インデント、ペイロード構造を確認します。キャッシュが残っている場合、一部のクライアントは古いファイルを使い続けるため、ページが一時的に表示できても更新成功とは限りません。ログでプロバイダー名と更新時刻を確認し、手動更新後に新しいエラーが出ていないか確認してください。GeoIPやGeoSiteデータに関するルールで問題がある場合は、GeoIP・GeoSiteデータベースの更新方法も参照できます。

ルールの保守が終わったら、固定のテストセットを用意します。明確に直接接続するドメイン、明確にプロキシを使うドメイン、LANアドレス、IPだけの接続、最終フォールバックの対象をそれぞれ1つ以上含めます。ルールソースを更新するたびに同じテストを実行すれば、順序の変化、ルールソースの失効、誤一致をすばやく発見できます。テスト結果は一致したルールとプロキシ名で判断し、Webページの見た目だけを基準にしないでください。ルールセットが増え続けても、説明可能な状態を保てます。

DNS設定の最適化と分岐

まずmihomo DNSの役割を明確にする

mihomo DNSを有効にすると、カーネルがルールに従ってドメイン問い合わせを処理し、その結果を後続の接続と関連付けられます。単に「DNSアドレスを変更する」機能ではなく、ドメイン解決とプロキシ判断を同じ経路に置く仕組みです。アプリが独自の暗号化DNSを使う、固定アドレスへ直接接続する、独立したhostsファイルを読む場合は、問い合わせがカーネルを迂回することがあります。この場合 nameserver だけを変更しても動作は変わらないため、TUNのDNSハイジャック、ブラウザー設定、ドメインスニッフィングも合わせて確認します。

default-nameserver は主に他のDNSサーバー自身のドメイン名を解決するために使い、直接到達できるIPアドレスを指定するのが一般的です。「暗号化DNSへ接続するには先に名前解決が必要だが、現在利用できるDNSがない」という循環を避けられます。nameserver は通常の問い合わせを処理します。proxy-server-nameserver はプロキシサーバーのドメイン名専用に解決でき、通常の分岐に依存するノード名解決を減らせます。nameserver-policy はドメインごとにDNSサーバーを指定し、内部ドメイン、LANドメイン、解決先が異なる用途に適しています。

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

例にあるアドレスは利用環境に合わせて置き換えてください。listen は、本当に同じ端末の他のプログラムから問い合わせを受ける必要がある場合だけ設定します。すべてのインターフェースにバインドする場合は、OSのファイアウォールとLANからのアクセス範囲も確認してください。デスクトップクライアントは通常、待ち受けアドレスを自動管理するため、設定例をコピーする目的で無理に公開する必要はありません。ipv6: false はDNSモジュールがIPv6の結果を返さないことを示し、安定したIPv6経路がないネットワークに適しています。ネットワークとプロキシがIPv6を完全にサポートしているなら有効化し、直接接続とプロキシ接続を個別に検証してください。

Fake-IPとredir-hostの選び方

fake-ip モードは、まずアプリに対応する仮想アドレスを返し、アプリがそのアドレスへ接続するとカーネルが元のドメインを復元してドメインルールを適用します。ルール一致を直接的にし、「先にIPへ解決されたため、その後はアドレスだけで判断する」情報の損失も減らせます。対応アドレスはローカルカーネル内だけで意味を持ち、実際の宛先アドレスとして扱ってはいけません。パケットキャプチャ、ログ、アプリの診断画面に 198.18.0.0/16 のようなアドレスが表示されたら、異常なDNS結果と決めつけず、まずFake-IPの対応アドレスか確認します。

一部のLANサービス、デバイス検出、ネットワーク接続性チェック、時刻同期、実アドレスを必要とするアプリはFake-IPに適さないため、fake-ip-filter に追加します。フィルター後は、これらのドメインに実際の解決結果が返されます。最初から範囲を広げすぎないでください。多数のトップレベルドメインを直接除外すると、Fake-IPが持つドメイン関連付けの利点が弱まります。互換性の問題が出たら、まず具体的なドメインから始め、ログで確認したうえでサフィックスを追加します。redir-host は実IPを返すため従来の名前解決に近い互換性を持ちますが、ドメインと接続の関連付け方が異なります。Fake-IPの互換性問題が明確で、フィルターでも解決できない場合に限り、全体を切り替えるとよいでしょう。

nameserver-policyと名前解決経路

内部サービスはルーターや企業DNSによる解決を必要とすることがあり、公開DNSにはそのレコードがありません。nameserver-policy で指定したサフィックスを内部サーバーへ送り、同時にルールの先頭で該当ドメインを直接接続にします。DNSの分岐と接続の分岐は一致させる必要があります。内部DNSで私有アドレスを得たドメインを外部プロキシへ送ると、通常は接続できません。反対に、公開DNSでパブリックアドレスへ解決したドメインを内部サービスとして扱っても問題になります。設定時は「誰が解決するか」と「どのプロキシを通るか」を1組として確認してください。

respect-rules を使ってDNS接続にもルールを適用する場合、プロキシノードのドメイン解決が、まだ確立していないプロキシに依存しないようにします。そのため、直接動作する proxy-server-nameserver を設定し、DNSルールの循環を避けてください。起動後にすべての接続が名前解決で止まる場合は、いったん直接接続できる基本DNSに変更し、プロキシサーバーのドメインが解決できることを確認してから、暗号化DNSとルール分岐を段階的に戻します。

トラブル対処では、まずログで問い合わせがmihomoへ到達しているか確認します。記録がまったくなければ、システムDNSがカーネルを向いているか、TUNのDNSハイジャックが機能しているか、アプリが独自DNSを有効にしていないかを確認します。問い合わせはあるが失敗する場合は、上流サーバーへ到達できるか、ドメイン形式のDNSアドレスを default-nameserver で解決できるかを確認します。解決に成功しても接続できないなら、ルール、プロキシ、実際の宛先を調べ、DNSレイヤーだけに留まらないでください。LANのデバイス名だけが失敗する場合は、検索ドメイン、ルーターDNS、Fake-IPフィルターを確認し、すべてのドメインを直接接続に変更しないようにします。

DNS最適化に唯一の正解はありません。安定した設定には通常、基本の名前解決経路だけで起動できること、内部ドメインの解決と接続ポリシーが一致していること、Fake-IPの例外に具体的な理由と明確な範囲があること、という3つの特徴があります。設定後は通常のWebページ、LANドメイン、プロキシサーバーのドメイン、IPv6のみをサポートする対象を個別にテストします。各対象で想定するDNSサーバーとプロキシを記録しておけば、ネットワークを変更したときも、ローカル環境の変化か設定の劣化かをすばやく判断できます。

TUNとFake-IPの連携設定

TUNが必要になる場面

システムプロキシは、OSのプロキシ設定を自ら読み取るアプリにだけ有効です。コマンドラインプログラム、一部のゲーム、仮想マシン、直接接続ソケットを固定的に使うソフトウェアは、システムプロキシを迂回することがあります。TUNはOSのネットワーク層に仮想インターフェースを作り、ルーティングによってより多くのTCP・UDP通信をカーネルへ送るため、通信を一元的に取り込みたい場面に適しています。ただし、システムプロキシより本質的に速いわけではなく、すべての問題に対する標準的な修復方法でもありません。ブラウザーや通常のデスクトップアプリがシステムプロキシで安定しているなら、シンプルな設定を維持するほうが保守しやすいでしょう。

TUNの起動には仮想NIC、ルーティングテーブル、DNS、システム権限が関係します。デスクトップクライアントはサービスのインストールやネットワーク拡張の許可を求めることがあり、モバイル端末ではシステムVPNインターフェースを使います。スイッチが有効と表示されても、すべての通信がカーネルへ入っているとは限りません。ログでTUNインターフェース、ルート、DNSハイジャックが正常に作成されたか確認し、対象接続が現れるかも調べます。macOSでネットワーク拡張やキーチェーンの認証に問題がある場合は、macOSのネットワーク拡張とキーチェーンの対処手順を参照してください。

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

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

auto-route は必要なルートをカーネルが自動作成します。auto-detect-interface は現在のネットワークに応じて出口インターフェースを選ぶため、有線、無線、モバイルホットスポットを切り替える端末に適しています。strict-route は通信の迂回を減らしますが、仮想マシン、コンテナ、他のVPNのルートと競合することがあります。有効化後にLANや社内ネットワークへ突然接続できなくなったら、まずルート競合を確認し、厳格なルートを無効にするか明示的な除外を追加するか判断します。すぐにプロキシノードを変更しないでください。

stack、MTU、UDPの動作

TUNのスタックはカーネルバージョンとプラットフォームの機能で決まり、一般的な選択肢には system、gvisor、mixed があります。systemはOSのネットワーク実装を利用するため、互換性と性能はプラットフォームに左右されます。gVisorのユーザー空間スタックは別の処理経路を提供し、特定のシステムスタックの問題を比較するときに使えます。mixedは異なる通信を組み合わせて処理し、多くのデスクトップ環境での出発点になります。名前だけで優劣を判断せず、同じネットワークと対象を使ってTCP、UDP、LAN、スリープ復帰を個別にテストしてください。

MTUが大きすぎると、特定の経路でのフラグメントやパス検出の異常が「小さいページは開くが、大きなファイルや特定のリクエストが止まる」という形で現れることがあります。小さすぎるとパケット数とオーバーヘッドが増えます。デフォルト値で正常なら変更不要です。MTUを疑う場合は、まず問題がTUNでのみ発生するか確認し、システムプロキシへ切り替えて比較してから、数値を少しずつ下げてテストします。スタックとDNSを同時に変更しないでください。UDP異常では、選択したプロキシが対象の通信方式に対応しているかも確認します。TUNは通信を取り込むだけで、UDP非対応のプロキシにUDP機能を追加するものではありません。

Fake-IPがTUNと組み合わせられる理由

TUNには、通常はシステムプロキシを通らない大量の接続が入ります。接続前のDNS問い合わせもmihomoへハイジャックされていれば、Fake-IPがドメイン情報を保持し、これらの接続でもドメインルールを使えます。DNS問い合わせがカーネルの外で完了すると、TUNから見えるのは実IPだけになり、ルールがIP一致や最終フォールバックへ退化する可能性があります。そのためTUN、DNSハイジャック、Fake-IPを一連の流れとして確認します。アプリの問い合わせがカーネルに入っているか、対応アドレスが保存されているか、アプリが対応アドレスへ接続した後にドメインが復元されるか、想定したルールに一致しているかを調べてください。

アプリによってはハードコードされたIPへ直接接続し、最初からドメインが存在しません。この場合、Fake-IPでドメインを作り出すことはできず、IPルール、プロセスルール、またはドメインスニッフィングがプロトコル内容から対象を識別できるかに頼る必要があります。プロセスルールの利用可能性はプラットフォームによって異なり、モバイル端末では制限が多い傾向があります。最終フォールバックを残し、ログで実際に見えている情報に応じてルール種別を選んでください。すべての接続でドメインを復元できると想定してはいけません。

よくある競合元は、他のVPN、仮想マシンのブリッジ、コンテナネットワーク、LANプロキシツール、セキュリティソフトです。複数のプログラムがデフォルトルートやDNSを同時に変更すると、後から起動したものが先の設定を上書きすることがあります。トラブル対処では起動順を記録し、他のネットワークツールを一時停止してClashだけを有効にします。スリープ復帰後に失敗する場合は、まずTUNインターフェースを再起動します。Wi-Fi切り替え後に失敗する場合は、出口インターフェースの自動検出を確認します。ルートが正常に作成されていると確認できてから、ルールとプロキシを分析してください。

モバイル端末でTUNを常時有効にするとカーネルが常駐し、速度テストの周期、複雑なルール、頻繁なDNS問い合わせが電池消費に影響します。自動テストの頻度を下げ、不要なルールプロバイダーを整理し、システムのバックグラウンド設定でクライアントを安定動作させてください。停止と接続の再構築が繰り返されるのを避けられます。Androidの具体的な確認手順はAndroidのバックグラウンド設定と電池消費のチェックリストを参照してください。

ドメインスニッフィングとルール補完

スニッフィングが解決するのは情報不足

接続がmihomoに入った時点で、宛先がIPしかないことがあります。ドメインスニッフィングは接続初期のプロトコル情報を調べ、HTTP HostやTLS ClientHelloのサーバー名などからドメインを復元し、ドメインルールによる判断を可能にします。すべてのアプリ内容を読み取る機能でも、DNSの代替でもありません。暗号化接続で識別できるのは、ハンドシェイク時に公開される対象名です。プロトコルにドメインが含まれない、ハンドシェイクがさらに暗号化されている、接続がIPを直接使う場合は、スニッフィングで結果を得られません。

スニッフィングは「DNSはカーネル外で完了したが、接続にはドメイン情報が残っている」場面を補完します。たとえばアプリが独自DNSで実IPを取得してTLS接続を開始した場合、カーネルがハンドシェイクからサーバー名を復元できることがあります。復元後もルールの順序に従って判断されます。スニッフィングしたドメインと元の宛先IPの対応が特殊な場合、宛先を不用意に上書きすると接続異常を起こすことがあります。最初は一般的なHTTP・TLSポートから設定し、すべてのポートやプロトコルをいきなり対象にしないでください。

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

parse-pure-ip は、IPだけを持つ対象に対してプロトコル上のドメイン解決を試みます。force-dns-mapping はDNSの対応情報と組み合わせます。override-destination はスニッフィング結果で元の宛先を書き換えるかどうかを制御します。初めて有効にするときは、宛先を書き換えず、ログにドメインが復元されるかだけを確認するとよいでしょう。特定サービスがスニッフィングしたドメインによるルーティングを必要とすると確認できてから、上書きの有効化を検討します。フィールドの対応状況はクライアントのカーネルによって異なるため、設定読み込み後にログでこれらのパラメータが受け入れられたか確認してください。

force-domainとskip-domainの使い分け

force-domain は明確にスニッフィングが必要なドメインに適し、skip-domain は互換性に問題がある、または書き換えるべきでない対象に使います。どちらもログと再現結果に基づいて管理し、出所不明の大規模な除外リストをそのままコピーしないでください。デバイス検出、LANサービス、プッシュ通知の長時間接続、特殊な証明書検証を使うアプリではスキップが必要なことがあります。ただし接続失敗を見つけても、まずDNS、ルール、プロキシ自体を除外し、すべてをスニッフィングの原因にしないでください。

送信元アドレスの除外は、LAN機器を本機経由で転送しつつドメイン識別を行いたくない場合に適しています。ネットワーク範囲を設定するときは実際のLANの範囲を確認してください。広すぎると多数の接続がドメインルールを失います。ポート範囲も絞るべきです。HTTPスニッフィングは典型的な平文ポート、TLSは一般的な暗号化ポート、QUICは主にUDPを対象にします。すべてのポートをすべてのプロトコルで試すと、不要な判定が増え、ログも読みにくくなります。

スニッフィングが本当に機能しているか判断する

検証では既知のドメインを1つ選び、まずログで接続開始時の宛先がIPだけか確認します。次にスニッフィング後にドメインが現れるか、最終的にドメインルールとIPルールのどちらに一致したかを確認します。接続開始時からドメインがあった場合、正常に一致してもスニッフィングが働いた証拠にはなりません。同じアプリでスニッフィングを無効にした動作と比較できますが、既存接続を閉じてください。ブラウザーには通常コネクションプールがあるため、ページを更新するだけでは新しい接続が作られないことがあります。

ログにスニッフィング結果がない場合は、通信がmihomoに入っているか、ポートが設定範囲内か、プロトコルがHTTP、TLS、QUICのいずれかを確認します。ドメインを復元できても期待した分岐にならない場合は、ルールの順序とドメインの記述を確認します。override-destination を有効にして接続が失敗したら、まず上書きを無効にして復元だけを残し、原因が宛先書き換えにあることを確認します。その後、対象をスキップリストへ追加します。除外項目は具体的なドメインまたはサフィックスで記述し、理由も添えて後から確認できるようにしてください。

長期保守では、スニッフィングの例外を対象アプリ、プロトコル、発生した症状と一緒に記録します。ドメインだけを残して理由を書かないと、数か月後に除外がまだ必要か判断できません。クライアントやカーネルを移行した後は、過去の除外をすべてそのままコピーせず、狭い範囲から再検証してください。「情報不足を確認 → 対応プロトコルを限定して有効化 → ドメイン復元を検証 → 上書きするか判断」という順序で進めれば、スニッフィングを不確実性の層ではなく、制御可能なツールとして使えます。

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

サブスクリプションは入力として扱い、最終設定に直接しない

リモートサブスクリプションは通常、プロキシノード、基本的なプロキシグループ、一部のルールを提供しますが、本機のLAN、内部ドメイン、アプリの使い方、プラットフォーム権限まで把握しているとは限りません。サブスクリプションを入力として扱い、ローカル上書きで最終設定を作るほうが長期保守に適しています。更新でノード一覧が置き換わっても、ローカル上書きにはDNS、TUN、カスタムルール、プロキシグループの変更を残せます。上書きに対応するクライアントには、YAML上書き、スクリプト処理、統合画面などがあります。入口は異なりますが、いずれも更新で消えるメイン設定を直接編集しないことが目的です。

上書きには、変更が必要なキーだけを含めるようにします。メイン設定全体をコピーすると、上流で追加されたフィールドを遮ってしまい、すでに無効なノード名も残りやすくなります。マッピング型のフィールドはキー単位で統合できますが、配列型は注意が必要です。クライアントによって置換、先頭追加、末尾追加、スクリプト処理のいずれになるかが異なります。rules は典型的な順序配列です。単純な置換ではサブスクリプションのルールを失い、単純な追加では MATCH の後ろに入って永遠に一致しないことがあります。クライアントの「ルールを先頭に追加」機能を使うか、統合スクリプトで最終フォールバックの前へ明示的に挿入してください。

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-filter:
    - "+.internal.example"

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

profile:
  store-selected: true
  store-fake-ip: true

このローカル上書きにはサブスクリプションのプロキシを含めず、ノード更新と本機のネットワーク設定を分離しています。保存後は上書きファイルだけでなく、最終的に有効な設定を確認します。クライアントに「統合結果をプレビュー」や「実行中の設定を開く」機能があれば、DNSとTUNのフィールドが1回だけ現れるか、インデントが正しいか、ルールの挿入位置が想定どおりかを確認してください。同名キーがある場合はどの層が優先されるかを明確にし、試行錯誤に頼らないでください。

複数サブスクリプションの統合設計

複数サブスクリプションを統合することは、すべてのノード文字列を連結することではありません。より安定した方法は、ソースごとに独立した proxy-providers を作り、異なるキャッシュパスを設定して、プロキシグループから use で参照することです。これなら1つのソースの更新失敗が別のソースのキャッシュに影響せず、メンバーの出所も確認しやすくなります。プロバイダー名は安定させ、プロキシグループはプロバイダーだけを参照し、変化するノード名を直接列挙しないでください。

proxy-providers:
  provider-main:
    type: http
    url: https://subscription.example.com/main.yaml
    path: ./providers/main.yaml
    interval: 21600
    health-check:
      enable: true
      url: https://www.example.com/
      interval: 900

  provider-backup:
    type: http
    url: https://subscription.example.com/backup.yaml
    path: ./providers/backup.yaml
    interval: 21600
    health-check:
      enable: true
      url: https://www.example.com/
      interval: 900

proxy-groups:
  - name: ノード選択
    type: select
    use:
      - provider-main
      - provider-backup
    proxies:
      - 自動選択
      - DIRECT

  - name: 自動選択
    type: url-test
    use:
      - provider-main
      - provider-backup
    url: https://www.example.com/
    interval: 600
    tolerance: 80

例のURLは構造を示すためのもので、実際には自分のサブスクリプションアドレスを使い、機密情報として管理してください。プロバイダーごとに異なる path を指定します。同じパスを使うと、後から更新された内容が前のキャッシュを上書きすることがあります。ヘルスチェックとプロキシグループの速度テストは別の層です。プロバイダーのヘルスチェックはメンバーの可用性を示し、url-test はグループ内の選択を決めます。両方の周期が短すぎると重複テストが増えるため、特にモバイル端末では間隔を長めに設定してください。

複数のソースに同名ノードが含まれることがあります。画面に名前しか表示されないと、どのソースを選んだか判断しにくくなります。統合時にソースの接頭辞を付けるか、プロバイダーごとに「メインサブスクリプション」「予備サブスクリプション」という中間グループへ分け、総入口から参照します。サブスクリプション更新で並び順が変わるため、ノードの位置に依存しないでください。フィルタールールもソースごとに検証し、名前が変わっても地域グループが突然空にならないことを確認します。

更新、失敗、復元

サブスクリプションを更新する前に、現在のキャッシュが利用可能か確認します。更新に失敗しても、クライアントは古いキャッシュを使い続けることがあります。この場合、キャッシュを削除して何度も再試行せず、まずサブスクリプションアドレスの解決、ネットワーク経路、返却形式を確認してください。リモート内容をダウンロードできても読み込めない場合は、それが完全なClash設定なのか、プロキシプロバイダー形式だけなのかを確認します。両者の構造は異なります。クライアントに変換機能がない限り、完全な設定をそのままproviderファイルとして使うことはできません。

ローカル上書きを更新するときは、小さな段階に分けて移行します。まず基本のprofileとDNSを統合して読み込みを確認し、次にルールの先頭追加を行い、最後にTUNとスニッフィングを有効にします。古い端末の設定全体を一度にコピーすると、プラットフォーム固有のフィールド、パス、インターフェース名が合わないことがあります。Windows、macOS、Android、Linuxでは権限とネットワークスタックが異なります。同じロジックは維持できますが、待ち受けアドレス、TUN権限、ローカルパスは改めて確認してください。

クライアントを移行するときは、まずサブスクリプションアドレスとカスタム上書きをエクスポートし、プロキシグループの現在の選択も記録します。クライアント内部のキャッシュディレクトリを長期バックアップとみなさないでください。ディレクトリ構造はプラットフォームによって変わる可能性があります。旧版クライアントの保守終了後の移行方法は、FlClashとClash Verge Revの移行方法比較を参照できます。新規インストールでは、まずクライアントダウンロードページからClash Plusを選び、システムとプロセッサアーキテクチャに合うものをインストールしてから、設定をレイヤーごとにインポートしてください。

外部コントローラーとセキュリティ境界

コントロールインターフェースでできること

mihomoの外部コントロールインターフェースでは、実行状態の取得、プロキシグループの切り替え、プロバイダーの更新、接続とログの確認ができます。GUIクライアント自身がこのインターフェースでカーネルと通信することもあります。独立したコントロールパネルはインターフェースを表示するフロントエンドにすぎず、カーネルの代替ではありません。また設定ファイルの権限境界を変更するものでもありません。アクセスの可否は、external-controller の待ち受けアドレス、OSのファイアウォール、認証キーで決まります。

本機だけで使う場合は、127.0.0.1:9090 のようなループバックアドレスで待ち受けます。これにより、他のLAN機器から直接接続できなくなります。別の端末から管理する必要があるときだけ、LANアドレスでの待ち受けを検討し、強力な認証、ファイアウォールでの送信元制限、現在のネットワークの信頼性を同時に確認します。すべてのNICで待ち受けるとアクセス範囲が広がります。コントロールパネルに「キー入力が必要」と表示されるだけで安全と判断せず、実際の保護をAPI接続層で行ってください。

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

log-level: info
allow-lan: false

secret の例は必ず本機専用の値に置き換え、サブスクリプションアドレスや他のアカウント認証情報と共用しないでください。クライアントがコントロールインターフェースの設定を自動生成している場合は、手動で上書きせず、クライアント設定から変更するのが安全です。external-ui はローカルの静的パネルディレクトリを指定します。クライアントによってはパネルリソースを自動でダウンロード・管理しますが、APIだけを提供し、対応フロントエンドを自分で用意するものもあります。パスはクライアントが読み取れる設定ディレクトリ内に置いてください。

コントロールパネル接続の確認手順

パネルが開かないときは、まず静的ページとAPIを分けて確認します。ブラウザーでパネルファイル自体を開けない場合は、external-ui のパスとクライアントのリソース管理を調べます。ページは開くが接続できない場合は、コントロールアドレス、ポート、キー、ブラウザーのアクセス元を確認します。インターフェースがループバックアドレスで待ち受けている場合、別端末から本機のLAN IPを入力しても接続できません。これは想定された境界です。LANで待ち受けるなら、OSのファイアウォールが指定した送信元だけを許可しているか確認し、ネットワーク全体に公開しないでください。

コントロールパネルのアドレスでHTTPとHTTPSのどちらを使うかは、配置方法によって決まります。ループバックアドレス上で本機だけが使う場合と、LANから遠隔管理する場合ではリスクが異なります。端末間で管理する必要があるなら、管理下のローカルネットワークや既存の安全なトンネルを通してアクセスし、コントロールポートを直接インターネットへ公開しないでください。インターフェースではプロキシの切り替え、接続先の読み取り、実行状態の変更ができるため、通常のステータスページではなく管理インターフェースとして扱います。

curl -H "Authorization: Bearer your-control-secret" \
  http://127.0.0.1:9090/version

curl -H "Authorization: Bearer your-control-secret" \
  http://127.0.0.1:9090/proxies

このコマンドは本機のAPIが応答するかを確認するために使います。1つ目でインターフェースと認証が機能しているかを確認し、2つ目でプロキシとプロキシグループの構造を読み取ります。「未認証」が返る場合はキーが一致しているか確認します。「接続拒否」ならカーネルが動作しているか、ポートが待ち受けているかを調べます。接続できてもパスが応答しない場合は、現在のカーネルインターフェースの互換性を確認してください。デバッグ後は認証情報を含むコマンドを共有スクリプトや公開ログに保存しないでください。

接続情報とログを正しく使う

コントロールパネルの接続一覧は、通信がカーネルに入っているか、対象情報がドメインかIPか、最終的にどのルールとプロキシが使われたかという3つの疑問に答えるのに適しています。大量の接続が表示されても異常とは限りません。現代のWebページは複数のリソースを並行して要求します。トラブル対処では対象アプリやドメインで絞り込み、古い接続を閉じて1回だけリクエストを発生させるほうが、流れ続ける全一覧を見続けるより効果的です。

プロキシグループを切り替えても、既存のTCP接続は通常、新しいプロキシへ自動移行しません。テスト結果が変わらない場合は、対象接続を閉じるかアプリを再起動し、新しい接続がどのプロキシを使うか確認します。ルールプロバイダーを更新した後も、新しい接続が一致しているかを確認し、更新ボタンが完了しただけで判断しないでください。パネルが表示するのは実行中の状態であり、設定ファイルは次回読み込み時の状態を決めます。一時的な切り替えが再起動後も残るかは、profile.store-selected とクライアントの永続化機構によります。

コントロールパネルとクライアント画面で状態が異なる場合は、同じカーネルインスタンスとポートへ接続しているか確認します。端末上で旧クライアントのサービス、コマンドラインカーネル、新しいクライアントが同時に動作している可能性があります。パネルが別のインスタンスへ接続していると、「プロキシを切り替えても効果がない」という誤解が生じます。プロセス、待ち受けポート、設定ディレクトリを確認し、不要なインスタンスを停止してから再接続します。完了後は、コントロールアドレス、パネルパス、設定ファイルの場所を端末の説明書に記録しておくと、次回の移行が容易です。

設定検証、トラブル対処、長期保守

固定の順序で経路全体を検証する

複雑な設定が完成しても、複数のアプリをいきなり同時にテストしないでください。まずカーネルが設定を読み込み、YAMLやフィールドのエラーがないことを確認します。次にシステムプロキシまたはTUNの取り込みが成功しているか確認し、その後にDNS問い合わせ、ドメインスニッフィング、ルール一致、プロキシグループの選択、プロキシ接続を検証します。各レイヤーでは1つの問いだけに答えます。最初の段階で失敗しているなら、その後のWebエラーを分析しても意味がありません。固定順序で進めれば、プロキシグループのノードを切り替えているのに実際の問題はTUNルートが作られていない、といった無駄を避けられます。

ローカルのテスト表を用意し、対象、想定ルール、想定プロキシ、検証結果を記録することをおすすめします。少なくともLANへの直接接続、通常の直接接続、プロキシが必要なドメイン、IPだけの接続、UDPアプリ、最終フォールバックを含めます。テスト時はコントロールパネルやログに実際の一致項目を記録します。サブスクリプション、ルールセット、DNS、クライアントを更新した後も同じテストを繰り返せば、結果を比較でき、内容の更新による変化かクライアント環境による変化かをすばやく見分けられます。

# ローカルのmixedプロキシポートが待ち受けているか確認
curl -x http://127.0.0.1:7890 https://www.example.com/

# 外部コントロールインターフェースを確認
curl -H "Authorization: Bearer your-control-secret" \
  http://127.0.0.1:9090/version

コマンドで確認できるのはポートとリクエストパスだけで、すべてのルールが正しいことを意味しません。1つ目が成功すれば、アプリがローカルプロキシ経由でリクエストを送れることを示します。ブラウザーが動作しない場合は、ブラウザーのプロキシ設定元と既存接続を確認してください。コマンドが失敗したら、接続拒否、DNS失敗、認証失敗、リクエストタイムアウトをエラー内容で区別します。すべてを「ノードが使えない」とまとめないでください。ローカルポートが待ち受けていない場合と、リモートプロキシに障害がある場合では対処がまったく異なります。

現象ごとにトラブル対処の分岐を作る

「すべての対象が失敗する」場合は、まずカーネル、ポート、権限、DNSの基本経路、現在のプロキシグループのメンバーを確認します。「1つのドメインだけ失敗する」場合は、ドメイン解決、ルール一致、サービスが要求する出口を確認します。「特定のアプリだけ失敗する」場合は、システムプロキシを通っているか、独自DNSを使っているか、UDPだけを使っていないかを調べます。「ネットワーク変更後に失敗する」場合は、出口インターフェース、ルート、LAN DNSを確認します。「サブスクリプション更新後に失敗する」場合は、プロバイダー形式、プロキシグループのメンバー、ルール順序を確認してください。

ログでは、連鎖して発生した後続エラーより最初のエラーのほうが重要です。DNS初期化の失敗が、ノードのドメイン解決失敗、プロバイダー更新失敗、すべてのプロキシのタイムアウトを引き起こすことがあります。最後の1行だけを見ると、複数のサブスクリプションが同時に無効になったと誤解するかもしれません。一時的にdebugを有効にし、カーネルの起動段階から読み返して、今回の変更に関係する最初のエラーを見つけます。修正後に再起動し、そのエラーが消えたことを確認してから次の項目に進んでください。

アップグレードと移行で変数を管理する

クライアントのアップグレード、カーネルの置き換え、設定の移行を同時に行わないでください。まず現在のクライアントから動作する設定とローカル上書きをエクスポートします。新しいクライアントをインストールしたら、最初はサブスクリプションだけをインポートして基本接続を完了します。その後にプロキシグループ、ルールプロバイダー、DNSを追加し、最後にTUN、スニッフィング、外部コントロールパネルを有効にします。これなら問題が起きた段階から、フィールド対応、プラットフォーム権限、設定内容のどれが原因か判断できます。プラットフォームをまたぐ移行では、パス区切り、サービス権限、ネットワーク拡張、ファイアウォールも改めて確認してください。

特定の画面名が将来も変わらないとは考えないでください。長期保守の記録は画面ではなく、設定フィールドと動作を中心にします。たとえば「profile.store-selected を有効にしてグループ選択を保存する」と記録し、「3ページ目の2番目のスイッチを開く」とだけ書かないようにします。UIが更新されてもボタンの位置は変わりますが、フィールドの意味は比較的安定しています。画面でしか行えないシステム権限の許可については、プラットフォーム別の手順と確認できる現象を補足してください。

問題が起きたら、まずログ、現在の設定、再現手順を保存してから復元します。エラー画面を1枚残すだけでは、接続がどのレイヤーを通ったか判断できないことが多いです。再現手順には、クライアント、取り込み方式、対象アプリ、想定プロキシ、実際の一致項目、ネットワーク環境を含めます。基本概念がまだ不明な場合は、FAQで「基本知識、インストールと設定、使い方のコツ、トラブル対処」から探してください。サブスクリプションのインポートとモード選択を最初からやり直す必要がある場合は、使い方ガイドへ戻ります。

長期的に安定したClash設定は、通常それほど複雑ではありません。サブスクリプションがプロキシを提供し、プロキシグループが出口の選択を表し、ルールセットが再利用可能な一致を担い、DNSがドメイン情報を保持します。TUNは必要なときだけ通信を取り込み、スニッフィングは不足したドメインを補い、外部コントロールインターフェースは明確な境界内に制限します。毎回1つのレイヤーだけを変更し、固定のテストセットで検証すれば、機能を増やしながら設定の可読性、復元性、移行性を維持できます。