プラットフォーム 読了目安 15分

ルーターで mihomo カーネルを直接動かす構成ガイド：メインルーター・サブルーター・透過プロキシの選び方

ルーターやサブルーターで mihomo カーネルを直接動かす方法を解説。ファームウェアとハードウェアの要件、メインルーターとサブルーターの違い、透過プロキシの通信経路、適した用途と避けたい構成を整理します。

まず目的を明確にする：ルータープロキシで解決したいこと

mihomo をルーターに組み込む本質は、デスクトップクライアントを別の機器へ移すことではなく、プロキシの入口を LAN のゲートウェイ側へ移すことです。スマートフォン、テレビ、ゲーム機、スマートデバイスからの通信はいったんゲートウェイを通り、宛先ドメイン、宛先 IP、送信元デバイス、プロトコル種別に応じて、DIRECT、REJECT、またはプロキシグループへ振り分けられます。端末は通常のネットワーク設定のまま使え、振り分けのルールはルーターに集約できます。

この構成は、接続機器が多いネットワーク、クライアントをインストールできない機器がある環境、ルールを一元管理したい場合、送信元デバイスごとに通信を振り分けたい場合に適しています。たとえば、テレビはストリーミング向けノード、仕事用 PC は固定出口、プリンターと NAS は常に直接接続、ゲストネットワークはプロキシを完全に回避するといった設定が可能です。ルールを一括管理できるため、機器ごとの変更は必要ありません。

ルーターの透過プロキシは、障害の影響範囲も広げます。mihomo の設定読み込み失敗、DNS 上流への接続不能、ポリシールーティングの消失、ファイアウォールルールの順序ミスなどにより、複数の機器が同時に通信不能になる可能性があります。構築前に、プロキシが必要な機器、対応必須のプロトコル、mihomo 停止時に自動で直接接続へ戻すかどうかの3点を決めておきましょう。目的によって、メインルーター、サブルーター、透過プロキシの選択も変わります。

ファームウェア・アーキテクチャ・ハードウェア要件

ルーターの型番だけでなく、まず CPU アーキテクチャを確認する

mihomo には、アーキテクチャごとに異なる Linux カーネルファイルが用意されています。一般的な x86 ルーターは x86_64、新しい ARM ルーターの多くは aarch64、一部の旧型機は armv7 または mipsle です。アーキテクチャを間違えると、実行時に Exec format error が表示されることがあります。SSH で次のように確認できます。

uname -m
cat /etc/openwrt_release
ubus call system board
df -h
free -m

以下では、OpenWrt 24.10.0、Linux 6.6、mihomo 1.19.3 で一般的に利用できる機能を基準にしています。すべてのファームウェアに同じモジュールが含まれるとは限りません。サードパーティ製ファームウェアでは、カーネル、nftables、DNS サービス、起動管理の方式が変更されている場合があるため、実際の構築では機器上のコマンド出力を優先してください。

ルールセット用にメモリとストレージの余裕を確保する

mihomo カーネルと小規模な YAML 設定だけを起動するなら、必要なリソースはそれほど多くありません。ただし、GeoIP、GeoSite、ルールセット、Fake-IP のマッピング、接続テーブル、管理画面などがメモリを追加で消費します。ハードウェアの計画は、次の目安から始めるとよいでしょう。

リソース 適した用途 判断の目安
メモリ 128 MB、フラッシュ 16 MB 小規模ルール、少数の機器 容量に余裕がなく、更新やロールバックも難しいため、家庭全体の透過プロキシには非推奨
メモリ 256 MB、ストレージ 128 MB 10～20台の機器、一般的なルールセット 動作可能。ただしログレベルとルールセット数の管理が必要
メモリ 512 MB 以上 TUN、大規模ルールセット、多数の機器による同時接続 保守に必要な余裕を確保しやすい
x86_64、メモリ 1 GB 以上 ギガビット回線、コンテナ、複雑なポリシー メインルーターまたは専用ゲートウェイに適している

ストレージは mihomo の実行ファイルだけで計算しないでください。設定、実行ログ、ルールデータベース、更新時の一時ファイルにも容量が必要です。書き込み可能な領域を最低 50 MB は確保し、ルールデータとログを本体に置く場合は 100 MB 以上を推奨します。フラッシュ容量が不足する場合は、データディレクトリをマウントしたディスクへ移せますが、起動スクリプトでマウント完了を待つ必要があります。

スループットは単一コアの性能、プロトコル、暗号化で決まる

