Clash 高度な設定ガイド

CHAPTER 01 / POLICY GROUPS

プロキシグループの種類と実践

プロキシグループは、ルールとノードの間に位置します。ルールの最後のフィールドは通常、個別ノード名ではなくプロキシグループ名です。プロキシグループは、ユーザーの選択、ヘルスチェック、障害状態に応じて実際の送信先を決めます。ルールを単一ノードに直接結び付けると記述は簡単ですが、ノード障害時の切り替え、用途別の振り分け、購読更新が難しくなります。安定した設定では、まず「手動選択」「自動最適化」「フェイルオーバー」「ストリーミング」「ダウンロードは直接接続」のように目的別に分け、ルールからこれらの固定名を参照します。購読でノード名が変わっても、フィルターで該当グループに再登録できれば、ルール側を変更する必要はありません。

select、url-test、fallback、load-balance

selectは明示的に選択するグループで、長期間同じ地域の出口を使う場合、アカウントのログイン地域を手動で固定する場合、一時的な障害調査に適しています。自動で切り替わらないため、現在のノードが利用できなくなった場合は通常ユーザーの操作が必要です。そのため、グループ内に「自動最適化」を選択肢として残すと便利です。url-testは固定URLへ接続テストを行い、候補の中から測定遅延が低いノードを選びます。測定値は対象URLとその時点の状態だけを示し、すべてのサイトの実速度を表すものではありません。間隔が短すぎると余分な接続が発生するため、デスクトップの日常利用では継続的に更新するのではなく、数分間隔に設定するのが一般的です。

fallbackはリスト順に最初の利用可能なノードを選ぶ方式で、主回線が明確で、障害時だけ予備回線へ切り替えたい場合に適しています。最低遅延ではなく、順序と可用性を重視します。load-balanceは複数ノードへ接続を分散するため、ログイン状態を持たず出口の変化を許容できる並列処理に向いています。一方、アカウントログイン、決済、長時間接続、送信元アドレスに敏感なサービスには不向きです。同じ処理の接続が異なる出口から送信される可能性があるためです。一貫性ハッシュを使えば同一宛先の出口が頻繁に変わる確率を下げられますが、それでも業務側が許容できるか先に確認してください。

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

  - name: 自動最適化
    type: url-test
    use:
      - remote-nodes
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 80
    lazy: true

  - name: フェイルオーバー
    type: fallback
    use:
      - remote-nodes
    url: https://www.gstatic.com/generate_204
    interval: 300
    lazy: true

useはproxy-providersを参照し、リモート購読のノードを自動的にプロキシグループへ追加する場合に適しています。proxiesには固定ノードや別のプロキシグループを列挙します。カーネルの対応状況に応じて併用できますが、保守時は出所をできるだけ明確にしてください。ノードが多い場合はfilterの正規表現で名前から地域を絞り込み、たとえば「香港」や「HK」を含むノードをグループに追加できます。除外フィルターは慎重に使ってください。ノード名の付け方が統一されていないと、候補をすべて除外することがあります。フィルター条件を変更したら、YAMLを読み込めるかだけでなく、クライアントのプロキシグループ詳細で実際のメンバーを確認します。

階層化して循環参照を防ぐ

実運用では、3層構成にすると管理しやすくなります。下層はノードプロバイダー、中層は自動最適化またはフェイルオーバー、上層はユーザーが選ぶ用途別グループです。ルールは上層の用途別グループだけを参照し、上層から中層グループと少数の固定ノードを参照します。どのプロキシグループも、間接的に自身を参照してはいけません。たとえば「手動選択」が「自動最適化」を含み、「自動最適化」が候補として「手動選択」を含むと循環が発生します。クライアントによっては読み込み時にエラーになり、別のUIでは空のグループとして表示されます。調査時はエラーが出たグループから参照を順に展開し、すべての末端が実ノードまたはDIRECT、REJECTなどの組み込みポリシーに到達するまで確認します。

CHAPTER 02 / RULE PROVIDERS

ルールセットの購読管理

ルールが数十件から数千件に増えると、すべてをメイン設定へ直接書く方法は可読性を下げ、購読更新によってローカルの変更が上書きされる原因にもなります。rule-providersを使うと、ドメイン、ネットワーク範囲、クラシックルールを独立したリソースに分け、カーネルが定期的に取得してキャッシュできます。メイン設定にはプロバイダー定義、用途別ポリシー、ルールセット参照だけを残し、広告ブロック、プライベートネットワーク、業務サービス、ストリーミングなどのルールをテーマごとに管理します。カテゴリ単位で更新でき、異常時も該当する参照だけをすぐ停止できるため、設定全体を書き直す必要がありません。

behaviorとformatの対応関係

behaviorはルールセットの内容を示します。domainはドメインだけの集合に適し、完全修飾ドメイン、ドメインサフィックス、カーネルが対応するドメイン表現を記述します。ipcidrはIPv4・IPv6のネットワーク範囲だけを扱います。classicalはDOMAIN-SUFFIX,example.comやPROCESS-NAME,example.exeのように、種類とパラメーターを含む完全なルールを保存します。選択を誤ると、ファイルのダウンロードは成功しても解析できず、ログにpayload形式やルールタイプのエラーが出ます。formatはリソースがYAML、プレーンテキスト、バイナリ形式のどれかを示すため、拡張子だけで推測せず、実際の内容と一致させる必要があります。

rule-providers:
  private-domain:
    type: http
    behavior: domain
    format: yaml
    path: ./rules/private-domain.yaml
    url: https://rules.example.invalid/private-domain.yaml
    interval: 86400
    health-check:
      enable: true
      interval: 600

  office-classical:
    type: http
    behavior: classical
    format: text
    path: ./rules/office.list
    url: https://rules.example.invalid/office.list
    interval: 43200

  private-network:
    type: file
    behavior: ipcidr
    format: yaml
    path: ./rules/private-network.yaml

