導入方式を選ぶ：ゲートウェイの配置を決めてから通信の振り分け方法を選択

メインルーターの性能に余裕があり、ネットワーク全体を一元管理したい場合は、OpenWrt上で mihomo を直接動かせます。既存のメインルーターを維持し、一部の端末だけを接続したい場合は、バイパスルーターなら段階的にテストできます。初めて導入する場合は、まず手動プロキシを確認し、次にDNS、最後に透過プロキシを有効にしましょう。一度に3か所を変更すると、障害の原因を特定しにくくなります。

mihomo は Clash Meta から発展したプロキシコアで、プロトコル接続、ルール判定、DNSなどを担います。ルーター用ファームウェアではなく、ルーター管理画面も標準では備えていません。OpenWrtのプラグインは通常、設定の生成、プロセス管理、ファイアウォールルールの適用、LuCI画面の提供を行います。バイナリを直接実行する場合、これらの作業は自分で行う必要があります。

設置場所接続方法主な管理項目
OpenWrt メインルーターLAN通信をネットワークの出口で制御ファイアウォール、DNS、ハードウェアオフロード
OpenWrt バイパスルーター対象端末のゲートウェイをバイパスルーターに設定戻り経路、DHCP、同一サブネット内の転送
Linux小型PC手動プロキシ、またはゲートウェイとして設定サービス管理、転送、ルーティング、ファイアウォール
コンテナ上の mihomoまず明示的なプロキシを提供し、透過的な通信制御はその後に検討ネットワーク名前空間、デバイス割り当て、権限

必要スペック：アーキテクチャ、使用可能メモリ、ストレージを確認

アーキテクチャはOSを基準に確認

まずSSHで以下のコマンドを実行してください。CPUが64ビット対応でも、インストール済みファームウェアが64ビットとは限りません。バイナリは実際のシステムアーキテクチャに合わせてダウンロードします。ARMでは命令セットのバージョン、MIPSではエンディアンにも注意が必要です。高度な命令セットを必要とするビルドは、古いCPUでは動作しません。

uname -m
cat /etc/openwrt_release
free -m
df -h /overlay
df -h /tmp

たとえば、aarch64 は通常 ARM64、x86_64 は64ビット x86 に対応します。起動後に不正な命令と表示された場合は、まずビルドの要件を確認してください。実行できないというエラーが出る場合は、サブスクリプションを何度も変更するのではなく、ファイルのアーキテクチャ、実行権限、実行環境を確認します。

動作時の余裕を見込んで容量を計画

  • メモリ256 MBの機器：余裕の少ない構成です。ルールセットやサブスクリプションの規模を抑え、ルール更新時は空きメモリも確認してください。起動直後の使用量だけで判断するのは避けましょう。
  • メモリ512 MBの機器：軽量な家庭用構成を検討する際の目安になります。ただし、無線サービス、ファイル共有、その他のプラグインが使用するメモリも差し引いて考えてください。
  • メモリ1 GB以上：複数のサービスを同時に動かしたり、大きなルールセットを使ったりする場合に適しています。実際の接続数に応じて使用量を確認してください。
  • ストレージ：初期計画として、書き込み可能な領域を少なくとも100 MB確保することをおすすめします。コア、設定、ルールデータ、更新時の一時ファイルを保存するための目安であり、すべての構成に共通する最低要件ではありません。

OpenWrtの /tmp は通常、メモリ上のファイルシステムを使用します。大きなファイルを置くとメモリを消費し、再起動後に消えることもあります。通信速度はCPUのシングルコア性能、暗号化プロトコル、NICドライバー、透過プロキシの経路にも左右されるため、ギガビット対応ポートだからといってプロキシ通信も必ず1 Gbpsに達するとは限りません。

導入方法：プラグイン管理、ネイティブサービス、コンテナ

OpenWrtプラグイン：設定を一元管理

