コアの役割：Clash Metaとmihomoの設定範囲

mihomoはClash Metaから引き継がれたプロキシコアです。クライアントは設定管理、システムプロキシ、画面操作を担い、コアは接続の待ち受け、ルールの解析、プロキシ経路の確立を担います。クライアント名にClashが含まれていても、mihomoを使っているとは限りません。YAMLを読み込めても、記述されたすべてのプロトコルや拡張項目に対応しているとは限りません。

この記事でいう「新機能」は、初期のClashオープンソースコアと比べて拡張された機能を指し、特定のバージョンで特定の日に追加された機能を意味するものではありません。ルールプロバイダーはClash Premiumなどの派生版にも実装されており、rule-providersをmihomo独自の項目とみなすことはできません。移行時はクライアントの見た目だけで判断せず、現在使用中のコアを確認してください。

機能主な設定項目有効化の条件
外部ルールセットrule-providers、RULE-SETルール形式とbehaviorが一致し、リソースを読み込めること
ドメインスニッフィングsniffer接続がコアに到達し、通信に識別可能なドメイン情報が含まれていること
VLESSアウトバウンドtype: vlessサーバーのプロトコル、トランスポート層、TLS設定が一致していること
Hysteria2アウトバウンドtype: hysteria2サーバーがHysteria2に対応し、ネットワークで必要なUDP通信が許可されていること

まず実行中のコアを確認する

単独で導入している場合は、次のコマンドを実行できます。GUIクライアントでは、まずコア情報画面と起動ログを確認してください。システムのターミナルで見つかる同名のプログラムが、クライアントから実際に呼び出されている実行ファイルとは限りません。

mihomo -v
mihomo -t -f config.yaml

-vはコアのバージョン確認、-tは指定した設定ファイルの検証に使います。設定の検証で多くの項目エラーや参照ミスを見つけられますが、リモートノードへの接続確認にはならず、DNS・TCP・UDPの実通信テストの代わりにもなりません。未対応の項目がある場合は、バージョン情報を省略せず記録し、そのバージョンの設定ドキュメントと照らし合わせてください。

rule-providers：ルール内容と振り分け方針を分離する

大量のドメインを一つずつrulesに記述すると、メンテナンスの手間が増えます。ルールプロバイダーを使えば、「照合する条件の集合」を独立したリソースに分離し、メイン設定には集合名、更新方法、適用するアクションだけを記述できます。ルールセットはノードのサブスクリプションではありません。前者は照合条件、後者はプロキシサーバーを提供するもので、相互に読み込むことはできません。

HTTPルールセットとRULE-SETの参照

以下では公開ドメインルールセットを使い、各項目の関係を説明します。リモートリソースは提供元のプロジェクトが管理しているため、導入前に内容と用途を確認してください。例では一致した通信をREJECTに振り分け、それ以外は直接接続します。目的はルールセットの読み込み確認であり、完全な中国本土・国外の振り分け設定ではありません。

mode: rule
log-level: info

rule-providers:
  reject-domains:
    type: http
    behavior: domain
    format: yaml
    url: https://raw.githubusercontent.com/Loyalsoldier/clash-rules/release/reject.txt
    path: ./ruleset/reject-domains.yaml
    interval: 86400

rules:
  - RULE-SET,reject-domains,REJECT
  - MATCH,DIRECT
  • type: http：HTTPまたはHTTPSでリソースを取得します。初回利用時にはネットワークに接続できる必要があります。
  • behavior: domain：内容をドメインの集合として扱い、ルール文全体としては解釈しません。
  • format: yaml：リソースの形式を指定します。URLの末尾が.txtでも、内容が必ずプレーンテキスト形式とは限りません。
  • path：ローカルのキャッシュ先です。コアの作業ディレクトリに書き込み権限があることを確認し、複数のルールセットで同じファイルを使わないようにしてください。
  • interval: 86400：更新間隔は86400秒、つまり24時間です。ミリ秒ではありません。

behaviorとファイルの内容を一致させる

domainはドメインの集合、ipcidrはIPアドレス範囲の集合、classicalはDOMAIN-SUFFIXやIP-CIDRなどのルール文に使います。名前だけを変更して、同じファイルを使い回すことはできません。以下はローカルのclassical形式のYAMLファイル例です。一般的なドメイン一覧との違いを確認できます。

payload:
  - DOMAIN-SUFFIX,example.com
  - IP-CIDR,192.168.50.0/24,no-resolve

ここでのexample.comは予約済みの例示用ドメイン、192.168.50.0/24はプライベートIPアドレス範囲の例です。このファイルに記述するのは照合条件だけです。直接接続、プロキシ、拒否のいずれにするかは、メイン設定のRULE-SET,集合名称,策略名称で決まります。出口を分けたい場合は、条件を別々の集合に分けてください。集合の各項目に方針グループを任意に付け足す方法は避けましょう。

ドメインスニッフィング：通信内容からドメイン情報を補う

