Mihomoルーター・バイパスルーター導入ガイド：カーネル直接実行、通信の振り分けと保守範囲

Mihomoを家庭用ルーターやバイパスルーターで動かす目的は、各端末にデスクトップクライアントを個別インストールすることではありません。LANの出口付近にプロキシ機能を置き、条件に合う通信をネットワーク機器でまとめて処理します。これにより、Clashクライアントをインストールしにくいテレビ、ゲーム機、スマートスピーカー、家庭内サーバーなども対象にできます。一方で、設定、転送、DNS、障害切り分けが一つのネットワークノードに集約されます。

「ルーター導入」は、実際には大きく異なる2種類の構成を指すことがあります。一つは、家庭用ゲートウェイを担う主ルーターのシステム上でMihomoを直接動かす方式です。もう一つは、別の機器をバイパスルーターとして追加し、主ルーターと並行して動かしながら、ゲートウェイ、ポリシールーティング、または手動設定によって一部の端末の通信をバイパスルーターへ渡す方式です。どちらも透過プロキシを実現できますが、パケットの経路、電源断時の影響範囲、保守方法は異なります。

まず導入モデルを決める：主ルーターで直接実行するか、バイパスルーターで振り分けるか

主ルーターでカーネルを直接実行

主ルーターでのカーネル直接実行とは、現在のLANでデフォルトゲートウェイを担う機器上でMihomoを動かす方式です。端末はDHCPによって主ルーターのIPアドレスをデフォルトゲートウェイとして取得するため、外部ネットワークへアクセスする際、パケットは自然にこの機器へ到達します。ルーターのシステムは転送段階で通信をMihomoの透過プロキシ入口へ渡し、Mihomoがルールモード、プロキシグループ、プロキシノードに基づいてその後の経路を決定します。

この構成の利点はトポロジーがシンプルなことです。デフォルトゲートウェイ、LANのDHCP、DNS転送、プロキシプログラムを1台に集約でき、ルールの適用範囲も自然に広がります。一方で主ルーターの役割が増え、カーネルがCPU、メモリ、コネクションテーブルを消費します。設定更新の失敗、ルーターシステムの再起動、Mihomoプロセスの異常によって、家庭内ネットワーク全体に影響が及ぶ可能性もあります。ハードウェア性能が限られている場合、メーカー製ファームウェアが閉鎖的な場合、またはルーターの起動項目に不慣れな場合は、主ルーターを変更する前に元へ戻せるか確認してください。

バイパスルーターを独立して運用

バイパスルーターは通常、LAN内に置く2台目の機器です。Linux、OpenWrt、その他のルーターシステムを動かす小型PCなどが使われます。主ルーターは引き続き接続認証、無線LAN、DHCPを担当し、バイパスルーターではMihomoと関連する透過プロキシコンポーネントだけを動かします。端末から利用する方法は、主に3つあります。バイパスルーターをデフォルトゲートウェイにする方法、DNSだけをバイパスルーターへ向けて透過転送と組み合わせる方法、対象端末だけにゲートウェイとプロキシ入口を手動設定する方法です。

バイパスルーターの価値は、リスクを分離できる点にあります。主ルーターの既存設定を維持でき、バイパスルーターが停止しても、そこを経由していない端末は主ルーターからインターネットへ接続できます。また、まず1台のPCだけで試し、その後テレビ、家庭内サーバー、ゲストネットワークへ広げるといった段階的な検証にも向いています。ただし、バイパスルーターを置くだけで全通信が自動的に集約されるわけではありません。端末のデフォルトゲートウェイが主ルーターのままで、主ルーターからバイパスルーターへ関連通信を転送する設定もなければ、Mihomoはその接続を確認できません。

透過プロキシを理解する：通信の取り込みは、すべての接続が自動的にプロキシされることではない

