ルーター・サブルーターで mihomo コアを直接稼働:全宅透過プロキシ構築概説

なぜプロキシをルーター層に下ろすのか

デスクトップクライアント(Clash Verge Rev、FlClash など)は1台の端末上でプロキシを動かすため、設定がわかりやすく画面も操作しやすい一方、カバーできるのはその1台だけです。家にあるテレビ端末、スマートスピーカー、タブレット、プリンター、友人が使う端末などはプロキシの対象外になってしまい、直接インターネットに出るしかない、あるいはそもそもプロキシ設定自体ができないケースもあります。mihomo コアをルーターやサブルーターに直接導入すれば、「プロキシ」という機能を各端末から切り離し、ネットワークの出口側にまとめて配置できます。そのルーターに接続したすべての機器が自動的にプロキシ機能を得られるため、端末ごとにクライアントをインストールしたり、サブスクリプションを設定し直したりする必要がなくなります。

この「全宅プロキシ」という考え方は、機器数が多く種類も雑多な家庭、カスタムプロキシ設定に対応していないスマート機器(テレビ、セットトップボックスなど)に出口を用意したい場合、あるいは端末ごとにクライアントを個別管理する運用コストを省きたい場合に特に向いています。反面、導入の難易度はデスクトップクライアントを1つ入れるのに比べてはるかに高く、設定ファイルやコマンドライン操作、一定のネットワーク基礎知識が必要になります。トラブル時もクライアントのような可視化された接続状況の表示はなく、ログを見て自力で切り分けることになります。

機種選定:メインルーターに直接導入するかサブルーター方式か

導入前にまずハードウェア構成を決めます。よくある選択肢は次の2つです。

• メインルーターに mihomo 対応ファームウェアを直接導入する方法:もともとルーターを買い替える予定があり、既存ルーターの安定性にそれほどこだわらない場合に向いています。機器を1台増やさずに済み、構成もシンプルになる利点がありますが、メインルーターが全転送処理を担うため、ファームウェアに問題が起きると家全体がネット切断になるリスクが集中します。
• サブルーター方式(大半の家庭に推奨):既存のメインルーターの下流に小型機器(x86 のミニPC、Raspberry Pi、ファームウェア書き換え対応の中古ルーターなどが一般的)を1台追加し、そこだけで mihomo を動かします。メインルーターは DHCP と通常のルーティングを継続して担当し、ゲートウェイアドレスまたはデフォルトルートをサブルーターに向けます。この構成は変更範囲が小さく、メインルーターの安定性に影響を与えません。問題が起きればデフォルトルートをメインルーターに戻すだけで一時的にネットに戻せるため切り戻しコストが低く、全宅プロキシを初めて試すユーザーに向いています。

ハードウェア要件について、mihomo 自体は CPU・メモリの要求がさほど高くなく、一般的なギガビット環境ではデュアルコア・メモリ512MB以上の機器で安定して動作します。家庭の帯域が500Mbpsを超え、ルール数も多い場合は、余裕のあるメモリとやや強めのCPUを用意し、ルールマッチングやコネクション数増加による転送ボトルネックを避けることを推奨します。ストレージは数十〜数百MB程度でコアと設定ファイルの日常運用に十分です。

システム環境の準備

ハードウェア構成によってシステム環境は異なりますが、進め方の考え方は共通しています。