現在のファームウェアバージョンとファイアウォールの仕組みに対応したプラグインを選びます。新しいOpenWrtでは通常 firewall4 と nftables、古い環境では firewall3 と iptables が使われています。導入前にプラグインのドキュメントを確認し、旧バージョン向けのファイアウォールスクリプトを新しいシステムにそのまま適用しないでください。

  1. 現在のネットワーク、DHCP、ファイアウォールの設定をバックアップし、ルーターのLANアドレスとSSHのログイン方法を記録します。
  2. プラグインからインストールするか、アーキテクチャに合った mihomo コアを選び、対応するサブスクリプション設定を追加します。
  3. まず透過的な通信制御を無効にし、設定の読み込みとノードへの接続を確認します。その後、DNSと通信制御を一つずつ有効にしてください。
  4. プラグインが設定を再生成するか確認してください。継続して使う変更は、プラグインが用意するオーバーライドまたは追加設定の項目に記述します。

プラグインのメニュー名はプロジェクトやバージョンによって異なるため、デスクトップクライアントと同じ設定手順が使えるとは限りません。また、2つのプロキシプラグインでDNSや透過転送を同時に制御すると、ポートの競合、ルールの上書き、二重プロキシが発生することがあります。

ネイティブバイナリ：プロセスと自動起動を自分で管理

以下の例では、コアを /usr/bin/mihomo にインストールし、設定を /etc/mihomo/config.yaml に保存しているものとします。まず構文を確認し、次にフォアグラウンドで起動してログを確認します。

/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

設定チェックに成功しても、リモートノードに接続できることや、透過転送が有効になっていることを意味するわけではありません。フォアグラウンドでの確認後、OpenWrtではprocdにサービスを管理させます。systemdを使うLinuxでは、作業ディレクトリと再起動ポリシーを設定したサービスユニットを作成してください。SSHからバックグラウンド起動するだけでは、ターミナルの終了後や機器の再起動後にサービスが停止するおそれがあります。

コンテナ：透過ゲートウェイより明示的なプロキシが導入しやすい

通常のブリッジネットワークとポートマッピングを組み合わせれば、まずHTTPまたはSOCKSプロキシを提供できます。TUNでは通常、/dev/net/tunへのアクセス、ネットワーク管理権限、適切なネットワークモードも必要です。コンテナ内のルーティングが影響するのは、そのネットワーク名前空間内だけです。ホストやLAN全体の通信が自動で制御されるわけではありません。トラブルシューティングのためにすべての権限を与えるのではなく、通信をどの層からコアに渡す必要があるかを先に確認してください。

バイパスルーターの構成：ゲートウェイとDNSを分けて確認

ネットワークの例として、メインルーターを 192.168.50.1、バイパスルーターを固定アドレス 192.168.50.2 とし、両方のサブネットマスクを 255.255.255.0 とします。バイパスルーター自身のデフォルトゲートウェイはメインルーターに設定します。最初のテストではPCを1台だけ変更し、ほかの端末は従来の設定のままにしてください。

テスト方法端末の設定確認する項目
手動プロキシゲートウェイは .1 のまま。アプリのプロキシを .2:7890 に設定コア、サブスクリプション、ノードへの接続
透過プロキシデフォルトゲートウェイを .2 に変更し、設定済みのLAN DNSサービスを指定転送、ルール、DNS制御
元のネットワークに戻すゲートウェイとDNSを .1 または元のDHCP設定に戻すバイパスルーター側と上流側の障害を切り分ける

DNSだけを変更しても、すべての接続が自動でバイパスルーターを経由するわけではありません。ゲートウェイだけを変更しても、ドメイン名が想定どおりに解決されるとは限りません。透過プロキシには、IP転送の有効化と適切なファイアウォール設定、戻り経路も必要です。特に単一NICのバイパスルーターでは、直接接続の通信がバイパスルーターからメインルーターへ転送され、戻りの通信はメインルーターから端末へ直接送られる非対称経路に注意してください。

