ルーター・サブルーターで直接動かす Clash カーネル:mihomo 導入方法まとめ

プロキシをルーター層に置く理由

デスクトップクライアントやスマホアプリは、ソフトをインストールした端末しかカバーできません。家庭内のテレビボックス、ゲーム機、スマートスピーカー、タブレットなどは1台ずつ設定するのが難しく、しかもシステムプロキシや TUN モードの実装は機種ごとにバラバラで、カスタム DNS や仮想ネットワークカードに対応していない機器では手詰まりになります。プロキシをルーターやサブルーターという層に落とし込めば、ネットワークの出口で一括して通信を制御でき、このネットワークに接続したすべての機器が自動的に振り分け機能を得られます。端末ごとにクライアントを入れる必要も、アーキテクチャがマイナーでソフトが入らない機器を心配する必要もありません。これが、多くの家庭ネットワークが最終的にゲートウェイ層で mihomo カーネルを動かす選択をする核心的な理由です。

mihomo は Clash Meta プロジェクトから続くカーネル実装で、初期の Clash カーネルと比べてプロトコル対応が広く、ルールエンジンも柔軟です。TUN モードをネイティブで備え、プロセス単位の豊富な振り分け機能も持つため、ファームウェア化してルーターに長期間常駐させる用途に非常に向いています。以下では、メインルーターとサブルーターという2つの構成に分けて導入方法を説明します。

メインルーター vs サブルーター:どちらを選ぶべきか

「メインルーター」方式とは、サードパーティファームウェア(一般的には OpenWrt 系)を直接書き込み、ルーター自体に mihomo の実行環境を担わせる構成です。「サブルーター」方式は、既存のルーターに加えてもう1台の小型機器(ミニPC、余っているルーターを純粋なゲートウェイとして再利用したもの、あるいは NAS 上の仮想マシンなど)を用意し、ゲートウェイのハイジャックや LAN 内の DHCP オプションによって、プロキシが必要な機器をこのサブルーターへ向ける方式です。

• メインルーター方式:構成が単純で、1台の機器がルーティングとプロキシの両方を担うため追加ハードウェアが不要という利点があります。一方で、ルーター本体のファームウェア互換性や CPU 性能への要求が高くなり、プロキシプロセスに異常が発生するとネットワーク全体の転送にも影響が出うるため、リスクが1台に集中します。
• サブルーター方式:メインルーターは工場出荷時のファームウェアのままにでき、安定性やサポート面に影響を与えません。サブルーターはプロキシ専用機として動き、問題が起きてもそのサブルーターだけ再起動すればよく、切り分けが明快です。一方で機器が1台増え、ネットワーク設定(ゲートウェイの向き先、DHCP 配布)も1段増えるため、初期構築の敷居は少し上がります。

サードパーティファームウェアを書き込める対応ルーターが1台しかなく、「すべてを1台に集約するリスク」を受け入れられるなら、メインルーター方式のほうが手間が少なく済みます。プロキシ環境を基礎ネットワークから分離させ、ネット接続に影響を与えずにプロキシ機器をいつでもリセット・入れ替えできるようにしたいなら、サブルーター方式のほうが安全な選択で、現在の家庭ネットワークではより一般的なやり方です。

ハードウェア選定とファームウェアの基礎

mihomo 自体は Go で書かれた単一バイナリのプログラムで、リソース消費はさほど重くありませんが、透過プロキシのシーンでは NAT 転送、DNS クエリ、ルールマッチングを同時に処理する必要があります。選定時は次の3点に注目することをおすすめします。

1. CPU アーキテクチャと処理能力:ハードウェアアクセラレーションに対応したマルチコアの ARM または x86 プラットフォームを優先しましょう。ルーター向けの低消費電力シングルコアチップは、高い同時接続数の下でルールマッチングの遅延が出やすくなります。
2. メモリ容量:ルールセットの読み込みや接続テーブルの維持はメモリを消費します。プロキシプロセスとファームウェア本体のために最低でも 512MB 以上を確保することをおすすめします。ルール数が多い場合やログ追跡を有効にする場合はさらに余裕を持たせましょう。
3. ストレージとファームウェアのエコシステム:メインルーター方式は通常 OpenWrt かその派生ファームウェアに依存するため、対象機器に安定したサードパーティファームウェアの対応とコミュニティによるメンテナンスがあるか確認が必要です。サブルーター方式はより自由で、ミニPCで Linux ディストリビューションを動かす、古いルーターを OpenWrt の純ゲートウェイモードにするなど、選択肢は多岐にわたります。

ファームウェア面では、mihomo の公式・コミュニティが OpenWrt 向けパッケージと LuCI 管理画面を提供しており、パッケージマネージャーからインストールすることも、ビルド済みバイナリを配置して init スクリプトで動かすことも可能です。この2つの方式については後述の自動起動の項でも触れます。

透過プロキシモード:TUN・TPROXY・REDIRECT の選び方

ゲートウェイ層で通信を制御する核心は、LAN 内の機器から出る TCP/UDP 通信を透過的に mihomo が待ち受けるポートへ導き、カーネルがルールに従って通過・プロキシ・遮断を判断することです。よく使われる3つの実装方式には、それぞれ一長一短があります。

• TUN モード:mihomo が仮想ネットワークカードを作成し、レイヤー3で直接通信を受け取ります。設定が分かりやすく UDP への対応も完全で、現在推奨されているデフォルトの方式です。特に IPv4/IPv6 の振り分けを精密に制御したい場合に適しています。
• TPROXY:Linux カーネルの透過プロキシ機構に依存し、ゲートウェイ機器上で iptables/nftables を使って通信を mihomo にリダイレクトします。元の宛先アドレス情報を保持できるため互換性が高く、成熟した OpenWrt 振り分けスクリプトでよく使われます。
• REDIRECT:比較的古い実装方式で、TCP のリダイレクトのみに対応しています。UDP(特に UDP に依存するゲームや一部の動画プロトコル)には追加対応が必要で、新規導入では第一選択にはなりにくくなっています。