1. システムアーキテクチャの確認:mihomo コアをダウンロードする前に、機器が amd64、arm64 か他のアーキテクチャかを確認します。アーキテクチャが合わないとバイナリが実行できません。
2. 実行環境の準備:Linuxベースのサブルーター(一般的なディストリビューションや OpenWrt 系ファームウェア)の場合、基本的なネットワークツール(iproute2、iptables または nftables)と起動スクリプト機能が揃っていることを確認します。サードパーティプラグインに対応したルーターファームウェアであれば、まず mihomo/Clash 用の既存プラグインパッケージがないか確認しておくと、手動コンパイルや依存関係の確認作業を省けます。
3. 競合コンポーネントの停止:以前その機器で別のプロキシや透過プロキシ方式を動かしていた場合は、既存の転送ルールや DNS ハイジャックルールが整理済みかを先に確認します。新旧のルールが重なると通信経路が乱れ、切り分けが困難になります。
4. 管理用アクセス経路の確保:導入前に SSH またはファームウェア標準の管理画面へのアクセスを通しておき、後でコアのログ確認やサービス再起動を行いやすくします。ネットワーク断が起きてから管理画面自体もプロキシルールの対象になっていて接続できないことに気づく、という事態を避けてください。

設定ファイルの配置と主要フィールド

mihomo が使用する設定ファイルは Clash 系設定の YAML 構造を引き継いでおり、主要フィールドには受信ポート、モード、DNS ブロック、プロキシルールが含まれます。この部分はデスクトップクライアントの「サブスクリプション読み込み」で内部的に行われている処理と本質的に同じで、ルーター層ではファイルパスの手動配置とサービスのライフサイクル管理が必要になる点が異なります。典型的な最小構成は以下のようになります。

mixed-port: 7890
mode: rule
log-level: info
tun:
  enable: true
  stack: system
  auto-route: true
  auto-detect-interface: true
dns:
  enable: true
  nameserver:
    - 223.5.5.5
    - 119.29.29.29
proxies: []
proxy-groups: []
rules:
  - MATCH,DIRECT

実際の運用では、proxies と rules のセクションは通常サブスクリプションリンクから取得したリモート設定に置き換えられ、ノード情報を手書きする必要はありません。サブスクリプションから生成された設定ファイルをコアの規定する設定ディレクトリに配置すると、起動時にそのファイルを読み込んでプロキシグループとルールテーブルを構築します。多くの導入例では設定ファイルを単独で保管し、コアの起動パラメータでそのファイルパスを固定指定しておくことで、サブスクリプション更新時に設定ファイルだけ置き換えれば済み、起動スクリプトを毎回調整する必要がなくなります。

ルールセクションの書き方はデスクトップ版と同じで、一般的な判定優先順位はドメインルール、IPルール、最後は MATCH による受け皿という形です。例えば日本国内のドメインは直接接続、特定サービスはプロキシ経由、その他は方策グループで振り分けるといった構成になります。ルール数が多くなってきたら、数千行のルールをメイン設定に詰め込むのではなく、rule-provider を使ってリモートのルールファイルを参照する方式にすると、更新もしやすくコア起動時の解析負荷も軽減できます。

透過プロキシモード:TUN とゲートウェイハイジャックの選び方

ルーター層導入で解決すべき核心的な課題は、接続機器が「意識せず」トラフィックを mihomo に渡せるようにすることです。よくある方式は2つあります。

TUN モードで全出口を引き受ける

サブルーターまたはファームウェア書き換え済みルーターで TUN モードを有効にすると、コアが仮想ネットワークカードを作成し、システムのルーティングテーブルを自動的に引き受けます。この機器を経由して転送されるすべてのトラフィックはまず mihomo に入り、ルールに従って振り分けられます。この方式は設定が比較的シンプルで、iptables の転送ルールを追加設定する必要がなく互換性も高いため、現在のルーター層導入で最も主流な引き受け方式になっています。設定は上記サンプルの tun.enable と auto-route フィールドに対応します。

ゲートウェイハイジャックと DNS 振り分け

LAN 内の他の機器に mihomo を動かしているこの機器をデフォルトゲートウェイとして指定させる(あるいはサブルーター側でだけデフォルトルートをそちらに向ける)ことで、機器の DNS リクエストと TCP/UDP トラフィックがすべてこの機器を経由して一括処理されます。この方式はネットワーク層でデフォルトルートや DHCP のゲートウェイアドレスを調整する必要があり、ネットワークの基礎知識がより求められますが、利点として接続機器側は完全にゼロ設定で、LANケーブルを挿すか Wi-Fi に接続するだけで自動的にプロキシ機能を得られます。これこそが「全宅プロキシ」が最終的に目指す効果です。

