ルーター・旁路ルーターで mihomo を直接動かす構成ガイド：アーキテクチャ選びと設定の要点

まず導入目的を決める：ルーター上の mihomo に何を任せるか

Windows、macOS、スマートフォンで Clash のGUIクライアントを使う場合、通常はその端末だけがプロキシ対象になります。mihomo のコアをルーターや旁路ルーターに配置すると、通信の入口をLANゲートウェイへ移せます。テレビ、ゲーム機、スマートスピーカーなど、クライアントをインストールしにくい機器もルールに従って振り分けられます。mihomo は Clash Meta の流れをくむコアで、Clash 形式の YAML 設定を読み込み、ルールマッチング、プロキシグループ、DNS、TProxy、リダイレクト、TUN などに対応します。

ルーターへの導入で重要なのは「コアを起動すること」ではなく、パケットが確実にそこを通り、正しい経路で戻ることです。完全な通信経路には少なくとも、LAN機器がゲートウェイへ送信する、ルーティングルールが対象通信を mihomo に渡す、コアがルールに従って直接接続またはプロキシ出口を選ぶ、応答が正しい経路で元の機器へ戻る、という4段階があります。プロセスを起動しただけで透過プロキシのルールがなければ、LAN機器が自動的に mihomo を使うことはありません。

メインルーターと旁路ルーターの主な違い

メインルーター構成は経路が最も明確です。LANクライアントのデフォルトゲートウェイが mihomo を動かす機器そのものなので、ファイアウォールはどの通信を透過プロキシのポートへ渡すかを判定するだけで済みます。一方、旁路ルーター構成では「なぜクライアントが旁路ルーターへパケットを送るのか」という追加の問題に答える必要があります。一般的には、対象機器のデフォルトゲートウェイを旁路ルーターのアドレスに変更するか、メインルーターで送信元アドレスに基づくポリシールーティングを設定します。クライアントのDNSだけを旁路ルーターへ向けても、通常のTCP・UDP通信が自動的に旁路ルーターを経由することはありません。

ファームウェア、アーキテクチャ、ハードウェア資源の選び方

mihomo にはCPUアーキテクチャごとの実行ファイルがあります。導入前にルーターの商品名ではなく、uname -m でシステムのアーキテクチャを確認してください。よくある結果は aarch64、armv7l、x86_64、mips です。ダウンロードするファイルはシステムと一致していなければなりません。たとえば64ビットARMのファームウェアなら通常はARM64ビルドを使いますが、32ビットのファームウェアをインストールした機器では、CPUが64ビット対応でもARM64ファイルを直接実行できません。

ファームウェアに必要な基本機能

• Linuxカーネルがポリシールーティングに対応し、システムで ip rule と ip route を利用できること。
• ファイアウォールが nftables または iptables に対応し、透過プロキシに必要な TProxy モジュールを利用できること。
• 設定、ルールセット、GeoIP、GeoSite データを保存できる永続書き込み領域があること。
• OpenWrt の procd や一般的なLinuxの systemd など、起動時サービスを登録できること。
• システム時刻とDNSが正常に動作すること。そうでない場合、サブスクリプション更新、TLS接続、ドメインルールに問題が生じる可能性があります。

OpenWrt 23.05以降の一般的なビルドは firewall4 と nftables が中心です。古い手順にある iptables コマンドをそのまま混在させないでください。導入前にLuCIの「システム」→「ソフトウェアパッケージ」で、TProxy、nftables、ポリシールーティング関連のコンポーネントが存在するか確認できます。SSHから nft list ruleset を実行して、現在のファイアウォール構成を確認することも可能です。コマンドが見つからない場合は、mihomo の設定を何度も変更するのではなく、先にファームウェアのコンポーネントを補完してください。

メモリ、ストレージ、CPUの実用的な目安

コア本体は負荷の一部にすぎません。設定内のルール数、GeoSite データ、DNSキャッシュ、接続数、管理画面のリソースもメモリを消費します。128MBの機器でも軽量な設定なら動作しますが、大規模なルールセット、fake-ip、多数の同時接続を有効にすると余裕はほとんどありません。基本的な出発点としては256MBが扱いやすく、512MB以上あれば広告ブロック、DNSサービス、監視コンポーネントも同時に動かしやすくなります。

以下は、RK3399 6コアのARM64機器、メモリ4GB、OpenWrt 23.05.5、mihomo v1.19.10を使ったLAN内テストの結果です。回線は300Mbps、下流クライアントはギガビット有線接続、設定には約8.6万件のドメイン・IPルールを含めました。数値は規模感の目安であり、暗号方式、ノードまでの距離、ファームウェアのビルドが異なる環境で再現されることを保証するものではありません。

