ルーターと旁路ルーターで mihomo コアを直接動かす導入ガイド：構成選びと基本手順

Clash Premiumの旧コアが更新を終了して以降、ルーター側の導入は継続的に更新されているmihomoへ移行しつつあります。デスクトップクライアントと異なり、ルーターには設定ディレクトリ、権限、DNS転送、プロセス監視を処理するGUIがありません。重視すべきなのはプロキシポートを待ち受けさせることだけでなく、LANトラフィックが明確で復旧可能な転送経路を通る状態にすることです。

本稿では、OpenWrtを導入したメインルーターと、Debian、Ubuntu、ImmortalWrtなどのLinuxシステムを動かす旁路ルーターという、代表的な2つの環境を扱います。例ではmihomo v1.19系の設定構文を基準に、TUNによる取り込みを中心に説明し、従来型のファイアウォール転送で追加対応が必要な点にも触れます。実際に導入する前に、デバイスのアーキテクチャと対象バージョンのリリースノートでファイル名を確認してください。

まず構成を選ぶ：メインルーターに直接導入するか、独立した旁路ルーターにするか

メインルーターへの直接導入は、ダイヤルアップ接続、DHCP、NAT、ファイアウォールを担う同じ機器にmihomoを配置する方法です。すべての端末のデフォルトゲートウェイはもともとその機器を指すため、通信経路が短く、端末ごとにゲートウェイを変更する必要も通常ありません。一方、プロキシ設定の誤りが家庭内ネットワーク全体に影響しやすく、コアの更新、ファイアウォールの再起動、DNSの誤変更が起きた場合も、復旧の入口が同じ機器に集中します。

旁路ルーターでは、別のLinux機器にプロキシ処理を任せます。上流のメインルーターが引き続き接続処理を担い、旁路ルーターはポリシールーティング、DNS、mihomoを担当します。停止して保守しやすく、テレビやスマートフォン、検証用PCだけをプロキシ経由にすることも可能です。ただし、同一セグメントの片側接続型では、戻り経路の迂回、ゲートウェイループ、DHCP競合が起きやすいため、アドレスと転送関係を明確に設計する必要があります。

比較項目	メインルーターへの直接導入	独立した旁路ルーター
デフォルトゲートウェイの変更	通常は不要。端末は引き続きメインルーターのアドレスを使用	DHCPまたは端末側で旁路ルーターを指定
障害の影響	設定ミスがネットワーク全体に影響する可能性あり	端末のゲートウェイをメインルーターへ戻してすぐに迂回可能
ハードウェアの余裕	ルーターのCPU、フラッシュ、メモリに制限される	x86の小型PCや高性能なARMデバイスを利用可能
保守の複雑さ	通信経路は直接だが、接続処理とファイアウォールも考慮が必要	機器が1台増え、転送、戻り経路、DHCPへの対応が必要
適した環境	ネットワーク構成が単純で、機器性能に余裕があり、全体を一括制御したい場合	段階的な導入、頻繁な検証、素早く戻せる経路を残したい場合

片側接続型旁路ルーターのアドレス例

メインルーターのアドレスを 192.168.1.1、旁路ルーターの固定アドレスを 192.168.1.2 とします。旁路ルーター自身のデフォルトゲートウェイには引き続き 192.168.1.1 を設定し、取り込み対象の端末ではゲートウェイとDNSを 192.168.1.2 に指定します。DHCPで一括配布する場合は、同じブロードキャストドメインにDHCPサーバーが1台だけ存在することを確認してください。2台の機器が異なるゲートウェイを同時に配布すると、競合が発生します。

片側接続型では、戻りトラフィックが安定して旁路ルーターを通るよう、旁路ルーターの出口で送信元アドレス変換を行う構成が推奨されます。クライアントの元のアドレスをルール照合に残す場合は、メインルーターにクライアント側セグメントへの静的ルートを追加し、戻り経路が旁路ルーターを直接迂回しないことを確認してください。パケットの実際の経路を判別できない状態になるまで、2つの方式を混在させないでください。

ハードウェア、システム、バイナリアーキテクチャを確認する

mihomoは単一のコアプログラムですが、ルールセット、コネクション追跡、Fake-IPマッピングがメモリを消費します。小規模な設定では起動後の使用量はおよそ70〜120 MBが一般的です。大きなドメインルールセット、複数のprovider、数千件の接続を読み込むと、180〜300 MBに達することがあります。メモリ128 MBの古いルーターは余裕が少なく、512 MBがより現実的な開始点です。長期運用やルール更新を頻繁に行うなら、1 GB以上が適しています。

まずSSHでシステムのアーキテクチャとカーネル情報を確認します：

uname -m
uname -a
getconf LONG_BIT
cat /etc/os-release
free -m
df -h

