プロキシルールをルーター層に集約するのは、複数機器の振り分け問題を解決する一般的な発想だ。各機器に個別にクライアントを入れるのに比べ、ルーターで mihomo コアを直接稼働させれば、LAN 内のすべての接続機器(クライアントを入れられないテレビボックス、スマートスピーカー、ゲーム機なども含む)が同じ振り分けルールに従うようになり、設定を一箇所変えるだけで全体に反映される。この記事はルーターで mihomo を直接動かす際の全体的な考え方を整理するもので、特定ファームウェアの画面操作を逐一なぞるものではなく、判断すべきポイントと落とし穴を重点的に説明する。
なぜルーターで mihomo を稼働させるのか
スマートフォン・タブレット・パソコンにそれぞれクライアントを入れる方法は柔軟ではあるが、明確な弱点が二つある。一つは、アプリをインストールできない機器(スマートテレビ、ロボット掃除機、一部のゲーム機)がプロキシネットワークに一切接続できず、プロキシサーバーのアドレスを手動設定するしかないが、多くの機器にはそもそもその設定項目が用意されていないこと。もう一つは、複数機器がそれぞれ別々に設定を持つため、ルールやサブスクリプションの更新を一台ずつ同期する必要があり、バージョンのずれによって振り分け結果が食い違いやすいことだ。
mihomo コアをルーターに導入すれば、この二つの問題を解決できる。LAN 内のすべての機器はデフォルトでルーターを経由して通信するため、ルーター側で透過プロキシをきちんと構成しておけば、機器側は何も追加設定せずにルール振り分けの恩恵を受けられる。設定の維持もルーターという一箇所に集約される。この構成は実務上「ゲートウェイプロキシ」または「サブルータープロキシ」と呼ばれることが多く、違いはプロキシがネットワーク出口を担うメインルーター上で動くか、メインルーターと並列に置かれ、ポリシールーティングで通信を引き受けるサブルーター上で動くかという点だけだ。
メインルーターとサブルーターの選択
メインルーター直動作とは、mihomo に対応したサードパーティファームウェア(一般的には OpenWrt およびその派生版)を書き込んだルーターで、ネットワーク出口そのものでプロキシコアを稼働させ、すべての通信がデフォルトでそこを経由する構成を指す。この方式は経路が最短で追加のハードウェアも不要だが、ルーター本体のファームウェア互換性と性能への要求が高くなる——設定にミスがあると家全体のネット接続に影響しかねず、切り分けもしづらいため、実験的な設定変更をする前には切り戻し手段をきちんと考えておく必要がある。
サブルーター方式は、既存のネットワークにもう一台小型機器(Raspberry Pi、ミニ PC、あるいは中古ルーターへのファームウェア書き込みなどが一般的)を追加し、プロキシコアだけを稼働させて、メインルーターが担う DHCP や無線などの基本的な役割は持たせない構成だ。メインルーター側でポリシールーティングや DHCP のゲートウェイ指定を使って、一部の通信をサブルーターへ転送する。この方式のメリットは、メインルーターの安定した設定に手を加えなくてよいこと。問題が起きてもゲートウェイをメインルーターに戻すだけで済み、リスクを抑えられる。デメリットは経路が一段増えるため理論上わずかに遅延が大きくなり、また追加機器とポリシールーティングを通す一定のネットワーク知識が必要になることだ。
ほとんどの家庭ネットワークにとって、サブルーターは比較的無難な出発点だ。まず小規模な範囲で振り分けルールが想定通りに動くかを検証し、安定を確認したうえでメインルーター方式に統合するかどうかを検討すればよい。すでに書き込み対応の高性能ルーターを使っていて、自分でネットワークの問題を切り分ける自信がある場合は、メインルーターに直接導入したほうが経路がすっきりする。
ハードウェアとファームウェアの基本要件
どちらの方式を選ぶにしても、ハードウェア面で避けられないハードルがいくつかある。
- CPU アーキテクチャと性能:mihomo コアは CPU に一定の要求を課す。ルール数が多く同時接続数が大きい場面では、低性能なシングルコア機器では転送遅延やパケットロスが起きやすい。機器を選定・再利用する際はマルチコアの ARM または x86 プラットフォームを優先し、性能の弱い古いルーターに高負荷なプロキシ処理を任せないこと。
- メモリ容量:ルールセットや GeoIP/GeoSite データベースはメモリに読み込まれるとある程度の容量を占有する。メモリが小さすぎる機器(128MB 未満など)ではルール数が多いときにコアが異常終了したり応答が遅くなったりすることがあるため、最低でも256MB 以上の空きメモリを確保することを推奨する。
- ストレージ容量:ファームウェア本体、mihomo バイナリ、ルールデータベース、ログファイルはすべてストレージに保存する必要がある。機器の内蔵ストレージが少なすぎる場合は、USB メモリの外付けやストレージ拡張に対応した機種の利用を検討したい。
- ファームウェアの対応:主流の選択肢は OpenWrt およびその派生ファームウェア(対応の良いコミュニティ版など)。このジャンルのファームウェアはエコシステムが成熟しており、パッケージリポジトリにはパッケージ化済みの mihomo や互換コンポーネントが用意されていることが多く、手動コンパイルの手間を省ける。純正ファームウェアには基本的にプロキシコアを直接動かす機能がないため、まずカスタムソフトウェアの導入に対応したサードパーティファームウェアへの書き込みが必要になる。
ファームウェアの書き込みには機器が起動不能になるリスクがある。作業前にファームウェアのバージョンと機器型番が完全に一致していることを確認し、純正ファームウェアと重要なパーティションのデータを事前にバックアップしておくこと。
コアバイナリの選び方
mihomo コアは CPU アーキテクチャや命令セットごとに対応するバイナリファイルを配布している。一般的なアーキテクチャ表記には amd64、arm64、armv7 などがあり、選択を誤るとプログラムが起動しない、または起動直後にクラッシュすることがある。アーキテクチャの一致以外にも、次の二点に注意が必要だ。
- バージョンの安定性:ルーター用途では最新版を追うより安定性が優先される。ある程度検証を経た安定版を選び、公開直後の最新版を避けることで、ネットワーク出口を未知の互換性問題にさらすリスクを減らせる。
- 機能面の対応状況:利用予定の機能(TUN モード、特定のルール記法、特定の通信プロトコル実装など)を選んだバージョンが対応しているか確認すること。配布元によってはサイズを抑えるために一部機能を省いてパッケージ化している場合があるため、導入前に該当バージョンの更新情報を確認し、必要な機能が揃っているかをチェックしておく。
ファームウェアのパッケージリポジトリで配布されている mihomo コンポーネントは、通常アーキテクチャの対応がすでに処理済みのため、手動導入の手順に不慣れなユーザーにとっては手間の少ない出発点になる。カスタムのビルドオプションが必要な場合や、まだパッケージリポジトリに登録されていない新しいバージョンを使いたい場合にのみ、手動でバイナリを取得し起動スクリプトを設定する方法を検討すればよい。
透過プロキシと DNS リダイレクトの要点
ルーター直動作の核心的な価値は「透過性」にある——LAN 内の機器はプロキシの存在を意識する必要がなく、すべての通信がゲートウェイ層で自動的に処理される。これを実現するには二つの仕組みの連携が必要になる。
通信の透過転送
mihomo は TUN モードによりシステム層に仮想ネットワークインターフェースを作成し、ルーターを通過する通信を仮想インターフェースにリダイレクトしてから、コアがルールに従って振り分け処理を行う方式に対応している。この方式はプロトコル互換性が高く、TCP と UDP の両方をカバーできる。一部のファームウェア環境では iptables/nftables ルールベースの透過プロキシ方式にも対応しており、特定のポート範囲またはすべての通信をコアが待ち受けるローカルポートにリダイレクトする仕組みになっている。両方式にはそれぞれ適した場面があり、TUN モードは設定がわかりやすい一方でカーネルバージョンとファームウェアのネットワークスタックとの互換性要求が高い。iptables 方式は互換性が広いが、ルールの記述が複雑で、問題の切り分けにはネットワークリダイレクトの経路への理解が必要になる。
DNS リダイレクトと汚染の回避
ルールによる振り分けは、多くの場合ドメイン名の解決結果に基づいて判断される。機器の DNS リクエストが mihomo を経由せず直接通信事業者の DNS に送られると、汚染された不正確な解決結果を受け取り、振り分けの精度に影響が出る可能性がある。そのためルーター導入では通常、追加で DNS リダイレクトの設定が必要になる。LAN 内すべての機器から発せられる 53 番ポートの DNS リクエストを mihomo 内蔵の DNS サーバーへ強制的にリダイレクトし、名前解決とその後の振り分け判断をコアに一元的に処理させる。
この設定が不十分だと、最もよく見られる症状は「一部のアプリは正常にプロキシ経由になるが、一部のアプリは直接元のネットワークに接続してしまう」というものだ。多くの場合、これらのアプリが独自の DNS 解決ロジックを内蔵しており、システムの DNS 設定を無視することでリダイレクトルールも回避してしまっている。こうした問題を切り分けるときは、まずルーター層の DNS リダイレクトルールがすべてのサブネットとすべてのポート方向をカバーしているかを確認し、次にそのアプリが暗号化 DNS(DoH など)で特定のサーバーに直接接続していないかを確認する。
LAN 機器の接続方式の主要な2パターン
mihomo を動かすことは最初のステップに過ぎず、より重要なのは LAN 内の他の機器に「このプロキシ経路を通る」ことを認識させることだ。よく使われる接続方式には二種類あり、それぞれにトレードオフがある。
| 方式 | 実装方法 | メリット | 制約 |
|---|---|---|---|
| ゲートウェイ直接指定 | DHCP が割り当てるデフォルトゲートウェイを mihomo 稼働機器に直接指定 | 設定が簡単で、新たに接続した機器にも自動的に適用され、個別設定が不要 | その機器が単一障害点となり、故障時は配下の全機器のネット接続に影響 |
| ポリシールーティングによる振り分け | メインルーターが送信元 IP や MAC アドレスに基づき、指定機器の通信をサブルーターへ転送 | 機器単位でプロキシ経由かどうかを制御でき、障害時の影響範囲を抑えられる | メインルーター側でポリシールーティングのルールを維持する必要があり、新規機器は手動でリストに追加が必要 |
ゲートウェイ直接指定は「家全体を統一してプロキシ経由にする」場面に向いており、一度設定すれば新たに接続する機器すべてに適用されるため、家庭内の機器数が多く、一台ずつ設定したくない場合に適している。ポリシールーティングによる振り分けは「一部の機器だけプロキシを通し、他は直接接続を維持したい」場面に向いており、たとえばスマートテレビとゲーム機だけをプロキシ経由にし、その他の業務用機器は元のネットワーク経路を保つことで、不要な影響を避けられる。どちらを選ぶかは「全機器を一括で処理する」ことと「機器ごとに細かく制御する」ことのどちらを優先するかで決まる。まずポリシールーティングで小規模に検証し、安定を確認してからゲートウェイ直接指定へ切り替えるという進め方も可能だ。
導入前のチェックリスト
作業に取り掛かる前に、以下の項目を確認しておくと、あとの切り分けにかかる時間をかなり減らせる。
- 機器のアーキテクチャとファームウェアのバージョンを確認し、対応する mihomo バイナリまたはパッケージを事前にダウンロードしておく。ネットが切れた状態で現地で資料を探す事態を避ける。
- サブスクリプションリンクと基本のルールセットを準備し、まず小規模な範囲(たとえば自分の一台の機器)で設定ファイルの文法が正しく、ルールのマッチが想定どおりであることを検証してから、家全体に展開する。
- ログの保存先を計画しておく。ルーターのストレージ容量には限りがあるため、長期運用ではログローテーションや定期的な削除を行い、ストレージが満杯になって機器が異常動作するのを防ぐ。
- 切り戻し手段を確認しておく:導入後に家全体でネットが切れた場合、ゲートウェイを速やかにメインルーターに戻せるか、または代替ネットワーク(スマートフォンのテザリングなど)でルーターの管理画面に一時的にアクセスして修正できるか。
ルーター層でのプロキシ導入には明確なメリットがあるが、試行錯誤のコストも単体クライアントより高い——問題が起きれば家全体のネットワークに影響する。まずアクセスの少ない時間帯に導入と調整を行い、設定が安定してから長期運用に切り替え、すぐに復元できる元のネットワーク設定のバックアップを保管しておくことを推奨する。