100Mbps回線と少数の端末ならCPU要件は高くありませんが、ギガビット回線、WireGuard、複雑な暗号化、多数のUDP通信では負荷が大きく増えます。ソフトウェアルーターでは、LANポートが同じバスを共有していないか、USB NICがボトルネックになっていないかも確認してください。CPUクロックだけではスループットを判断できません。AES命令、カーネルドライバー、冷却性能も継続的な処理能力に影響します。

透過プロキシの方式：TProxy、リダイレクト、TUN

ルーター側でよく使われる通信の取り込み方式は REDIRECT、TProxy、TUN です。REDIRECT は主にTCPを処理する比較的シンプルな方式ですが、UDPを完全にはカバーできず、コアが認識する宛先アドレスの扱いも変わります。TProxy はTCPとUDPを透過的に取り込み、元の宛先情報を保持できるため、Linuxルーター環境でよく使われます。TUN は仮想NICでIP通信を受け取る方式で概念は分かりやすい一方、性能の低いルーターではコンテキストスイッチやプロトコルスタックのオーバーヘッドが大きくなりがちです。

TProxyポートとポリシールーティング

mihomo の tproxy-port は、透過プロキシ通信を待ち受けるだけです。ファイアウォール側で対象パケットにマークを付け、ポリシールーティングによってマーク済みの通信をローカルのループバックインターフェースへ送る必要があります。待ち受けポートには 7893 がよく使われますが、ポート番号に決まりはありません。設定、nftables ルール、サービス権限が一致していれば動作します。

mixed-port: 7890
tproxy-port: 7893
allow-lan: true
bind-address: "*"
mode: rule
log-level: info

external-controller: 127.0.0.1:9090
secret: "独立した管理用シークレットを設定してください"

dns:
  enable: true
  listen: 127.0.0.1:1053
  ipv6: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16

mixed-port: 7890 は、LAN内でHTTPまたはSOCKSプロキシを一時的に手動テストする用途に使えます。ただし他の機器からアクセスさせる場合は、ファイアウォールで送信元ネットワークを制限してください。コントロールインターフェースは 127.0.0.1:9090 での待ち受けを推奨します。リモートの管理画面が必要な場合は、管理下のリバースプロキシまたはSSHポートフォワーディング経由でアクセスし、WANへ直接公開しないでください。

TUNを検討するタイミング

ファームウェアに完全なTProxyモジュールがない場合や、ポリシールーティングを手作業で記述する量を減らしたい場合は、TUNを検討できます。mihomo のTUN設定では通常、自動ルートとインターフェース検出を指定します。しかしルーターがWAN、LAN、ダイヤルアップ、ブリッジを同時に担う場合、自動検出で意図した出口が選ばれるとは限りません。導入後はデフォルトルート、TUNのルーティングテーブル、ローカルネットワークを確認し、特にルーターの管理アドレスや上流ゲートウェイがTUNへ送られないようにしてください。

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  strict-route: true
  dns-hijack:
    - any:53
    - tcp://any:53

stack: mixed は一般的な開始点ですが、プラットフォームの対応状況はコアのバージョンによって変わります。dns-hijack を有効にする前に、LANの53番ポートを dnsmasq、AdGuard Home、別のリダイレクトルールが同時に取り合っていないか確認してください。実際の構成では、dnsmasq にLANの53番ポートを引き続き待ち受けさせ、特定の問い合わせだけを mihomo の 127.0.0.1:1053 へ転送できます。これにより、DHCPのドメイン名やローカルホスト名は引き続き dnsmasq で管理できます。

メインルーターへの導入：障害範囲をサービス層に限定する

メインルーター構成では、すべてのクライアントがもともと機器を経由するため、端末ごとにゲートウェイを変更する必要はありません。安全な有効化手順は、まず mihomo を通常の混合プロキシとして起動し、127.0.0.1:7890 が利用できることを確認します。次にテスト端末1台へ透過プロキシのルールを追加し、最後にLAN全体へ広げます。こうすれば、YAMLやルールに誤りがあっても、ルーターの基本的なNATとDHCPは動作し続けます。

1. ルーターには、たとえば有線管理ポートや透過プロキシを経由しない管理端末など、直接インターネットへ接続できる管理経路を1つ確保してください。
2. テストクライアントには固定DHCPリースを割り当て、送信元IPに基づくルールを追加しやすくします。
3. まずそのクライアントのTCP通信を取り込み、次にUDP、DNS、IPv6を検証します。
4. 直接接続するサイト、プロキシ経由のサイト、LAN機器へのアクセス、ルーターの管理画面がすべて正常であることを確認します。
5. ロールバック可能なファイアウォール設定を保存してから、対象範囲を段階的に広げます。