rules:
  - RULE-SET,private-domain,DIRECT
  - RULE-SET,office-classical,業務サービス
  - RULE-SET,private-network,DIRECT,no-resolve
  - MATCH,手動選択

サンプルのドメインには、解決できない予約済みサフィックスを使用しています。構造説明専用なので、導入時は実際にアクセスでき、出所の明確なルールURLへ置き換えてください。pathはローカルキャッシュの保存先です。同じ設定内の複数プロバイダーで同じファイルを共有すると、更新時に互いの内容を上書きする可能性があります。相対パスは通常、GUIクライアントのインストール先ではなく設定の作業ディレクトリを基準にします。コンテナやシステムサービスでは、そのディレクトリに実行ユーザーが作成・書き込みできることも確認してください。ログにダウンロード成功と書き込み失敗が出る場合は、リモートURLを繰り返し変更するのではなく、ディレクトリ権限、読み取り専用マウント、パス階層を確認します。

ルールは数より順序が重要

Clashとmihomoは通常、rulesを上から順に照合し、最初に一致した時点で停止します。具体的なドメインルールは広範なルールより前に置き、プライベートアドレスやローカルサービスは通常パブリックなネットワーク範囲より先に配置し、最後をMATCHで受けます。広い地域ネットワークやワイルドカードドメインを先に置くと、後続の詳細ルールは実行されません。ルールセット同士にも優先関係があります。同じドメインが「業務サービス」と「直接接続ドメイン」の両方に属する場合、先に置いた参照が結果を決めます。デバッグでは項目の存在だけでなく、接続詳細やログで実際に一致したルールタイプ、ルールペイロード、対象ポリシーを確認してください。

no-resolveはIP系ルールで使われ、照合時に宛先IPを得るための追加のドメイン解決を行わないことを示します。不要なDNS問い合わせを減らし、ルール段階で元のドメイン処理経路が変わるのを防げますが、すべてのルールに機械的に追加するものではありません。ドメインルールはドメイン自体に依存するため不要です。解決結果に基づいて地域やネットワーク範囲を判定する場合は、解決を禁止すると一致できません。まず、そのルールがドメイン、宛先IP、プロセス情報のどれを使うかを明確にしてから、解決を省略するか決めます。

更新失敗とキャッシュへのフォールバック

リモートルールの更新失敗が、ただちに現在の通信停止を意味するとは限りません。ローカルキャッシュが残っていて形式も有効なら、カーネルは通常、古い内容を使い続けられます。ただし、初回読み込み、キャッシュ消去、パス変更の後にはフォールバック先がありません。保守前にルールファイルのキャッシュディレクトリと最終成功時刻を記録してください。異常時は、システム時刻、DNS解決、リモートの応答状態、プロキシ経路、証明書エラー、ファイル権限の順に確認します。ルールURL自体へのアクセスにプロキシが必要で、そのルールがプロキシ経路を決めている場合、初回起動で依存循環が起きることがあります。既知の利用可能なプロキシ設定でルールを取得するか、まずローカルファイルで起動してからリモート更新へ戻します。

ルールセットは多ければよいとは限りません。複数の出所が同じドメインを重複収録していたり、管理方針が衝突したりするためです。各プロバイダーについて、出所、用途、更新頻度、対象ポリシーを記録し、参照されなくなったキャッシュは定期的に削除してください。変更前に小さなローカルルールセットで動作を確認し、安定した項目をリモートリソースへ移す方法も有効です。購読構造と互換性の違いはClash購読形式の詳しい解説で確認できます。ノード購読、完全な設定、ルールセット購読を混同しないようにしましょう。

CHAPTER 03 / DNS PIPELINE

DNS設定の最適化

DNS設定はドメインからアドレスを取得する方法を決め、ルールが元のドメインを認識できるか、接続がプロキシを迂回するか、TUNモードの互換性にも影響します。よくある誤りは、解析サーバーを1つのリストに詰め込み、数が多いほど安定すると考えることです。実際には、プロトコル、アクセス経路、地域別応答、ルールモードを連携させる必要があります。調査時は、クライアントが問い合わせをmihomoへ渡しているか、mihomoがどのnameserverを選んだか、直接接続かプロキシ経由か、返されたアドレスが後続のルール照合にどう使われたかの4段階に分けて確認します。障害箇所を特定してから変更すれば、変数を増やさずに済みます。

基本の解析サーバーと用途別解析サーバー

default-nameserverは、暗号化DNSサーバー自身のドメインを解決するなど、初期解決に使います。通常は直接アクセスできるIPアドレスの解析サーバーを指定し、「解析サーバーのドメインを先に解決する」という循環依存を避けます。nameserverは主な問い合わせ先で、通常のUDP/TCP DNS、DoT、DoHを指定できます。暗号化プロトコルは解析サーバーまでの問い合わせ通信を保護しますが、その接続にも正しいルーティングが必要です。DoHのURLがプロキシへ振り分けられ、プロキシノードのドメインが同じDoHの解決を待つと、起動時に停止する可能性があります。そのため、ノードのドメインと解析サーバーのドメインについて、初期解決経路を別々に検討してください。

proxy-server-nameserverは、プロキシノードのドメイン解決を専用に担当し、ノード接続が用途別ドメイン用のFake-IP結果に依存しないようにできます。nameserver-policyはドメインごとに解析サーバーを指定します。たとえば内部ドメインをLANのDNSへ、特定地域のドメインを対応する解析サービスへ送れます。ポリシーは具体的なものから広いものへ並べ、ルールセット表現が現在のカーネルで対応しているかにも注意します。企業内ネットワークでは内部ドメインがプライベートアドレスを返すことが多く、公衆DNSへ送ると失敗するだけでなく、本来アクセスさせるべきでない経路へ問い合わせが流れる可能性があります。

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

