2026-09-15 導入・構築読了時間：約12分

mihomoをOpenWrtのバイパスルーターで動かす方法｜構築手順と構成例

OpenWrtの主ルーターとバイパスルーターの役割、mihomoの配置場所や設定ファイル、透過プロキシ、ゲートウェイ設定を解説。初心者向けに構築方法を整理します。

まずは手動プロキシで検証し、その後ゲートウェイを切り替える

OpenWrtでmihomoを直接動かすとは、システムからmihomoのプロセスを起動し、YAML設定を読み込んで、必要に応じてルーティングやファイアウォールに接続することです。一般にClash Metaのコアとして知られるmihomoは、LuCIプラグインではありません。ルーターにコピーしただけで、家庭内の全通信を自動的に処理するわけでもありません。管理画面、サブスクリプションの更新、透過プロキシのルール、起動時の自動実行は、それぞれ個別に設定する必要があります。

初心者は次の3段階で進めるのがおすすめです。まず設定ファイルの検証を通し、次に1台のパソコンからバイパスルーターの明示的プロキシを使い、最後にそのパソコンのデフォルトゲートウェイとDNSを変更します。各段階に確認ポイントがあるため、問題が起きても直前の状態へ戻しやすくなります。

方式	端末の接続方法	必要な設定
明示的プロキシ	バイパスルーターのIPアドレスとポート7890を手動で指定	カーネル、設定ファイル、LANからのアクセス許可
TUNによる通信の取り込み	端末のゲートウェイをバイパスルーターに設定	TUNデバイス、ルーティング、DNS、ファイアウォール、IPv6
ファイアウォールによる透過プロキシ	端末のゲートウェイをバイパスルーターに設定	REDIRECTまたはTPROXY、ポリシールーティング、ループバックの除外

ブラウザーだけでプロキシを使いたい場合は、最初の方法で十分です。テレビやゲーム機、手動プロキシに対応していないアプリもまとめて接続したい場合に限り、後の2方式を検討してください。OpenWrtの管理プラグインがすでに入っている場合は、mihomoが起動済みか先に確認しましょう。複数の管理手段が同時にポートやルーティングを制御する事態を避けられます。

主ルーターとバイパスルーター：まず通信経路を整理

ここでは、IPv4の家庭内ネットワークを例に、それぞれの役割を説明します。主ルーターはインターネット接続、外部への出口、DHCPを担当します。バイパスルーターには固定アドレスを割り当て、まずは指定したテスト端末だけを経由させます。以下のアドレスは説明用です。実際に設定する前に、現在のネットワーク範囲とアドレスの重複がないか確認してください。

主ルーター：192.168.10.1/24。インターネットに接続。
OpenWrtのバイパスルーター：192.168.10.2/24。上位ゲートウェイは192.168.10.1。
テスト用パソコン：192.168.10.100/24。初期状態では主ルーターをゲートウェイに設定。
DHCPアドレスプールの例：192.168.10.100–192.168.10.200。バイパスルーターのアドレスは動的割り当ての範囲から除外します。

バイパスルーターのIPを固定し、DHCPサーバーは1台にする

標準のLuCI画面では、「ネットワーク」→「インターフェース」→「LAN」→「編集」を開き、静的IPv4アドレスと上位ゲートウェイを確認します。テーマによって項目名が多少異なる場合があります。バイパスルーターのLANインターフェースにある「DHCPサーバー」では、通常「このインターフェースを無視する」にチェックを入れ、主ルーターと同時にアドレスを配布しないようにします。管理用IPを変更する前に、有線接続を維持し、新しいアドレスを控えてください。

同一ネットワーク内に設置するシングルアーム型のバイパスルーターでは、送受信の両方が同じLANインターフェースを通る場合があります。LANとWANが別々のデュアルポートルーターとは異なり、戻りの経路も非対称になることがあります。送信元アドレス変換が必要か、ICMPリダイレクトをどう扱うかは、既存のファイアウォールと透過プロキシの構成に合わせて判断してください。他の機器向けのファイアウォールコマンドを、そのまま貼り付けるのは避けましょう。

