2026-07-24プラットフォーム読了目安 12 分

OpenWrt ルーターに mihomo コアを導入:サブルーターでの分流実践記録

プロキシコアをパソコンからルーターへ移すのは、多くの家庭ネットワークにとって最終形態と言える構成だ。テレビやゲーム機など、クライアントを直接インストールできない機器もまとめて制御下に置けるようになる。本稿では OpenWrt のサブルーターに mihomo(Clash Meta)コアを導入する手順を、構成方式の選定からバイナリのインストール、サブスクリプション設定の反映、TUN による通信の引き受け、procd によるプロセス監視、分流の検証まで一通り記録する。各手順にはそのまま使えるコマンドと明確なチェックポイントを添えた。

mihomo コア·TUN 通信引き受けモード·procd 起動監視·OpenWrt 23.05 検証環境

一、構成方式:メインルーター直接導入かサブルーターか

ルーターでプロキシコアを動かすには、まずどの機器にコアを載せるかを決める必要がある。2 つの方式にはそれぞれ明確な適用範囲があり、方式選びを誤ることが初心者が最初につまずく原因になる。

メインルーター直接導入

出口ゲートウェイ上でコアを直接動作させる方式で、LAN 内の全通信が自然に経由するためクライアント側は無設定で済む。ただし依存度が高すぎるのが代償だ。コアのクラッシュ、ルール設定ミス、メモリ不足などいずれかが起きると家全体がネット断になる。さらに NAT と暗号化処理が同じチップに集中するため要求される処理能力が最も高く、100Mbps 超の帯域を扱う低価格帯 MIPS 機種ではまず対応できない。

サブルーター(シングルアーム構成)

別に用意した機器──不要になったテレビボックス、Raspberry Pi、x86 小型機など何でもよい──に OpenWrt を書き込み、メインルーターと同じ LAN にポートで接続し、同一セグメントの固定 IP を割り当てる。プロキシ経由にしたい機器だけ、デフォルトゲートウェイと DNS サーバーをこのサブルーターに向ければよく、対象外の機器はそのままで互いに干渉しない。サブルーターが落ちた場合もゲートウェイをメインルーターに戻すだけで 10 秒ほどで復旧でき、リスクは完全に分離されている。

本稿はサブルーター構成を軸に進める。コアのインストールと設定の部分は両方式で完全に共通なので、メインルーター直接導入を選ぶ読者は第四節の「ゲートウェイの向け先」の項を読み飛ばしてよい。

補足

サブルーターの最大の価値は性能ではなく「戻せること」にある。どんな設定ミスをしても 10 秒で元に戻せる退路が常に確保されている。これはプロキシコアを本番ネットワークに投入する前に敷いておく安全策だ。

二、コアの選定とインストール

mihomo は Clash 本家コアがアーカイブされた後、コミュニティによって開発が継続されているフォーク(旧称 Clash.Meta)で、単一バイナリとして配布され、追加の依存関係なしに OpenWrt 上でそのまま動作する。現時点でルーターに導入する際の定番コアだ。リリース物は gzip 圧縮された素のバイナリで、CPU アーキテクチャごとに分かれているため、まず自分の機器のアーキテクチャを確認する必要がある。

SSH でルーターにログインし、uname -m を実行して以下の表と対応させてダウンロードパッケージを選ぶ:

uname -m の出力代表的な機器リリースファイル名のキーワード
aarch64Raspberry Pi 4/5、NanoPi R4S、多数の ARM ボックスlinux-arm64
armv7lRaspberry Pi 2/3(32bit システム)、古めの開発ボードlinux-armv7
mipselMT7621 などの MIPS ルーター(K2P、新三 など)linux-mipsle-softfloat
x86_64x86 小型ルーター機、仮想マシンlinux-amd64-compatible

陥りやすい点が 2 つある。1 つ目は x86 ルーター機では compatible サフィックス付きのパッケージを選ぶこと。OpenWrt の x86 ビルドは比較的古い命令セットを対象としており、通常の amd64 パッケージだと一部の CPU で Illegal instruction エラーが即発生する。2 つ目は MT7621 などの MIPS 機器はリトルエンディアンかつ大半が浮動小数点演算ユニットを持たないため、必ず mipsle-softfloat を選ぶ必要がある。

arm64 機器を例に、完全なインストールコマンドは以下のとおり:

opkg update
opkg install curl ca-bundle kmod-tun
curl -L -o /tmp/mihomo.gz https://github.com/MetaCubeX/mihomo/releases/download/v1.19.5/mihomo-linux-arm64-v1.19.5.gz
gunzip /tmp/mihomo.gz
mv /tmp/mihomo /usr/bin/mihomo
chmod +x /usr/bin/mihomo
mihomo -v

