OpenWrtルーターでmihomoを動かす方法｜メインルーター・バイパスルーターの構成

構成を決める：ゲートウェイ経路を整理してから通信の取り込み方を選ぶ

OpenWrtでmihomoを動かすには、カーネルをどの機器で実行するか、LAN内の通信をどうカーネルに流すかの2点を決める必要があります。分けて考えることで、設定ファイル、DNS、ルーティング、ファイアウォールのどこに問題があるか判断しやすくなります。

mihomoはClash Metaプロジェクトで引き続き使われているカーネル名です。設定を読み込み、ルールを照合して、通信の出先を選択します。LuCI管理プラグインは管理レイヤーにあたり、通常は設定の生成、ファイアウォールルールの導入、プロセス管理も担います。カーネルをルーターにコピーしただけでは、家庭内の全端末の通信は自動的に取り込まれません。

ハードウェア選び：命令セット、メモリ、ストレージを確認

まずOpenWrtのSSHターミナルでシステム情報を確認し、対応するLinuxカーネルファイルを選びます。ルーターの外装に記載された型番や、プロセッサの宣伝上の名称からアーキテクチャを推測しないでください。同じシリーズでも搭載チップが異なる場合があります。

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

• x86_64は通常amd64に相当しますが、配布ファイルが要求するCPU命令セットのレベルも確認が必要です。古いプロセッサでは、新しい最適化ビルドが動作しないことがあります。
• aarch64は通常arm64に相当します。32ビットARMの場合はARMのバージョンと浮動小数点演算への対応も確認してください。arm64用ファイルをそのまま使うことはできません。
• MIPS機器ではエンディアンとビルド要件を確認してください。OpenWrtのパッケージアーキテクチャ名と、上流のバイナリファイル名が完全に一致するとは限りません。
• /tmpは通常メモリ上のファイルシステムにあり、再起動すると内容が消去されます。ダウンロード、展開、ログの出力にも利用可能なメモリが必要です。空きフラッシュ容量を空きメモリと混同しないでください。

必要な容量は実際の負荷で判断

サブスクリプションのノード数、ルールセットのサイズ、接続数、DNSキャッシュ、ログレベルは、いずれもメモリ使用量に影響します。一定のメモリ容量があれば必ず動作する、とは言い切れません。実際の設定を読み込んで動作を確認してから、自動起動を設定してください。大規模なルールセットでは、ダウンロード用の空き容量や永続ストレージも必要になる場合があります。

プロセスが起動直後に終了する場合は、logreadでメモリ不足やプロセス終了の記録を確認してください。Exec format errorが出たら、まずアーキテクチャとアーカイブの展開状況を確認します。Illegal instructionの場合は、CPU命令セットとの互換性を重点的に調べてください。

カーネルと設定：ファイルを検証してからサービス管理へ

以下は手動導入時の例です。カーネルを/usr/bin/mihomoに置き、作業ディレクトリを/etc/mihomo、メイン設定ファイルを/etc/mihomo/config.yamlにします。LuCI管理プラグインを導入済みの場合は、プラグイン指定のカーネル配置先と設定画面を使い、別のインスタンスを追加起動しないでください。

手動導入時の確認手順

1. 既存のネットワーク、ファイアウォール、DNS設定をバックアップし、有線接続でルーターに再アクセスできることを確認します。
2. アーキテクチャに合った展開済みのカーネルを/tmp/mihomoにアップロードします。既存の正常な設定を上書きしないよう、設定ファイルは別に用意してください。
3. 配置先に十分な空き容量があることを確認してから、カーネルをコピーし、実行権限を付与します。
4. まずバージョン確認と設定テストを実行します。テストに成功したら、フォアグラウンドで起動してログを確認してください。

mkdir -p /etc/mihomo
cp /tmp/mihomo /usr/bin/mihomo
chmod 755 /usr/bin/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

実行前にconfig.yamlが存在することを確認してください。-vは実際のバージョン確認、-tは設定ファイルのテストに使います。テストに成功しても、上流ノードへの接続やLAN内通信の取り込みが確認できたわけではありません。設定によってはルールセット、地理データ、外部ファイルも必要です。初回テストに失敗した場合は、作業ディレクトリとダウンロードログも確認してください。

最小限の直接接続設定：プロセスと待ち受けを確認

以下は単独でテストするためのファイルで、プロキシノードは含まれていません。すべての接続は最終的に直接接続されます。YAML、ポート、プロセス起動の問題を切り分けるためのもので、プロキシ経由の通信確認には使えません。

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

external-controller: "127.0.0.1:9090"

dns:
  enable: true
  listen: "127.0.0.1:1053"
  enhanced-mode: redir-host
  nameserver:
    - 223.5.5.5

rules:
  - MATCH,DIRECT