バイパスルーター自身の上位ゲートウェイは、常に主ルーターを指定します。自分自身を指定してはいけません。正式に切り替える前に、主ルーターのDHCP設定は変更せず、テスト端末1台だけで確認してください。

カーネルとディレクトリ：アーキテクチャ、権限、設定パスを確認

まずSSHでハードウェアとファームウェアを確認します。uname -mでカーネルのアーキテクチャ、ubus call system boardで機種とシステム情報、df -hでストレージの空き容量を確認できます。mihomoのリリースファイルを選ぶ際は、CPU命令セットの要件も確認してください。どちらもx86_64の機器であっても、より新しい命令セットを必要とするビルドがすべて動くとは限りません。

uname -m
ubus call system board
df -h
free -m
ls -l /dev/net/tun

/dev/net/tunがない環境でも、明示的プロキシのテストは先に行えます。TUNを有効にする前に、必要なカーネルモジュールを準備してください。OpenWrtのカーネルモジュールはファームウェアのカーネルバージョンと一致している必要があります。異なるバージョンのものを無理にインストールしないでください。パッケージ管理ツールはopkgまたはapkの場合があるため、使用中のファームウェアに合わせます。

配置場所を3か所に固定する

/usr/bin/mihomo：展開後のカーネル実行ファイル。圧縮ファイルではありません。
/etc/mihomo/config.yaml：実際に読み込む設定ファイル。
/etc/mihomo/：作業ディレクトリ。設定から参照するルール、データベース、実行データを保存します。

アーキテクチャに合ったカーネルを指定のパスにアップロードしたら、実行権限を設定してバージョンを確認します。設定にはサブスクリプションURL、ノードのパスワードやトークンが含まれる場合があります。読み取り権限を適切に制限し、公開の掲示板などにそのまま貼り付けないでください。

mkdir -p /etc/mihomo
chmod 755 /usr/bin/mihomo
/usr/bin/mihomo -v
chmod 600 /etc/mihomo/config.yaml
/usr/bin/mihomo -t -d /etc/mihomo -f /etc/mihomo/config.yaml

最後のコマンドで設定を検証します。フィールドのエラーが表示されたら、ログを確認し、YAMLのインデントや非対応のパラメーターを修正してください。ルールファイルや地理データベースが見つからない場合は、該当するパスとダウンロード時の接続を確認します。設定の検証に通るのは、設定ファイルを読み込めることを示すだけです。ノード接続、DNS、透過プロキシが正常に動作する保証にはなりません。

まずは7890番ポートを開き、明示的プロキシとサブスクリプションを確認

次は、待ち受けと外部への直接接続を確認するための最小構成です。プロキシノードは含まれておらず、すべての接続をDIRECTとして処理するため、サブスクリプションのノードが使えるかは判断できません。まずこの設定で構築上の問題を切り分けてから、mihomoに対応していることを確認済みのサブスクリプション設定に置き換えてください。

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

rules:
  - MATCH,DIRECT

mixed-portは、同じポートでHTTPとSOCKS5のプロキシ接続を受け付けます。allow-lanを有効にすると、他の端末からもアクセスできます。待ち受けアドレスには、バイパスルーターが実際に持つアドレスを指定してください。ファイアウォールでTCP 7890へのアクセスを信頼できるLAN内に限定し、主ルーターでインターネット向けのポート転送を設定しないでください。

/usr/bin/mihomo -d /etc/mihomo -f /etc/mihomo/config.yaml

フォアグラウンドで実行すると、エラーを確認しやすくなります。SSH接続を開いたまま、テスト用パソコンから以下のリクエストを実行してください。curlが使えない場合は、OSまたはブラウザーのプロキシ設定にHTTPプロキシのアドレス192.168.10.2、ポート7890を入力します。

