カーネル解説 読了目安 13分

mihomoはオリジナル版Clashより何が優れている？プロトコル対応・ルールセット・TUNの違いを比較

オリジナル版カーネルと比較し、mihomoの拡張点を詳しく解説。対応プロトコル、rule-providers、TUNモード、スニッフィング機能が日常の設定に与える影響を紹介します。

まずカーネルとクライアントを区別する

Clash、mihomo、FlClashはそれぞれ異なる層にあります。カーネルはYAML設定の読み込み、プロキシ接続の確立、ルール照合、DNS処理、トラフィック転送を担当します。クライアントはサブスクリプション管理、設定編集、システムプロキシの切り替え、ログ表示、プラットフォーム権限の申請を担います。FlClashはGUIクライアントで、mihomoはそのクライアントで利用できるプロキシカーネルです。「オリジナル版Clashとmihomo」を比較する際に見るべきなのは、ウィンドウのレイアウトやボタン数ではなく、2種類のカーネルが持つ機能です。

一般にオリジナル版Clashと呼ばれるのは、Dreamacroが公開したオープンソースのClashです。公開版はv1.18.0で止まっており、HTTP、SOCKS5、mixedの各インバウンド、ルールモード、プロキシグループ、DNS処理、Shadowsocks、VMess、Trojanなどのプロキシタイプが基本機能として知られています。Clash Metaはオリジナル版のコード体系を引き継いで拡張され、後にmihomoへ改名されました。多くの設定項目は引き続き互換性があるため、古いサブスクリプションも通常はそのまま読み込めます。ただし、互換性があることと、両者の機能が完全に同じであることは別です。

実際に確認できる主な違い

機能 オリジナル版Clash mihomo 日常利用への影響
基本ルールとプロキシグループ 対応 互換性を保ちながら継続的に拡張 古い設定の移行コストが低い
新しい出力プロトコル 対応範囲が限定的 Hysteria2、TUIC、VLESS、WireGuardなどに対応 サブスクリプションに新しいノードが含まれていてもカーネルを替える必要がない
ルールセット 基本的なrule-providers体系に対応 形式、照合動作、更新機能がより充実 大規模なルールを分割して管理できる
TUN 配布形態によって機能が異なる 自動ルーティング、厳格なルーティング、複数のプロトコルスタックを継続的にサポート システムプロキシを参照しないアプリも制御できる
トラフィックのスニッフィング 機能が限定的 独立したsniffer設定と上書きポリシー 透過プロキシでもドメイン情報を復元できる

プロトコル対応：違いはまずノードタイプに現れる

オリジナル版Clashの一般的な出力タイプは、従来型のサブスクリプションをすでに幅広くカバーしています。Shadowsocks、VMess、Trojan、HTTP、SOCKS5、Snellなどです。ただし、プロキシプロトコルは今も進化しています。サーバーがHysteria2、TUIC、VLESS Reality、ShadowTLS、WireGuardのノードを提供している場合、古いカーネルでは「サポートされていないプロキシタイプ」と表示されることがあります。また、サブスクリプションの解析後に該当ノードが無視される場合もあります。

mihomoはこれらのタイプにネイティブな設定項目を用意し、統一されたプロキシグループ、ヘルスチェック、ルール分岐の仕組みに組み込めます。たとえば、url-testプロキシグループに従来のTrojanノードとHysteria2ノードを同時に登録し、測定した遅延に応じて自動選択できます。ユーザーにとっての強化点は、対応プロトコルの名前が増えたことだけではありません。サブスクリプション内のノードを同じルール体系から利用できることにあります。

プロトコルが増えても、すべてを有効にする必要はない

ノードを選ぶ際は、サーバーの構築品質、経路上のパケットロス、ローカルネットワークも確認してください。1回の遅延テストで分かるのは、その時点における測定URLへの往復時間だけです。たとえば同じネットワークでTCPノードが82 ms、QUICノードが61 msでも、後者が継続的なダウンロードで必ず速いとは限りません。通信事業者がUDPを制限している場合、QUICノードは数分後に大きく揺らぐ可能性があります。

rule-providers：大規模ルールを設定本体から分離する

rule-providersの主な用途は、ルールを独立したファイルに保存し、メイン設定からRULE-SETで参照することです。この仕組みはmihomoが突然追加したものではなく、オリジナル版Clashの後期設定体系にもルールプロバイダーは存在していました。mihomoの強みは、対応形式、マッチングタイプ、更新フロー、関連動作を継続的に改善し、より豊富なルール構文と組み合わせて使える点にあります。