ルーターの箱にある「ギガビット」という表記は、通常ハードウェア NAT 使用時の転送性能を指し、プロキシ経由のスループットとは異なります。透過プロキシでは通信がユーザー空間に入り、プロトコルの暗号化、ルール照合、接続の再利用に CPU を消費します。4コアの ARM 機が通常の NAT で 940 Mbps を出せても、暗号化ノード経由の mihomo で同じ速度が出るとは限りません。

テストでは、少なくとも次の3つを記録します。直接接続の速度、端末クライアント経由の速度、ルーターの透過プロキシ経由の速度です。さらに top で、特定のコアが 100% 近くまで使用されていないか確認します。透過プロキシが 180 Mbps にとどまる一方、端末クライアントでは 600 Mbps 出る場合、ボトルネックは通常、ルーターの CPU、仮想 NIC の処理、またはプロトコル実装にあり、サブスクリプションのノード自体ではありません。

メインルーターで直接動かす：経路は短いが、障害範囲は広い

メインルーターに mihomo を導入する構成が最も直接的です。メインルーターが PPPoE や上位回線への接続、DHCP、DNS、ファイアウォール、NAT、mihomo を同時に担います。すべての端末のデフォルトゲートウェイがメインルーターを指すため、追加のネクストホップ設定なしで通信がプロキシルールを通ります。

端末
  ↓ デフォルトゲートウェイ
メインルーター：DHCP / DNS / ファイアウォール
  ↓ 透過プロキシルール
mihomo：ルール照合
  ├─ DIRECT → WAN
  ├─ REJECT → 破棄
  └─ プロキシグループ → リモートノード → 宛先サイト

メインルーター構成のメリット

  • ネットワークトポロジーがシンプルで、デフォルトゲートウェイも1つだけです。
  • 送信元 IP、MAC アドレスとの対応、ゲストネットワークのインターフェースを把握しやすくなります。
  • DNS ハイジャック、IPv4 のポリシールーティング、ファイアウォールルールを一元管理できます。
  • 端末同士で NAS、プリンター、キャスト機器へアクセスする際の経路を制御しやすくなります。

メインルーター構成のデメリット

  • 設定を誤るとネットワーク全体に影響するため、復旧時にプロキシを回避できる手段が必要です。
  • ファームウェアの更新で、ファイアウォールのカスタムルールやパッケージが初期化される可能性があります。
  • メインルーターの CPU が PPPoE、SQM、Wi-Fi、NAT、プロキシを同時に処理するため、リソース競合が目立ちやすくなります。
  • 一部のハードウェア NAT、フローオフロード、ソフトウェアオフロードが透過プロキシのチェーンを迂回することがあります。無効化するか、動作を改めて確認してください。

メインルーターで直接動かす場合も、少なくとも1つの管理経路を残してください。LAN からのみアクセスできる SSH 経路を用意するか、管理用 PC に固定アドレスを設定し、mihomo の停止、ポリシールーティングの削除、DNS の復元を行うコマンドを準備します。管理用ドメイン、ルーター自身の更新通信、プロキシノードのアドレスを再びプロキシへ送らないでください。ループが発生しやすくなります。

サブルーター構成：変更は少ないが、戻り経路の確認が必要

サブルーターは通常、メインルーターの LAN に接続する独立した機器です。PPPoE を担当するとは限らず、ネットワーク全体の DHCP を引き継ぐ必要もありません。mihomo はサブルーター上で動作し、選択した端末のデフォルトゲートウェイまたはポリシー上のネクストホップをサブルーターへ向けます。その後、サブルーターがメインルーターへ転送してインターネットへ接続します。

テスト用 PC 192.168.10.50
  ↓ ゲートウェイ 192.168.10.2
サブルーター 192.168.10.2：mihomo
  ↓ 上位ゲートウェイ 192.168.10.1
メインルーター 192.168.10.1
  ↓
インターネット

方式1：端末でサブルーターのゲートウェイを手動指定

サブルーター構成の中で、最もトラブルシューティングしやすい方法です。メインルーターを 192.168.10.1、サブルーターを 192.168.10.2 に設定し、テスト用 PC のデフォルトゲートウェイを 192.168.10.2 に変更します。サブルーター自身のデフォルトルートは引き続き 192.168.10.1 を指します。テストに失敗した場合は、PC のゲートウェイをメインルーターへ戻すだけで復旧できます。

