2026-09-09 プラットフォーム読了時間：約12分

OpenWrtのバイパスルーターでmihomoを動かす方法：構成と透過プロキシの概要

OpenWrtのルーターやバイパスルーターでmihomoを動かす構成を解説。アーキテクチャ、設定ファイルの配置、TProxyとRedirの違い、ゲートウェイ設定を紹介します。

バイパスルーターの構成：まず通信経路を確認

OpenWrtでmihomoを動かすには、コアのプロセス、通信の取り込み、DNSをそれぞれ設定する必要があります。コアはconfig.yamlを読み込み、rulesに従って通信先を選択します。Linuxのルーティングとファイアウォールは、どのパケットをコアに渡すかを決めます。DNSは端末へのアドレス配布と、ドメイン名に基づく振り分けの可否を左右します。プロセスを起動しただけでは設定の一部にすぎず、LAN全体で透過プロキシが有効になったわけではありません。

ここでは、単一のネットワークポートを使い、同一セグメントに設置するバイパスルーターを例に説明します。以下のアドレスは構成を説明するための例です。実際のネットワークに合わせて変更し、アドレスが重複しないことを確認してください。

機器	アドレス例	役割
メインルーター	`192.168.10.1/24`	インターネットに接続し、DHCPサービスを維持
OpenWrtバイパスルーター	`192.168.10.2/24`	mihomoを実行し、転送とDNSを処理
テスト用PC	`192.168.10.100/24`	まず単体で動作を確認し、すぐにネットワーク全体の設定は変更しない

テスト用PCのIPv4デフォルトゲートウェイを192.168.10.2に設定し、バイパスルーターのデフォルトルートはメインルーター192.168.10.1を向くようにします。互いをゲートウェイに指定してループさせないでください。バイパスルーターではIPv4転送を有効にし、必要なインターフェース間またはファイアウォールゾーン間の転送を許可します。これは、バイパスルーター自身に届く入力ポートを開放する設定とは別です。

コアのアーキテクチャと設定ディレクトリ

CPU、OS、実行環境を確認する

まずSSHでシステム情報を確認し、対応するLinux用コアを選びます。通常、x86_64はamd64、aarch64はarm64に相当します。32ビットARMでは命令セットと浮動小数点ABIも確認してください。ルーターの商品名だけで判断せず、OpenWrtのパッケージ用アーキテクチャ名をコアのリリースファイル名としてそのまま使わないでください。

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

amd64版を選ぶ場合は、リリースノートに記載されたCPU命令セットの要件も確認します。起動時にIllegal instructionが出た場合は、機器の性能を超えるビルドを選んでいないか確認してください。Exec format errorの場合は、まずアーキテクチャとファイル形式を確認します。Permission deniedの場合は、実行権限とマウントオプションを調べてください。サブスクリプションの内容が原因と決めつけないようにしましょう。

永続ファイルと一時ログを分けて保存する

個別に導入する場合、コアを/usr/bin/mihomo、設定ディレクトリを/etc/mihomo、メイン設定ファイルを/etc/mihomo/config.yamlに置く構成にできます。これらは本記事で使用するパスであり、すべてのOpenWrt管理プラグインの標準パスではありません。管理プラグインをすでに使っている場合は、同じ管理機能でプロセスとファイアウォールを管理し、別のインスタンスを起動しないでください。

/etc/mihomo/config.yaml：メイン設定を保存します。サブスクリプションURLや認証情報を含む場合は、読み取り権限を制限してください。
/etc/mihomo/providers/：設定から参照するproviderファイルを保存できます。具体的な相対パスは各フィールドの指定に従います。
/tmp/：一時的な診断ファイルの保存に適しています。通常は再起動後に消えるため、唯一の設定ファイルの保存先には向きません。
ルールセットと地理データ：実際の設定に合わせて用意してください。まずフラッシュ容量とメモリを確認し、すべてのデータソースを有効にするのは避けましょう。

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

上記のコマンドは、コアと設定ファイルを所定のパスに配置済みであることを前提としています。-tは設定の検証に使いますが、ノードへの接続やファイアウォールによる通信の取り込みまでは確認できません。検証に通ったらフォアグラウンドで実行し、起動ログを確認します。常時稼働させる場合は、OpenWrtのprocdでプロセスを管理してください。SSHセッション内で一時的にバックグラウンド起動する方法には頼らないでください。

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

まずmixed-portを確認し、その後に透過プロキシを設定する

まずテスト用PCで明示的プロキシを使い、サブスクリプション、アウトバウンド、ルールの問題を切り分けます。以下は待ち受けを確認するための最小限の設定例です。プロキシノードは含まず、最後のルールですべて直接接続します。プロセス、ポート、リクエスト経路の確認専用です。プロキシ経由の通信を検証するには、有効な設定を使い、proxies、proxy-providers、proxy-groups、rulesで参照する名前が一致しているか確認してください。

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

rules:
  - MATCH,DIRECT