`uname -m` の代表的な結果	通常の選択	注意点
`x86_64`	linux-amd64	古いCPUが新しい命令セットに対応していない場合は、互換性重視のビルドを選択
`aarch64`	linux-arm64	64ビットARMルーターや開発ボードでよく使われる
`armv7l`	linux-armv7	システムの浮動小数点ABIとリリースファイルの説明を確認
`mips` または `mipsel`	MIPSのビッグエンディアンまたはリトルエンディアン向けビルド	古い機器では性能と利用可能なメモリに余裕がないことが多い

TUNモードにはカーネルデバイスと関連モジュールも必要です。ls -l /dev/net/tun を実行してデバイスノードを確認し、続けて ip rule、ip route、nft list ruleset で、ポリシールーティングとnftablesを管理できることを確認します。OpenWrtではLuCIの「システム」→「ソフトウェアパッケージ」で kmod-tun を確認できます。SSHから、現在のファームウェアカーネルに対応するパッケージをインストールすることも可能です。

設定ディレクトリを作成し、初回検証を行う

汎用Linuxでは、プログラムを /usr/local/bin/mihomo、設定ディレクトリを /etc/mihomo に配置できます。OpenWrtでフラッシュ容量が厳しい場合は、大きなルールファイルを /mnt/data/mihomo などのマウントディスクへ置けます。ただし、起動サービスはマウントポイントが利用可能になるまで待機させる必要があります。以下のコマンドは、アーカイブをすでに本体上で展開した前提です。ファイル名は実際にダウンロードしたアーキテクチャ向けのものへ置き換えてください：

sudo install -m 0755 mihomo-linux-amd64 /usr/local/bin/mihomo
sudo mkdir -p /etc/mihomo
sudo install -m 0600 config.yaml /etc/mihomo/config.yaml

/usr/local/bin/mihomo -v
sudo /usr/local/bin/mihomo -t -d /etc/mihomo

-t は設定のテスト、-d は作業ディレクトリの指定に使います。テストに合格しても、YAMLを解析でき、主要フィールドを読み込めることを示すだけです。サブスクリプションURL、DNS上流、ノードへの接続性までは保証されません。本稼働後は、ログでproviderの更新、待ち受けポート、TUNインターフェース、ルールの照合結果も確認してください。

サブスクリプションは、そのまま動く完全な設定とは限らない

デスクトップクライアントでは、サブスクリプションのインポート、上書き設定、コアパラメータがGUIにまとめられていることが多い一方、ルーターで直接動かすには完全な config.yaml が必要です。サブスクリプションによっては完全なClash設定を返しますが、ノード一覧だけを返すものもあります。後者は proxy-providers で参照し、プロキシグループ、DNS、ルール、待ち受けポートを自分で補う必要があります。

サブスクリプションURLには通常アカウントトークンが含まれるため、設定ファイルは管理者だけが読めるよう権限を制限してください。providerを更新した後は、リモート側が空の内容を返しても稼働中のノード一覧をすぐ上書きしないよう、利用可能なキャッシュを1世代残します。メイン設定を置き換える前に、次のテストを実行できます：

cp /etc/mihomo/config.yaml /etc/mihomo/config.yaml.bak
/usr/local/bin/mihomo -t -d /etc/mihomo

# テスト失敗時の復元
cp /etc/mihomo/config.yaml.bak /etc/mihomo/config.yaml

透過プロキシの設定：TUN、DNS、待ち受け範囲

mixed-port: 7890 だけを有効にした場合、LAN内の端末でHTTPまたはSOCKSプロキシを手動設定する必要があります。テレビアプリ、ゲーム機、システムプロキシ設定に従わないプログラムを自動的に取り込むことはできません。ルーターでの導入では、通常TUNまたはnftablesベースの透過転送を使用します。TUN設定は一元化しやすい一方、カーネルモジュール、ポリシールーティング、DNSハイジャック、ファイアウォールとの互換性への対応が必要です。

以下は主要フィールドを説明するための基本的な断片です。ノード、プロキシグループ、用途別ルールは完全な設定で用意してください：

mixed-port: 7890
allow-lan: true
bind-address: "*"
mode: rule
log-level: info
ipv6: false

external-controller: 127.0.0.1:9090
secret: "replace-with-a-long-random-secret"

profile:
  store-selected: true
  store-fake-ip: true

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

dns:
  enable: true
  listen: 0.0.0.0:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - 223.5.5.5
    - 119.29.29.29

auto-detect-interface は実際の出口インターフェースを識別し、ダイヤルアップ用インターフェース名の変更による設定修正を減らします。マルチWAN、VPNの多重化、コンテナブリッジが多い環境では、自動判定が期待どおりにならない場合があるため、ログと ip route get 1.1.1.1 で出口を確認してください。strict-route はDNSや接続の迂回を減らせますが、誤ったポリシールーティング設定も表面化しやすくなります。

