導入前に確認すること：コアの起動、通信の振り分け、端末のゲートウェイ

OpenWrtでmihomoを起動しただけでは、ルーター上でプロキシコアのプロセスが動いているにすぎません。スマートフォン、テレビ、PCの通信を通すには、通信の入口とルーティング、DNSの設定が必要です。設定ファイルを読み込めた、管理画面を開けたというだけでは、LAN内の通信がすでに振り分けられているとは判断できません。

mihomoはClash Metaの設定体系を引き継ぎ、プロキシプロトコル、ルール判定、接続処理を担います。OpenWrtはインターフェース、ルーティング、ファイアウォール、サービス管理を担当します。LuCIプラグインで操作を画面上にまとめられますが、プラグイン、コア、購読設定はそれぞれ別々に更新されるものです。

  • 明示的プロキシ：端末やアプリにプロキシサーバーのアドレスとポートを設定します。まず設定を検証するのに適していますが、プロキシ設定に従わないアプリの通信は自動的にコアへ送られません。
  • 透過プロキシ：ルーターのファイアウォールとポリシールーティングで通過する通信を振り分ける方式です。通常、端末ごとにHTTPプロキシを設定する必要はありません。
  • TUN：仮想ネットワークインターフェースを介してIP通信を処理します。システムのルーティング、ファイアウォールの転送、ループ防止の設定も必要です。

メインルーターとバイパスルーター：実際の通信経路を確認する

メインルーターに導入する

メインルーターはインターネットへの出口を担い、LAN内端末のデフォルトゲートウェイにもなっているのが一般的です。端末の通信はもともとこのルーターを通るため、透過的な振り分けを一元化しやすい反面、コアの再起動、ルールの再読み込み、DNS設定の誤りによる影響も大きくなります。すべての接続を一度に振り分けるのではなく、通常の出口と管理用アドレスを例外として確保することが重要です。

同一サブネットにバイパスルーターを設置する

以下はネットワーク構成を説明するための例であり、実測値ではありません。メインルーターを192.168.10.1、バイパスルーターを192.168.10.2、テスト用PCを192.168.10.100/24とします。バイパスルーターの上流デフォルトルートはメインルーターを向き、テスト用PCのデフォルトゲートウェイはバイパスルーターを向きます。

対象設定例確認事項
メインルーター192.168.10.1上流への出口を担当。初期設定では既存のDHCPサービスを維持
バイパスルーター192.168.10.2/24上流ゲートウェイを192.168.10.1に設定し、必要な通信転送を許可
テスト用PC192.168.10.100/24デフォルトゲートウェイを192.168.10.2に設定し、設定済みのDNS入口を指定

バイパスルーターと端末が同じサブネットにある場合、直接接続の戻り通信がメインルーターから端末へ直接返され、経路が非対称になることがあります。SNATが必要か、ICMPリダイレクトをどう扱うかは、コネクショントラッキングと実際のルーティングを確認して判断してください。どの構成でも「NATを有効にすればよい」とは限りません。デュアルNIC構成や独立した下流サブネットを使うバイパスルーターは、一般的なルーターに近く、経路も比較的明確です。

  • 端末のDNSだけをバイパスルーターに変更しても、アプリの通信までバイパスルーターに送られるわけではありません。
  • DHCPでゲートウェイとDNSを配布する場合、IPv4オプションは通常それぞれ3と6です。設定変更後は、クライアント側でリースを更新してください。
  • 同じブロードキャストドメインで計画なく2台目のDHCPサーバーを有効にすると、端末によって異なるゲートウェイが割り当てられることがあります。
  • IPv6のデフォルトルートは通常、ルーター広告によって通知されます。IPv4のゲートウェイだけを変更しても、IPv6の通信経路は自動的には切り替わりません。

構成とシステムを確認する：実行可能なmihomoを選ぶ

ダウンロード前に、OpenWrtのバージョン、CPUアーキテクチャ、空きストレージを確認します。OpenWrt 23.05および24.10の一般的な公式イメージではfirewall4とnftablesが使われます。サードパーティ製ファームウェアでは構成要素が変更されている場合があるため、ファームウェア名だけでスクリプトを選ばず、実際の環境を確認してください。

ubus call system board
uname -m
opkg print-architecture
df -h /overlay /tmp
free -m
command -v fw4
command -v nft
test -c /dev/net/tun && echo "TUN device available"