mixed-port: 7890はHTTPとSOCKSのプロキシポートを提供します。allow-lan: trueで他の機器からの接続を許可し、bind-addressで待ち受けアドレスを指定します。このアドレスはバイパスルーターに設定済みである必要があります。OpenWrtのファイアウォールでは、信頼できるLANからのTCP 7890だけを許可してください。WAN側にプロキシポートを公開しないでください。

テスト用PCから次のリクエストを実行できます。最小構成では直接接続が成功するはずです。有効なノードとルールに置き換えた後、mihomoのログを確認して実際のアウトバウンド先を調べます。HTTPリクエストが一度成功しても、UDP、DNS、ネットワーク全体の透過プロキシが正常とは限りません。

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

ここで失敗する場合は、まず待ち受けアドレス、ファイアウォールの入力ルール、コアのログを確認してください。すぐにTProxyを変更する必要はありません。PCの明示的プロキシが正常で、ゲートウェイを変更すると失敗する場合は、転送、ファイアウォールによる取り込み、ポリシールーティング、DNSに問題を絞り込めます。

Redir、TProxy、TUNの違い

方式	mihomoの設定項目	主な用途	OS側で必要な設定
Redir	`redir-port: 7892`	Linux上でTCPを透過的にリダイレクト	ファイアウォールのREDIRECTルールと対象外通信の設定
TProxy	`tproxy-port: 7893`	Linux上でTCPとUDPを透過プロキシ	TPROXYルール、パケットマーク、ポリシールーティング
TUN	`tun.enable: true`	仮想ネットワークインターフェースでIP通信を受信	TUNのサポート、ルーティング、ファイアウォールの連携

Redir：ポートを待ち受けるだけでは通信を取り込めない

redir-portは透過プロキシ用の入口であり、アプリに設定するHTTPプロキシのポートではありません。LinuxのRedirはTCPで使われることが多く、これだけでUDPもプロキシされるとは限りません。TCPのリダイレクトだけを設定した場合、QUIC、ゲーム、音声通話のUDP通信は、残りのファイアウォールルールによって直接接続されるか、失敗する可能性があります。

TProxy：パケットをローカルに渡すポリシールーティングが必要

TProxyはTCPとUDPを扱い、元の宛先情報を保持できます。導入時には対象の通信にマークを付け、ip ruleと対応するルーティングテーブルを使ってローカルの透過リスナーへ転送します。tproxy-port: 7893を設定しただけで、OS側のルールがなければ端末の通信はmihomoに入りません。

ファイアウォールでは、LAN、ブロードキャスト、マルチキャスト、必要なローカルサービス、コア自身のアウトバウンド通信も除外し、プロキシのループを防ぐ必要があります。マーク値とルーティングテーブル番号は、既存のVPN、ポリシールーティング、マルチWAN設定と重複しないようにしてください。別の機器の数値をそのまま流用しても、動作するとは限りません。

TUN：別系統の通信取り込み方式であり、単なる追加スイッチではない

TUNには、OSが利用可能なTUNデバイスと適切な権限を提供している必要があります。tun.auto-routeはルートを自動設定し、Linuxの対応環境でtun.auto-redirectを使うとファイアウォールによる通信の取り込みも関係します。管理プラグインの既存の透過プロキシルールと安易に重ねないでください。バイパスルーターでは、まず主となる通信取り込み方式を一つ選び、その方式に合わせて除外ルールとロールバック手順を整えます。

DNS転送：dnsmasqとmihomoで異なるポートを使う

OpenWrtでは通常、dnsmasqがLAN向けに53番ポートでDNSを提供します。mihomoも同じアドレスの53番ポートを使うと競合します。確認しやすい構成の一例では、端末からバイパスルーターの53番ポートに問い合わせ、dnsmasqがローカルのmihomoの1053番ポートに転送します。

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

この設定例はローカルでの転送関係を示すもので、記載した上流DNSがすべてのネットワークで使えるとは限りません。dnsmasqの上流を127.0.0.1#1053に設定できます。ほかの上流DNSも読み込まれていないか確認し、想定した経路を迂回する問い合わせが発生しないようにしてください。mihomoの上流DNSをdnsmasqの53番ポートに戻すと、名前解決のループが発生します。

redir-hostとfake-ipは通信の取り込み方式に合わせる

redir-hostは端末に実際のIPアドレスを返します。一方、fake-ipはマッピング用のIPアドレスを返し、接続を取り込む際にコアがドメイン名との対応を復元します。fake-ipを使う場合、マッピング用アドレスを取得した端末からの接続がmihomoに戻る必要があります。DNSだけを切り替え、透過プロキシの設定が済んでいないと、「名前解決はできるのに、接続がすべて失敗する」ことがあります。

まず1台の端末でDNSの経路を確認し、ログに該当する問い合わせが記録されることを確かめてから、対象を広げてください。
ドメイン名を使う暗号化DNSを上流に設定する場合は、設定に応じて上流サーバーのドメイン名を解決するための初期DNSも用意してください。
端末のプライベートDNSやブラウザーのセキュアDNSが、DHCPで配布されたDNSサーバーを迂回する場合があります。それぞれ個別に確認してください。
DNSやfake-ipモードを変更した後は、テスト端末のDNSキャッシュを消去して接続を作り直し、古い結果が検証に影響しないようにしてください。