例ではDNSの待ち受けを 1053 に設定し、dnsmasqが使用している可能性のある 53 ポートを直接占有しないようにしています。OpenWrtではdnsmasqの上流転送先を 127.0.0.1#1053 に設定できます。LuCIでの一般的な場所は「ネットワーク」→「DHCP/DNS」→「一般設定」→「DNS転送」です。保存前に、リクエストを他の上流へ同時送信する並列転送設定を無効にしてください。有効なままだと、名前解決の結果とプロキシルールが一致しないことがあります。

Fake-IPの除外対象にはLANサービスも含める

Fake-IPを使うと、接続確立時点でドメインルールに基づく振り分けを行えます。ただし、プリンター、NAS、キャスト、LAN内のサービス検出は実アドレスに依存することがあります。ローカルドメインのサフィックス、ルーター管理用ドメイン、必要な接続性確認用ドメインを fake-ip-filter に追加してください。LAN内サービスでは、まずローカルDNSからプライベートアドレスを返すようにし、ドメインが先にパブリックDNSで解決されないようにします。

dns:
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "router.local"
    - "nas.home.arpa"
    - "+.home.arpa"

OpenWrtメインルーターへの導入手順

既存設定をバックアップ。LuCIで「システム」→「バックアップ／アップグレード」を開き、復元可能な設定アーカイブを作成します。同時にWANインターフェース名、LANアドレス、DHCP設定も記録してください。
空き容量を確認。df -h でoverlayを確認します。実行ファイル、Geoデータ、ルールセットで合計数十MBを消費する場合があります。容量が不足する場合は外部ストレージを使い、ルートパーティションを満杯にしないでください。
TUNをサポートするパッケージを導入。「システム」→「ソフトウェアパッケージ」でファームウェアに一致する kmod-tun をインストールし、その後 /dev/net/tun が存在することを確認します。
プログラムと設定を配置。/usr/bin/mihomo と /etc/mihomo/config.yaml の使用を推奨します。権限はそれぞれ 0755 と 0600 に設定してください。
まずフォアグラウンドで実行。/usr/bin/mihomo -d /etc/mihomo を実行し、TUN、DNS、providerのログを確認します。その後、検証用端末から直接接続とプロキシルールをテストしてください。
起動時サービスに追加。フォアグラウンドで安定して動作することを確認してからprocdサービスを作成し、最後に「システム」→「起動項目」で有効化の状態を確認します。

OpenWrtではprocdでサービスを管理します。以下のスクリプトは最小構成の例です。設定ディレクトリは実際の配置場所に合わせてください：

#!/bin/sh /etc/rc.common

START=95
STOP=10
USE_PROCD=1

start_service() {
  procd_open_instance
  procd_set_param command /usr/bin/mihomo -d /etc/mihomo
  procd_set_param respawn 3600 5 5
  procd_set_param stdout 1
  procd_set_param stderr 1
  procd_set_param limits nofile="1048576 1048576"
  procd_close_instance
}

service_triggers() {
  procd_add_reload_trigger "mihomo"
}

/etc/init.d/mihomo として保存した後、次を実行します：

chmod 0755 /etc/init.d/mihomo
/etc/init.d/mihomo enable
/etc/init.d/mihomo start
logread -e mihomo

起動時に外部ディスクがまだマウントされていないと、サービスが設定やルールファイルを見つけられません。設定は内部フラッシュに残し、providerキャッシュだけを外部ディスクへ置く方法もあります。起動順序を調整し、スクリプト内でディレクトリを確認することも可能です。マウント順序の問題を、数秒固定で待つだけの処理で隠さないでください。

汎用Linuxの旁路ルーター向けsystemd設定

Debian、Ubuntuなどsystemdを使用するシステムでは、/etc/systemd/system/mihomo.service を作成できます。ルーターで透過的な取り込みを行うには、TUNの作成、ルートの追加、関連するネットワーク権限の管理が必要です。最初はrootで実行するのが最も簡単です。導入が安定してから実際の機能に応じて権限を減らし、最初から権限を削ってTUN作成に失敗する事態は避けてください。

[Unit]
Description=mihomo routing core
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
ExecStartPre=/usr/local/bin/mihomo -t -d /etc/mihomo
ExecStart=/usr/local/bin/mihomo -d /etc/mihomo
Restart=on-failure
RestartSec=5
LimitNOFILE=1048576

[Install]
WantedBy=multi-user.target

sudo systemctl daemon-reload
sudo systemctl enable --now mihomo
sudo systemctl status mihomo
sudo journalctl -u mihomo -n 100 --no-pager

旁路ルーターではIPv4転送も有効にする必要があります。/etc/sysctl.d/90-router-forward.conf を作成します：

net.ipv4.ip_forward=1