戻り経路を安定させるために、一部の構成では送信元NATを使いますが、上流側から見える送信元アドレスが変わります。内容を確認せずにNATコマンドをコピーしないでください。使用するプラグインの構成ガイドに従って設定します。1台の端末で正常に動作することを確認してから、DHCPでゲートウェイのオプション3とDNSのオプション6を配布するか検討してください。同じブロードキャストドメインで、安易に2つ目のDHCPサーバーを有効にしないでください。

設定のポイント：LAN内で使うプロキシの接続先は制限する

以下は前述のネットワークを想定した基本例で、サブスクリプション全体ではありません。リッスンアドレス、混合プロキシポート、DNSの接続先の関係を示しています。ノード、グループ、ルールは有効な設定から追加してください。プラグインを使う場合は、対応している設定方法を利用し、生成済みファイルを直接編集しないでください。

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

dns:
  enable: true
  listen: 192.168.50.2:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - 223.5.5.5
    - 1.1.1.1
  • mixed-port: 7890 はHTTPとSOCKSの両方のプロキシ接続を受け付けます。このポートは透過プロキシ用ではないため、端末側でプロキシを明示的に設定する必要があります。
  • allow-lan: true はLANからの接続を許可しますが、ファイアウォールでは信頼できるLANからのアクセスだけに制限してください。ポート7890をインターネットに公開しないでください。
  • bind-address は例で使うバイパスルーターのアドレスにバインドします。実際の環境では、このアドレスがローカルのインターフェースに割り当てられている必要があります。
  • 1053 はDNS上流のリッスンポートの例です。通常、端末はポート53に問い合わせるため、DHCPだけでポート1053を指定することはできません。

OpenWrtでは、dnsmasqでLAN向けのポート53を引き続き提供し、問い合わせを mihomo のポート1053へ転送できます。この場合、転送経路を確認してください。dnsmasqから mihomo へ転送し、mihomoの上流が同じdnsmasqに戻らないようにしないと、DNSループが発生します。例にあるパブリックDNSは形式を示すためのものです。実際には、LANからの到達性や通信の振り分け方針に合わせて設定してください。

透過プロキシとTUN：同じ通信を二重に制御しない

一般的な透過プロキシの方式には、ファイアウォールによるリダイレクト、TProxy、TUNがあります。リダイレクトは通常TCP向けです。TProxyはTCPとUDPを扱えますが、対応するカーネル機能、ポリシールーティング、ファイアウォールルールが必要です。TUNは仮想ネットワークインターフェースを通じて通信をコアに渡しますが、ルーティングやDNSの問題をすべて自動で解決するものではありません。

3つのポイントをまとめて確認

  1. 通信の取り込み：LANからの転送通信が、想定したチェーンまたはTUNルートに入っているか確認します。ルーター自身の通信だけが制御されていても、LAN端末が接続されている証拠にはなりません。
  2. 除外：プロキシノードのサーバーアドレス、LANアドレス、コア自身の外向き通信などが正しく除外されているか確認し、再びプロキシに入ってループしないようにします。
  3. 戻り通信：ポリシールーティング、ファイアウォールマーク、コネクショントラッキングに矛盾がないか確認し、UDPとTCPの両方が想定した経路を通ることを確かめます。

mihomo のTUNでは、auto-route などのオプションを使ってルートの作成を補助できます。対応するLinux環境では、auto-redirect でリダイレクトを補助することもできます。有効にするかどうかはプラグインの設計に従ってください。プラグインのTProxy制御と、別のTUN自動制御を同時に有効にし、両者が自動で連携することを期待しないでください。

トラブルシューティングでは、ソフトウェアまたはハードウェアのフローオフロードを一時的に無効にして、挙動を比較します。高速化の経路によっては、必要な処理チェーンを通らない場合があります。QUICを使う動画やゲームだけで問題が起きる場合は、UDP転送とノードのプロトコル対応を個別に確認してください。ブラウザーで1ページ開けただけで、すべての通信が正常だと判断することはできません。

DNS、Fake-IP、IPv6：名前解決と接続の経路をそろえる