リッスンアドレスによって、このDNSサービスを利用できる機器が決まります。本機だけで使うならループバックアドレスにバインドし、LAN機器から利用する場合だけ全インターフェースにバインドします。その際はファイアウォール、LANアクセス許可、ポート競合も確認してください。外部ネットワークからアクセスできるインターフェースへDNSを公開すると悪用リスクが増すため、サーバー環境ではファイアウォールで送信元を制限します。ipv6はローカルネットワークとプロキシノードのIPv6対応状況に応じて有効化します。IPv6を単純に無効化するとルーティング問題を隠したり、AAAAレコードしかないサービスへ接続できなくなったりします。逆に上流や出口に利用可能なIPv6がないまま有効にすると、IPv6接続を試して失敗を待ち、その後フォールバックする遅延が発生することがあります。

redir-hostとFake-IPの選択

redir-hostは実際のアドレスを返すため、従来方式との互換性を把握しやすい一方、透過的な取り込みでは後続接続が宛先IPだけを持ち、ドメイン情報が失われることがあります。その場合、マッピングやスニッフィングでドメインを復元する必要があります。fake-ipはドメインに予約アドレスを割り当て、接続時にカーネルがマッピング表から元のドメインを復元します。そのためルール照合が安定しやすく、アプリがカーネルを迂回して解決結果へ直接接続するケースも減らせます。代わりに、実際のDNS応答、LAN探索、時刻同期、ゲーム、特殊機器のサービスに依存する一部の環境では互換性問題が起きるため、fake-ip-filterへの追加が必要です。

フィルターリストを巨大なテンプレートからそのままコピーするのは避けてください。範囲が広すぎると多くのドメインがFake-IP処理から外れ、ルールの一貫性が低下します。狭すぎると特定アプリの障害が残ります。より確実なのは、デフォルト設定から始め、ログで異常なドメインを確認し、明確な項目を1つずつ追加する方法です。変更後はOSのDNSキャッシュ、アプリキャッシュ、カーネルのマッピングを消去して接続を作り直します。ブラウザー独自のセキュアDNSが有効な場合もあるため、調査中はOSと同じ解決経路を使っているか確認してください。

DNS漏れと原因の切り分け

DNS経路の異常は、単一のスイッチだけが原因とは限りません。ブラウザーのDoH、OSのDNS、TUNによるDNSハイジャック、コンテナ内の解析サーバー、LANルーターの転送が同時に存在することがあります。まずログで問い合わせがmihomoに入っているかを確認し、次に解析サーバーへの接続経路を調べます。ログに対象ドメインの問い合わせがまったくないなら、問題はアプリまたはOS側です。問い合わせは見えるがタイムアウトするなら、上流への到達性とルーティングを確認します。解決は成功しているのに接続だけ失敗する場合は、DNSを交換し続けるのではなく、ルール、プロキシグループ、ノードを調べます。比較テストでは毎回1つの解析サーバーまたは1つの拡張モードだけを変更し、ログと照合できるよう時刻を記録してください。

キャッシュは解決遅延を下げる一方、誤った記録や古いアドレスの影響を長引かせます。サービス側でドメインを切り替えたとき、ルールを変更した直後、Fake-IPモードを変更した直後は、アプリ、OS、カーネルのキャッシュを同時に考慮します。端末全体の再起動だけが方法ではありません。まずクライアントのDNSキャッシュ削除機能を使い、対象アプリを終了して再起動してください。特定のブラウザー、コンテナ、LAN機器だけで発生するなら、それぞれのDNS設定を比較し、全機器が余計な複雑さを抱えるような全体設定変更は避けます。

CHAPTER 04 / TUN AND FAKE-IP

TUNとFake-IPの取り込み範囲

システムプロキシはプロキシ設定に従うアプリだけに影響しますが、TUNは仮想ネットワークインターフェースを通じて、より広いIP通信を取り込みます。コマンドラインプログラム、一部のゲーム、システムサービス、プロキシ設定を読まないソフトは、システムプロキシでは直接接続することがあります。TUNならこうした接続もカーネルのルールチェーンへ送れます。取り込み範囲が広がるほど、ルーティング、DNS、ファイアウォール、仮想マシン、他のネットワークツールとの衝突も起きやすくなります。有効化する前に、通常のシステムプロキシで正常に使えること、購読・ノード・ルールが有効であることを確認し、その後にTUNだけを検証してください。そうしないと、ノード障害とルーティング障害が重なります。

主要パラメーターとOSごとの差異

stackはTUNが使うネットワークスタックを決めます。systemはシステムのネットワークスタックを使う傾向があり、互換性を把握しやすい方式です。gvisorはユーザー空間のネットワークスタックを使い、環境によって分離や特定プロトコルの挙動を改善できますが、オーバーヘッドが増える場合もあります。mixedは通信の種類に応じて組み合わせます。すべてのOSに適した選択肢はないため、特定アプリのタイムアウト、UDPの異常、スループット低下が起きたら、他の設定を固定して順に比較してください。

auto-routeはカーネルが自動でルートを追加し、宛先通信を仮想インターフェースへ送る機能です。auto-detect-interfaceは実際の送信インターフェースを識別するため、有線、Wi-Fi、テザリング、VPNを切り替えるノートPCで特に役立ちます。Windowsではファイアウォール、ネットワークプロファイル、他の仮想NICにも注意が必要です。macOSではシステム許可が必要になる場合があります。Linuxのサービス環境では実行権限、ポリシールーティング、ファイアウォールフレームワークが関係します。GUIクライアントが権限の一部を処理しても、許可ダイアログの拒否、サービスコンポーネントの未起動、古いルートの残存があると、画面上で有効に見えても実際には取り込めません。

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

