Mihomoのルーター導入ガイド：メインルーター・サブルーター・コア単体運用を比較

ネットワーク上の配置と実行方式を切り分ける

Mihomoは、Clash Metaの開発を引き継いだプロキシコアです。ルーター環境へ導入する際に混同しやすいのは設定構文ではなく、ネットワーク内で機器をどこに置くか、コアをどのように起動・管理するかという2つの観点です。メインルーターとサブルーターはネットワーク構成を、コア単体運用、ルータープラグイン、コンテナはソフトウェアの実行方式を表します。これらは排他的な選択肢ではなく、サブルーターでもコア単体運用を選べます。

導入前に、最短のデータ経路を図にしてください。端末がパケットを渡すデフォルトゲートウェイ、DNSクエリの送信先、トラフィックがMihomoへ入る機器、プロキシ処理後に戻る出口の4点です。ここが不明確なままだと、Webサイトが開かない、特定地域のサイトへ遠回りする、一部の端末だけ反映されない、IPv6で迂回されるといった問題が起きた際に、原因がルール、DNS、ルーティングのどこにあるのか判断しにくくなります。

メインルーター構成：経路は明快、変更の影響は広範囲

メインルーター構成では、Mihomoをネットワーク全体のデフォルト出口に配置します。通常、端末はこの機器からIPアドレス、デフォルトゲートウェイ、DNSアドレスを取得するため、端末ごとの設定なしで共通ルールの対象にできます。透過プロキシの入口にはTProxy、リダイレクトルール、TUNデバイスなどを利用でき、OSカーネル、プラグインの実装、UDP処理の要否に応じて選びます。

この構成の利点は経路が明快なことです。LAN内の端末からの通信はまずメインルーターへ届き、ルールに従って直接接続、プロキシ、ブロックへ振り分けられます。DNSも一元管理しやすく、送信元IP、MACアドレスにひも付けた固定リース、VLAN、サブネットを使って端末をグループ分けできます。テレビ、スマートフォン、パソコン、ゲーム機を長期的に一括管理する家庭内ネットワークでは、各端末にクライアントを導入するよりも設定を統一しやすい方式です。

一方、障害の影響範囲は広くなります。誤ったファイアウォールルール、利用できない設定ファイル、DNSループによって、LAN全体が同時に影響を受ける可能性があります。コアの更新時には、機器のアーキテクチャ、実行権限、設定の互換性、サービスの再起動順序も考慮が必要です。ルーターの性能が限られる場合、暗号化通信、ルール照合、DNSキャッシュ、ログ書き込みがCPUとメモリを同時に消費するため、LANポートの公称速度だけでは実際のプロキシ性能を判断できません。

メインルーター構成に適した条件

1. ルーターOSを管理でき、ローカルの管理経路と設定を元に戻す手順を確保できる。
2. 機器のCPUアーキテクチャに対応するMihomoビルドがあり、コア、ルールセット、ログを保存できる容量がある。
3. 一部の端末だけでなく、大半の端末へ同じ振り分けルールを標準で適用したい。
4. 更新時間を確保でき、プロキシサービスの再起動に伴う短時間の切断を許容できる。

サブルーター構成：段階的な検証に向き、経路制御が重要

サブルーターは通常、メインルーターと同じLAN内に配置します。メインルーターは引き続き回線接続、NAT、Wi-Fi接続を担当し、サブルーターは指定した端末のプロキシとDNSを処理します。段階的な導入に適しており、まず検証用パソコン1台でサブルーターを使用し、ルール、サブスクリプション、DNSを確認してから、固定端末や専用サブネットへ対象を広げられます。

サブルーターをスイッチへ接続しただけでは、ネットワーク全体のトラフィックは自動的に流れません。最も単純な方法は、端末のデフォルトゲートウェイとDNSをサブルーターへ向けることです。DHCPで特定端末へ別のゲートウェイを配布する方法や、メインルーターのポリシールーティングで指定した送信元アドレスをサブルーターへ転送する方法もあります。どの方式を選べるかは、メインルーターが固定リース、端末別のパラメーター配布、ポリシールーティングに対応しているかによって決まります。

ワンアーム構成のサブルーターはLANインターフェースを1つだけ使用し、パケットは同じインターフェースから入り、処理後も同じインターフェースを通ってメインルーターへ送られます。この場合は戻り経路に注意が必要です。端末からのパケットはサブルーターを通る一方、応答パケットがメインルーターから端末へ直接返されると、非対称ルーティングが発生することがあります。通常の接続は動作する場合もありますが、コネクショントラッキング、透過プロキシ、厳格なステートフルファイアウォールに依存する環境では問題が生じる可能性があります。実際の導入では、適切なゲートウェイ設計、ポリシールーティング、必要に応じた送信元NATによって往復経路を統一します。