IPv6は見落とされやすいポイントです。LANクライアントがグローバルIPv6アドレスも取得しているのに、透過プロキシがIPv4しか処理しない場合、一部のアプリがIPv6で直接通信し、ルールがランダムに効かないように見えることがあります。単純にIPv6をすべて無効にするのではなく、IPv6を完全に取り込む、対象ドメインにIPv4アドレスを返す、またはネットワークの準備が整うまでRAとDHCPv6の層で統一して無効にする、のいずれかを明確に選んでください。設定の ipv6: true は mihomo のDNSと接続機能でIPv6を許可するだけで、ファイアウォールルールを自動的に補完するものではありません。

メインルーター構成のロールバック設計

透過プロキシサービスが停止した状態で、ファイアウォールが通信を 7893 へ送り続けると、クライアントはネットワークに接続できなくなります。起動スクリプトは、まずコアを起動して待ち受けポートを確認し、その後で透過プロキシのルールを読み込むべきです。停止スクリプトでは、先にルールを削除してからプロセスを終了します。OpenWrtではprocdにプロセスを監視させ、再起動ポリシーを設定することもできますが、高速な無限再起動は避けてください。設定の構文エラーがあると、CPUを消費し続け、ログも急速に埋まります。

旁路ルーターへの導入：ゲートウェイ、戻り経路、シングルアーム構成

旁路ルーターは通常、メインルーターと同じサブネットに配置します。たとえばメインルーターが 192.168.10.1、旁路ルーターが 192.168.10.2 です。テスト用PCのデフォルトゲートウェイを 192.168.10.2 に設定する場合、旁路ルーターでIPフォワーディングを有効にし、プロキシ対象外の通信やプロキシ後の通信を 192.168.10.1 へ正しく転送する必要があります。この構成では、旁路ルーターがクライアントのゲートウェイであり、mihomo の実行場所でもあります。

シングルアームの旁路ルーターはLANインターフェースを1つだけ持ち、入出力通信が同じ物理ポートを通ります。配線はシンプルですが、戻り経路には特に注意が必要です。メインルーターが応答パケットを直接クライアントへ返す一方で、要求パケットだけが旁路ルーターを経由すると、状態追跡が非対称になることがあります。一般的な対処は、旁路ルーターが転送する通信を送信元アドレス変換するか、メインルーターにクライアントのサブネット宛ての静的ルートを追加することです。前者は設定しやすい反面、クライアントの元のアドレスが隠れます。後者はアドレス情報を保持できますが、メインルーターに正確なルート設定機能が必要です。

クライアントを旁路ルーター経由にする3つの方法

• ゲートウェイを手動指定：1～2台だけを変更するテスト向けの方法です。クライアントのゲートウェイを旁路ルーターに向け、DNSは旁路ルーターまたは指定したLAN内DNSを利用できます。
• DHCPで旁路ルーターをゲートウェイとして配布：ネットワーク全体の移行に向いています。ただし、ネットワーク内でアドレス配布を担当するDHCPサービスは1系統に明確化し、競合するゲートウェイがクライアントへ配布されないようにしてください。
• メインルーターのポリシールーティング：メインルーターで、クライアントIP、MACに対応する固定リース、またはサブネットに基づき通信を旁路ルーターへ転送します。グループ単位の有効化に向いていますが、メインルーターのファームウェア機能に依存します。

旁路ルーターとメインルーターが同じブロードキャストドメインへ無秩序にDHCPを配布する構成は避けてください。旁路ルーターにDHCPを任せる場合は、メインルーターの該当インターフェースでDHCPを無効にするか、両者を別のVLANに分けます。移行中は、ゲートウェイをメインルーターに固定した管理用PCを1台残しておくと、旁路ルーターの設定に失敗しても両方の管理画面へアクセスできます。

設定ファイル、サブスクリプション、ルールセットの配置

mihomo は永続化されたディレクトリから設定を読み込むようにします。OpenWrtでは、メイン設定を /etc/mihomo/config.yaml、プロキシプロバイダーのファイルを /etc/mihomo/providers/ に保存する構成が一般的です。実行時キャッシュや大容量データベースは /var/lib/mihomo/ またはマウントしたストレージに置けます。唯一の設定ファイルを /tmp に置かないでください。OpenWrtの /tmp は通常メモリ上のファイルシステムで、再起動すると内容が消えるためです。

/etc/mihomo/
├── config.yaml
├── providers/
│   ├── primary.yaml
│   └── backup.yaml
└── rules/
    ├── direct.yaml
    └── proxy.yaml