どの方式を選んでも、設定ファイル内で対応する透過プロキシのスイッチを有効にし、待ち受けポートを宣言する必要があります。例えば TUN モードを有効化する際の主要フィールドはおおむね次の通りです(具体的なパラメータは最新のバージョンドキュメントを参照してください)。

tun:
  enable: true
  stack: system
  auto-route: true
  auto-detect-interface: true

auto-route はルーティングテーブルを自動で書き込む役割を、auto-detect-interface はカーネルが出口ネットワークカードを識別するのを助ける役割を担っており、この2つを組み合わせることで手動でルーティング規則を修正する手間を大幅に省けます。サブルーター方式で最もよく使われる組み合わせです。

DNS の制御と汚染対策

透過プロキシは通信転送の問題しか解決しません。DNS クエリが依然としてプロバイダの標準経路を通っていると、ドメインベースの振り分けルールが「間違った」解決結果を受け取ってしまい機能しなくなります。よくある症状は、ルールを設定したはずなのに一部のサイトへのアクセスが依然として遅い、あるいはまったく繋がらないというものです。そのため、ゲートウェイ層の導入では DNS も同時に制御する必要があります。

1. mihomo の設定内で内蔵 DNS サーバーを有効化し、LAN 内の機器がアクセスできる待ち受けアドレスとポートを設定します。
2. fake-ip または redir-host モードと組み合わせて、カーネルが先にドメイン名を取得した上でどの上流に解決を依頼するか決定できるようにし、ルールエンジンによって IP レンジ単位ではなくドメイン単位の振り分けを実現します。
3. ルーターの DHCP 設定で、LAN 内の機器に配布する DNS サーバーアドレスをゲートウェイ自身(mihomo を動かしている機器)に向け、機器がゲートウェイをバイパスして外部 DNS に直接問い合わせるのを防ぎます。

サブルーター構成の場合は、メインルーター側でも DHCP オプション6(DNS)が確実にサブルーターのアドレスを指しているか確認が必要です。そうでなければ、サブルーターの設定が正しくても LAN 内の機器はメインルーターが配布するデフォルト DNS を受け取ってしまい、振り分けルールが実質的に機能しなくなります。この点は「ルールを設定したのに効かない」問題を調査する際に最も見落とされがちな部分です。

自動起動と長期的な安定性

ゲートウェイ層のプロキシプロセスには「ルーターを再起動したら自動で復旧する」能力が求められます。そうでなければ、一度の突然の停電で家全体がネット接続不可、あるいは振り分けなしの状態に戻ってしまいます。導入時は以下の点に注目することをおすすめします。

• init スクリプトまたはシステムサービス:OpenWrt では procd サービススクリプトを書いて mihomo をシステムサービスとして登録でき、enable、start、stop といった標準操作に対応し、ファームウェア再起動後は procd が自動的に起動します。
• ウォッチドッグと自己回復:簡単な定期タスク(cron)を組み合わせてプロセスの生存を検知し、異常終了時には自動的に再起動させることで、カーネルの不定期なクラッシュによる長時間のネット断絶を人知れず放置してしまう事態を避けます。
• 設定とルールセットの分離:サブスクリプションから生成されるノード設定と、ローカルで手動調整したルールを別ファイルに分けて参照させると、サブスクリプションを更新しても手動で調整したルーティングルールが上書きされず、更新後の再確認作業が減ります。
• ログの保存:適度な接続ログとカーネルログをローカルファイルに出力するよう設定しておくと、機器がオフラインになったり振り分けに異常が出たりした際に、どのルールやどの DNS クエリが問題だったかを遡って調べやすくなります。

サブルーター方式はメインルーターと独立して動くため、通常はログ保存やプロセス監視がしやすく、実験的なルール変更を試すのにも向いています。一方メインルーター方式では、設定を比較的保守的に保ち、大きな変更を行う前には現在動作している設定ファイルをバックアップすることをおすすめします。

導入前の判断チェックリスト

ここまでの判断基準を簡単なチェックリストにまとめました。自宅のネットワーク状況と照らし合わせて確認してみてください。

1. 既存のルーターは安定したサードパーティファームウェアに対応しているか?対応していて、リスクの集中を受け入れられる → メインルーター方式を優先的に検討。
2. プロキシ専用機として使える余っているミニPC、古いルーター、小型 NAS があるか?ある → サブルーター方式のほうが切り分けが明快でリスクも分散できる。
3. 家庭内にカスタム DNS に対応しないスマート機器(テレビボックス、スピーカーなど)があるか?ある → 事前にゲートウェイ層での DNS ハイジャック戦略を計画しておく。
4. プロキシ機器の入れ替えやファームウェアの再書き込みテストを頻繁に行う予定か?頻繁に行う → サブルーターのほうがメインネットワークに影響を与えずいつでも入れ替えやすい。
5. 長期間無人で運用するシーン(出張、遠隔地)があるか?ある → 自動起動とウォッチドッグを必ず設定し、停電後に遠隔から復旧できない事態を避ける。

最終的にどちらの構成を選んでも、核心となる考え方は同じです。まずゲートウェイ層で通信と DNS をどちらも mihomo カーネルに集約し、次に明確なルールファイルで振り分けロジックを記述し、最後にシステムサービスとログの仕組みで長期的な安定運用を保証する。この3つの層をそれぞれしっかり作り込むことで、家庭ネットワーク内のすべての機器が本当の意味で同じプロキシ戦略を共有でき、1台ずつ設定に手間をかける必要がなくなります。