数十件程度のルールなら、ドメインをrulesの下に直接記述しても問題ありません。しかし数万件に達すると、メインファイルへの埋め込みは読みにくくなり、サブスクリプションの上書きやバージョン管理も複雑になります。分離後のメイン設定には、ルールセットのURL、更新間隔、適用するポリシーだけを残し、ルール本体は独立したファイルで管理できます。

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

  private-ip:
    type: http
    behavior: ipcidr
    format: yaml
    url: https://example.com/rules/private-ip.yaml
    path: ./ruleset/private-ip.yaml
    interval: 86400

rules:
  - RULE-SET,private-domain,DIRECT
  - RULE-SET,private-ip,DIRECT,no-resolve
  - MATCH,ノードを選択

behaviorでファイルに記述できる内容が決まる

interval: 86400は、リモートルールを86400秒ごと、つまり24時間ごとに確認することを意味します。「リクエストのたびにダウンロードする」という意味ではありません。初回の取得に成功すると、カーネルはローカルキャッシュを使用します。リモートサーバーに一時的に接続できなくても、既存のファイルは通常そのまま照合に利用できます。ただし、ルールURL自体に現在のネットワークからアクセスできなければ、初回起動時に利用可能なキャッシュがない場合があります。

mihomoは、ルール集合向けのバイナリ形式mrsにも対応しています。大容量のドメインルールやIPルールセットに適しており、解析コストとストレージ使用量の削減を目的としています。mrsは通常のテキストではないため、エディターで1行ずつ直接編集することはできません。手作業で管理するプライベートルールには、引き続きYAMLやテキスト形式のほうが分かりやすいでしょう。

ルールの順序は件数より重要

Clashのルールは上から順に評価され、最初に一致した時点で処理を停止します。ルールセットの更新に成功していても、広範囲にマッチするプロキシルールを直接接続ルールより前に置けば、後ろの直接接続ルールは実行されません。一般的には、プライベートドメイン、LAN、予約済みアドレスを先頭に置き、業務用ルールセットを中央に配置し、GEOIPなどの地域判定を後ろに置いて、最後にMATCHで受け止めます。

TUNモード：システムプロキシから全体のトラフィック制御へ

システムプロキシが影響するのは、通常、OSのプロキシ設定を自ら参照するアプリだけです。ブラウザーの多くは対応していますが、ゲーム、コマンドラインツール、一部のストアクライアント、仮想マシン、UDP通信を直接行うソフトウェアは迂回することがあります。TUNモードでは仮想ネットワークインターフェースを作成し、ルーティング条件に合うIPトラフィックをカーネルへ送るため、より広い範囲をカバーできます。

オリジナル版Clashでも、バージョンや配布形態によってはTUN機能が提供されていました。しかし、設定、プラットフォーム対応、メンテナンス状況は統一されていません。mihomoはTUNの自動ルーティング、DNSハイジャック、複数のネットワークプロトコルスタック、インターフェース選択、厳格なルーティングを継続的に拡張しており、これが現代のGUIクライアントでmihomoが広く採用される重要な理由です。

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

これらの項目が制御する内容

FlClashでは、まず設定をインポートし、通常のシステムプロキシが動作することを確認してから、「設定」→「ネットワーク設定」でTUNモードを有効にするのが基本です。AndroidやデスクトップOSでは、VPNまたは仮想ネットワークインターフェースの作成を求められます。許可した後、ログでTUNの初期化結果を確認してください。クライアントのバージョンによってメニュー名が少し異なる場合は、「設定」でTUN、VPNサービス、ネットワークインターフェースに関する項目を探します。

TUNでよくある競合

  1. 別のVPNも同時に実行：2つのプログラムがデフォルトルートを同時に制御しようとすると、ネットワーク切断やルートの頻繁な切り替えが起きることがあります。
  2. LANアクセスの異常：プリンター、NAS、開発機器があるネットワーク帯域は直接接続ルールに追加する必要があります。よくあるプライベートネットワークは192.168.0.0/16、10.0.0.0/8、172.16.0.0/12です。
  3. 仮想マシンとコンテナのネットワーク：Docker、WSL、Hyper-Vなどは仮想NICを作成します。インターフェースの自動検出が正しくない場合は、出口インターフェースの選択と除外ルートを確認してください。
  4. DNSの二重制御：システムのセキュリティソフト、暗号化DNSツール、mihomoが同時にDNSを待ち受けたりリダイレクトしたりすると、名前解決がタイムアウトすることがあります。

スニッフィング機能：透過プロキシでもドメインを復元

ルールエンジンはドメインに基づくトラフィック判定に向いていますが、TUNが最初に受け取るのは宛先IPだけであることが少なくありません。たとえばアプリが自らDNS問い合わせを完了し、その後203.0.113.10:443へ直接接続した場合、カーネルがIPしか取得できなければDOMAIN-SUFFIXルールを直接利用できません。スニッファーは接続初期のデータを解析し、TLSのサーバー名、HTTP Host、QUIC情報から宛先ドメインを取り出してルール照合に利用します。