上記のopkgコマンドは、opkgを使うファームウェア向けです。別のパッケージマネージャーを使う場合は、そのファームウェアの説明に従って確認してください。uname -mで表示されるのは実行環境のアーキテクチャです。CPUの命令セットやリリース資産の説明も別途確認する必要があります。

  • x86_64：amd64系に該当します。ただし最適化ビルドによって必要なCPU命令セットが異なる場合があるため、古いルーターでは配布ファイルの要件を確認してください。
  • aarch64：通常はarm64に相当します。ハードウェアが64ビットに対応していても、ファームウェアが32ビット環境で動作している場合は、実際のシステムに合わせて選んでください。
  • ARM、MIPS：ARMの世代や浮動小数点演算の要件、MIPSのエンディアンも確認が必要です。製品説明にあるチップ系列だけで判断しないでください。
  • ストレージとメモリ：コア、ルールセット、地理情報データベースには容量が必要です。/tmpは通常メモリ上にあり、再起動すると内容は保持されません。

Exec format errorが出た場合は、まずアーキテクチャを確認します。Illegal instructionが出た場合は、必要な命令セットを確認してください。ファイルが存在するのに実行できない場合は、ローダーや権限が原因の可能性もあります。購読設定の無効化と決めつけないでください。

導入方法：LuCIプラグイン、単独プロセス、コンテナ

方法1：LuCIプラグインで一元管理する

購読の更新、起動時の自動起動、透過プロキシのルール連携が必要な環境に適しています。現在のOpenWrtのファイアウォール体系とmihomoに対応していることを確認し、プラグインのバージョンに合ったドキュメントを読んでください。メニューや設定の上書き方法、コアの更新経路はプラグインごとに異なるため、別のプラグインの手順をそのまま適用することはできません。

プラグインは通常、最終的な設定ファイルを生成します。生成後のファイルを手動で編集すると、次回の購読更新やサービス再起動で変更が上書きされることがあります。プラグインが用意する永続的な上書き機能を使い、ポートを奪い合う2つ目の独立したコアを起動しないようにしてください。

方法2：バイナリとprocdサービスを個別に管理する

実行パラメーターやファイアウォールルールを明確に管理したい場合に適しています。ここではコアを/usr/bin/mihomo、データディレクトリを/etc/mihomoに置く例を使います。これらは本記事の例であり、すべてのプラグインの標準パスではありません。確認済みの設定ファイルを配置してから、まずフォアグラウンドで実行してエラーを確認してください。

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

-tは設定ファイルのテストに使います。テストに成功しても、DNS、通信の出口、転送設定の検証は必要です。フォアグラウンドで安定して動作することを確認した後、/etc/init.d/以下にprocdサービスを作成し、起動コマンド、標準出力、異常終了時の再起動、停止時の後処理を設定します。バックグラウンドコマンドを繰り返し実行してサービス管理の代わりにすると、複数プロセスや古いルールが残りやすくなります。

方法3：コンテナ内で実行する

コンテナは、すでにコンテナ管理環境を使っているルーターに適していますが、ネットワーク名前空間、データボリューム、権限境界の管理が追加で必要です。TUNを使うには、コンテナから対象デバイスにアクセスでき、必要なネットワーク管理権限が付与されている必要があります。透過プロキシのルールをホスト側とコンテナ側のどちらに設定するかも明確にしてください。7890ポートを公開するだけでは、通常は明示的プロキシを提供するにとどまり、LAN全体の通信は自動的に振り分けられません。

透過プロキシとTUN：通信を振り分ける方式を決める

透過プロキシは通信を振り分ける目的を指し、TUNはその実現方法の一つです。ほかによく使われる方法としてREDIRECTやTPROXYがあります。REDIRECTはTCPのリダイレクトに使われることが多く、TPROXYはTCPとUDPに対応しますが、ポリシールーティング、パケットマーク、対応するカーネルモジュールが必要です。どの方式を選ぶかは、プラグインの対応状況、ファームウェアの構成、ネットワークトポロジーに応じて決めてください。