この2つの方式は排他的ではなく、実際の導入では「サブルーターで TUN を有効にして自身の転送トラフィックを引き受ける」+「LAN内の機器のゲートウェイをサブルーターに向ける」を組み合わせ、サブルーターを LAN 全体の統一出口にするケースが多く見られます。

自動起動と安定運用の維持

ルーターやサブルーターは通常長時間通電した状態で稼働するため、停電・再起動後にコアが自動的に立ち上がらないと家全体のネットワークがそのまま停止してしまいます。したがって自動起動は任意項目ではなく必須項目です。システムサービスマネージャーをベースにした機器では、コアの起動コマンドをサービスユニットとして記述し、システム起動時に自動実行、異常終了時に自動再起動する設定にするのが一般的です。ファームウェアのプラグイン体系を利用するルーターでは、多くのプラグインにすでに自動起動の仕組みが組み込まれているため、管理画面で「ルーター起動時に開始」を有効にするだけで済みます。

• 定期的にコアのログを確認し、ルールマッチングの異常やノード接続失敗のエラーがないかチェックして、「動いているように見えて実際には機能していない」状態が長期間放置されるのを防ぎます。
• サブスクリプション更新後は設定を再読み込みします(多くの導入ではホットリロードに対応しており、サービス全体を再起動する必要はありません)。これにより設定更新時の一時的なネット断時間を減らせます。
• 管理用アクセス経路には直接接続またはホワイトリストルールを残しておき、あるルール更新によって自分自身の管理画面にすらアクセスできなくなる事態を防ぎます。
• コアのバージョン更新のペースに注意します。mihomo は更新頻度が高く、新バージョンは通常プロトコル互換性の修正やパフォーマンス改善をもたらしますが、更新前にはリリースノートを確認し、設定フィールドの変更による起動失敗を避けることを推奨します。

デスクトップクライアント方式との使い分け

ルーター層導入とデスクトップクライアントはどちらか一方を選ぶ二択の関係ではなく、必要に応じて組み合わせるのに向いています。

• カバー範囲:ルーター層導入は一度で家全体の機器をカバーしますが、デスクトップクライアントはインストールしたその1台だけです。家にスマート機器が多い、あるいは訪問者が一時的にネットワークに接続することが多い場合、ルーター層導入のほうが1台あたりのコストが低くなります。
• 可視性と使いやすさ:デスクトップクライアントにはグラフィカルな画面、接続テスト、ノード遅延の一覧があり、問題が起きても自分で確認しやすい一方、ルーター層導入にはこれらがなく、切り分けはログとコマンドラインに依存するため、技術に詳しくないユーザーには扱いにくい面があります。
• 柔軟な切り替え:デスクトップクライアントはアプリごと、ウィンドウごとにいつでもプロキシ方策を切り替えられますが、ルーター層導入の方策はネットワーク全体に統一的に適用され、機器単位のきめ細かい差別化設定には追加のポリシールーティングの知識が必要です。
• 障害の影響範囲:デスクトップクライアントに問題が起きてもその1台にしか影響しませんが、ルーター層導入で問題が起きると、特にメインルーターに直接導入していた場合は家全体のネット断につながる可能性があります。これが前述のとおりサブルーター方式を優先的に勧める理由です。

よく見られる組み合わせ方は、テレビ端末やスマート機器など「個別にクライアントを入れにくい」端末にはルーター層導入で基本的なプロキシ機能を提供し、自分のパソコンやスマートフォンでは引き続きデスクトップ版やモバイル版のクライアントを使ってアプリ単位のきめ細かい振り分けを行う、というように両者が役割分担する形で、互いに置き換える関係ではありません。