宛先IPアドレスでコアに届いた接続では、ドメインルールの照合に必要な情報が不足する場合があります。スニッフィングは、HTTPのHost、TLS ClientHelloで確認できるSNI、または対応するQUICハンドシェイクの情報を読み取り、宛先ドメインを補います。HTTPSを復号する機能ではないため、暗号化されたWebページの本文を取得することはできません。また、すべての接続でドメインを識別できるわけではありません。

HTTP・TLS・QUICの設定例

sniffer:
  enable: true
  force-dns-mapping: true
  parse-pure-ip: true
  override-destination: false
  sniff:
    HTTP:
      ports: [80, 8080]
    TLS:
      ports: [443, 8443]
    QUIC:
      ports: [443]

portsは、対象のプロトコルを識別しようとするポートの範囲です。443だけを指定しても、他のポートで動作するすべてのTLSサービスを自動的に対象にはできません。parse-pure-ipはIPアドレスのみの宛先でもスニッフィングを試みる設定、force-dns-mappingは関連するDNSマッピングがある場合にスニッフィングを続ける設定です。どちらもドメインを必ず取得できることを保証するものではありません。

例ではoverride-destinationをfalseに設定し、スニッフィングしたドメインで元の宛先を上書きしないようにしています。まずルールの照合結果の変化を確認する場合に適しています。trueにすると接続先の扱いが変わるため、個別にテストしてください。取得したドメインがルール選択に影響する場合はありますが、ルールは現在のモードと記述順に従います。グローバルモードでドメイン単位の振り分けが完全に行われるとは限りません。

Fake-IP・TUNとの関係

  • Fake-IP：コアが管理するDNSマッピングで、ドメインと偽装アドレスを対応付けます。アプリのDNS通信がコアを経由していれば、通常は利用可能なドメイン情報があるため、スニッフィングは補助的な仕組みです。
  • TUN：仮想ネットワークインターフェースを通じて通信を取り込みます。取り込む範囲は広がりますが、すべての接続に自動でドメイン情報が付くわけではありません。
  • スニッフィング：コアに届いた接続を処理します。システムプロキシを迂回し、TUNも通らない通信は取り込みません。
  • 識別できないケース：ECHなどの暗号化方式、標準外のハンドシェイク、SNIの欠落、未対応プロトコルなどにより、想定したドメインを取得できない場合があります。

トラブル対処では、まずクライアントの接続一覧に対象の通信が表示されているか確認し、次に宛先IP、識別されたドメイン、適用ルール、最終的な方針を調べてください。接続がコアに届いて初めて、snifferの調整が意味を持ちます。アプリの通信が取り込まれていない場合は、スニッフィングのポート範囲を広げ続けるのではなく、システムプロキシやTUNのルーティングを先に確認してください。

VLESS：プロトコル・トランスポート・TLSを個別に確認

VLESSはプロキシプロトコル、WebSocketは選択可能なトランスポート方式、TLSは接続を保護するレイヤーです。これらは同じ設定項目ではありません。サーバーがVLESS over WebSocket over TLSを使う場合、クライアント側でもUUID、ポート、WebSocketパス、Host、TLSのサーバー名をすべて一致させる必要があります。

以下は予約済みの例示用ドメインとデモ用UUIDを使った項目構成の例で、実際に使えるサービスではありません。実際に設定する際は、サーバーから提供された完全なパラメーターを使用してください。接続エラーを解消するためにパスを推測したり、証明書の検証を無効にしたりしないでください。

proxies:
  - name: VLESS-WS-TLS
    type: vless
    server: vless.example.com
    port: 443
    uuid: 550e8400-e29b-41d4-a716-446655440000
    network: ws
    tls: true
    servername: vless.example.com
    udp: true
    ws-opts:
      path: /proxy
      headers:
        Host: vless.example.com

よくある設定の食い違い

  1. トランスポート方式の不一致：サーバーがTCPを使っているのに、クライアント側でnetwork: wsを設定しても、ポートの変更では解決できません。
  2. ドメイン項目の役割の混同：serverは接続先アドレス、servernameはTLS用、WebSocketのHostはHTTPリクエスト用です。構成によって値が異なることはありますが、任意に入れ替えることはできません。
  3. パスの不一致：/proxyなどのパスは、リバースプロキシによって異なるサービスに転送される場合があります。サーバーで指定されたパスと大文字・小文字をそのまま使ってください。
  4. 別方式の設定項目を混在：REALITY、公開鍵、フィンガープリント、flowにはそれぞれ適用条件があります。一般的なWebSocket TLSの例にそのまま追加しないでください。

プロキシを追加したら、既存の方針グループにその名前を登録し、ルールからそのグループを参照する必要があります。proxiesに追加しただけでは、実際のリクエストで選択されるとは限りません。クライアントがサブスクリプション設定を定期的に上書きする場合は、クライアント対応のオーバーライド機能やマージ機能を使って独自項目を保存し、次回の更新で消えないようにしてください。