dns-hijackは指定ポートのDNS要求をカーネルの解析処理へ取り込み、Fake-IPを正常に動作させる重要な仕組みの1つです。内蔵DoHを使うアプリは従来の53番ポートへアクセスしないため、ハイジャックだけではすべての問い合わせを捕捉できません。strict-routeは別インターフェースへの迂回を減らしますが、仮想マシン、LAN共有、企業VPN、複数NICの環境では必要な経路まで遮断することがあります。有効化後にプリンター、NAS、社内ネットワークへ接続できなくなった場合は、すべてのプライベートアドレスをプロキシへ送るのではなく、ルーティング除外とプライベートネットワークのルールを確認してください。

MTU、ループバック、ルーティング競合

MTUの不一致は、一部のサイトだけ開く、大きなリクエストが止まる、アップロードに失敗する、特定トンネル内の接続がタイムアウトするといった症状で現れます。小さなパケットは通るため、ノードの不安定さと誤認しやすい問題です。ノードを固定したままTUNのMTUを少しずつ下げて比較できますが、極端に小さくするのは避けてください。低すぎると断片化と処理負荷が増えます。別のVPN、モバイルホットスポット、PPPoEを経由した環境だけで発生するなら、下位リンクの追加カプセル化による実効MTUの低下を優先して疑います。

カーネル自身が発行するプロキシ接続は実インターフェースから送信し、再びTUNに捕捉されないようにする必要があります。自動ルーティングとインターフェース検出が通常は処理しますが、カスタムルート、コンテナネットワーク、ポリシールーティング、複数の透過プロキシが同時に存在すると失敗することがあります。典型的には、TUNを有効にするとすべてのノードがタイムアウトし、無効にすると直ちに復旧します。その場合はルーティングテーブルと送信インターフェースを確認し、プロキシサーバーのアドレスが除外されているか、デフォルトルートの優先順位が正しいか、古いクライアントの仮想インターフェースが残っていないかを調べます。

Fake-IPマッピングとルールの関係

アプリがDNSへドメインを問い合わせると、カーネルはFake-IPを返し、そのアドレスとドメインの対応を記録します。アプリがFake-IPへ接続すると、TUNが接続を捕捉し、カーネルがドメインを復元してドメインルールと照合します。最後に選択したポリシーを通じて実際の宛先へアクセスします。この過程でFake-IPが存在するのは本機の取り込み経路だけで、リモートの実アドレスではありません。アプリが古いFake-IPをキャッシュし、再起動や設定変更でカーネルのマッピングが失われると、ドメインを復元できず接続に失敗することがあります。ルールを増やすより、アプリの接続とDNSキャッシュを削除する方が効果的な場合があります。

LANサービス、ブロードキャスト探索、実アドレスの応答を必要とするアプリはfake-ip-filterで除外できますが、対応するプライベートネットワークのルールも適切な位置に置く必要があります。ドメインを除外しただけでは通信が自動的に直接接続になるわけではありません。プライベートアドレスが返された後、後続ルールによってプロキシグループへ送られる可能性があります。逆に、プライベートネットワークを直接接続にしても、実際のDNS応答内容に依存するアプリの問題は直りません。調査では「DNSが何を返すか」と「接続が最終的にどこへ向かうか」を別の問題として扱います。

TUNを有効にして全体的にインターネットへ接続できなくなった場合は、次の順序で確認します。まずTUNを無効にして基本プロキシを検証し、次にDNS設定を変えずにTUNを有効化します。仮想インターフェースが作成されたか、デフォルトルートと物理インターフェースが正しいか、DNS問い合わせログに異常がないかを確認し、最後に固定IPとドメインアクセスの違いをテストします。固定IPは通るのにドメインだけ失敗するならDNS、両方失敗するならルーティング、権限、ループバックを重点的に調べます。より一般的な切り分け手順はClashの実行ログの読み方を参照してください。

CHAPTER 05 / DOMAIN SNIFFING

ドメインスニッフィングと宛先の復元

透過プロキシが受け取る接続には、宛先IPしか含まれず元のドメインがない場合があります。ドメインスニッフィングは接続初期のプロトコル特徴を調べ、HTTPのHost、TLS ClientHelloのサーバー名、対応するQUIC情報からドメインを復元し、ドメインルールを照合できるようにします。これは「アプリが自分で解決し、カーネルにはIPしか見えていない」問題を補うもので、DNSの代替ではありません。すべての暗号化プロトコルや非標準プロトコルから宛先を復元できるわけでもありません。設定時は対象、ポート範囲、上書き条件を明確にし、無関係な通信を誤認しないようにします。

override-destinationの影響

ドメインを識別するだけで宛先を上書きしない場合、カーネルは復元したドメインでルール照合できますが、接続先はアプリが元々解決したIPのままです。override-destinationを有効にすると、スニッフィング結果に基づいて宛先を再決定でき、アプリ側の解決結果とプロキシ側のアクセス経路が一致しない場合の修正に役立ちます。ただし、CDN、プライベートDNS、分割DNS、固定アドレスのサービスは元のIPへの接続を前提としていることがあります。上書き後にドメインが別のアドレスへ解決されると、地域差、証明書エラー、内部サービスへの接続失敗が起こる可能性があります。まずプロトコルとポートで範囲を絞り、互換性が確認できないドメインは除外リストへ追加してください。

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