通信の入口必要なシステム設定主な確認項目
明示的なHTTP / SOCKSプロキシアプリにプロキシアドレスを設定プロキシを迂回するアプリがないか。UDPの対応状況は別途確認
REDIRECT / TPROXYファイアウォールルールを設定し、必要に応じてポリシールーティングを構成TCP・UDPの振り分け範囲、markの競合、ループの除外
TUNTUNデバイス、ルーティング、転送ルールインターフェースが作成されるか、通信がインターフェースに入るか、DNSが適切に処理されるか

TUNを使う前に、LuCIの「システム」→「ソフトウェア」で、現在のカーネルに合ったkmod-tunがインストールされているか確認し、/dev/net/tunも確認してください。カーネルバージョンの異なるファームウェア間でモジュールを安易に使い回すことはできません。デバイスファイルが存在するのは基本条件を満たすというだけで、後続のルーティングが正しく設定されているとは限りません。

  • ルーティングを担当するコンポーネントを明確にしてください。プラグインが通信振り分けルールを生成する場合、別の設定を流用して自動ルーティングまで有効にしないでください。
  • コア自身のプロキシ出口への接続、ルーターの管理用アドレス、上流ゲートウェイ、必要なLANサブネットを除外し、通信がコアに繰り返し入るのを防ぎます。
  • LuCIの「ネットワーク」→「ファイアウォール」でゾーンと転送関係を確認してください。ルールの誤りを全体許可で覆い隠さないでください。
  • トラブルシューティングでは、ソフトウェアまたはハードウェアのフローオフロードを一時的に無効にして再テストしてください。オフロードによって後続のパケットが通る経路が変わることがあります。

DNSの振り分け：待ち受けポート、上流DNS、Fake-IP

OpenWrtでは、LAN向けDNSをdnsmasqが提供する構成が一般的です。わかりやすい構成例として、端末からルーターの53番ポートへ送られたリクエストのうち、コアに渡すものをdnsmasqからローカルの127.0.0.1:1053へ転送します。dnsmasqによるローカルホスト名の処理を維持できますが、実際の設定を確認し、コアの問い合わせが自身に再転送されるループを防いでください。

以下はmihomoのDNS設定部分だけを示したもので、ルーターでそのまま動作する完全な設定ではありません。ポートの関係を説明するため一般的な上流DNSを使っています。実際の導入時は、ネットワーク到達性、プライバシー要件、プロキシサーバーのドメインを解決する方法に応じて上流DNSを選んでください。

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - 223.5.5.5
    - 119.29.29.29
  1. 53番ポートの入口を一つに決めます。dnsmasqがLAN向けの53番ポートを待ち受けている場合、mihomoを同じアドレスとポートにバインドしないでください。
  2. 転送を設定します。LuCIの「ネットワーク」→「DHCP/DNS」にあるDNS転送先には、dnsmasqのアドレス形式で127.0.0.1#1053を指定できます。上流から配布されたDNSサーバーを引き続き使用する設定になっていないかも確認してください。
  3. ループを防ぎます。mihomoの上流DNSをdnsmasqの入口に戻してはいけません。プロキシサーバーのドメインにも、最初の名前解決に使える経路が必要です。
  4. 実際の問い合わせ経路を確認します。従来のDNSではUDPとTCPの両方で53番ポートが使われます。アプリ内蔵のDoHはHTTPSを使うため、53番ポートをリダイレクトしても同じDNS経路には自動的に入りません。

Fake-IPは対応するアドレスを返し、コアはその対応関係を使ってドメインを特定します。端末が198.18.0.0/16のアドレスを受け取っても、そのアドレス帯を振り分けないゲートウェイに通信を送ると、「名前解決はできるのにウェブサイトが開かない」状態になります。Fake-IP、DNSの配布、通信の入口をセットで検証してください。

プリンター、画面ミラーリング、LAN内の名前解決に依存するアプリは別途テストしてください。必要に応じてFake-IPの対象を適切に除外し、ローカルドメインの名前解決ルールを設定します。IPv6のDNS配布、AAAAレコードの応答、通信の出口もあわせて確認してください。IPv4のテストが成功しただけで、すべての通信が振り分けられていると判断しないでください。各項目の説明は完全ガイドのDNSセクションとFake-IP用語解説をご覧ください。

検証の手順：設定テストからLAN端末の接続まで