curl -I --proxy http://192.168.10.2:7890 https://example.com

対象サイトのHTTPレスポンスヘッダーが表示されれば、パソコンからバイパスルーターのプロキシに接続でき、カーネルから外部にも接続できています。次に実際の設定を読み込み、プロキシグループの参照名とルールの接続先が一致しているか確認し、対象への接続にどのルールが適用されたか検証します。サブスクリプションURLを含むテキストファイルをダウンロードできただけでは、そのまま実行できるYAML設定を取得したことにはなりません。

管理APIとプロキシポートは別の接続先です。この段階ではexternal-controllerを公開する必要はありません。後から管理パネルを接続する場合はsecretを設定し、管理ポートにアクセスできる範囲を制限してください。

透過プロキシ：ゲートウェイ、TUN、DNSをまとめて確認

明示的プロキシでの接続に成功したら、まずテスト用パソコンの手動プロキシを解除し、デフォルトゲートウェイを192.168.10.2に変更します。この操作で通信がバイパスルーターを経由するようになりますが、TUNのルートやファイアウォールの転送ルールがなければ、通信が自動的にmihomoに渡るわけではありません。「ゲートウェイを変更した」ことを、透過プロキシの成功の証拠にしないでください。

TUN方式で確認すべきこと

mihomoのtun.enableは仮想ネットワークデバイスを有効にし、auto-routeは関連するルートを自動設定します。auto-detect-interfaceは外部への通信に使うインターフェースを自動判別します。これらの設定ですべてのOpenWrtファイアウォール設定が不要になるわけではありません。特にLAN側の同じインターフェースで通信が出入りするバイパスルーターでは、転送許可、カーネル内の通信経路、除外先、戻りの経路も確認してください。

もう1つの方法は、redir-portまたはtproxy-portをファイアウォールと組み合わせることです。REDIRECTは主にTCPのリダイレクトに使い、TPROXYはTCPとUDPに対応しますが、ポリシールーティングの設定も必要です。最近のOpenWrtではfirewall4とnftables、古い解説ではfirewall3とiptablesが使われていることがあります。両者のルールを区別せずに混在させないでください。また、2つの方式で同じ接続を同時に処理しようとしないでください。

DNSの待ち受け先とDHCPの配布先を一致させる

よく使われる構成は、LANの53番ポートでdnsmasqにDNSを提供させ、mihomoのDNSを127.0.0.1:1053で待ち受けさせてから、dnsmasqの上流DNSをこのアドレスに転送する方法です。1053は内部転送用のポートで、スマートフォンなどにDNSサーバーとして直接指定するアドレスではありません。一般的な端末のDNS設定では、ポート番号を指定できません。

端末のDNSサーバーにバイパスルーターを指定する場合、バイパスルーターの53番ポートが実際にDNSリクエストへ応答することを確認してください。
dnsmasqからmihomoへDNSを転送する場合、mihomoの上流DNSを同じdnsmasq経由に戻すと、名前解決がループします。
fake-ipを有効にする場合は、DNSの応答とその後の接続が同じ通信制御経路を通るようにしてください。仮想IPアドレスを取得しても、通信がカーネルに渡らない状態を避けられます。
ブラウザーのセキュアDNS、アプリ内のDoH、DNSサーバーを直接指定するアプリは、OSのDNS設定を迂回することがあります。それぞれ個別に確認してください。

IPv6も別途設定が必要です。主ルーターがRAで配布するIPv6のデフォルトルートは、IPv4のゲートウェイを手動で変更しても消えません。設定内のipv6: falseは、LAN全体のIPv6を無効にはしません。検証段階ではテスト端末のIPv6を一時的に無効にして、確認範囲を絞る方法があります。正式に運用する場合は、IPv6のルーティング、DNS、通信の取り込み方針を明確にしてください。

自動起動：バックグラウンド実行ではなくprocdで管理