最後の行の mihomo -v でバージョン番号が表示されればアーキテクチャの選定は正しい。Illegal instruction や Exec format error が出た場合は上の表に戻ってパッケージを変えて試してほしい。コマンド内のバージョン番号はあくまで例示であり、ダウンロード前に mihomo の releases ページで最新の安定版と正確なファイル名を確認すること。kmod-tun もここで一緒にインストールしておき、第四節で使用する。

補足

OpenWrt の /tmp はメモリ上のディスクで再起動すると消えるため、一時的な受け渡しにしか使えない。コア本体と設定ファイルは必ずフラッシュストレージ、例えば /usr/bin や /etc/mihomo に置くこと。フラッシュ容量が 32MB 未満の機種は先に extroot を設定するか外部ストレージを利用してほしい。そうしないと GeoIP データベースすら格納できない。

三、設定の反映:サブスクリプションの取得と重要な項目

設定ディレクトリは /etc/mihomo とし、コアは -d /etc/mihomo パラメーターで起動する。このディレクトリ内に config.yaml、GeoIP データベース、キャッシュファイルが順次生成される。まずディレクトリを作成し、サブスクリプションを取得する:

mkdir -p /etc/mihomo
curl -L -o /etc/mihomo/config.yaml "あなたのサブスクリプションURL"

多くのプロバイダのサブスクリプションリンクは、Clash 系クライアントからのリクエストに対して YAML 設定を直接返すため、そのまま config.yaml として保存すれば使える。取得した内容が base64 エンコードされたノードリストだった場合、サーバー側が汎用サブスクリプション形式を返していることを意味する。リクエストに Clash の User-Agent を付与するか、パソコン側で先に変換してから scp でルーターにアップロードするとよい。ルーター上でサブスクリプション変換プログラムを動かすのは保守対象が増えるだけなので推奨しない。

サブスクリプションを取得したら、サブルーターとしての役割に合わせて以下の重要項目を修正し、それ以外は取得した内容のままにする:

mixed-port: 7890            # HTTP と SOCKS の混合入口
allow-lan: true             # LAN 内機器からの接続を許可、サブルーターでは必須
bind-address: "*"
log-level: warning
external-controller: 0.0.0.0:9090   # 外部管理インターフェース
external-ui: ui             # パネル用静的ファイルのディレクトリ
secret: "任意のパスワードに変更してください"
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
  fallback:
    - https://1.1.1.1/dns-query
    - https://dns.google/dns-query
tun:
  enable: true
  stack: system
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

この 3 項目がサブルーターとして機能するかどうかを左右する。allow-lan を有効にしないと LAN 内の機器はそもそも 7890 ポートに接続できない。external-controller を 0.0.0.0 にバインドしないとパソコンのブラウザからパネルにアクセスできない。tun のセクションは次節で解説する通信引き受けの核心部分だ。修正が終わったら、コア付属の検証機能で構文をチェックする:

mihomo -t -d /etc/mihomo

configuration file test is successful と表示されれば問題なし。エラーが出た場合は具体的な行番号が示されるので、その行に戻って修正する。

補足

external-controller を LAN 内に公開する場合は必ず secret を設定し、絶対に外部インターネットへ転送しないこと。9090 ポートはノードの切り替え、接続状況の確認、設定変更まで全権限を持っている。無防備な状態で公開すると、同一ネットワーク内の誰でもネットワークの出口を操作できてしまう。

四、通信の引き受け:TUN モードとゲートウェイの向け先

通信の引き受け方式には TUN を選ぶ。理由はルーティング管理をコア内部に取り込める点にある。有効化すると mihomo は utun という名前の仮想ネットワークインターフェースを作成し、auto-route が自動でルーティングルールを書き込み、自機発信および転送されてくる TCP・UDP 通信をすべてコアに取り込む。iptables の REDIRECT ルールを手で書く必要も、UDP を別途処理する必要もない。stack は system を選ぶと互換性が最も高い。スループットを追求するなら gvisor に切り替えて比較検証するとよい。

TUN を使うにはカーネル側のサポートが前提で、第二節でインストールした kmod-tun がまさにそのためのものだ。デバイスノードの存在を確認する:

ls /dev/net/tun

/dev/net/tun と出力されれば正常。存在しないと表示された場合は kmod-tun が正しくインストールまたはロードされていないことを意味するので、再インストール後に再起動する。

クライアントのゲートウェイ設定