7890はこの例のHTTP/SOCKS混合ポート、9090はコントローラー、1053はDNSの待ち受けポートです。それぞれ用途が異なり、相互に置き換えることはできません。フォアグラウンドでの確認後は、管理プラグインまたはOpenWrtのprocdで起動、停止、再起動を管理してください。同じカーネルをプラグイン、自作サービス、バックグラウンドコマンドから重複起動しないでください。

メインルーターで実行：通信の一括取り込みとDNSの連携

メインルーターに導入する利点は、端末の通信がもともとこの機器を経由するため、端末ごとにゲートウェイを変更しなくてよいことです。一方、ファイアウォールやDNSの設定を誤ると、LAN全体に影響するおそれがあります。まずテスト端末1台またはテスト用サブネットに限定し、問題がなければ段階的に範囲を広げてください。

まずLuCIで既存設定を確認

• 「ネットワーク」→「インターフェース」→「LAN」→「編集」を開き、LANのIPアドレスとサブネットマスクを記録します。
• LANの「DHCPサーバー」でアドレスプールとDHCPオプションを確認し、別の機器が競合するゲートウェイを配布していないことを確かめます。
• 「ネットワーク」→「ファイアウォール」を開き、LANからWANへの既存の転送設定が誤って削除されていないことを確認します。
• 「ステータス」→「システムログ」で、カーネルとDNSサービスのログを確認します。ファームウェアの翻訳やテーマによって、メニュー名が多少異なる場合があります。

よくあるDNS経路では、端末からルーターの53番ポートに問い合わせ、dnsmasqがmihomoのローカル1053番ポートへ転送します。この場合、上流への転送先がdnsmasq自身に戻っていないか確認してください。DNSのループが発生するおそれがあります。dns.listenを設定しただけでは端末が自動的にそのポートを使うようにはなりません。転送または通信の取り込みルールも明示的に設定する必要があります。

バイパスルーターをゲートウェイにする：端末1台で往路と復路を確認

シングルポートのバイパスルーターは、メインルーターと同じサブネットに置く構成がよくあります。例では、メインルーターを192.168.50.1/24、バイパスルーターを192.168.50.2/24、テスト端末を192.168.50.100/24としています。これらはネットワーク構成の例です。導入時には、既存のDHCPアドレスプールとの重複やIPアドレスの競合を避けてください。

1. バイパスルーターのLANアドレスを192.168.50.2に固定し、デフォルトの上流ゲートウェイを192.168.50.1に設定します。
2. 同じブロードキャストドメインでアドレス配布が競合しないよう、DHCPはひとまずメインルーターだけで有効にします。
3. テスト端末1台のデフォルトゲートウェイを、手動で192.168.50.2に変更します。
4. バイパスルーターがLAN向けDNSサービスを提供している場合は、テスト端末のDNSも192.168.50.2に設定します。提供していない場合は、まずルーティングだけを検証してください。
5. バイパスルーターで必要な転送が許可されているか、直接接続する通信の戻り経路が設計どおりか確認します。

このように同一サブネットに配置すると、直接接続の通信がバイパスルーターからメインルーターへ転送され、応答だけがメインルーターから端末へ直接返る非対称経路になることがあります。送信元アドレス変換、メインルーターの静的ルート、サブネットの分割が必要かどうかは、ファイアウォールのコネクション追跡とネットワーク構成を踏まえて判断してください。「バイパスルーターではNATを必ず無効にする／有効にする」と一律に決めることはできません。

ゲートウェイとDNSを個別に検証

ゲートウェイの変更で決まるのはIPパケットの次の転送先です。DNS問い合わせもバイパスルーターを通るとは限りません。ブラウザーの暗号化DNS、端末に固定されたDNS、IPv6のルーター広告によって別経路になる場合があります。まずテスト端末が実際に取得したIPv4ゲートウェイ、IPv6デフォルトルート、DNSアドレスを確認し、そのうえで通信を取り込む必要があるか判断してください。

1台での検証が済んでから、メインルーターのDHCPでオプション3を使ってIPv4デフォルトゲートウェイ、オプション6を使ってDNSを配布することを検討します。家庭用ルーターの中には配布内容を細かく設定できない機種もあります。その場合は、全端末を一度に切り替えるより、手動設定またはテスト用サブネットを使うほうが元に戻しやすくなります。

透過プロキシ：REDIRECT、TPROXY、TUNの違い

明示的なプロキシでは、アプリから7890などのポートへ接続します。透過プロキシでは、ルーティングとファイアウォールによって元の通信をカーネルに転送します。両方を併用できますが、複数のルールで同じ接続を重複して取り込まないようにしてください。

OpenWrt 22.03以降の一般的な初期環境では、firewall4とnftablesが使われます。古い解説にあるiptablesルールを確認せずに新しい環境へ貼り付けないでください。実際のファームウェアが独自のファイアウォールバックエンドを使っていないか、必要なモジュールが導入済みかも確認します。

TUNを有効にしてもLANの通信を取り込めるとは限らない