sniffer:
  enable: true
  parse-pure-ip: true
  override-destination: true
  sniff:
    HTTP:
      ports:
        - 80
        - 8080-8880
    TLS:
      ports:
        - 443
        - 8443
    QUIC:
      ports:
        - 443

parse-pure-ipは、宛先が純粋なIPとして現れる接続からドメインの識別を試みます。override-destinationは、スニッフィング結果で元の宛先情報を上書きするかどうかを決めます。ポート範囲は実際の用途に合わせて設定し、「すべてをカバーする」ために全ポートであらゆる解析器を有効にするのは避けてください。HTTP、TLS、QUIC以外の独自プロトコルでは、これらの解析器から有効なドメインを取得できません。

スニッフィングはDNSの代替ではない

スニッフィングは接続確立時に行われ、DNSはドメインをどのように解決するかを決めます。両者が解決する問題は異なります。安定した設定には、通常nameserver、fallback、fake-ip、redir-hostなどのDNS項目を適切に設定する必要があります。Fake IPを使用すると、カーネルはドメインを予約アドレスプールに割り当て、接続時にドメインを復元します。スニッフィングは、カーネルのDNSを迂回してIPへ直接接続するトラフィックを補完できます。

一部のアプリは、証明書ピンニング、暗号化されたクライアントハロー、独自のQUIC動作を使用するため、スニッフィングで利用可能な名前を取得できないことがあります。接続先が誤って上書きされた場合は、すべてのスニッフィングを無効にするのではなく、まずログの元の宛先とスニッフィング後の宛先を確認し、ドメイン除外または送信元アドレス除外ルールで対象の通信だけを外してください。

DNS、ルール、TUNは一つの設定として確認する

mihomoの拡張機能は相互に関連しています。TUNだけを有効にしてDNSを処理しなければ、ルールがドメインを取得できないことがあります。スニッフィングだけを有効にしても、ルールの順序が正しくなければ、復元したドメインが誤ったポリシーに一致します。ルールセットが正しく設定されていても、ダウンロードURLが現在のネットワークで遮断されていれば、初回起動時にルールファイルを保存できません。トラブルシューティングでは、「インバウンドの制御 → DNS → スニッフィング → ルール照合 → プロキシグループ → 出力接続」の順にログを確認してください。

再現可能な確認手順

  1. 通常のシステムプロキシモードで、少なくとも1つの基本ノードがTCP接続を確立できることを確認します。
  2. mixedインバウンドのポートが使用中でないか確認します。一般的な値は7890です。2つのクライアントが同じポートを待ち受けないようにしてください。
  3. DNSログが応答を返すことを確認し、返されたアドレスが実際のIPかFake IPかを確認します。
  4. TUNを有効にした後でシステムプロキシを無効にし、システムプロキシを参照しないアプリがカーネルのログに現れるかテストします。
  5. 接続記録のHost、宛先IP、一致したルール、最終的なプロキシグループを確認し、スニッフィング結果による誤った上書きがないことを確認します。
  6. ルールプロバイダーを手動更新し、HTTPステータス、保存先、更新時刻を確認します。その後、完全なinterval周期を待って自動更新を検証します。
  7. TCPとUDPを個別にテストします。Webページが開くだけではTCP経路が基本的に正常だと分かるに過ぎず、QUIC、ゲームのボイスチャット、DNSのUDP経路が正常だとは限りません。

mihomoの改善を実感しやすいユーザー

ブラウザー、基本的なShadowsocksノード、数個のドメインルールだけを使うユーザーは、カーネルを切り替えても速度の変化をすぐに感じるとは限りません。mihomoの価値は「対応範囲と設定の上限」にあります。サブスクリプションに新しいプロトコルが登場しても解析でき、アプリがシステムプロキシを迂回してもTUNで制御でき、透過トラフィックにドメイン情報がなくてもスニッフィングで補完でき、大規模なルールもルールプロバイダーで独立して更新できます。

古い設定をmihomoへ移行する際は、最初からすべての拡張機能を有効にする必要はありません。まずノードとプロキシグループを検証し、次にルール、続いてDNS、最後にTUNとスニッフィングを調整するのが安全です。異常が起きた場合も、プロキシプロトコル、名前解決経路、ルール順序、システムルーティングのどこに原因があるかを素早く特定できます。

結論は4点にまとめられます。オリジナル版Clashは設定構文とルールベースのプロキシモデルを築き、mihomoはその互換性を引き継ぎながら新しいプロトコルを継続的に追加しています。ルールプロバイダーは、大規模で更新可能なルールデータの管理に適しています。TUNとスニッフィングは、分岐対象を「システムプロキシに対応するアプリ」から、より広範なデバイストラフィックへ拡張します。実際の設定では項目を機械的に増やすのではなく、必要な機能を中心に組み立ててください。

FlClashのダウンロード 各プラットフォーム版を確認