サブルーターはどの機器とも直接接続していないため、通信を「導く」設定が必要になる。推奨度の高い順に 3 つの方法を挙げる:

  1. メインルーターの DHCP から配布:メインルーターの DHCP オプションで、ゲートウェイ(option 3)と DNS(option 6)をサブルーターの IP に変更する。家中の機器が意識せずに切り替わり、新たに接続した機器にも自動的に反映される。
  2. 個別の機器で手動指定:必要な機器だけゲートウェイと DNS を変更し、それ以外はメインルーターに直接接続させる。これはサブルーター構成ならではの細やかな制御で、まず 1 台だけ試して動作確認したい場合に向いている。
  3. サブルーターで DHCP を自前運用:メインルーターの DHCP を無効にしてサブルーターに完全に任せる方法で、制御は最も徹底しているが、サブルーターに障害が起きると家中どの機器も IP を取得できなくなるため初心者には推奨しない。

システム側で確認すべき点が 2 つある。OpenWrt は既定で IP フォワーディングが有効になっており、sysctl net.ipv4.ip_forward で値が 1 であることを再確認できる。ファイアウォールについては「ネットワーク → ファイアウォール → ゾーン」に入り、utun デバイスを lan ゾーンのデバイスリストに追加すること。これを怠ると転送されてきた通信が netfilter の段階で破棄され、クライアントはサブルーターに接続できてもどのウェブページも開けない、という症状になる。

五、起動時自動実行:procd によるプロセス監視

OpenWrt のサービス管理は procd が担っており、init スクリプトを 1 つ書くだけで起動時自動実行とクラッシュ時の自動再起動が実現できる。/etc/init.d/mihomo を新規作成し、以下の内容を書き込む:

#!/bin/sh /etc/rc.common
# mihomo コア監視スクリプト
START=99
STOP=10
USE_PROCD=1

start_service() {
    procd_open_instance mihomo
    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_close_instance
}

respawn 行の 3 つの数字は順に、しきい値・間隔・リトライ回数を表す。つまりプロセス終了後 5 秒で再起動し、1 時間以内に 5 回を超えて繰り返しクラッシュした場合は再起動を諦める、という設定だ。stdout と stderr は syslog にリダイレクトされるので、以降は logread でコアのログを確認できる。実行権限を付与して有効化する:

chmod +x /etc/init.d/mihomo
/etc/init.d/mihomo enable
service mihomo start

enable を実行すると /etc/rc.d 内に S99 から始まるシンボリックリンクが作成され、ルーター再起動後にコアが自動的に起動するようになる。サブスクリプションの更新もついでに自動化しておける。crontab に、毎週深夜に config.yaml を再ダウンロードしてから service mihomo restart を実行するタスクを 1 行追加すれば、ノードリストを常に最新の状態に保てる。

六、検証とトラブルシューティングチェックリスト

導入が完了しても分流が正しく機能しているとは限らない。以下の順番で一つずつ検証し、各段階で明確な判断基準を確認する:

  1. プロセスが稼働しているか

    pgrep mihomo で出力があり、/etc/init.d/mihomo status で running と表示されること。初回起動時に GeoIP データベースが /etc/mihomo に自動ダウンロードされるので、このディレクトリに書き込み権限があり空き容量が十分あることを確認する。

  2. ログが正常か

    logread -e mihomo で同じエラーが繰り返し出ていないこと。同一のエラー行が続けて出る場合は設定またはネットワークの問題であることが多いので、エラー内容から原因を特定する。

  3. パネルにアクセスできるか

    ブラウザで http://サブルーターのIP:9090/ui を開き、secret を入力してリアルタイムの接続一覧が表示されること。external-ui で指定した ui ディレクトリには、事前に metacubexd や zashboard のビルド済みファイルを展開しておく必要がある。

  4. DNS が引き受けられているか

    クライアント側で nslookup www.google.com サブルーターのIP を実行し、fake-ip モードでは 198.18.x.x 帯のアドレスが返れば、クエリがコア側で処理されていることを意味し、サブルーターを迂回して漏れていないことが確認できる。

  5. 出口 IP が正しいか

    クライアントで任意の IP 確認サイトを開くと、ノードの出口アドレスが表示されるはずだ。続けて中国本土のサイトにアクセスし、直接接続で速度が正常であることを確認できれば、分流が正しく機能していると言える。

よくある不具合と対処法:

以上で、自己修復可能かつ元に戻せる、必要な機器だけを引き受けるサブルーターの導入が完了した。今後のメンテナンスは 2 点だけ残る。mihomo のバージョン更新の動向を追うこと、そして /etc/mihomo ディレクトリを定期的にバックアップすること──ここに全ての設定とデータベースが格納されているので、機器を乗り換える際もこのディレクトリをそのままコピーすればよい。

Clash をダウンロード