デスクトップクライアントで一般的なシステムプロキシは、HTTP、HTTPS、SOCKSのプロキシアドレスをOSやアプリの設定に登録する方式です。アプリが設定を利用すれば接続は指定ポートへ送られますが、システムプロキシに対応しないプログラムは完全に回避することがあります。ルーターの透過プロキシは仕組みが異なり、通常は転送経路上で接続を判定し、ファイアウォールによるリダイレクト、ポリシールーティング、TUNなどを使って、直接転送されるはずの通信をプロキシカーネルへ渡します。

従来型の透過プロキシは、システムのネットワークスタックとファイアウォールルールに依存することが多くあります。たとえばTCP通信がルーターの転送経路を通る際にローカルの透過プロキシポートへリダイレクトされ、Mihomoが元の宛先アドレスに基づいてルールを判定します。UDP、ICMP、IPv6、ローカルホスト発の通信には別の処理が必要な場合があります。TCPのウェブページが開けたからといって、すべてのプロトコルが取り込まれているとは限りません。

TUNモードでは、システムのルーティングを通過するIPパケットを仮想ネットワークインターフェースで受け取り、カーネルがTCPやUDPなどの接続を処理します。その後、設定されたDNSとルーティングに基づいて転送を行います。ポートごとのリダイレクト設定を避けながら多くのアプリケーションプロトコルをカバーしたい場合に適していますが、システム権限、ルーティングテーブル、DNS処理、IPv6設定の影響を受けやすい方式です。ルーター環境でTUNが利用できるかどうかは、システムカーネルの機能、仮想デバイスの権限、使用するMihomoのバージョンにも左右されます。

1つの接続が実際に通る場所

LAN内の端末がドメインを名前解決し、端末自身のルーティングテーブルに基づいてデフォルトゲートウェイまたはDNSサーバーを決定します。
パケットが主ルーターまたはバイパスルーターへ到達します。バイパスルーターがデフォルトゲートウェイでない場合は、通信をそこへ通す追加の転送ルールが必要です。
透過プロキシの入口が接続を受け取ります。入口はリダイレクトポート、TProxyポート、TUN仮想ネットワークインターフェースなどで、具体的な名称はシステムと設定によって異なります。
Mihomoが宛先を解析し、DNS処理を実行したうえで、ルールの順序に従ってダイレクト接続、プロキシ、または特定のプロキシグループを選択します。
接続がダイレクト接続の出口またはプロキシノードから送信され、戻りデータが到達可能な復路を通って端末へ戻ります。

どこか一つでも欠けると、「一部のウェブサイトだけ開けない」という症状になることがあります。たとえばルールがプロキシを選択していても、バイパスルーターからノードへ接続できない場合があります。逆にノードが利用可能でも、端末がDNSを主ルーターへ送り続けて誤ったアドレスを取得することもあります。切り分けでは、まず接続がMihomoへ到達しているかを確認し、次にどのルールに一致したかを確認します。プロキシノードと外部ネットワークの確認は最後に行います。

ルーター上でMihomoを動かす構成要素：設定、ポート、ルール

Mihomoは設定の解析、ルールの判定、プロキシ接続の確立を担うカーネル実装です。ルーターへ導入する際は、少なくとも3種類の要素を分けて考える必要があります。カーネルの実行パラメータ、プロキシ設定ファイル、システム側のネットワーク取り込みルールです。設定ファイルには通常、プロキシノード、プロキシグループ、ルールセット、DNS、モード、リスニングポートが含まれます。一方、システム層は端末の通信を正しい入口へ送ります。片方だけを変更してもう片方を同期しないと、完全な結果を得られないことがよくあります。

設定のモードには通常、ルール、グローバル、ダイレクトがあります。家庭内ネットワークで長期運用する場合は、ドメイン、IP、ルールセットに基づいて通信を振り分けられるルールモードが適しています。グローバルモードはプロキシ経路が利用できるか確認する際に使え、ダイレクトモードは問題がプロキシノードやルール選択に由来するか判断するのに役立ちます。モードの切り替えで変わるのはMihomoの通信処理方針だけであり、デフォルトゲートウェイの誤り、DNSへの到達不能、ポートのリッスン失敗が修復されるわけではありません。

