ルーターで Clash コアを直接動かす方法:OpenWrt とサブルーター構築の考え方
メインルーターとサブルーターという2つの構成で mihomo コアを直接動かす方法を紹介。ファームウェア選定、透過プロキシ経路、DNS ハイジャック、自動起動設定を網羅し、デスクトップクライアント方式との比較も解説します。
なぜ Clash コアをルーターに移すのか
デスクトップクライアントはクライアントをインストールしたパソコンだけでプロキシ機能が使える仕組みです。スマホやテレビボックス、ゲーム機で同じ振り分けルールを使いたい場合、それぞれにクライアントを入れるか、あるいはまったく対応できないかのどちらかになります。mihomo コアをルーターに直接デプロイすれば、プロキシ機能をネットワーク出口のレイヤーに落とし込むことになり、家中のすべての機器がソフトを一切入れずに、このルーターに接続するだけで自動的に振り分けルールが適用されます。これは多台数の機器がある家庭、スマートテレビ、アプリを入れられない機器(一部のテレビボックス、プリンターのネットワークモジュールなど)にとって特に意味があります。
この方法の代償は、設定のハードルがデスクトップクライアントより明らかに高いことです。ファームウェアの書き込み、透過プロキシ経路、DNS ハイジャックといった比較的低レイヤーな部分に触れる必要があり、どこか一箇所でも設定を誤ると家全体がネット切断になる可能性があるため、コマンドラインやネットワークの基礎知識に完全に不慣れな人にはおすすめできません。1台の機器だけを日常使いするなら、デスクトップやモバイルクライアントのGUI設定の方が明らかに楽です。「家中すべての機器で振り分けを統一する」ことが本当に必要になったときだけ、ルーター方式に手間をかける価値があります。
2つの構成:メインルーター直動作とサブルーター接続
ルーターに Clash コアをデプロイする方法は主に2種類あり、選ぶ前に自分のハードウェア環境と、どこまで手間をかけられるかを整理しておきましょう。
メインルーター直動作:家庭用ルーターを OpenWrt 化する
この方式は、家にある既存のルーター(あるいは書き込み対応の機種を新たに購入)を OpenWrt ファームウェアに書き換え、そのファームウェア上に mihomo コアと管理用プラグインを導入し、ルーター自体がプロキシ転送の全処理を担う方法です。利点は経路が最短で、追加のハードウェアが不要な点、LAN 内のすべての機器のトラフィックが自然にこのルーター出口を経由する点です。欠点は、ルーターの CPU とメモリに一定の要求があることです。mihomo の動作に加えてルールマッチングや DNS 解析を行うと、入門機種のプロセッサには小さくない負荷になり、既存ルーターの性能が不足していると、プロキシを有効にした際に通信速度が明らかに落ちたり、詰まったりする場合があります。ファームウェアの書き込み自体にも文鎮化(ブリック)のリスクがあるため、事前に機種が対応するファームウェアバージョンを確認し、復旧用の純正ファームウェアと書き込みツールを必ず保存しておきましょう。
サブルーター接続:小型機器を1台追加してプロキシゲートウェイにする
サブルーター方式は、既存のルーター(基本的なネット接続はそのまま担わせ、変更しない)に加えて、mihomo コアを専用で動かす小型PCやミニルーターを1台追加接続し、LAN 内の他機器のゲートウェイや DNS の向き先を変更することで、プロキシが必要なトラフィックをこのサブルーターに導いて処理させる方法です。よく使われるハードウェアは Raspberry Pi、ミニ x86 マシン、あるいは OpenWrt を書き込んだ2台目のルーターで、ブリッジモードで既存ネットワークに接続します。この方式ではメインルーターのファームウェアに触れる必要がなく、リスクとハードルはメインルーター直書き込みより低く、サブルーターの性能が足りなくなった場合は単独でハードウェアをアップグレードでき、メインルーターの基本的なネット接続機能には影響しません。「メインルーターに手を入れるべきか」で迷っている家庭ユーザーの多くにとって、サブルーターはより無難な出発点です。
サードパーティファームウェアの書き込みは、通常機器の既存設定を消去し、保証条項に触れるリスクもあるため、必ず事前にお使いのルーター機種が OpenWrt 公式の対応機種リストに載っているか確認し、純正ファームウェアパッケージをバックアップしておいてください。サブルーター方式はファームウェア書き込みを伴わないため、リスクの範囲がはるかに小さく、最初に試す選択肢としておすすめです。
透過プロキシ経路:トラフィックがどのようにルーターに引き渡されるか
ルーターレイヤーでプロキシを引き渡す仕組みの核心は透過プロキシ(Transparent Proxy)です。これはデスクトップクライアントのシステムプロキシや TUN モードと原理は通じていますが、実現方法が異なります。機器(スマホ、テレビボックス)自体は自分のトラフィックがプロキシされていることを認識せず、通常どおりリクエストを送信します。ルーターはネットワーク層でこのトラフィックを透過的に本体の mihomo プロセスへリダイレクトして処理し、処理後に転送します。クライアント機器側は完全に無自覚で、各機器で個別にプロキシアドレスを設定する必要はありません。
透過プロキシの実現はルーターOSのトラフィックリダイレクト機能に依存します。OpenWrt でよく使われる方法は、ファイアウォールルール(iptables または nftables)によって特定のポート範囲やプロトコルのトラフィックを mihomo がリスンしている透過プロキシポートに導き、さらに mihomo 設定ファイル内の tproxy-port または類似のフィールドと組み合わせて引き渡しを完成させます。この部分の設定は全体の構成の中で最もミスが起きやすいところで、ルールの記述ミスが起きると、機器のネット接続自体は正常なのにプロキシルールが一切効かない、あるいは逆にすべてのトラフィックが外に出られなくなる、といった直接的な結果を招きます。まずテスト用の機器で経路が正常に通っているか確認し、その後徐々に家中の機器へ適用範囲を広げることをおすすめします。
| 工程 | 役割 | よくある落とし穴 |
|---|---|---|
| ファイアウォールリダイレクトルール | LAN 機器のトラフィックを mihomo の透過プロキシポートへ導く | ルールの順序ミスで一部のトラフィックがプロキシを回避する |
| mihomo 透過プロキシポート | リダイレクトされたトラフィックを受け取りルールに従って振り分ける | ポートがリスン開始していない、または権限不足 |
| ルーティングテーブルとポリシールーティング | プロキシ後のトラフィックが正しく戻ることを保証する | マルチ NIC 環境でルーティングテーブルが競合する |
DNS ハイジャック:振り分けルールが機能する前提条件
透過プロキシはトラフィックの転送経路の問題を解決するだけで、プロキシルールをドメイン単位で精密に振り分けるには、DNS レイヤーでの連携も必要です。機器が直接プロバイダの DNS に問い合わせると、返ってくるのは実際の IP であり、mihomo は IP 帯や GeoIP ルールでざっくり判定するしかなく、サイト単位で別々のプロキシグループへ振り分けるような細かいドメインルールは機能しません。解決策として、ルーター上で LAN 内すべての機器の DNS 問い合わせを mihomo 内蔵の DNS サーバーにハイジャックし、mihomo 自身にドメイン解決を担わせて、解決結果とルールに応じてこの通信を直接接続にするかプロキシ経由にするかを決定させます。
この工程は OpenWrt では通常、dnsmasq の設定を変更するか、ファイアウォールルールで 53 番ポートへの問い合わせを強制的に mihomo の DNS リスンポートへ転送することで実現します。mihomo 設定ファイル内の対応フィールドには DNS サーバーアドレスや fake-ip モードの有効化などがあり、fake-ip はドメイン振り分けの精度をさらに高められますが、実際の IP を必要とする一部のシーン(たとえば LAN 内のサービス検出プロトコルなど)では互換性の問題が起きる可能性があるため、実際の利用シーンに応じて取捨選択が必要です。
dns:
enable: true
listen: 0.0.0.0:1053
enhanced-mode: fake-ip
fake-ip-range: 198.18.0.1/16
nameserver:
- 223.5.5.5
- 119.29.29.29上記は mihomo 設定ファイルの DNS セクションを簡略化した例です。実際のデプロイでは fake-ip の除外範囲や国内ドメインの直接接続リストなどのフィールドも合わせてより細かく調整する必要があり、各フィールドの詳しい意味は用語集ページで確認できます。
自動起動と安定運用の設定
ルーターとデスクトップパソコンでは使われ方が異なり、ルーターはほぼ 24 時間 365 日通電し続けるため、停電による再起動後は人手を介さず自動的にプロキシサービスが復旧する必要があります。OpenWrt で mihomo の自動起動を設定するには、通常 /etc/init.d/ 以下に procd の規約に沿った起動スクリプトを作成し、service mihomo enable でシステムサービスとして登録します。これによりファームウェアの再起動後にプロセスが自動的に立ち上がります。サブルーター方式で汎用の Linux ディストリビューションを使う場合は、通常 systemd で対応する .service ファイルを作成し、Restart=on-failure を設定して、プロセスが異常終了した際に自動的に再起動するようにします。
自動起動のほかにも、長期の安定運用では次の点に注意が必要です。サブスクリプションの更新に定期実行タスクが設定されているか、ログファイルが無限に肥大化してストレージを圧迫していないか、メモリ使用量が稼働時間とともに増え続けていないか(メモリリークは一部の古いコアバージョンで発生したことがあるため、コアのバージョンは最新を保つことをおすすめします)。サブルーターのような独立した小型マシンの場合は、mihomo のプロセス状態を定期的にチェックするウォッチドッグスクリプトを設定し、異常時に自動的に立ち上げ直すようにしておくと、深夜にサービスが落ちても誰も気づかず、翌朝家中の機器がネット異常に気づく、といった事態を避けられます。
デプロイ完了後は次の順で確認しましょう。まず mihomo プロセスが正しくポートをリスンしているか確認し、次にファイアウォールのリダイレクトルールが機能しているか(テスト機器から既にプロキシ経由と分かっているサイトへアクセスして確認)、最後に DNS ハイジャックの経路が正しいか(nslookup 系のツールで解決結果が fake-ip 帯になっているか確認)を確かめます。この3つすべてが通ってから、家中の機器のゲートウェイを切り替えることをおすすめします。
デスクトップクライアント方式との比較
ルーター方式とデスクトップクライアント方式は互いに置き換える関係ではなく、シーンに応じて組み合わせて使うのが適しています。家に常用の機器が1〜2台しかなく、それだけにプロキシが必要な場合は、デスクトップクライアント(Clash Verge Rev や FlClash など)を1つ入れて GUI で設定すれば数分で完了し、コマンドラインやファームウェアに触れる必要はありません。しかし家の機器数が多く種類も雑多で、特にテレビボックスやゲーム機、スマートスピーカーのようにクライアントを自分でインストールできない機器にも振り分けルールを適用したい場合は、ルーター方式がすべての機器を一度に網羅できる唯一の方法になります。
もう一つ考慮すべきは保守コストです。デスクトップクライアントの更新は新バージョンをダウンロードして再インストールするだけですが、ルーター上のコアのアップグレードは多くの場合バイナリファイルを手動で置き換えたり、ファームウェアパッケージを再度書き込んだりする必要があり、操作の手順はより煩雑で、問題が起きた際の切り分けもより手間がかかります。一般ユーザーが本番稼働中のルーターに直接大きな変更を加える前には、まずテスト環境や予備機器で一度確認しておくのが得策です。多くの家庭ユーザーにとって、より現実的な組み合わせは、メイン機器にはデスクトップクライアントを入れて柔軟性と速やかな更新を確保し、家に複数機器を統一して振り分けたいという本当のニーズがある場合にのみ、別途サブルーターを1台構築してその役割を担わせる、という二者択一ではなく相互補完のスタイルです。
ルールや設定はどこから入手するか
ルーター上の mihomo であれデスクトップクライアントであれ、ルールセット、ポリシーグループ、サブスクリプションリンクの書き方は同じ mihomo 設定文法であり、ルーター専用の特別な形式が別に存在するわけではありません。つまり、既にデスクトップクライアントで動作確認済みの設定ファイルは、理論上そのままルーター側の mihomo インスタンスに移して使うことができ、透過プロキシのポートや DNS リスンアドレスといったルーター特有のフィールドだけを追加すれば済みます。ポリシーグループやルール分類といった概念に初めて触れる場合は、まずデスクトップクライアントで設定ロジックを整理し、その後ルーター環境へ移行することをおすすめします。そうすれば問題が起きた際に、ルールの記述ミスなのかルーターの経路設定の問題なのかを判断しやすくなります。