サブルーターの主な接続方式

サブルーターでは常にDHCPを無効にする、という決まりはありません。メインルーターがアドレスを一元配布する場合、通常はサブルーターで同一サブネット向けのDHCPを有効にする必要はありません。一方、サブルーターが独立したサブネットを管理する場合は、そのサブネットへDHCPを提供できます。重要なのは、各ブロードキャストドメインに明確で管理可能なアドレス配布方式が1つだけあることであり、特定のサービスを機械的にオン・オフすることではありません。

コア単体運用：細かな制御が可能、OS側の設定は自前で用意

コア単体運用では、CPUアーキテクチャに対応するMihomoの実行ファイルを直接ダウンロードし、YAML設定を用意してOSのサービスマネージャーから起動します。GUIプラグインによる設定構造の制約を受けにくく、独自のルールプロバイダー、待受ポート、試験的機能、自動デプロイ処理を必要とする場合に適しています。ただし、コアが担うのは自身のプロキシ機能のみであり、ルーターOSに必要な作業をすべて自動で行うわけではありません。

実用的なコア単体運用には、少なくとも設定ファイルと外部ルールリソース、永続化ディレクトリ、起動サービス、透過プロキシまたはTUNに必要な権限、DNSとファイアウォールの連携という5つの要素が必要です。更新とロールバックの手順も用意します。たとえば更新前に設定チェックを実行し、直前のバイナリを残しておき、新しいプロセスが起動できなければ元のサービスへ戻せるようにします。

mode: rule
allow-lan: true
bind-address: "*"
mixed-port: 7890
tproxy-port: 7893

dns:
  enable: true
  listen: 0.0.0.0:1053
  enhanced-mode: fake-ip
  nameserver:
    - 223.5.5.5
  proxy-server-nameserver:
    - 1.1.1.1

上記の例は待受関係だけを示しており、そのままルーターへ投入できる完全な設定ではありません。プロキシノード、ポリシーグループ、ルール、ルールセット、ファイアウォールによる転送は別途定義する必要があります。DNSの上流サーバーも、ネットワーク環境と振り分け方針に応じて選んでください。DNSを1053番ポートで待ち受ける場合、OSのDNSフォワーダーからそのポートへクエリを転送するか、端末が直接アクセスするよう明示的に設定する必要があります。設定へ記述するだけでは、LANの53番ポートを自動的に引き継ぐことはありません。

コア単体サービスの起動順序

1. ネットワークインターフェース、時刻同期、設定ディレクトリの準備が完了していることを確認します。
2. 設定の構文と外部リソースの読み取り可否を確認し、サービスが再起動を繰り返す状態を防ぎます。
3. Mihomoを起動し、プロキシポート、DNSポート、コントローラーが想定どおり待ち受けていることを確認します。
4. その後に透過プロキシとポリシールーティングのルールを適用し、まだ待ち受けていないポートへトラフィックが送られるのを防ぎます。
5. 停止時は先に転送ルールを解除してからコアを終了し、LAN内の通信がブラックホール化する時間を短縮します。

DNS・透過プロキシ・IPv6をまとめて設計する

ルーターへの導入では、一見「ノードが不安定」に見える症状の多くが、実際にはDNS経路に起因します。端末からメインルーターへDNSクエリを送り、さらにMihomoへ転送する構成もあれば、サブルーターへ直接問い合わせる構成もあります。「OSのDNSがMihomoへ転送し、Mihomoが同じ上流への問い合わせを再びOSのDNSへ戻す」というループが発生しないことを確認してください。

Mihomoのfake-ipモードは予約済みアドレスプールからマッピング用アドレスを返し、その後の接続がコアへ入った際にドメイン名へ復元します。これにより、ドメイン名ベースのルールで接続を処理しやすくなります。一部のLAN機器、ローカルドメイン、時刻同期サービス、実際のIPアドレスを必要とするアプリは、fake-ip-filterへ追加する必要があります。redir-hostモードは実際の名前解決結果を返す方式に近いものの、ドメイン名の識別やキャッシュの挙動はプロトコルごとに確認が必要です。どちらが常に優れているとは言えないため、選択後はログでドメインルールが実際にマッチしているか確認してください。