/var/lib/mihomo/
├── cache.db
├── country.mmdb
└── geosite.dat

サブスクリプションURLは proxy-providers に記述し、mihomo に一定間隔で更新させられます。ルーターのフラッシュメモリには書き込み寿命があるため、更新間隔を短くしすぎる必要はありません。多くの環境では interval: 21600、つまり6時間から始めれば十分です。ルールセットは変更頻度に応じて12時間または24時間に設定できます。毎分取得すると上流へのリクエストが増えるだけでなく、不要な書き込みやログも発生します。

proxy-providers:
  primary:
    type: http
    url: "https://example.invalid/subscription"
    path: ./providers/primary.yaml
    interval: 21600
    health-check:
      enable: true
      url: "https://www.gstatic.com/generate_204"
      interval: 600

上記のドメインは設定構造を示すための例です。導入時には実際のサブスクリプションURLへ置き換えてください。設定ファイルには通常、アクセス資格情報が含まれるため、サービスユーザーと管理者だけが読み取れるように権限を制限します。YAMLを編集したら、まずコアが提供する設定チェックを実行し、その後で現行ファイルを置き換えてください。インデントにはスペースを使い、プロキシグループが参照するプロバイダー名、ルールセット名、アウトバウンド名も完全に一致させる必要があります。

自動起動、ヘルスチェック、ログによるトラブルシューティング

手動コマンドは初回検証に向いていますが、長期運用ではサービスマネージャーに任せるべきです。OpenWrtでprocdを使う場合、サービススクリプトに実行ファイル、作業ディレクトリ、設定ディレクトリ、標準出力、再起動ポリシーを指定します。一般的なLinuxの旁路ルーターではsystemdを使い、After=network-online.target などでネットワークの準備完了を待てます。サービスが正常に起動しただけでは透過プロキシが機能しているとは限りません。ポート、ファイアウォールルール、ポリシールーティング、DNSも確認してください。

推奨する起動チェックの順序

1. mihomo -t -d /etc/mihomo を実行し、設定を解析できるか確認します。
2. サービス起動後に ss -lntup を使い、7890、7893、9090、1053のうち実際に有効なポートを確認します。
3. ip rule と ip route show table all を使い、ポリシールーティングのテーブルを確認します。
4. nft list ruleset を使い、通信マーク、プライベートアドレスの許可、透過プロキシへの転送を確認します。
5. テストクライアントから、ドメインアクセス、IPアドレスへの直接アクセス、UDPアプリ、LAN機器へのアクセスをそれぞれテストします。

設定ミスは通常、起動ログにフィールドのパスと行番号として表示されます。OpenWrtではLuCIの「ステータス」→「システムログ」で確認でき、logread -e mihomo を実行して見ることもできます。プロセスは存在するのにクライアントが接続できない場合は、まず透過プロキシのポートが待ち受けているか確認します。ドメインだけ失敗するなら、上流DNSと53番ポートの経路を確認してください。TCPは正常なのにゲームや音声通話が失敗する場合は、UDPがTProxyを経由しているか確認します。ルーターの管理画面にアクセスできない場合は、LANのプライベートアドレスが誤って取り込まれていないか確認してください。

アーキテクチャ選びの結論：機能数ではなく運用コストで決める

既存のメインルーターに十分なCPU、メモリ、保守しやすいファームウェアがあり、家庭内ネットワークの構成もシンプルなら、メインルーターで mihomo を直接動かすと中間層を減らせます。デフォルトゲートウェイと透過プロキシの経路も明確です。導入時は管理経路を確保し、まず1つのテストIPで有効化してから、LAN全体へ広げてください。

メインルーターが通信事業者の管理下にあり、ファームウェアの拡張性が限られている場合や、プロキシ障害を基本的なインターネット接続から切り離したい場合は、旁路ルーターが適しています。「クライアントのゲートウェイを旁路ルーターに向ける」か「メインルーターでポリシー転送する」かを1つ選び、DHCP、戻り経路、DNSを事前に整えてください。複数のルールを重ねて偶然つながる状態に頼るのは避けます。

TProxy は機能の揃ったLinuxルーター環境に適しており、TCPとUDPを同時にカバーできます。TUNは仮想NICで通信を一元的に取り込みたい場合や、ハードウェアに十分な余裕がある機器に向いています。どちらを選んでも、安定運用の原則は同じです。設定を永続化し、ノード接続に迂回経路を設け、サービスとファイアウォールを順序どおりに起動し、ロールバック経路を確保したうえで、1台のクライアントから項目ごとに検証します。