DNS はまずサブルーターのアドレスを明示的に設定し、mihomo DNS が正常に動作することを確認してから DHCP 配布へ移行します。サブルーターでは IPv4 転送を有効にし、LAN からの通信を上流のメインルーターへ転送できるようにします。2台の機器が同じサブネットにある場合は、戻りの通信がサブルーターを迂回していないか特に確認してください。ウェブページが開くだけでは、透過プロキシが完全に機能しているとは判断できません。

方式2：メインルーターから機器ごとに異なるゲートウェイを配布

DHCP オプションやポリシールーティングに対応したメインルーターなら、MAC アドレスに応じて指定した機器へサブルーターのゲートウェイを配布できます。テレビやスマートフォンで静的アドレスを手入力する必要がありません。設定時はサブルーターに固定リースを割り当て、アドレスが変わらないようにします。DNS をどの機器が配布するかも明確にしてください。ゲートウェイはサブルーターを指しているのに DNS はパブリックリゾルバーを使い続けると、ドメインルールが機能しなかったり、名前解決の経路が漏れたりする可能性があります。

サブルーターで起きやすいループエラー

典型的な問題は、サブルーター自身のプロキシ接続まで透過プロキシのルールに捕捉されることです。mihomo がリモートノードへ接続すると、その通信が再び mihomo に入り、最終的にタイムアウトします。対策には、プロセスの実行ユーザーによる回避、ファイアウォールマークによる回避、ノードサーバーの IP を直接接続の集合へ追加する方法、ルーター自身の通信と転送通信を異なるチェーンへ分ける方法があります。

もう1つの問題は、メインルーターが戻りパケットを直接端末へ渡し、行きの通信だけがサブルーターを経由するケースです。通常の TCP は動作することもありますが、コネクション追跡、送信元アドレス変換、TProxy マークに依存する処理では不整合が起こりえます。より安定した方法は、サブルーターで必要な SNAT を実行するか、独立したサブネットで上下流を明確に分離し、同一サブネット内の非対称ルーティングを避けることです。

透過プロキシを実現する3つの方式

透過プロキシは、単一のスイッチで有効にする機能ではありません。Linux ルーターでよく使われる方式には Redirect、TProxy、TUN があります。いずれも端末の通信を mihomo へ渡せますが、対応プロトコル、ルーティング方式、トラブルシューティングの要点が異なります。

Redirect：まず TCP を動かすのに適した方式

Redirect は通常、NAT ルールで TCP 接続を mihomo の redir-port へリダイレクトします。設定例：

redir-port: 7892
allow-lan: true
bind-address: "*"
mode: rule
log-level: info

仕組みがシンプルで、HTTP、HTTPS、大半の TCP アプリを検証しやすいのが利点です。一方、TCP Redirect だけでは UDP を完全に処理できません。QUIC、一部のゲーム、音声通信、UDP ベースの DNS には追加の対策が必要です。ウェブ閲覧だけを確認するなら Redirect は妥当な出発点ですが、ネットワーク全体を引き継ぐなら、通常は TProxy または TUN も追加します。

TProxy：宛先アドレスを維持し、TCP と UDP を処理

TProxy は、ポリシールーティング、パケットマーク、ファイアウォールの透過プロキシターゲットを利用して、TCP と UDP を mihomo の tproxy-port へ渡します。カーネルには対応する透過プロキシモジュールが必要です。OpenWrt では、nftables または iptables のルールが現在のファイアウォール構成と一致していることも確認してください。

tproxy-port: 7893
mixed-port: 7890
allow-lan: true
mode: rule

TProxy で重要なのは、ポートルールを1本追加することだけではありません。パケットには通常、先にマークを付け、その後 ip rule で専用のルーティングテーブルを選び、宛先をローカルの透過プロキシポートへ戻します。ファイアウォールルールだけを設定してポリシールーティングを用意しないと、接続は失敗します。プロキシノードの IP、LAN サブネット、予約済みアドレスをあらかじめ回避しない場合、ループやローカルサービスへの接続不能が起こる可能性があります。

TProxy を調査するときは、リスニングポート、nftables のカウンター、ポリシールール、ルーティングテーブルの順に確認します。

ss -lntup
nft list ruleset
ip rule show
ip route show table all
conntrack -L | head

TUN：より広範囲を引き継げるが、ルーティング衝突も増える

mihomo の TUN モードは仮想 NIC を作成し、対象の通信をユーザー空間のプロトコルスタックへ渡します。通常は TCP と UDP をまとめて処理でき、異なる Linux 環境で設定を再利用しやすい点も特徴です。簡略化した例は次のとおりです。

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

