クライアント・カーネル・設定ファイルを区別する
「サブスクリプションをインポートできるのにノードへ接続できない」と「クライアントにTUNの設定がない」は、同じレイヤーの問題ではありません。GUIクライアントはサブスクリプション管理、トレイメニュー、システムプロキシ、設定のマージを担当します。カーネルは最終的な設定を読み込み、ポートを待ち受け、DNSを解決し、ルールを照合してプロキシ接続を確立します。設定ファイルは、こうした動作を記述するものです。Clashの標準版、Clash Meta、mihomoの違いを判断するときは、ウィンドウに表示されたアプリ名だけでなく、実際に動作しているカーネルを確認しましょう。
- クライアントのバージョン：画面、サービスのインストール方法、設定の上書き方法を左右します。GUIを更新しても、カーネルが同時に更新されるとは限りません。
- カーネルのバージョン：プロトコルの実装、対応フィールド、ルーティング機能を左右します。クライアントの起動ログ、またはカーネルのバージョン確認コマンドの出力を基準にしてください。
- サブスクリプションの形式：Clash形式の完全なYAMLの場合もあれば、ノード一覧だけの場合や、エンコードされた共有リンクの集合の場合もあります。これらはそのまま相互に置き換えられません。
標準版・Meta・mihomoの関係
Clash標準版：オープンソース版とPremiumを分けて考える
Clash標準版とは、一般にDreamacro/Clashを指します。かつてはオープンソースのカーネルに加え、機能を追加したクローズドソースのPremiumビルドも提供されていました。元のプロジェクトはすでにメンテナンスを終了しています。標準版がTUNやスクリプト、特定のルールに対応しているかを論じる場合は、どのビルドを指すのか明確にしましょう。Premiumの機能をすべてオープンソース版の機能として扱ったり、両者の設定が完全に一致すると考えたりするのは誤りです。
たとえば、標準版のオープンソースカーネルにあるmixed-portと、PremiumのTUN機能は別の種類の機能です。前者はローカルのHTTP/SOCKSプロキシの入口を提供し、後者は仮想ネットワークインターフェースによる通信の取り込みに関わります。設定にtun:があっても、Clashと名の付くあらゆるバイナリが実行できるとは限りません。
Clash Meta：標準版から機能を拡張した派生版
Clash MetaはClashから派生したプロジェクトで、プロトコル、DNS、ルール、TUNなどの機能を拡張しています。「Meta用の設定」とは通常、この派生版がサポートする拡張フィールドを使った設定を指し、まったく別のファイル形式という意味ではありません。YAMLを引き続き使用し、proxies、proxy-groups、rulesといったおなじみのトップレベル構造も利用します。
mihomo：Metaプロジェクトの後継名称
Clash Metaは後にmihomoへ改称されており、両者にはプロジェクトとして直接の継続性があります。無関係な別々のカーネルではありません。クライアントのカーネル項目が「Meta」のままでも、実行ファイルはすでにmihomoという場合があります。一方、古いMetaのバイナリが、名称が似ているというだけで後から追加されたフィールドに対応するわけではありません。実際の互換性は具体的なバージョンによって決まります。
# 手動でインストールしたカーネルのバージョンを確認
mihomo -v
# 旧Clashバイナリのバージョンを確認
clash -v上記のコマンドを実行するには、対象の実行ファイルがシステムの検索パスに含まれている必要があります。Windows PowerShellでカレントディレクトリにあるファイルを実行する場合は、.\mihomo.exe -vを使用できます。クライアントにカーネルが同梱されている場合は、別の場所にグローバルインストールされたプログラムを調べないよう、起動ログに記録されたバージョンを優先して確認してください。
プロトコル対応：ノードの種類と通信パラメーターを確認
プロトコル名は最初に確認すべき項目ですが、それだけでは不十分です。同じVMessやTrojanのノードでも、WebSocket、gRPC、TLSなどの通信方式や暗号化設定が異なる場合があります。ノードの種類、通信方式、重要なフィールドのすべてに対応して初めて、正常に接続できる条件が整います。
| 機能 | Clash標準版 | mihomo | 移行時の確認事項 |
|---|---|---|---|
| Shadowsocks、VMess、Trojan | 対応する実装あり。旧バージョンでは制限あり | 対応。詳細なパラメーターはバージョンによって異なる | 暗号化方式、通信方式、TLSの各フィールドを確認 |
| VLESSとREALITY | 非対応 | 対応する設定をサポート | UUID、flow、サーバー名、REALITYのパラメーターを確認 |
| Hysteria2、TUIC | 非対応 | 対応するプロトコルをサポート | バージョン、認証フィールド、UDPの通信条件を確認 |
| TUNによる通信の取り込み | オープンソース版とPremiumを区別する必要あり | TUN機能を提供 | 管理者権限、サービス、システムルートも確認 |
「Shadowsocksに対応」していても、すべての暗号化方式に対応するとは限らない
新しい暗号化方式には、より新しいカーネルが必要な場合があります。問題を調べるときは「SSノード」とだけ記録せず、type、cipher、networkなどのフィールドを控えてください。ログに「未対応のプロキシタイプ」と表示される場合は、カーネルの機能不足が疑われます。一方、接続タイムアウトの場合は、サーバー、経路、UDPの到達性、認証パラメーターも確認が必要です。両者に同じ対処法を使うべきではありません。
REALITYは単独のプロキシタイプではない
一般的な設定ではtype: vlessでノードを定義し、reality-optsなどのフィールドで関連パラメーターを指定します。ノードタイプをそのままrealityに変更したり、見慣れないフィールドだけを削除したりしても、プロトコルを変換したことにはなりません。同様に、type: hysteria2をssに変えても、使用可能なShadowsocksノードにはなりません。サーバー側も対応するプロトコルを提供している必要があります。
設定の互換性：基本構造は似ていても、拡張フィールドには境界がある
標準版の設定をmihomoへ移行する場合、基本的な構造はそのまま使えることが多いでしょう。一方、mihomoの設定を標準版へ戻すと、未対応のプロトコルやルール、フィールドの意味の違いに遭遇しやすくなります。互換性には方向があり、「どちらもYAMLだから相互に使える」というわけではありません。パーサーでエラーが出なくても、各フィールドが実際に反映されているか確認が必要です。
最小構成でポートとルールの入口を確認する
以下は、基本構造を確認するためのmihomo設定例です。リモートノードは含みません。PROXYグループにはDIRECTだけが含まれるため、すべてのリクエストは最終的に直接接続されます。ローカルの待ち受けとルール構造は検証できますが、プロキシ経路の品質確認には使えません。
mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
proxies: []
proxy-groups:
- name: PROXY
type: select
proxies:
- DIRECT
rules:
- DOMAIN-SUFFIX,example.org,PROXY
- MATCH,DIRECTmixed-port: 7890：同じローカルポートでHTTPとSOCKSのプロキシリクエストを受け付けます。システムプロキシが自動で有効になるわけではありません。allow-lan: false：LANにプロキシの入口を公開しません。移行時は従来のアクセス範囲を維持し、接続問題の解決を理由に待ち受けを安易に開放しないでください。mode: rule：ルールモードを使用します。グローバルモードに切り替えた場合、ドメインルールの照合結果で分岐を検証することはできません。MATCH,DIRECT：最後のフォールバックルールです。プロキシを利用する場合は、実際の運用方針に合わせてフォールバック先を変更してください。
バージョン間で問題が起きやすいフィールドを優先して確認
| 設定項目 | 確認する内容 | よくある症状 |
|---|---|---|
proxies | プロトコルタイプ、TLSパラメーター、通信オプション | 読み込みに失敗する、または特定ノードのハンドシェイクに失敗する |
proxy-groups | ノード名、グループ名、providerの参照先 | プロキシが見つからない、またはポリシーグループが空になる |
dns | 拡張モード、リゾルバーのアドレス、ルーティングポリシー | ノードには接続できるが、ドメイン名の解決に問題がある |
tun | ネットワークスタック、ルート、DNSハイジャックの設定 | カーネルは起動するが、アプリの通信が取り込まれない |
scriptなどの旧来の拡張機能 | Clash標準版Premium専用の設定かどうか | 別のカーネルにはそのまま適用できない |
ルール、ルールセット、サブスクリプションを分けて確認する
基本ルールでは順序と参照先の名前を確認
DOMAIN、DOMAIN-SUFFIX、IP-CIDR、MATCHはよく使われるルールタイプです。通常は記述順に照合されるため、前方の大まかなルールが後続の詳細なルールに先行してマッチすることがあります。移行後にすべての通信が同じグループへ流れる場合は、まずMATCHが早い位置にないか確認し、次にルールが参照するグループ名とproxy-groups内の名前が完全に一致しているか確認してください。
mihomoの論理ルール、プロセス関連ルール、拡張マッチング機能がすべて標準版でサポートされているとは限りません。プロセスの識別は、プラットフォームや権限、通信を取り込む方式にも左右されます。設定のチェックに通ったとしても、それは現在のカーネルで構文と参照先が条件を満たしたという意味にすぎず、どのプラットフォームでもすべてのアプリのプロセスを識別できる保証はありません。
RULE-SETではルールファイルの形式も確認
RULE-SETを使う場合は、rule-providers内の名前、behavior、format、ファイルの内容をあわせて確認してください。domain、ipcidr、classicalでは、ルールの内容にそれぞれ異なる要件があります。完全なDOMAIN-SUFFIX,example.org形式のルールを、ドメイン名だけを受け付けるデータソースにそのまま入れることはできません。
mihomoのMRSルールセットは専用の形式で、対応状況はカーネルのバージョンやbehaviorの種類にも左右されます。拡張子を.mrsから.yamlに変えても、ファイルのエンコード形式は変わりません。古いカーネルへ戻す場合は、拡張子だけを変えるのではなく、対象のカーネルが対応するルールソースを用意してください。
サブスクリプションをインポートできても、互換性の確認が完了したわけではない
- サブスクリプションが完全な設定を返すのか、
proxy-providersで使用するノード一覧を返すのか確認してください。 - サブスクリプションサービスがClash共通の設定を提供しているのか、Meta/mihomo向けの拡張設定を明示的に提供しているのか確認してください。
- クライアントが上書き、マージ、スクリプトによってポート、DNS、ルール、ポリシーグループを変更していないか確認してください。
- ダウンロードした元ファイルだけでなく、実際にカーネルへ渡される最終的な設定を確認してください。
設定やログには、サブスクリプションURL、ノードのパスワード、UUID、コントロールインターフェースのキーが含まれる場合があります。問題を報告するときは、関連するフィールド構造とエラー情報だけを残し、認証情報を先に削除してください。サブスクリプションURL全体をスクリーンショットや公開の掲示板に載せないでください。
移行手順：まず設定を検証し、次に通信を確認
旧環境をいつでも戻せる状態で残し、一度に変更する項目は一つにしましょう。クライアントの変更、サブスクリプションの変更、TUNの有効化、DNSの再設定を同時に行うと、問題が解消しても原因を特定できません。
- 現状を記録：カーネルとクライアントのバージョン、現在の設定ファイルのコピー、待ち受けポート、ポリシーグループの選択内容を保存します。現在のネットワークで旧設定が実際にどう動作するかも確認してください。
- 移行先の設定を確認：実際に使用するmihomoバイナリで設定テストを実行します。最初の構文エラーが見つかったら、そのエラーを修正してから次の確認に進んでください。
- 新しいカーネルだけを起動：旧カーネルを停止するか、新しいカーネルに別のポートを割り当てます。2つのプロセスが
7890やコントロールインターフェースのポートを同時に使用しないようにしてください。 - まず明示的なプロキシをテスト：TUNを無効にし、指定したHTTP/SOCKSポート経由で、接続できることが確認済みのノードをテストします。
- 次にルールとDNSをテスト：直接接続されるべき宛先とプロキシ経由で接続されるべき宛先にそれぞれアクセスし、接続ログでマッチしたルール、ポリシーグループ、最終的なノードを確認します。
- 最後にTUNを有効化：クライアントが必要とするサービスをインストールするか、必要な権限を付与したうえで、仮想ネットワークインターフェース、ルート、DNSの取り込みを確認します。
# 移行先の設定を確認する。常駐プロキシサービスは起動しない
mihomo -t -f ./candidate.yaml
# HTTPプロキシの入口からリクエストを送信
curl -I --proxy http://127.0.0.1:7890 https://example.org/
# SOCKSの入口からリクエストを送り、宛先ドメイン名の解決をプロキシ側で行う
curl -I --proxy socks5h://127.0.0.1:7890 https://example.org/Windowsではcurl.exeを使ってcurlを明示的に実行すると、旧バージョンのPowerShellにある同名のエイリアスとの競合を避けられます。テスト時は確認したいサイトのアドレスに置き換え、接続ログで通信の出口を確認してください。上記の最小構成は直接接続のみを行うため、リモートノードが使えることの証明にはなりません。
-tによる確認は、インターネット接続全体のテストとは異なります。外部ルール、ノードprovider、ローカルデータベースファイル、相対パスは別途確認が必要です。また、コマンドラインとクライアントでは作業ディレクトリが異なる場合があります。手動実行時にファイルが見つからなくても、YAMLの内容に誤りがあるとは限りません。
よくある質問とカーネルの選び方
以前のClash YAMLをそのままmihomoに渡せる？
基本的なノード、ポリシーグループ、ルールの構造はそのまま使えることが多いものの、まず設定を検証し、DNS、TUN、外部リソースを確認してください。標準版Premium専用のスクリプトなどが、同等に実装されているとは限りません。クライアントが最終的な設定を変更していないかも確認しましょう。
クライアントにMetaと表示されている場合、手動でmihomoに変える必要はある？
名称だけを理由に入れ替える必要はありません。実際のカーネルのバージョンとプロジェクトの配布元を確認しましょう。画面上の表示には旧名称が残っている場合があります。カーネルはクライアントが提供する更新方法で更新するのが基本です。手動で入れ替える場合は、実行ファイルのパスや権限、クライアントとのインターフェース互換性も考慮してください。
カーネルを変えると通信速度は上がる？
カーネルはプロトコル対応や接続動作、リソース使用量に影響することがありますが、ノードの帯域や通信事業者の回線を直接改善するものではありません。比較するときはノード、宛先、ネットワーク接続、テスト時間帯をそろえ、遅延、スループット、失敗率をあわせて確認しましょう。1回の速度測定の差を一般的な結論とみなすべきではありません。
TUN対応のカーネルでもアプリの通信を取り込めないのはなぜ？
カーネルの対応はあくまで前提条件です。サービスの権限、自動ルーティング、他のVPNとのルート競合、DNSリクエストが想定どおりの経路に入っているかも確認してください。明示的なプロキシ接続は成功するのにTUNだけ失敗する場合は、通信の取り込み経路を優先して調べましょう。すぐにノードを変更したり、認証パラメーターを変更したりする必要はありません。
最終的な選択は、必要な設定から逆算しましょう。まずノードのプロトコルを整理し、次にルール、DNS、通信の取り込み要件を確認します。そのうえで、必要なバージョンのmihomoと権限管理機能を提供するクライアントを選んでください。フィールドの意味は技術リファレンスを参照できます。初めてセットアップする場合は、ガイドに沿ってサブスクリプションのインポートと明示的なプロキシ接続を確認し、その後でルールやTUNを段階的に追加してください。