parse-pure-ipは宛先が純粋なIPの接続でもスニッフィングを試みる機能で、透過的な取り込みでよく使われますが、検査範囲は広がります。force-dns-mappingはDNSマッピングと連携し、既存の対応関係からドメインを復元する環境に適しています。プロトコルのポートは実際の用途に合わせて指定してください。HTTPは80番だけでなく、TLSも8443などを使うことがあります。反対に、すべてのポートをすべてのスニッファーへ渡すと、誤判定と処理コストが増えます。まず一般的なポートから始め、特定アプリが別ポートを使うとログで確認できた場合だけ追加します。

スニッフィングで解決できないケース

暗号化されたクライアントハロー、ECH、非標準のカプセル化、証明書ピンニング、ドメインフィールドを持たないプロトコルでは、スニッフィングで有効なホスト名を取得できないことがあります。UDPプロトコルはHTTPより情報が少ない場合もあります。ログに宛先IPしか表示されなくても、機能が壊れているとは限らず、接続自体に読み取れるドメインがない可能性があります。スニッフィング範囲を広げ続けるのではなく、IPルールやプロセスルールを使うか、アプリのDNS問い合わせをカーネルへ入れてください。プロセスルールはOSの権限とカーネル機能に依存するため、サーバーやモバイルOSでは利用性が異なります。導入前に実際のクライアントログで確認してください。

誤検出は、機能を有効にした後にLAN機器、ゲーム、プッシュ通知、特殊なクライアントだけが失敗する形で現れることがあります。まずoverride-destinationだけを無効にしてスニッフィングを残し、問題が識別そのものか宛先上書きかを切り分けます。その後、送信元、宛先、ドメインに基づいて除外項目を追加します。LANの範囲を全面的にスニッフィングする必要は通常ありません。内部DNSと固定アドレスは元の経路を維持する方が適切です。除外ルールを公衆ネットワーク全体のような広すぎる範囲にすると、スニッフィング機能が実質的に無効になります。

Fake-IPとルール照合の連携

Fake-IPはマッピングによって、カーネルDNSを通過した多くのドメインをすでに復元できます。そのためスニッフィングは、システムDNSを迂回するアプリ、過去の接続、実IPへ直接接続するケースを補う役割が中心です。両方を有効にした場合は、ログで最終的にDNSマッピングのドメインが使われたのか、スニッフィングのドメインが使われたのかを確認します。同じ接続で異なる結果が得られると、宛先上書きによってアクセス先が変わる可能性があります。まずは「通常のドメインはFake-IP、スニッフィングは一般的なHTTP/TLSポートだけを確認し、デフォルトでは上書きしない」という控えめな構成から始め、安定後に明確なアプリだけ上書きを有効にします。

スニッフィングの検証は、Webページが開くかどうかだけで判断しないでください。接続詳細の対象ホスト、命中ルール、プロキシグループを確認します。スニッフィングを無効にした状態で一度記録し、同じアプリと同じドメインで接続を作り直してから有効化後と比較します。対象がIPからドメインへ変わったか、ルールがIP系からドメイン系へ切り替わったかを確認してください。既存の長時間接続は設定変更だけでは再接続されません。アプリを完全に終了するか、接続が閉じるまで待つ必要があります。ブラウザーの接続再利用やQUICは古いセッションを長引かせるため、新しいプライベートウィンドウを使い、サイトの接続状態を一時的に削除すると検証しやすくなります。

ドメインスニッフィングは補助的な手段です。DNS問い合わせが安定してカーネルに入り、ルールもドメインで一致しているなら、設定を完全にするためだけに範囲を広げる必要はありません。プロトコルやポートを追加するたびに明確な根拠を用意し、有効化前後のログ差分を記録してください。アプリ更新やネットワーク環境の変化があった後も、以前の互換性例外が必要か判断できます。

CHAPTER 06 / PROFILE MERGE

ローカル上書きと複数購読の統合

購読を更新するとリモート設定が再生成されるため、購読ファイルへ直接書いたルール、DNS、プロキシグループの変更は、次回更新で上書きされることが多くなります。保守しやすい方法は、リモート購読を読み取り専用の入力として扱い、長期的なローカル設定を上書き、拡張スクリプト、独立したメイン設定へ分けることです。クライアントによって上書き形式と統合順序は完全には一致しないため、特定クライアントの拡張構文をmihomo標準のYAMLと見なしてはいけません。クライアントを移行する前に、どのフィールドがカーネルのものか、どれがGUIクライアントの設定管理層のものかを分けて確認してください。

上書き、追加、削除の3つの操作

mixed-portやmodeのようなスカラー項目は通常、直接上書きできます。dnsのようなマッピング項目はキー単位で統合される場合も、全体が置き換わる場合もあります。rulesやproxy-groupsのような配列項目はさらに複雑です。単純な上書きでは購読内容が失われ、単純な追加ではフォールバックルールが後続項目より先に処理を終わらせる可能性があります。特にMATCHはルール末尾に置く必要があります。リモートのMATCHの後ろへローカルルールを追加しても、永遠に一致しません。信頼できる統合処理では、前置き、後置き、名前による置換、明示的な削除に対応し、出力時に最終順序を検査します。

プロキシグループをnameで関連付ける場合、同名グループが置換されることも、重複項目になることもあります。重複名があるとルールの参照先が不明確になり、クライアントの画面に片方しか表示されない場合もあります。統合前に命名規則を決め、たとえばローカルの用途別グループには分かりやすい日本語名を使い、リモートの自動グループには出所プレフィックスを残します。ノード名も衝突する可能性があります。2つの購読に「香港 01」が含まれると、カーネルが重複プロキシ名を報告することがあります。次回更新でも再び衝突するため、各ノードを手作業で直すのではなく、インポート層で出所ごとのプレフィックスを付けます。