Fake-IPはドメイン名に対して対応付け用のIPアドレスを返します。例では 198.18.0.0/16 を使用します。これらのアドレスは mihomo が識別し、ドメイン名に対応付ける必要があり、パブリックな宛先として上流ルーターに渡してはいけません。端末がFake-IPを取得した後の接続も、同じプロキシ制御経路を通る必要があります。

  • LAN内のドメイン名：プリンター、NAS、ルーター管理用のドメイン名は、ローカルで名前解決できるようにしてください。必要に応じてFake-IPフィルターとDNSポリシーを組み合わせます。フィルターに追加するだけで、ローカルDNSの参照先を確認しないままにしないでください。
  • アプリ独自の暗号化DNS：ブラウザーのDoHは、システムのDNS設定を迂回する場合があります。従来のポート53の制御ではこうした問い合わせをすべて処理できないため、テスト時にブラウザーが別のDNSサーバーを設定していないか確認してください。
  • IPv6：端末がルーター広告を受け取り、別のデフォルトルートを使うことがあります。IPv4のゲートウェイだけを変更しても、IPv6通信は直接外部へ出る可能性があります。
  • 設定の復元：Fake-IPを無効にしたりDNSを切り替えたりした後は、端末とアプリのキャッシュを消去し、古いマッピングアドレスが使われ続けないようにします。

この例では mihomo のIPv6利用とAAAA応答を無効にしていますが、LAN全体のIPv6を無効にする設定ではありません。導入前に、IPv6の通信制御を適切に設定するか、テスト用ネットワークでIPv6のルーター広告と関連サービスを一時停止するかを決めてください。IPv6経路の見落としを、ルールが不規則に動作する原因と誤認しないようにしましょう。

動作確認と復旧：接続経路を段階ごとに切り分け

一度に変更する項目は1つにし、変更前後の設定を記録してください。以下のコマンドは、プロセスログ、リッスンポート、ルート、DNSの確認に使います。システムにインストール済みのツールを選んで実行すればよく、トラブルシューティングのためにすべてのツールを一度にインストールする必要はありません。

logread | grep -i mihomo
ss -lntup
ip route show
ip rule show
nslookup example.com 192.168.50.2
curl -I -x http://192.168.50.2:7890 https://example.com

nslookup は、バイパスルーターのポート53で提供されるLAN向けDNSサービスをテストします。例にあるポート1053のリッスン状態を確認するコマンドではありません。フロントエンドDNSサービスを用意していない場合、この結果だけで mihomo のDNS機能に問題があると判断することはできません。curl が確認するのは明示的に指定したHTTPプロキシであり、透過プロキシとは別のテスト経路です。

症状まず確認する項目次に行うこと
設定を読み込めないインデント、フィールドの型、コアとの互換性設定チェックを実行し、エラー行を特定する
手動プロキシでも接続できないリッスンアドレス、LANファイアウォール、ノードへの到達性まずプロキシ接続先を1つだけ復旧させる
手動プロキシは正常だが、ゲートウェイ変更後に接続できない転送設定、通信制御ルール、戻り経路ルートとファイアウォールのカウンターを確認する
一部のドメインで問題が起きるDNSキャッシュ、Fake-IP、ローカルドメインの名前解決システムとアプリで名前解決先を比較する
IPv4は正常だが、一部の接続が直接外部へ出るIPv6のデフォルトルートと通信制御の範囲IPv4とIPv6の経路を個別に確認する

動作確認が完了してから自動起動を有効にし、再起動後に設定、ルールデータ、ファイアウォールが順番どおりに復元されることを確かめてください。テストに失敗した場合は、まず端末のゲートウェイとDNSを元のメインルーターに戻し、プラグインから通信制御を無効にして、関連するファイアウォール設定を復元します。コアを停止するだけでは、無効なインターフェースを参照するルールが残る場合があります。バイパスルーターを経由しない管理用の接続手段を確保しておけば、設定ミスによるネットワーク全体の切断を防ぎやすくなります。