dns:
  enable: true
  enhanced-mode: fake-ip
  listen: 0.0.0.0:1053

auto-route と auto-redirect が想定どおり動作するかは、OS、mihomo のバージョン、ファイアウォール環境に左右されます。複数 WAN、VPN、WireGuard、ポリシールーティング、コンテナネットワークがすでに構成されている機器では、自動追加されたルートが既存のルールと競合する可能性があります。構築前に ip rule、ip route、nft list ruleset の出力を保存しておき、差分を比較できるようにしてください。

TUN も性能を保証するものではありません。ユーザー空間のネットワークスタック、GRO、MTU、UDP 処理がスループットに影響します。特定のサイトが途中までしか読み込めない場合は、パス MTU を確認してください。PPPoE のインターフェース MTU は 1492 が一般的ですが、トンネルを重ねると利用可能な値はさらに小さくなります。パケットキャプチャなどの根拠がないまま、TUN の MTU を極端な値に変更しないでください。

DNS がドメインルールの命中を左右する

透過プロキシで過小評価されがちなのが DNS です。ルールに DOMAIN-SUFFIX と記述しても、ルーターが接続に対応するドメインを必ず把握できるとは限りません。端末が外部 DNS に直接アクセスしている、暗号化 DNS を有効にしている、宛先 IP だけを透過プロキシへ渡しているといった場合、ドメインルールの命中率は低下します。

Fake-IP の通信フロー

  1. 端末がルーターへドメインを問い合わせます。
  2. mihomo DNS が Fake-IP アドレスを返し、ドメインとの対応関係を保存します。
  3. 端末がその Fake-IP へ接続します。
  4. 透過プロキシが接続を捕捉し、mihomo がマッピングから元のドメインを復元します。
  5. ルールエンジンがドメインに応じて DIRECT、REJECT、またはプロキシグループを選択します。

Fake-IP はドメインベースの振り分けに適していますが、LAN 内のドメイン、プリンター検出、一部のゲーム、特殊なアプリではフィルターリストへの追加が必要になる場合があります。ルーターの管理用ドメイン、ローカルドメインのサフィックス、プライベートアドレスの名前解決は、優先的にローカル DNS へ任せてください。リモートプロキシへ送らないことが重要です。

dns:
  enable: true
  listen: 0.0.0.0:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "router.lan"
  nameserver:
    - 223.5.5.5
  proxy-server-nameserver:
    - 1.1.1.1

proxy-server-nameserver は、プロキシノードのサーバードメインを解決するために使います。この名前解決経路は、プロキシがまだ確立していない状態でも動作しなければなりません。そうでないと、ノード接続には名前解決が必要なのに、名前解決にはノード接続が必要という依存ループが発生します。実際の設定では、利用中のネットワークから到達できる上流 DNS を選び、アドレスを機械的にコピーしないでください。

ポート 53 が扱える範囲

従来の DNS は UDP または TCP 53 を使用するため、ルーター上で mihomo DNS へリダイレクトできます。たとえばローカルの 1053 へ転送する方法です。ただし DoH は HTTPS、DoT は通常 TCP 853 を使うため、53 番ポートのルール1本だけでは制御できません。端末でシステムレベルの暗号化 DNS が有効になっている場合は、デバイス管理で無効化する、既知のエンドポイントをルールで制限する、またはその端末を拡張されたドメイン解決の対象外として扱う必要があります。

ルール設計：まず回避し、その後に取り込む

ルーターのルールで最優先すべきことは、より多くの通信をプロキシへ送ることではなく、プロキシへ絶対に入れてはいけない通信を明確にすることです。LAN アドレス、マルチキャスト、ブロードキャスト、DHCP、ルーター管理アドレス、プロキシノードのサーバー、必要な時刻同期は先に回避します。これを怠ると、デバイス検出、キャスト、NAS へのアクセス、ノード自身の接続が壊れる可能性があります。

rules:
  - IP-CIDR,127.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,224.0.0.0/4,DIRECT,no-resolve
  - DOMAIN-SUFFIX,lan,DIRECT
  - DOMAIN-SUFFIX,local,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,Fallback

送信元デバイスごとの振り分けは、送信元 IP のサブネットで実現できます。たとえばテレビに 192.168.10.60 の固定アドレスを割り当て、ゲストネットワークに 192.168.30.0/24 を使い、送信元に応じてポリシーを選択します。動的アドレスに依存するより、固定リースのほうが信頼性は高くなります。ルールは上から順に照合されるため、LAN 回避ルールは送信元デバイスのプロキシルールより前に置いてください。