# ローカルで管理するメイン設定の断片
proxy-providers:
  provider-a:
    type: http
    url: https://subscription.example.invalid/a
    path: ./providers/a.yaml
    interval: 3600
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 300

  provider-b:
    type: http
    url: https://subscription.example.invalid/b
    path: ./providers/b.yaml
    interval: 3600
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 300

proxy-groups:
  - name: すべての出所
    type: select
    use:
      - provider-a
      - provider-b
    proxies:
      - DIRECT

rules:
  - DOMAIN-SUFFIX,corp.example.invalid,DIRECT
  - RULE-SET,private-domain,DIRECT
  - MATCH,すべての出所

複数のノード購読をまとめるには、proxy-providersを使う方が、複数の完全な設定を直接連結するより明快です。完全な設定にはそれぞれポート、DNS、ルール、同名のプロキシグループが含まれる可能性があり、機械的に連結すると簡単に衝突します。ノードプロバイダーはプロキシ項目だけを提供し、その他はメイン設定で統一して管理できます。上流がprovider形式ではなく完全なClash設定を返す場合は、クライアントがノードを抽出できるか確認するか、信頼できるローカル処理で変換してください。アクセス認証情報を含む購読を、出所不明のオンライン変換サイトへ渡してはいけません。

上書き階層とフォールバックファイル

4層を残す構成がおすすめです。元の購読、ローカル上書き、統合後の最終設定、直近で利用できた設定です。元の購読は上流内容の確認に使います。ローカル上書きをバージョン管理する場合は、購読URLと認証情報を削除してください。最終設定は統合結果の特定に使い、利用可能な設定は障害時の復旧に使います。変更はローカル上書きだけに加え、生成後に構文チェックを行ってからカーネルに読み込ませます。クライアントに最終設定のエクスポート機能がない場合は、実行ディレクトリから実際の読み込みファイルを探せますが、クライアントが自動書き換えする可能性があるため編集元には適しません。

ローカル上書きでは、カスタムルール、固定プロキシグループの枠組み、DNSの選択、LANの例外など、安定した意図を管理するのが適しています。ノード一覧、認証フィールド、上流で随時変化する属性は購読から引き続き提供させます。これにより更新で新しいノードを取得しながら、ローカルの通信振り分けを維持できます。上流が互換性のないフィールドを提供し始めた場合は、上書き層で最小限の削除または変換を行い、理由を記録してください。古い設定全体をコピーして長期間固定すると、ノードとプロトコルの機能が徐々に更新されなくなります。

複数購読の可用性と障害分離

複数のプロバイダーで同じキャッシュパスを共有せず、ヘルスチェックも独立させます。ある出所の更新に失敗しても、他の出所は読み込める状態にします。すべてのグループが失敗した出所だけを参照すると、設定自体は読み込み成功に見えても、プロキシグループに利用可能なメンバーがいなくなることがあります。上位の手動グループに複数の自動グループを残し、出所を分かりやすく表示してください。自動選択グループに用途や地域の異なる全ノードを混在させると、測定結果が頻繁に変わることがあります。まず出所または地域ごとに分け、用途別の層で子グループを選ぶ方が適切です。

統合後は、プロキシグループ名が一意か、すべての参照先が存在するか、プロバイダーのパスが重複していないか、ルール末尾に想定したフォールバックだけがあるか、DNSマッピングが完全か、機密フィールドがログやエクスポートファイルへ意図せず書かれていないかを確認します。購読更新の前後で最終設定を構造化比較し、テキスト行ではなくフィールドの変化を見ます。更新後に起動できなくなったら、まず直近で利用できた設定へ戻し、その後で上流に追加されたフィールドを比較してください。利用不能な状態で上書きルールを連続して変更するのは避けます。

GUIクライアントによって、上書きの入口と保存場所は異なります。Clash Plusは、設定とプロキシグループをGUIで管理したいデスクトップユーザーに適しています。Clash Verge Rev、FlClash、Clash Nyanpasuなども拡張機能やスクリプトに対応している場合がありますが、構文は現在の画面の説明を基準にしてください。クライアントを選び直す場合はクライアント選定ガイドを確認し、コピー可能なスクリプトだけで判断しないようにします。

CHAPTER 07 / EXTERNAL CONTROLLER

外部コントローラーとAPIの境界

mihomoの外部制御インターフェースを使うと、GUIやWebコントローラーから実行状態の取得、ポリシー切り替え、接続確認、設定更新ができます。これは管理用インターフェースであり、プロキシポートではありません。external-controllerにリッスンアドレスを設定すると、クライアントはHTTPとWebSocketでそのポートへ接続します。コントローラーは通常、静的なフロントエンドファイルだけで構成され、実際のデータと操作機能はカーネルのAPIから提供されます。そのため、ページが開かない、開くがデータがない、閲覧はできるが操作できないという症状は、それぞれ静的リソース、API接続、認証・権限など異なる問題に対応します。

リッスンアドレスとアクセス範囲

本機だけで使う場合は127.0.0.1へのバインドが最も安全で、他の機器から直接アクセスできません。LANからサーバーやルーターを管理する必要がある場合だけ0.0.0.0または指定したLANアドレスへバインドし、ファイアウォールで信頼できるネットワークだけを許可します。全インターフェースで待ち受けることは、インターネットへ公開してよいという意味ではありません。制御インターフェースではノード切り替え、接続先の読み取り、設定の再読み込みができるため、公開範囲は通常のプロキシポートより狭くすべきです。遠隔保守には、制御ポートを直接公開するのではなく、SSHトンネルや管理下のリバースプロキシでローカルインターフェースへアクセスする方法を優先します。

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

# 別の端末からSSHでローカルインターフェースを一時転送
ssh -L 9090:127.0.0.1:9090 [email protected]