リスニングポートも通信の種類に合わせる必要があります。HTTPとSOCKSのポートは主に明示的なプロキシクライアント向け、透過プロキシポートはシステムの転送経路向け、DNSリスナーはドメイン名前解決のリクエスト向けです。通常のHTTPプロキシポートをそのまま透過プロキシの入口にしないでください。また、ポートの使用状況を確認せずに複数のサービスを重複起動するのも避けます。ルーターシステムではリスニングアドレスも確認が必要です。ループバックアドレスだけで待ち受けているとLAN内の端末から直接アクセスできません。LANアドレスで待ち受ける場合は、アクセス制御も設定してください。

mixed-port: 7890
mode: rule
allow-lan: true
external-controller: 127.0.0.1:9090

dns:
  enable: true
  listen: 0.0.0.0:1053

上記の断片は設定項目同士の関係を説明するためのもので、すべてのルーターシステムにそのまま適用できるわけではありません。allow-lan はLANから明示的なプロキシポートへアクセスできるようにしますが、透過プロキシには引き続きシステム側の転送設定が必要です。DNSのリスニングポートも、ルーターのDNS転送設定と一致させる必要があります。コントロールパネルのポートはローカルホストまたは信頼できる管理用ネットワークに限定し、不要なネットワークへ管理インターフェースを公開しないでください。

保守範囲：サブスクリプション更新、DNS、IPv6、復旧経路

サブスクリプション更新は分けて考える

サブスクリプション更新では通常、プロキシノード、プロキシグループ、ルール関連の内容が置き換わりますが、ルーターのトポロジーまで自動的に理解してくれるわけではありません。更新後の設定に、以前のルールが依存していたプロキシグループ名がない場合、存在しない対象に一致することがあります。ノードだけが提供され、DNS、TUN、ルーティング設定が含まれていない場合は、透過プロキシ機能をローカル設定で補う必要があります。更新前に現在動作している設定を保存し、更新後はファイルの解析、プロキシグループの存在を確認してから、まず1台の端末でテストしてください。

DNSは見落とされやすい中間層

端末がドメインへアクセスできるかどうかは、名前解決のリクエストがどこへ送られ、現在のルールに適したアドレスが返されるかで決まります。主ルーター、バイパスルーター、ISPのDNS、暗号化DNS、Mihomo内蔵DNSが同時に処理へ関与する場合もあります。プロキシ接続自体は正常なのに名前解決に失敗する場合は、IPアドレスへのアクセス、LANのDNSポート、MihomoのDNSリスニングポート、ルール内の名前解決方針を分けてテストしてください。モードを何度も切り替えても、端末が実際に利用するDNSサーバーは変わりません。

IPv6はIPv4の経験だけでは判断できない

家庭内ネットワークでIPv6を有効にすると、端末はAAAAレコードを優先して取得し、IPv6のデフォルトルートから直接接続することがあります。IPv4だけに透過プロキシを設定していると、一部のサービスがプロキシを迂回したり、接続待ち時間が長くなったりします。必要に応じてIPv6ファイアウォール、ルーター広告、MihomoのIPv6処理能力を確認してください。IPv6の経路設計がまだできていない場合は、テスト用セグメントで一時的にIPv6を無効にして比較する方法もあります。ただし、これはネットワーク方針の選択であり、必ずしもプロキシカーネルの障害を意味するものではありません。

主ルーターの復旧経路を確保する

主ルーターで直接実行する場合は、ローカルの管理入口、利用可能な元の設定、透過プロキシを無効にする方法を準備してください。バイパスルーター方式では、主ルーターとバイパスルーターの管理アドレス、DHCPの担当、デフォルトゲートウェイの変更箇所を記録します。DHCPで配布するゲートウェイやDNSを変更した後も、端末が古いリースを保持していることがあります。その場合はネットワークへ再接続するか、手動でリースを更新してください。保守作業では、カーネルの更新、サブスクリプションの交換、ファイアウォールの変更を同時に行わず、一度に1つの変数だけを変更するのが安全です。

選び方：対象範囲、性能、障害時のコストで判断する