ゲートウェイ設定、戻り経路、IPv6

まず1台の端末で試し、その後DHCPを変更する

LuCIの「ネットワーク」→「インターフェース」で、バイパスルーターのLANアドレスが192.168.10.2、IPv4ゲートウェイが192.168.10.1であることを確認します。画面の項目はバージョンや管理プラグインによって異なる場合があるため、最終的にはインターフェースのアドレスとルーティングテーブルで確認してください。まずテスト用PCのゲートウェイとDNSをバイパスルーターに手動設定し、動作を確認してからネットワーク全体への配布を検討します。

メインルーターでDHCPを続ける場合は、オプション3に192.168.10.2、オプション6にも192.168.10.2を指定できます。それぞれIPv4ゲートウェイとDNSサーバーを表します。同じブロードキャストドメインで、計画なしに2つのDHCPサービスを同時に起動しないでください。設定変更後は端末のリース更新が必要です。既存のリースがすぐにすべて更新されるわけではありません。

同一セグメントでも戻り通信がバイパスルーターを通るとは限らない

単一インターフェースのバイパスルーター構成では、直接接続の通信がバイパスルーターからメインルーターへ送られた後、メインルーターが応答を端末へ直接返し、非対称経路になることがあります。戻り通信をバイパスルーターに通すため、メインルーター方向の通信にSNATを設定する構成もありますが、その場合は端末の送信元アドレスが見えなくなります。SNATやmasqueradeが必要かどうかは、ネットワーク構成、コネクショントラッキング、通信の取り込み方式によって異なり、一律に「すべて有効」にすべきではありません。

同一セグメント間の転送では、ICMP Redirectにも注意してください。端末がより直接的な経路を通知され、その後の通信経路が変わる場合があります。最初はバイパスルーターを通るのに、その後迂回する場合は、端末のルートキャッシュとバイパスルーターの関連カーネルパラメーターも確認してください。

IPv4ゲートウェイの設定だけではIPv6通信を取り込めない

メインルーターがRAで配布するIPv6デフォルトルートが引き続き有効な場合があります。設定にipv6: falseと書いても、LAN全体のIPv6が無効になるわけではありません。IPv6もプロキシする場合は、IPv6のルーティング、ファイアウォール、DNSを別途設計してください。まだ対応していない場合は、テスト端末でIPv6の利用範囲を制御し、IPv4とIPv6を個別に検証して、迂回をルールの不具合と誤認しないようにしましょう。

動作確認の手順とロールバック

トラブルシューティングは「ローカル接続、明示的プロキシ、1台の端末で透過プロキシ、ネットワーク全体への配布」の順で進めます。一度に変更するのは1つの層だけにし、変更前のゲートウェイ、DNS、ファイアウォールの状態を記録してください。管理画面が開けても、バイパスルーターへのローカル接続ができることを示すだけで、インターネットへの転送が正常とは限りません。

プロセスと設定を確認。mihomo -tを実行し、フォアグラウンドで起動エラーを確認します。7890、7892、7893、1053番ポートを別のインスタンスが使用していないことも確認してください。
バイパスルーター自身のインターネット接続を確認。ip -4 routeを実行してデフォルトの次ホップを確認します。時刻とDNSが正常であることも確かめてください。システム時刻のずれが原因でHTTPSリクエストに失敗する場合があります。
明示的プロキシを確認。前述のcurl --proxyを使ってリクエストし、ページが開くかどうかだけでなく、ログに記録されたルールと実際のアウトバウンド先を確認します。
透過プロキシの取り込みを確認。テスト端末の明示的プロキシを無効にし、ゲートウェイをバイパスルーターに設定します。ip rule show、ip route show table all、ファイアウォールルールのカウンターを確認してください。
DNSとプロトコルの対象範囲を確認。nslookup example.com 192.168.10.2を実行します。TCPの成功を確認したら、必要なUDPアプリをテストし、最後にIPv6を個別に確認してください。

常時稼働に移行したら、procdで自動起動、異常終了、ログを管理し、ネットワークや必要なファイルが準備できてから起動することを確認してください。ルール更新、providerの取得、サブスクリプションのダウンロードでは追加の通信が発生することがあります。こうした通信が誤って再び取り込まれないようにしてください。フラッシュ容量が限られる機器では、高頻度のデバッグログを長期間保存しないでください。

バイパスルーター導入の確認では、単一のスイッチが「実行中」と表示されることではなく、ゲートウェイ設定、DNS転送、透過プロキシの入口、アウトバウンドルールが段階ごとに対応していることが重要です。設定項目を調べる場合は設定リファレンスを参照してください。同じサブスクリプションを先にPCで検証する場合は、まずクライアントで設定が有効なことを確かめてからOpenWrtに移行してください。