secretは制御インターフェースの認証に使うため、独立した推測困難な値を設定します。サンプルの文字列は説明用の分かりやすい値にすぎないため、導入時には必ず置き換えてください。コントローラーでは通常、設定画面にAPIアドレスとキーを入力します。APIアドレスはカーネルのリッスン位置を指し、プロキシのmixed-portを指してはいけません。ページをHTTPSで読み込んでいるのにHTTPの制御インターフェースへ接続しようとすると、ブラウザーが混在コンテンツとしてリクエストを遮断することがあります。同一オリジンのリバースプロキシまたは安全なトンネルでアクセス方式を統一し、ブラウザーのセキュリティ制限を無効にしないでください。

external-uiと静的リソースディレクトリ

external-uiはコントローラーの静的ファイルディレクトリを指し、そこには入口HTMLと関連リソースが必要です。この項目はコントローラーをダウンロードするものではなく、パスの基準もカーネルの作業ディレクトリです。システムサービスと手動実行では作業ディレクトリが異なることがあるため、「端末から起動すると表示されるのに、サービスでは空白」という症状は相対パスの解決差で起きがちです。明確な絶対パスを使うか、サービスユニットの作業ディレクトリとファイル権限を確認してください。読み取り専用ファイルシステムでは、コントローラーファイルを事前に読み取り可能な場所へ配置します。

一部の設定では外部UIのダウンロードURLから静的リソースを管理できますが、本番環境では出所を記録し、更新手順を固定してください。コントローラーの更新とカーネルの更新は別の作業です。新しいコントローラーが古いカーネルにないAPIを呼ぶことも、古いコントローラーが新しいフィールドを表示できないこともあります。画面のボタンが効かない場合は、まずブラウザーの開発者ツールでリクエスト状態とAPI応答を確認し、その後カーネルログと照合してください。制御画面の異常だけでプロキシコアが動かなくなることは通常ないため、最初にメイン設定を削除しないでください。

CORS、認証、リバースプロキシ

コントローラーとAPIが異なるオリジンにある場合、ブラウザーはクロスオリジンチェックを行います。mihomoでは、許可するオリジンに関する設定でアクセス可能なページの出所を制限できます。手軽だからと任意のオリジンを許可すると、ブラウザー側の攻撃面が広がります。実際に使うコントローラーのアドレスだけを列挙する方が適切です。オリジン制限を設定しても、キー認証やネットワーク制限の代わりにはなりません。役割は別々です。ファイアウォールはポートへ接続できる相手を制限し、認証は操作権限を判断し、オリジンポリシーはブラウザーから呼び出せるWebページを制限します。

リバースプロキシを使う場合は、WebSocketのアップグレードリクエストを正しく転送してください。そうしないと、通常の状態APIは使えても、リアルタイムログや接続一覧だけが切断され続けます。プロキシ層では認証ヘッダーを保持し、リクエストボディのサイズとアクセスパスも制限します。プロキシポート、制御インターフェース、静的コントローラーを区別のない同一パスへまとめないでください。LANからの利用だけが必要なら、複雑な公開用プロキシより、LANアドレスへの直接バインドとファイアウォールの方が保守しやすいことが多くあります。

インターフェース障害の段階的な確認

まずOSのツールでポートが待ち受けているか確認し、次に基本APIへリクエストして認証を検証し、その後ブラウザーのコンソールを調べます。接続拒否は、カーネルが待ち受けていない、アドレスが誤っている、ファイアウォールに遮断されていることを示します。未認証が返るならAPIには到達しているもののキーが一致していません。通常のリクエストは成功するのにリアルタイム情報だけ失敗する場合はWebSocketを重点的に確認します。コントローラーのリソースが見つからない場合はexternal-uiのパスを調べます。プロキシグループが空に見えるときは、APIの応答とカーネル設定を直接確認し、画面の描画問題か、グループ自体にメンバーがないのかを判断してください。

外部制御インターフェースは自動化されたヘルスチェックにも使えますが、スクリプトで全接続を高頻度にポーリングしたり、キーを公開リポジトリ、コマンド履歴、フロントエンドへ書いたりしないでください。自動処理では必要なエンドポイントだけを読み取り、失敗時にはタイムアウトとバックオフを設定します。設定の再読み込みは状態を伴う操作なので、実行前に利用可能なファイルを保存し、再読み込み後に成功応答とプロキシグループを確認します。コントローラーは便利な入口ですが、最終判断は設定ファイル、API応答、カーネルログを基準にします。

CHAPTER 08 / VALIDATION

設定の検証、ログの切り分け、安全なロールバック

高度な設定の難しさは、個々のフィールドよりも、複数のサブシステムを同時に変更した後で因果関係を特定できなくなる点にあります。保守では、構文検証、静的な参照確認、起動ログ、実行中の接続、業務上の結果を分けて観察します。Webページが開くことは一つの経路が使える証拠にすぎず、DNS、ルール、TUNがすべて期待どおりとは限りません。逆に、特定サイトの失敗だけでノードが使えないとも限りません。変更前に基準状態を記録し、変更後は固定した対象と固定したポリシーでテストすることで、比較可能な結論を得られます。

読み込み前の静的チェック

まずYAMLのインデント、コロン、リスト階層、重複キーを確認します。YAMLはスペースでインデントし、タブは解析エラーの原因になることがあります。コロン、シャープ記号、特殊文字を含む名前は引用符で囲み、構造やコメントとして解釈されないようにします。構文が通ったら、意味上の参照を確認します。ルールが参照するプロキシグループ、グループが参照するノードやprovider、ルールセット名、キャッシュパスの重複、制御インターフェースのポートとmixed-port・DNSリッスンポートの競合を調べます。