プロキシが必要な端末が少なく、端末自体がシステムプロキシやClashクライアントに対応しているなら、端末上でクライアントを動かし続けるほうが、接続、ルール一致、ログを確認しやすい場合があります。ルーターへの導入は、多様な端末をまとめてカバーしたい場合や、家庭内ネットワークを同じルールで振り分けたい場合に向いています。選ぶ前に機器の性能を確認してください。メモリ不足ではカーネルがシステムに強制終了され、CPU性能が低いと大量の接続、ルールセットの解析、暗号化転送によって遅延が生じることがあります。

要件	適した構成	主な注意点
家庭内の全端末を統一して振り分ける	主ルーターで直接実行、またはデフォルトゲートウェイをバイパスルーターに設定	DHCP、DNS、IPv4、IPv6の経路を重点的に確認
まず少数の端末でテストする	端末ごとにバイパスルーターをゲートウェイ指定	主ルーターをデフォルト出口として残し、対象範囲を段階的に広げる
ルーターのハードウェア資源が限られている	独立したバイパスルーター	メモリ、接続数、ルールセットの規模、冷却を確認
ブラウザーのプロキシだけが必要	端末側の明示的なプロキシ	家庭内ネットワークの転送構成を先に変更する必要がない

安全な検証手順は、まずMihomoプロセスが動作していることを確認し、次に設定ファイルが正常に読み込まれていることを確認します。続いてバイパスルーター本体からノードへの接続をテストし、その後、1台のLAN端末に指定した入口を使わせます。ゲートウェイやDNSをより多くの端末へ配布するのは最後です。各段階で、端末IP、デフォルトゲートウェイ、DNSアドレス、プロキシのリスニングポート、現在のモードを記録してください。問題が起きても、端末がバイパスルーターを経由していないのか、通信が透過プロキシ入口へ入っていないのか、ルール選択が想定と異なるのか、ノード自体が利用できないのかを素早く判断できます。

よくある症状と切り分けの順序

端末でプロキシの効果がまったくない：まず端末のデフォルトゲートウェイを確認し、プロキシによる通信取り込みを担う機器を指しているか確認します。次に、バイパスルーターで転送が許可され、ファイアウォールルールが読み込まれているか確認してください。
ウェブページは開けるのにアプリが失敗する：アプリがUDP、QUIC、独自DNS、IPv6を使用している可能性があります。テストでは接続種別とログを確認し、ブラウザーの結果だけで判断しないでください。
ノード一覧はあるのにすべてタイムアウトする：ルーター本体からノードサーバーへの接続性をテストし、時刻、出口側DNS、上流ファイアウォール、サブスクリプションに記載されたサーバーアドレスを確認してください。
LAN内の端末同士のアクセスに異常がある：透過プロキシがLAN内アドレスを誤って取り込んでいないか確認し、ルールでLAN、予約済みアドレス、管理用ネットワークが適切に処理されているか確認してください。
再起動後に設定が無効になる：起動サービス、マウント先、設定ファイルの権限を確認し、カーネルの起動がネットワークインターフェースとストレージのマウントより後になっているか確認してください。

ログは、ネットワークキャプチャやルーティングテーブルの情報と組み合わせて読みます。「接続失敗」と表示されただけでは、問題がノードにあるとは限りません。ログに該当するドメインや宛先アドレスがまったくない場合は、端末がMihomoの入口を通っていない可能性が高くなります。反対に、ルール一致と外向き接続まで確認できているのにタイムアウトする場合は、プロキシグループ、リモートノード、復路のネットワークを続けて確認します。

Mihomoのルーター導入は、単にプログラムをインストールする作業ではなく、ネットワーク出口を設計する作業です。主ルーターでの直接実行は経路の集約を重視し、バイパスルーターは役割の分離を重視します。透過プロキシは指定ノードを通る接続を取り込み、ルールは接続の処理方法を決め、サブスクリプションは主に更新可能なノードと設定内容を提供します。これらの境界を先に整理し、端末数、ハードウェア資源、保守に割ける能力に応じて構成を選べば、その後の設定と切り分けをより管理しやすくできます。