手順を固定すると、ルール、DNS、ファイアウォールを同時に変更せず、問題のあるレイヤーを特定しやすくなります。以下のポート番号は本記事の例です。明示的な混合プロキシは7890、コアのDNSは1053、必要に応じて管理インターフェースは127.0.0.1:9090に制限できます。

  1. コア：設定テストを実行し、ログを確認します。独立したprocdサービスではlogreadで起動エラーを確認できます。プラグインの場合は、まずプラグインのログ画面を使ってください。
  2. 待ち受け：ssがインストールされている場合はss -lntupを実行します。ない場合はファームウェアに付属する同等のツールを使い、7890や1053などのポートについて待ち受けアドレスとプロトコルを確認してください。
  3. 明示的プロキシ：LANからのアクセスを許可し、ファイアウォールで接続元を制限したうえで、テスト用PCからバイパスルーターの7890番ポート経由でウェブサイトにアクセスします。まず購読設定と通信の出口が使えることを確認してください。
  4. DNS：テスト用PCから想定するDNS入口へ問い合わせ、コアのログと応答を確認します。名前解決のタイムアウト、Fake-IPの正常な応答、上流DNSへのループを切り分けてください。
  5. ルーティング：テスト用PCの明示的プロキシを無効にし、テスト用のゲートウェイとDNSだけを設定した状態で、通信が引き続きコアに入るか確認します。ルーター上ではip route show、ip rule showと関連するルーティングテーブルも確認してください。
  6. プロトコル：通常のウェブ閲覧、動画、UDPを使うアプリ、IPv6接続を個別に確認します。TCPで接続できても、UDPやIPv6が同じ経路を通るとは限りません。

端末から明示的プロキシの接続をテストする場合は、curlがインストールされており、バイパスルーターで上記の例のとおりLAN向けプロキシ入口が実際に公開されている必要があります。例のURLはテスト対象であり、プロキシルールに一致するとは限りません。

curl --proxy http://192.168.10.2:7890 --connect-timeout 10 -I https://example.com/
nslookup example.com 192.168.10.2

グローバルIPアドレスが変わったかどうかだけで判断しないでください。ルールモードでは、対象によってはもともと直接接続される場合があります。接続ログに記録された宛先、適用ルール、プロキシグループ、最終的な出口をあわせて確認してください。ルーターのスループットに一律の「標準値」はありません。暗号化プロトコル、CPUのシングルコア性能、MTU、回線品質、ログ量などが結果に影響します。同じ端末と同じ接続先で、直接接続とプロキシ接続を比較してください。

安定運用：更新、権限、障害時の復旧

  • 設定の更新：購読を更新したら、設定の構文とリソースの読み込みを確認してから現在の設定を置き換えます。直前まで動作していた設定を残し、永続化する変更はプラグインの上書き機能か、個別に管理するファイルに保存してください。
  • コアの更新：新しいコアが現在の設定項目、ルール、起動パラメーターに対応しているか確認し、更新後に設定テストを再実行します。購読の更新はプログラムの更新の代わりにはなりません。
  • 管理インターフェース：管理インターフェースは、できる限りループバックアドレスにバインドしてください。LANからのアクセスが必要な場合は認証情報を設定して接続元を制限し、WAN側ではプロキシや管理用ポートを公開しないでください。
  • ストレージ管理：デバッグログを大量に生成してフラッシュメモリへ長期間書き込み続けないようにしてください。ルールリソースの更新ではダウンロード失敗と空き容量を考慮し、唯一の設定ファイルを一時ディレクトリに置かないでください。
  • 停止時の後処理：サービス停止時に、そのサービスが作成した通信振り分けルール、ルート、DNS転送を解除します。プロセス停止後も通信が無効な入口へ送られ続けるのを防ぎます。

問題が起きたら、まずテスト端末のゲートウェイとDNSを元の値に戻し、その後でバイパスルーターの通信振り分けを解除してください。メインルーターに導入した場合は、あらかじめ用意したサービス停止とルール復旧の手順を使います。障害発生後に途絶したリモート接続に頼るより、ローカルの有線接続で管理できる状態を保つほうが確実です。

1台のPCだけで購読を使いたい場合は、まずデスクトップクライアントで設定を検証し、その後でルーターによる通信の振り分けを検討できます。ルーターへの導入で重要なのはコアのファイルをコピーすることではなく、通信の入口、名前解決、プロキシの出口、戻りの経路を整合させることです。