続いて sudo sysctl --system を実行します。IPv6を有効にする場合は、IPv6のデフォルトルート、DNS、ファイアウォールを別途設計してください。net.ipv6.conf.all.forwarding=1 を有効にしただけで、すべてのトラフィックがmihomoに入ると判断してはいけません。IPv6の取り込みが未完成なら、まず検証ネットワークでIPv6を無効にし、端末がルール対象外のIPv6経路で接続するのを防ぎます。

ファイアウォールとTUNのルールで二重に取り込まない

既存のnftables、Docker、Tailscale、その他のVPNがあると、ルールの優先順位が衝突する可能性があります。mihomoを有効にした後は、ip rule、ip route show table all、nft list ruleset をそれぞれ実行し、重複したマーク、TUNへ戻るデフォルトルート、コンテナ用セグメントが誤ってプロキシへ入る状態などを確認してください。TUNの自動ルートが対象トラフィックをすでに取り込んでいる場合、旧式のREDIRECTルールをそのまま追加しないでください。

性能検証とトラブル対処

導入後は、ウェブページを開けるかどうかだけで判断しないでください。少なくともLAN内の直接接続、プロキシ接続、DNS、ルール照合、再起動後の復旧、高同時接続時の安定性という6項目を検証します。テスト中は同じノードと同じ端末に固定し、ノードの変動とローカル設定の変更が同時に起きないようにします。

ポート状態：ss -lntup を使い、7890、9090、1053 が想定どおり待ち受けているか確認します。
DNS経路：nslookup example.com 192.168.1.2 を実行し、mihomoのログに該当するクエリが現れるか確認します。
ゲートウェイ転送：端末で経路追跡を実行し、最初のホップが設計したメインルーターまたは旁路ルーターであることを確認します。別のDHCPサーバーが配布した古いゲートウェイになっていないかも確認してください。
ルール照合：ログレベルを一時的に debug に変更し、対象ドメインが最終的に想定したプロキシグループへ入るか確認します。完了後は info に戻し、大量のログが長時間出続けないようにします。
再起動後の復旧：機器を再起動し、mihomo、DNS転送、TUNが自動的に復旧するか確認します。providerキャッシュを読み取れることも確認してください。
復旧テスト：mihomoを停止した後、検証用端末のゲートウェイをメインルーターへ戻し、基本ネットワークが単独で動作することを確認します。

ハードウェア性能の目安として、500 Mbpsの回線、mihomo v1.19系、約8,000件のルールという条件では、Intel N5105の4コア小型PCがTUN転送でおよそ430〜470 Mbpsに達することがあります。4コアCortex-A53・メモリ1 GBの機器では、一般に約180〜240 Mbpsです。数値は暗号化プロトコル、ノードまでの距離、NICドライバー、ルール規模、トラフィック sniffing の有効化によって変わるため、機器の公称性能と直接比較することはできません。

速度が直接接続の半分程度しか出ない場合は、まず単一コアのCPU使用率が100%近くに達していないか確認し、次にMTUを調べます。PPPoE、WireGuard、TUNを重ねると、MTUが大きすぎてパケット分割や一部サイトの読み込み停止が起きることがあります。1500 から 1492、1480、1400 へ段階的に試し、毎回1つのパラメータだけを変更して、スループット、遅延、パケットロスを記録してください。

コアと設定を更新する引き継ぎ手順

ルーター上の更新は「新ファイルを検証し、旧ファイルを残してから、サービスを切り替える」順序で行います。稼働中のバイナリを直接上書きして、すぐ再起動しないでください。まず新版を mihomo.new として保存し、バージョン確認と設定テストを実行します。その後サービスを停止し、ファイルを置き換えて起動します。安定動作を確認した後も、旧版は1回の更新サイクル分残しておくと安心です。

sudo install -m 0755 mihomo.new /usr/local/bin/mihomo.new
sudo /usr/local/bin/mihomo.new -v
sudo /usr/local/bin/mihomo.new -t -d /etc/mihomo

sudo systemctl stop mihomo
sudo mv /usr/local/bin/mihomo /usr/local/bin/mihomo.previous
sudo mv /usr/local/bin/mihomo.new /usr/local/bin/mihomo
sudo systemctl start mihomo
sudo systemctl status mihomo

設定更新も、まず一時ファイルへ書き込んでテストしてからメインファイルを置き換えます。DNSモード、TUNスタック、ルールセット形式、providerの動作に変更がある場合は、まず1台の端末で検証し、システムファームウェアの更新と同じタイミングで実施しないでください。旧コアの終了後、mihomoへの移行で変わるのは実行ファイルだけではありません。設定フィールドやネットワークの取り込み方式も変化し続けます。検証と復旧を固定手順にするほうが、長期間変わらない1本のスクリプトに依存するより確実です。