フォアグラウンドでの検証が終わったら、Ctrl+Cでテストプロセスを停止し、システムサービスを設定します。OpenWrtではprocdでサービスを管理します。SSHでコマンドの末尾に&を付けるだけでは、自動起動やプロセス監視の代わりになりません。以下の最小サービスはカーネルの起動のみを担当し、ファイアウォールルールの作成やサブスクリプションの定期更新は行いません。

以下の内容を/etc/init.d/mihomoとして保存します。同名のサービスがすでにある場合や、プラグインがカーネルを管理している場合は、管理元を確認してから作業してください。上書きは避けましょう。

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

START=99
STOP=10
USE_PROCD=1

start_service() {
    procd_open_instance
    procd_set_param command /usr/bin/mihomo \
        -d /etc/mihomo \
        -f /etc/mihomo/config.yaml
    procd_set_param respawn
    procd_set_param stdout 1
    procd_set_param stderr 1
    procd_set_param file /etc/mihomo/config.yaml
    procd_close_instance
}

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

サブスクリプションを更新する前に、前回正常に使えた設定を残してください。新しい内容を一時ファイルに保存し、mihomo -tで検証してから正式な設定ファイルに置き換え、サービスを再起動します。設定の構文が正しくてもノードが使えない場合は、元に戻す必要があります。自動更新で手動修正済みの設定を繰り返し上書きしないようにしてください。ルールセットやデータベースの更新、キャッシュにもフラッシュメモリーを使うため、空き容量を定期的に確認しましょう。

動作確認と切り戻し：1台で検証してから範囲を広げる

構築後は、以下の順に確認してください。管理画面の接続状態だけで判断してはいけません。各項目を確認してから次に進めば、「ネットにつながらない」原因を特定しやすくなります。

ルーター自身の外部接続：バイパスルーターから主ルーターに接続でき、名前解決とHTTPS接続ができることを確認します。
プロキシ接続：テスト用パソコンから192.168.10.2:7890経由でリクエストを送り、ログに該当する接続が記録されることを確認します。
DNS応答：nslookup example.com 192.168.10.2を実行し、応答したDNSサーバーが想定どおりであることを確認します。
透過プロキシ：明示的プロキシを解除した状態で対象サイトにアクセスし、mihomoに接続が記録され、想定したルールが適用されることを確認します。
LAN内通信の除外：主ルーターの管理画面、プリンター、NAS、ローカルサービスへの通信が、誤って遠隔プロキシに送られていないことを確認します。
再起動後の復旧：バイパスルーターを再起動して再テストし、サービス、DNS、転送経路が復旧することを確認します。前回手動で実行したコマンドに依存していてはいけません。

ルーター全体でインターネットに接続できなくなった場合は、まずテスト用パソコンのゲートウェイとDNSを元の主ルーターの設定に戻し、手動プロキシを解除します。その後mihomoを停止してください。nftables、ポリシールーティング、DNS転送を手動で追加していた場合は、それらの変更も個別に元に戻す必要があります。カーネルを停止しても、外部に設定した通信制御ルールが自動で消えるわけではありません。

1台の端末で安定動作を確認してから、DHCPでバイパスルーターのゲートウェイとDNSを配布することを検討してください。DHCPでは通常、ゲートウェイがオプション3、DNSがオプション6に対応します。設定を配布した後、端末側でリースを更新しないと反映されない場合があります。バイパスルーターがネットワーク全体の必須経路になると、電源オフやアップデートも端末に影響します。主ルーターの管理手段と、明確な復旧手順を残しておきましょう。

この構築方法で重要なのは、一度にすべてのパラメーターを設定することではなく、カーネル、明示的プロキシ、DNS、通信転送を個別に確認することです。ルールやサブスクリプションの基本を確認する場合はサブスクリプションのインポート手順から始めてください。設定項目を確認するときは設定ガイドを参照し、複数の層の設定を同時に変更しないようにしましょう。