IPv6 は別途方針を決める必要があります。IPv4 だけを取り込み、IPv6 を直接接続のままにすると、アプリが AAAA レコードを優先して使い、ルールが時々しか効かないように見えることがあります。選択肢は3つです。IPv6 の透過プロキシを完全に構成する、テスト段階では管理対象端末へ IPv6 のデフォルトルートを配布しない、IPv6 の直接接続を明確に受け入れてセキュリティ境界に含める、のいずれかです。mihomo の設定で ipv6: false と書くだけで、端末がルーターからグローバル IPv6 を取得し続ける状態にしないでください。

ロールバック可能な構築手順

  1. 現状を記録する。メインルーターのアドレス、DHCP 範囲、DNS、デフォルトルート、ファイアウォールルール、既存の VPN 設定を保存します。
  2. バイナリを検証する。SSH で mihomo -v を実行してアーキテクチャが正しいことを確認し、続けて mihomo -t -d /etc/mihomo で設定を検査します。
  3. 管理ポートだけを開く。まず mixed-port: 7890 を起動し、テスト用 PC で HTTP または SOCKS5 プロキシを手動設定して、ノードとルールが使えることを確認します。
  4. DNS を接続する。テスト端末1台の DNS をルーターへ向け、nslookup または dig で応答を確認します。
  5. 透過プロキシを追加する。まずはテスト端末の送信元 IP だけを対象にし、他の機器は一時的に直接接続のままにします。
  6. TCP、UDP、ローカルサービスをテストする。ウェブ、動画、音声、ゲーム、NAS、プリンター、キャストを確認し、速度測定を1回行うだけで済ませないでください。
  7. 起動とロールバックを設定する。mihomo の起動に失敗した場合は、強制リダイレクトルールを残したままにしないでください。サービス停止後は通常の転送へ戻るようにします。
  8. 対象範囲を段階的に広げる。1台の端末から1つの VLAN へ拡大し、最後にネットワーク全体の取り込みを検討します。

実行ログはデバッグ中なら info、ルールの特定時だけ一時的に debug に設定できます。高いログレベルを長期間維持すると、ストレージへの書き込みと CPU 負荷が増えます。安定後はログローテーションを設定し、メモリ、接続数、プロセスの再起動回数を定期的に確認してください。

ルーターに適した用途、端末に残すべき用途

ルーターに任せるのに適したケース

  • テレビ、ゲーム機、スマートデバイスにプロキシクライアントをインストールできない。
  • 家庭や小規模オフィスで、ルールとサブスクリプションを一元管理したい。
  • デバイス、VLAN、送信元サブネットごとに異なるポリシーを選びたい。
  • ルーターのハードウェア性能に余裕があり、安定した SSH 管理経路がある。
  • 管理者が DHCP、DNS、ルーティングテーブル、nftables、コネクション追跡を理解している。

端末クライアントを使い続けるほうが適しているケース

  • プロキシが必要なのは PC 1～2台だけで、他の機器はすべて直接接続する。
  • メインルーターが通信事業者の機器で、ソフトウェアをインストールできず、ファイアウォールルールも確認できない。
  • 企業 VPN、複雑なマルチ WAN、厳格な端末認証に依存している。
  • 設定を頻繁に切り替えたい、または障害の影響を1台の端末だけに限定したい。
  • ルーターのメモリ、ストレージ、単一コアの性能がすでに上限に近い。

実際の構成は、どちらか一方を選ぶ必要はありません。よくある組み合わせは、ルーターでテレビ、ゲストネットワーク、クライアントをインストールできない機器だけを処理し、開発用 PC ではデスクトップクライアントを引き続き動かす方法です。これなら機器単位の制御を維持しながら、複雑なポリシーを1つのゲートウェイへ集中させずに済みます。

最終的な判断は次の一文にまとめられます。メインルーターはシンプルなトポロジー、サブルーターは変更範囲の制御、TProxy は Linux 本来の透過転送、TUN は統一的な取り込みを重視します。選定では機能の数より、まず障害の境界を確認してください。すぐ停止でき、DNS を復旧でき、ノードへのループを回避できる構成こそ、長期運用に適しています。

クライアントの設定を続ける

まず PC でサブスクリプション、ノード、ルールを検証し、その後で同じ振り分けロジックをルーターへ移行するか判断します。

ダウンロードページへ チュートリアルを見る
Clash をダウンロード