プロキシサーバーのホスト名解決は、別に考える必要があります。ノードのホスト名を先に解決できなければ、接続は確立できません。そのため、この問い合わせに利用できる到達可能なDNSサーバーを用意します。Mihomo設定のproxy-server-nameserverを使えばプロキシサーバーのホスト名を個別に解決でき、起動時にプロキシ経路へ依存するリスクを抑えられます。ルールプロバイダーやサブスクリプションURLへのアクセスにも同様の依存関係があります。設定の取得にプロキシが必要で、そのプロキシが未取得の設定に依存していると、起動時の循環依存が発生します。

透過プロキシの入口を選ぶ

• 明示的プロキシポート：端末側でHTTPまたはSOCKSプロキシを指定する方式です。経路を確認しやすい一方、プロキシ設定に対応しないアプリには適用できません。
• TProxy：Linuxルーター環境でよく使われ、元の宛先情報を保持したままTCPとUDPを処理できますが、ポリシールーティング、カーネルモジュール、ファイアウォールルールが必要です。
• TUNモード：仮想ネットワークインターフェースでトラフィックを受け取るため設定方針を統一しやすい一方、デバイス権限、ルーティングテーブル、DNSハイジャック、既存VPNとの競合を確認する必要があります。
• リダイレクト方式：TCPの転送で広く使われ、実装も成熟していますが、UDPと元の宛先情報を扱える範囲はOS側の方式によって異なります。

IPv6は、Mihomo設定内のスイッチ1つだけで判断できません。LANが端末へIPv6のデフォルトルートとDNSを引き続き通知している限り、端末がIPv6の直接接続を優先し、IPv4だけを処理する透過プロキシルールを迂回する可能性があります。IPv6もプロキシ対象にする場合は、上流プレフィックス、ルーター広告、ファイアウォール、TUNまたはTProxyの対応状況、ルールの適用範囲をまとめて確認してください。当面扱わない場合も、対応する通知を明示的に無効化するか、意図を説明できる直接接続ルールを用意し、IPv4とIPv6が別々の観測不能な経路を通らないようにします。

適用範囲・管理能力・切り戻しコストで選ぶ

方式を選ぶ際は、最も高速な構成を探す前に、対象とする端末数、メインルーターを変更できるか、障害時も通信を継続すべき利用者や端末を整理してください。テレビ1台や検証用パソコンだけで使うなら、サブルーターと端末別ゲートウェイの組み合わせで十分です。家庭内の全端末へ共通ルールを適用し、ルーターを管理できるなら、メインルーター構成がシンプルです。設定生成、サービスの起動順序、ファイアウォールの細部まで厳密に制御したい場合は、どちらのネットワーク構成でもコア単体運用を採用できます。

導入前の確認項目

• メインルーター、サブルーター、端末、DNSサービスのIPアドレスを記録し、アドレスの重複を防ぐ。
• 機器のCPUアーキテクチャ、空きメモリ、ストレージ容量、OSが使用するファイアウォール基盤を確認する。
• TCP、UDP、IPv4、IPv6をそれぞれどの入口で処理するか決める。
• プロキシを経由させないLANサブネット、管理アドレス、基盤サービスの除外ルールを作成する。
• 検証用端末へ固定アドレスを割り当て、ログから接続元を特定しやすくする。
• プロキシ停止後に通常のインターネット接続へ戻す手順を用意し、本番での切り替え前に実際に試す。

稼働後の段階別チェック

1. 基本ネットワーク：透過プロキシを無効にした状態で、端末から従来の出口を通じてLANとインターネットへ正常にアクセスできるか確認します。
2. DNS：端末が実際に使用するDNSアドレス、応答内容、MihomoのDNSログを確認し、ループやタイムアウトを除外します。
3. トラフィックの入口：対象の接続がMihomoのログに記録され、送信元アドレス、宛先アドレス、マッチしたルールを確認できるか検証します。
4. ポリシーの結果：直接接続、プロキシ、ブロックの対象となるドメインをそれぞれ試し、単一の速度測定サイトだけで判断しないようにします。
5. UDPとIPv6：リアルタイム通信、ゲームなどのUDP利用を個別に検証し、IPv6が想定した経路を通っているか確認します。
6. 障害時の切り戻し：Mihomoを停止するか無効な設定を与え、管理画面へ引き続きアクセスできることと、計画どおりネットワークを復旧できることを確認します。

ルーターへのMihomo導入は、ネットワーク経路を検証する作業です。メインルーター構成は入口の一元化、サブルーター構成は適用範囲の制御、コア単体運用は設定とOSレベルの自主的な管理を重視します。まず固定端末1台で観測と切り戻しが可能な最小構成を作り、DNSの引き継ぎ、UDP、IPv6、対象端末を段階的に追加するほうが、最初からネットワーク全体を切り替えるよりも問題を特定しやすくなります。