まずカーネルを確認：クライアント名だけでは機能は判断できない
サブスクリプションを追加したときにunsupport proxy typeと表示されたり、設定にsnifferを記述しても期待どおりに動作しなかったりする場合、まずノードのパスワードを変更するのは避けましょう。最初に確認すべきなのは、実際に起動しているカーネルです。クライアントの画面はサブスクリプション管理やシステムプロキシの設定、各種操作を担い、カーネルは設定の解析、ルール判定、接続を担います。画面上の名前が似ていても、同じ設定項目に対応しているとは限りません。
ここでいう「オリジナル版Clash」は、オリジナルのオープンソースカーネルと、かつて独立して配布されていたClash Premiumの2つに分けて考えます。PremiumのTUNやルールセットなどの機能を、オリジナルのオープンソースカーネルの機能として扱うことはできません。mihomoはClash Metaから発展したもので、多くのClash設定の慣習を受け継いでいますが、単なる名称変更ではありません。
- デスクトップクライアント：「バージョン情報」でカーネルのバージョンを確認し、起動ログもチェックしてください。メニュー名はクライアントによって異なるため、実際の画面で確認しましょう。
- コマンドラインでの導入：実際に実行中のバイナリに対して
mihomo -vを実行してください。ダウンロードフォルダーにある別のプログラムのバージョンだけを確認しないようにしましょう。 - ルーターまたはコンテナ：プラグインで選択されているカーネル、コンテナイメージ、プロセスのパスをすべて確認してください。管理画面を更新しても、カーネルが更新されるとは限りません。
対応プロトコル：VLESS、Hysteria2、TUICが主な違い
現在のサブスクリプションに従来のShadowsocks、VMess、Trojanノードしか含まれていない場合、移行しても目立った違いはないかもしれません。互換性エラーが起きやすいのは、新しいプロトコルや暗号方式、プロトコル固有のトランスポート設定です。ノード名に「Hysteria2」と書かれているだけでは判断できません。カーネルが読み取るのは、YAML内のtypeと関連する設定項目です。
| プロトコル・機能 | オリジナル版Clash | mihomo |
|---|---|---|
| Shadowsocks、VMess、Trojan | 一般的な基本プロトコルに対応。利用できる設定はバージョンによって異なる | 対応。以降も機能が追加されています |
| VLESS | オリジナルのオープンソース版とPremiumでは、このプロトコルに非対応 | 対応。ノードタイプはvless |
| Hysteria2 | 非対応 | 対応。ノードタイプはhysteria2 |
| TUIC | 非対応 | 対応。ノードタイプはtuic |
| VLESSとREALITYの組み合わせ | 非対応 | 対応する設定を利用可能。ただしサーバー側の設定との一致が必要 |
エラーが発生した段階から、確認すべき項目を絞る
設定テストで「サポートされていないプロキシタイプ」と表示される場合、問題はローカルでの設定解析段階にあり、ノードへの接続テストには進んでいません。一方、設定の読み込みに成功して接続がタイムアウトしたとしても、プロトコルが非対応とは限りません。サーバーのアドレスやポート、認証情報、トランスポートのネットワークを確認してください。
- VLESS：UUID、TLS、
servername、トランスポート方式、flowを確認します。REALITYを使う場合は、公開鍵やshort IDなどの設定も照合してください。 - Hysteria2：QUICを使用するため、UDPで通信できる必要があります。サーバーのTCPポートだけをテストしても、ノードが使える証明にはなりません。また、初代Hysteriaの設定を名称だけ変えて使わないでください。
- TUIC：UDPの通信環境を確認し、認証項目がサーバー側のプロトコルバージョンと一致していることも確認してください。クライアントがTUICに対応していることは、サーバー設定が正しい証拠にはなりません。
サブスクリプション変換にも限界があります。変換ツールで設定項目の順序は変更できても、古いカーネルにプロトコルの機能を追加することはできません。変換後にノードが消えた場合は、mihomo向けの形式が出力されているか、変換サービスがそのプロトコルに対応しているかを確認しましょう。同じ非互換のサブスクリプションを何度も更新するのは避けてください。
ルールセットの比較：rule-providersはmihomo独自の機能ではない
rule-providersはルールセットの取得元を定義し、RULE-SETはルール一覧からそのルールセットを参照します。この機能ではオリジナルのオープンソース版とPremiumに明確な違いがあります。Premiumはすでにルールセットに対応しているため、ルールセットの機能すべてをmihomoの新機能とみなすことはできません。mihomoはその機能を拡張し、より多くの形式や使い方に対応しています。
| 設定項目 | 移行時の確認ポイント |
|---|---|
rules |
基本ルールは上から順に評価され、最初に一致したルールのポリシーが適用されます。 |
rule-providers |
Premiumは対応。オリジナルのオープンソースカーネルが同じ機能を持つとは限りません。 |
behavior |
domain、ipcidr、classicalを区別し、宣言した形式に合う内容を指定します。 |
format: mrs |
mihomoのルールセット形式に関する機能です。domainとipcidrで利用でき、classicalには対応していません。 |
type: inline |
mihomoではルールの内容をproviderのpayloadに直接記述できます。古いカーネルで使えるとは限りません。 |
まずローカルのYAMLでルールセットの動作を確認
以下はmihomoの設定に追加できるルールの例です。リモートからのダウンロードを使わないため、「ルールの記述ミス」と「ルールファイルの取得失敗」を切り分けるのに役立ちます。設定では組み込みポリシーのDIRECTとREJECTのみを使い、未定義のプロキシグループには依存しません。
rule-providers:
local-block:
type: file
behavior: domain
format: yaml
path: ./rules/local-block.yaml
rules:
- RULE-SET,local-block,REJECT
- MATCH,DIRECT設定の作業ディレクトリにrules/local-block.yamlを作成し、以下の内容を記述します。ここで使うexample.orgはルールの動作を示すための予約ドメインです。テストでは、このドメインとサブドメインへの接続が拒否されることを確認してください。
payload:
- '+.example.org'behavior: domainにはドメインの照合対象を記述します。DOMAIN-SUFFIX,example.orgのようなルール形式は使わないでください。classicalを使う場合は、DOMAIN-SUFFIX,example.orgのように該当するルール形式で記述し、ルールセット内に最終的な出力ポリシーは追加しません。
snifferとDNS：ドメインの識別は通信の復号ではない
移行後、一部の接続でIPルールではなくドメインルールが適用される場合、DNSのマッピングやスニッフィングが関係していることがあります。mihomoのsnifferは、HTTPのHostやTLSのSNI、対応するQUICハンドシェイク情報など、一部のプロトコルのハンドシェイクからホスト名を取得できます。証明書をインストールしてHTTPS通信を復号する中間者機能ではなく、すべての接続でドメインを識別できるわけでもありません。
まず動作を確認し、必要な場合だけ接続先の上書きを有効にする
sniffer:
enable: true
sniff:
HTTP:
ports: [80, 8080-8880]
override-destination: false
TLS:
ports: [443, 8443]
override-destination: falseこの例ではHTTPとTLSのみを指定しています。すべてのポートでスニッフィングが必要という意味ではありません。override-destination: falseは、スニッフィング結果で接続先を上書きしない設定です。取得した情報がドメインの識別やルール判定に使われる場合はあります。接続先を上書きするかどうかはDNSやアプリの動作をテストして判断してください。常に有効にする最適化スイッチではありません。
- ドメインを識別できない：設定対象のポートを経由していない、ハンドシェイクに利用可能なドメイン情報が含まれていない、またはアプリが関連情報を隠す仕組みを使っている可能性があります。
- アプリが接続先のIPアドレスを直接指定：スニッフィングでドメインを特定できるとは限りません。必要なIPルールを残し、ドメインルールだけにしないでください。
- 意図しないルールが適用される：ルールの順序、DNSの応答、fake-ipのマッピング、snifferの設定をあわせて確認してください。最初からスニッフィングの対象範囲を広げるのは避けましょう。
dns.enhanced-mode: fake-ipとredir-hostは異なる処理方式です。fake-ipもmihomo独自の機能ではありません。移行時はまず従来のDNSモードを維持し、変更が必要な場合は個別に設定して関連するDNSキャッシュを削除してください。カーネルのDNS待ち受けアドレスは、システムまたは通信経路と接続する必要があります。dns.listenを指定しただけでは、システムのDNSリクエストがそこに送られるとは限りません。
TUNとポート：設定の互換性があっても通信経路は同じとは限らない
ブラウザーではアクセスできるのに、ゲームやコマンドライン、ほかのアプリではプロキシを経由しない場合、すぐにプロトコルを変更せず、まず通信の入口を確認してください。システムプロキシの設定は、その設定に従うアプリにのみ影響します。TUNは仮想ネットワークインターフェースで通信を受け取るため、より多くのアプリを対象にできますが、権限やルーティング、DNSの引き継ぎも関係します。
オリジナル版のPremiumにはTUNが搭載されていますが、オリジナルのオープンソースカーネルと混同しないでください。mihomoもTUNに対応していますが、古い設定のスタック選択、インターフェースのパラメーター、ルーティング設定が、すべてのOSでそのまま動作するとは限りません。Windows、macOS、Linuxでは権限やサービスの管理方法が異なります。
移行時は2段階で検証する
- まずTUNを無効にして、明示的なプロキシ設定でノードとルールが正常に動作することを確認します。たとえば
mixed-port: 7897と設定した場合、接続先は127.0.0.1:7897です。7897はここでの例であり、すべてのクライアントで共通のポート番号ではありません。 - 以下のコマンドをターミナルで実行し、リクエストが実際にこの入口を経由していることを確認します。テスト用URLで確認できるのは基本的なHTTPS接続のみで、すべてのサイトへの接続を保証するものではありません。
- 明示的なプロキシ設定で正常に動作することを確認してから、クライアントでTUNを有効にします。管理者権限やサービスの状態、仮想インターフェースとルートが設定されていることを確認し、最後にシステムプロキシを参照しないアプリでテストしてください。
curl --proxy http://127.0.0.1:7897 --connect-timeout 10 -I https://example.comaddress already in useが表示されたら、まずカーネルが2つ同時に起動していないか確認してください。移行中に古いクライアントを終了し忘れると、ローカルの待ち受けポートが競合することがあります。ネットワーク全体に接続できなくなった場合は、新しいクライアントのTUNとシステムプロキシを無効にして基本の通信を復旧させてから、原因を一つずつ調べてください。複数のVPNやルーティング制御ツールを同時に重ねて使うのは避けましょう。
設定の移行手順：テスト・読み込み・ルール・接続性を分けて確認
設定を「読み込める」ことが示すのは、その時点の解析と初期化に成功したということだけです。すべての設定項目が使われているとも、ノードやDNSが利用できるとも限りません。認識されない設定項目があっても、目立ったエラーが表示されないことがあります。実行ログと実際の動作も確認してください。
- 現在の状態をバックアップ：元のサブスクリプション、統合後の実行設定、ローカルの上書き設定を保存します。サブスクリプションURLやノードの認証情報を公開の掲示板に投稿しないでください。
- 対応するサブスクリプション形式を選択：サブスクリプションサービスがClash形式とClash Meta/mihomo形式を提供している場合は、実際に使うカーネルに合わせて選択します。ボタン名だけで判断せず、生成された設定を確認してください。
- まず設定テストを実行：実際に導入したバイナリを使い、設定ファイルと作業ディレクトリを指定してください。相対パスが意図しない場所を参照するのを防げます。
- 入口とノードを確認：まず明示的なプロキシ設定でテストし、接続ログで選択されたノードまたはプロキシグループを確認します。接続に失敗した場合は、エラーの内容を一連のログとして保存してください。
- ルールセットを確認：providerの読み込みに成功しているか、ルールが存在するか、テスト対象のドメインに実際にどのルールが適用されたかを確認します。
- 最後に拡張機能を有効化：DNS、sniffer、TUNの変更は1回につき1項目に絞ります。問題が発生したとき、直前の動作する設定に戻せる状態にしてください。
mihomo -v
mihomo -t -d /srv/mihomo -f /srv/mihomo/config.yaml上記の/srv/mihomoはLinux環境での導入例です。実行前に、ファイルが実際にそのディレクトリにあることを確認してください。Windowsでは、設定ファイルのあるディレクトリでmihomo.exe -t -d . -f .\config.yamlを実行してテストできます。クライアントがカーネルを管理している場合、最終的に使われる設定ファイルはサブスクリプションと上書き設定を統合して生成されることがあります。使用されていない元のファイルだけをテストしないようにしてください。
選び方：ノードのプロトコルと運用・保守の要件で判断
VLESS、Hysteria2、TUIC、MRS形式のルールセット、snifferなどが必要なら、mihomoの機能が要件に適しています。従来のプロトコルを使った設定を維持するだけなら、設定を検証できること、クライアントが保守されていること、問題発生時に原因箇所を特定できることが重要です。カーネルを変更するだけで遅延が自動的に改善するわけではありません。
- 現在の設定が安定している：バックアップを残し、専用のテスト環境で新しいカーネルを確認してください。ノード、ルール、DNSを同時に変更しないようにしましょう。
- サブスクリプションでプロトコル非対応と表示される：生成形式と実際に動作しているカーネルを確認してから、クライアントまたはカーネルを切り替えるか判断してください。
- ルーターのリソースに余裕がない：ルールセットの容量、読み込み時間、利用可能なメモリーを確認してください。形式を選ぶだけでは、実際の動作状況は判断できません。
- mihomoから元のカーネルに戻す：移行先のカーネルが対応していないプロトコルや設定項目を一つずつ削除してから、設定テストと接続確認をやり直してください。
違いは3つの層で整理できます。プロトコルはノードを認識できるかを決め、ルールとDNSは接続の振り分け方を決め、システムプロキシやTUNは通信をカーネルに通せるかを決めます。この3つを順に確認すると、複数の設定を同時に切り替えるより原因を見つけやすくなります。