tun.auto-routeは関連ルートを自動設定する項目ですが、実際の動作はシステム、バージョン、ネットワーク構成によって異なります。この項目だけを見て、転送通信がすべてTUNに流れると判断しないでください。tun.auto-redirectにもプラットフォームとバージョンの条件があり、すべてのLinux環境でそのまま使えるわけではありません。ルーターでプラグインが通信取り込みルールを管理している場合は、ルールの生成をプラグインに統一し、手書きルールを重ねないでください。

• ルーターの管理用アドレス、必要なローカルサブネット、カーネルから上流プロキシサーバーへの接続を除外し、通信ループを防いでください。
• fake-ipを使う場合は、DNSが返す仮想アドレス範囲に対応するルートと通信経路があることを確認してください。設定されていないと、名前解決は成功しても接続に失敗します。
• UDPを使うアプリでは、入口の方式、ノードのプロトコル対応、サーバー側の機能をすべて確認してください。TCPのWebサイトが開けても、UDPが正常とは限りません。
• IPv4とIPv6はそれぞれ個別に確認してください。IPv4の透過プロキシを設定しても、IPv6接続が自動的に対象になるわけではありません。

LAN端末の接続：まず明示的なプロキシで確認し、次にルールを検証

本格的に通信を取り込む前に、端末1台で明示的なプロキシを使い、ネットワーク転送の問題を切り分けます。テスト設定の7890番ポートをLANに公開するには、allow-lanをtrueにし、bind-addressを実際のLANアドレス（例："192.168.50.2"）に設定します。ファイアウォールでは、信頼できるサブネットからの接続だけを許可してください。

プロキシポートやコントローラーをWAN側のポート転送で公開しないでください。external-controllerは通常、ローカルからの接続だけを受け付ける設定にすると、アクセスを制御しやすくなります。リモート管理が必要な場合は、強固なsecretを設定し、接続元も制限してください。コントローラーの認証と混合プロキシポートの認証は別の設定であり、互いに代用できません。

レイヤーごとに問題を切り分ける

1. プロセス：設定テストが成功し、カーネルが継続して動作していること、同じポートを使う別プロセスがないことを確認します。
2. 接続入口：端末からLANアドレスのプロキシポートへ接続できることを確認します。接続拒否なら待ち受けアドレス、タイムアウトならファイアウォールと通信経路を優先して調べてください。
3. 外向き通信：実際に使えるノードとプロキシグループを設定し、認証、プロトコル、上流への接続を確認します。先ほどの直接接続テスト用ファイルでは、プロキシ経由で通信できません。
4. ルール：mode: ruleになっていることを確認し、ログで適用されたルールと出力先のポリシーを調べます。ルールは上から順に照合されるため、フォールバックルールを早く置きすぎると、後続のルールが適用されません。
5. 通信の取り込み：明示的なプロキシは使えるのに透過プロキシが使えない場合は、DNS、ポリシールーティング、ファイアウォール、IPv6を優先して調べてください。サブスクリプションを何度も入れ替えるのは避けましょう。

カーネルのリソース使用量とノードの通信速度も分けて考えます。Webページの最初の応答が遅い場合はDNSや接続確立が、大容量ファイルの転送が遅い場合はCPU、暗号化処理、回線速度、混雑が影響している可能性があります。発生時刻、テスト端末、接続先、適用されたポリシーを記録しておくと、「バイパスルーターが遅い」とだけ記録するより再現しやすくなります。

更新とロールバック：正常に動作する設定と独立した管理経路を確保

サブスクリプションの更新、カーネルのアップグレード、ファイアウォールの変更は、分けて実施してください。サブスクリプション更新でノード、プロキシグループ、ルールが上書きされることがあります。管理プラグインも起動時に実行設定を再生成する場合があります。継続して使う変更は、一時生成ファイルを直接編集せず、プラグインが対応する上書き設定やカスタムルールの入力欄に記述してください。

• アップグレード前にmihomo -vの出力を記録し、動作中のカーネル、メイン設定ファイル、カスタムルールを保管します。
• 古いプロセスを停止してからバイナリを置き換え、設定テストの後にサービスを起動してください。実行中のファイルを直接上書きしないでください。
• logreadで起動結果を確認し、ルール用のデータが読み込まれたことを確かめてから、DNS、TCP、使用するUDPアプリを検証します。
• 管理アドレスに直接接続できる端末を1台確保してください。バイパスルーターに問題が起きたら、テスト端末のゲートウェイとDNSを元のメインルーターに戻します。DHCPの配布設定を変更した場合は、オプションも元に戻し、端末にリースを再取得させてください。

パソコンやスマートフォン1台でプロキシを使いたいだけなら、まず対応するプラットフォームのクライアントを使うほうが設定の手間を抑えられます。テレビ、ゲーム機、複数の端末をまとめて管理する場合に、ゲートウェイ、DNS、透過プロキシをルーターへ移行しましょう。YAMLの基本構造やルールの順序については、設定ファイルの構造とルール設定項目の解説をご覧ください。