Hysteria2：UDPの経路を確認してから通信設定を調整

Hysteria2はQUICをベースとしており、UDP通信が必要です。初代Hysteriaとは設定構文が異なります。ノードの種類がHysteria2の場合は、type: hysteria2を使用してください。TCPでサーバーの443番ポートに接続できても、同じポートのUDPサービスに到達できるとは限りません。

proxies:
  - name: HY2-TLS
    type: hysteria2
    server: hy2.example.com
    port: 443
    password: demo-password-for-documentation
    sni: hy2.example.com
    skip-cert-verify: false

ここでも予約済みの例示用ドメインとデモ用の認証情報を使用しています。passwordはサーバーの認証設定と一致させ、sniは実際の証明書とサーバー構成に合わせてください。サーバーで特定の難読化方式が有効な場合は、対応する項目も設定する必要があります。同じプロトコル名だからといって、必要な設定を省略できるわけではありません。

接続タイムアウト時の確認手順

  • サーバーアドレスが想定したIPアドレスに名前解決されるか確認します。IPv4とIPv6の両方の経路が利用できるかも確認してください。
  • サーバーでUDP 443が待ち受け状態になっており、ホストのファイアウォール、クラウドのセキュリティグループ、中継ゲートウェイで対象の通信が許可されているか確認します。
  • 認証情報、SNI、証明書の有効期限、クライアント端末の時刻を確認します。
  • 別のネットワークでもテストし、現在のネットワークでUDPが制限されているかを切り分けます。
  • 基本接続が確立したら、サーバーの指定に従って帯域幅や難読化の設定を調整します。一度に変更する設定は一種類にしてください。

Hysteria2の実際の性能は、パケットロス、輻輳、通信事業者のポリシー、サーバーのリソースに左右されます。プロトコル名だけで一定のスループットが保証されるわけではありません。比較する際は、同じ端末、ネットワーク、接続先を使い、接続成功率と通信速度をそれぞれ記録してください。一度の測定結果をあらゆる環境に当てはめないようにしましょう。

設定検証：解析・リソース・接続・ルールの順に確認

ルールセット、スニッフィング、新しいプロトコルは組み合わせて使えますが、移行時にすべてを同時に有効にするのは避けましょう。まず元の設定をバックアップし、動作確認済みの出口を一つ残してから、項目ごとに変更してください。以下の手順で、「設定の読み込み失敗」と「ノードへの接続失敗」を分けて対処できます。

  1. 解析：mihomo -t -f config.yamlを実行し、インデント、同じ階層で重複したキー、未対応のプロキシタイプ、存在しない方針グループへの参照を確認します。
  2. リソース：コアを起動し、ルールセットのダウンロードが成功するか確認します。HTTPエラー、書き込み権限、内容形式の不一致はそれぞれ分けて調べてください。
  3. 接続：まずプロキシノードを一つ選び、ハンドシェイクを確認します。VLESSではトランスポートとTLS、Hysteria2ではUDPと認証を重点的に確認してください。
  4. ルール：ルールモードに切り替え、対象の通信が想定したRULE-SETに一致するか、最終的な出口が方針グループで現在選択されているものと一致するか確認します。

ポートを指定してローカルのプロキシ入口を確認

テスト用設定でmixed-port: 7890を指定している場合、次のリクエストでローカルのHTTPプロキシ入口を確認できます。mixed-portはHTTPとSOCKSの両方の接続を受け付けます。このポートはノードのサーバーポートでも、外部コントローラーのポートでもありません。

curl -I --proxy http://127.0.0.1:7890 https://example.com

このコマンドで確認できるのは、今回のリクエストの処理結果だけです。接続ログも確認し、プロキシノードとDIRECTのどちらを経由したかを調べてください。Webページの応答が返ってきただけでは、振り分け設定が正しいとは判断できません。テスト中は一時的にlog-levelをdebugにし、終了後にinfoへ戻してください。ログを共有する前に、サブスクリプションURL、認証情報、個人のアクセス記録を削除してください。

YAMLの統合ではトップレベルのキーを重複させない

この記事のコードブロックは機能ごとの断片を示しているため、整理せずにファイル末尾へ続けて貼り付けないでください。既存のproxiesがある場合は新しいノードをそのリストに追加し、rulesがある場合は優先順位に沿ってルールを挿入します。同じ名前のトップレベルキーを重複して定義すると、エラーになったり、パーサーによって上書きされたりすることがあります。この動作を設定の統合に利用しないでください。

移行完了の目安は、コアのバージョンが確認でき、設定テストに合格し、ルールリソースを利用でき、対象プロトコルでハンドシェイクが成功し、接続ログに想定したルールと出口が表示されることです。システム全体の通信を取り込む場合は、TUNを個別に有効化し、LANへのアクセス、DNS、アプリの接続を改めてテストしてください。基本操作は当サイトの設定ガイド、用語は用語一覧をご覧ください。