mihomoはコマンドラインから設定ディレクトリを指定してチェックできますが、実行ファイル名やパラメーターの入口は配布パッケージによってクライアント側にラップされている場合があります。カーネルを直接使う場合は、実際の実行環境で設定テストを行い、相対パス、権限、リソースファイルがサービス環境と一致していることを確認してください。個人の端末だけで検証し、サービスが別アカウントで動いていると、パスや権限の問題を見落とす可能性があります。

# 実際の設定ディレクトリへ移動して実行
mihomo -t -d /path/to/config-directory

# フォアグラウンドで起動して完全なログを確認
mihomo -d /path/to/config-directory

# Linuxでルートと待ち受けポートを確認
ip route
ss -lntup

設定テストに成功しても、リモートリソースが必ずダウンロードできるとは限らず、ノード接続が保証されるわけでもありません。主にローカル構造と一部リソースの読み取りを確認するものです。初回起動時は、provider更新、DNSの待ち受け、TUNインターフェース、制御ポート、プロキシポートのログを続けて確認します。ログの最初のエラーは、後続の連鎖エラーより根本原因に近いことが多くあります。たとえばDNSの待ち受けポートが競合すると解析が使えなくなり、その後に大量に出るノードドメイン解決失敗は結果にすぎません。

実行フローに沿ったテストマトリクス

テストは最小限の経路から機能を段階的に追加します。第1段階ではTUNを無効にし、システムプロキシと固定した手動ノードで基本的なTCP接続を確認します。第2段階ではノードを変えず、ドメイン解決とルール一致を検証します。第3段階で自動ポリシーグループへ切り替え、ヘルスチェックを確認します。第4段階でTUNを有効にし、第5段階でスニッフィング、上書き、複雑なルールセットを追加します。各段階で増やす変数は1つだけにしてください。第3段階で失敗したなら、第5段階のスニッフィングパラメーターまで疑う必要はありません。

ログを段階ごとに読む

起動段階では設定解析、ポートバインド、リソース読み込み、仮想インターフェース作成を確認します。購読段階ではHTTPステータス、タイムアウト、形式解析、キャッシュ書き込みを確認します。DNS段階では問い合わせ元、上流の選択、応答結果を見ます。接続段階では宛先、ルール、プロキシグループ、実際のノードを確認し、実行段階ではヘルスチェックと接続終了の原因を観察します。「timeout」と表示されたからといって、すぐノードを交換しないでください。同じ語がルールダウンロード、DNS問い合わせ、プロキシハンドシェイク、業務サーバーのいずれから出ることもあり、原因ごとに対処が異なります。

接続詳細には通常、送信元アドレス、対象ドメインまたはIP、ネットワーク種別、命中ルール、ポリシーチェーン、送信ノードが表示されます。これらを順に読めば、リクエストがどの層で期待から外れたか判断できます。対象ドメインが正しいのにMATCHへ到達するなら、前のルールが対象をカバーしていません。ルールは正しいのに想定外のノードへ落ちるなら、グループ内の選択と自動テストを確認します。ポリシーとノードが正しいのに失敗する場合は、ノード接続、対象サービス、MTUを調べます。モードを何度も切り替えるより、この順序の方が解決へ収束しやすくなります。

ロールバックはファイルを戻すだけではない

設定障害では、ルート、仮想インターフェース、DNSキャッシュ、リモートリソースのキャッシュが同時に残ることがあります。YAMLを復元しても症状が続く場合は、カーネルがそのファイルを再読み込みしたか、古いプロセスが終了しているか、TUNのルートが消去されたか、システムプロキシが復元されたか、DNSキャッシュが更新されたかを確認します。GUIクライアントが画面用設定と実行用設定を別々に保存していることもあり、誤ったファイルを復元してもカーネルの動作は変わりません。ロールバック後は起動ログで読み込んだ設定パスを再確認してください。

安定した変更ごとに、少なくとも設定ファイル、関連するルールセットの版、クライアントが使う設定ディレクトリ、変更内容を保存し、ロールバック可能な状態を作ることをおすすめします。記録には「何を解決するか、どのフィールドを変更したか、どう検証するか、どう戻すか」を明記し、「DNSを最適化」のような抽象的な説明だけにしないでください。購読URLと制御キーを公開リポジトリへ入れてはいけません。独立したローカルの秘匿ファイルや実行環境から注入し、設定から参照する方法を使えます。ログを共有する場合も、購読パラメーター、ノード認証情報、制御キー、内部ドメインを削除してください。

再現可能な保守手順を作る

一連の調整は次の順序で実行できます。現在利用できる設定をコピーし、最終的な統合結果をエクスポートまたは記録し、1つのテーマだけを変更します。その後、静的チェック、フォアグラウンドでの読み込みと最初のエラー確認、固定ノードでのシステムプロキシ検証、DNS問い合わせとルール一致の確認を行い、最後にTUNとスニッフィングを有効にします。安定してから自動ポリシーとリモート更新へ戻します。どこかで失敗したら、直前の利用可能な設定へ戻し、その段階で作られた実行状態を消去します。時間はかかりますが、複数の変数が重なった状態で長時間手探りするのを防げます。

ログ量が多い環境では、対象ドメイン、送信元プロセス、時間範囲で絞り込み、詳細ログを常時有効にする必要はありません。詳細ログは短時間の調査に適していますが、継続すると大量の記録が発生し、機密情報の露出範囲も広がります。問題解決後は通常のログレベルへ戻し、簡潔な障害概要だけを残してください。起動、購読、DNS、接続、ルール段階の代表的なエラーを理解するには、実行ログの切り分け手順と照合します。LAN共有でmixed-port、リッスンアドレス、ファイアウォールが関係する場合は、混合ポートとLANプロキシ設定を参照してください。