1 なぜルーター層に Clash を置くのか
Windows や macOS、Android に Clash 互換クライアントを入れる方式は、設定画面が見え、ログも取りやすく、試行錯誤に向いています。一方で、スマート TV はプロキシ欄が無い、ゲーム機はアプリストアに公式クライアントが無い、IoT は HTTPS すらまばら——といった端末が混在する家庭では、「端末ごとに設定する」だけではカバーしきれません。OpenWrt のような Linux 系ルーター OS 上で デフォルトゲートウェイに近い位置にプロキシ／透過転送を置けば、DHCP で配った DNS とルーティングを一括で整え、端末側の手作業を減らせます。
OpenClash はそのためのフロントエンドの一つで、Mihomo（旧 Clash.Meta）などのコアを OpenWrt のサービスとして束ね、iptables／nftables や TUN、DNS まわりの切り替えを Web UI から扱いやすくします。名称は「Clash」ですが、実際の設定言語はデスクトップの Clash Verge Rev と同系の YAML です。用語集やモードの整理は、ルーターでもそのまま参照できます。
2 前提：対応機種・フラッシュ・メモリ
OpenWrt は公式にサポートされたターゲットであっても、フラッシュ容量が極端に小さい機種では LuCI すら厳しく、OpenClash のような大型パッケージは入りません。実務では 最低でも数十 MB 級の空きと、ルールセットや Geo データを置ける RAM 余裕がある機種が無難です。チップセットが古くカーネルが追いづらい機種は、セキュリティアップデートの観点からも中長期運用は慎重に判断してください。
初めて OpenWrt を焼く場合は、メーカー純正ファームからの移行手順、バックアップ、シリアルコンソールの有無まで含めてリスクを把握してから進めるのが安全です。本稿は特定モデルの刷り込み手順には踏み込みませんが、「ルーターがブリックしたときの復旧手段」を用意してから試すことを強く推奨します。
3 OpenClash の位置づけ
OpenClash は OpenWrt 向けの LuCI アプリとして配布され、コアのダウンロード、設定ファイルの生成、実行ユーザーの切り替え、ファイアウォール連携、DNS の差し替えなどをまとめて扱います。ビルドやフィードの名称は時期により変わるため、利用中の OpenWrt バージョンと互換性があるリポジトリ／パッケージを選ぶことが重要です。アップストリームのリリースノートは、カーネルモジュール名や nftables 対応の変更点を読む価値があります。
設定画面は項目が多く、初見では圧倒されますが、考え方はデスクトップの Clash と同じです。proxies と proxy-groups、rules の階層を理解していれば、YAML を直接貼るか、購読 URL から生成するかの違いだけです。大規模な rule-provider を何本も有効にすると、メモリと初回起動時間に効いてくるので、家庭用途では「本当に必要なリストだけ」に絞るのが現実的です。
4 導入の流れ（概要レベル）
具体的な opkg コマンドやリポジトリ URL は環境依存が強いため、ここでは順序だけ示します。① OpenWrt を対応バージョンに揃え、② 必要な依存（ca-bundle、dnsmasq まわり、カーネルモジュールなど）を満たす、③ OpenClash パッケージを導入し LuCI にメニューが出ることを確認する、④ コア（Mihomo 等）を GUI から取得する、⑤ まずはルーター管理 UI へのログインが落ちない範囲で動作確認する——という段階を踏むと安全です。いきなり透明プロキシを有効にして SSH も遮断されると復旧が大変なので、コンソールやフェイルセーフの道を確保してください。
設定バックアップの習慣
ルールや購読 URL は資産です。OpenWrt の設定アーカイブに加え、生成された config.yaml の退避、Luci のエクスポートがあればそれも別媒体に保存します。アップデートのたびに差分が出やすいので、Git 管理できるなら尚良いです。
5 購読 URL とコアの整合
プロバイダーが Clash 形式の HTTPS 購読を出している場合は、その URL を OpenClash に登録し、更新間隔を適切に設定します。SS／V2Ray など別形式しか無いときは、先にデスクトップ側で Sub-Converter 等を使って YAML 化する流れが一般的です。手順の考え方は購読変換の記事と同じです。ルーター上で変換サービスを回すのは負荷とログ流出リスクがあるため、可能なら PC で整形してから貼り付ける方が無難です。
コアは Mihomo 系を選ぶ例が多く、デスクトップの Clash Verge Rev と挙動を揃えやすいです。バージョンを上げるときは、外部コントローラのバインドや API ポートが LAN に開いていないかも併せて確認してください。管理 API を WAN 側に晒すのは避け、必要なら SSH トンネルや VPN 越しに閉じます。
6 透明プロキシと TUN の整理
「透明プロキシ」とは、端末がプロキシを意識せずに送った TCP 接続を、ルーター上で傍受して Clash コアへ流し込む仕組みを指すことが多いです。実装は iptables／nft の REDIRECT や TPROXY、環境によっては eBPF 系の話題も出ます。OpenClash ではモード名やスイッチのラベルがアップデートで変わるため、利用中のバージョンのドキュメントを読み、どのチェーンにフックしているかを把握しておくとトラブル時に役立ちます。
TUN モードは仮想インターフェース側でトラフィックを取り込み、レイヤが異なるプロトコルまで含めて扱いやすい反面、カーネルモジュールや MTU、ハードオフロードの相互作用で「速いはずの回線が遅い」といった現象が出ることがあります。ルーター CPU が弱い場合は、透明プロキシと TUN のどちらが負荷に耐えるか実測し、必要なら別筐体への移行を検討します。
# 例：モードとポートは環境・コアにより異なります
mode: rule
tun:
enable: false # 透明プロキシ主体ならオフのことも
# redir-port / 透明転送の実体は OpenClash 側の firewall 連携に依存PC 上で TUN を試したことがある読者は、Clash Verge Rev の TUN 解説の考え方をそのままルーターに持ち込めます。違いは「ゲートウェイがルーター本体である」ことと、スループットが SoC 一本に依存する点です。
7 DNS ハイジャックと FakeIP
ルーターで分流するなら、端末がキャッシュした DNS 結果で「プロキシをすり抜ける」パターンを防ぐ必要があります。dnsmasq を置き換える／上流を Clash 側へ向ける、53 番をハイジャックする、といった設定は OpenClash と強く連動します。FakeIP や DoH を使う場合、テレビやゲーム機が期待する応答形式と矛盾しないか、ストリーミング視聴で地域判定がおかしくならないかを確認してください。
詳細なパターンはMeta コアの DNS 記事で扱っている通りで、ルーターでも同じ論点が立ちます。IPv6 が有効な WAN がある環境では、IPv4 だけ整えても AAAA で意図しない経路に流れることがあるため、ルーター側の IPv6 方針（無効化するか、ND プロキシとセットで設計するか）もセットで決めます。
8 旁ルーター（サイドルーター）とデフォルト GW
メインルーターをそのままにし、OpenWrt 機器を下流の二段目として置き、DHCP で「ゲートウェイ＝旁ルーター」を配る構成は、既存の VLAN やポート開放を壊しにくいです。メイン側で静的ルートを張る、旁ルーターの WAN を LAN ブリッジにする、などトポロジのバリエーションは複数ありますが、いずれも「どのサブネットのどのトラフィックを拾うか」を図に起こしてから設定すると迷子になりません。
逆に、メインルーター自身を OpenWrt 化して一括管理する構成は配線はシンプルですが、失敗時の影響半径が大きいです。家族が同じ回線を共有している場合は、メンテナンス窓とロールバック手順を決めておくと揉め事が減ります。
9 PC ゲートウェイ記事との関係
すでに公開しているSwitch／PS5 向け LAN プロキシゲートウェイは、PC の Clash を allow-lan と混合ポートで公開し、ゲーム機のプロキシ欄に書き込む方式です。ハード追加なしで試せる反面、PC がスリープすると経路が消える、UDP の扱いに限界がある、といった制約がありました。ルーター上の OpenClash は、常時起動の筐体にコアを載せられるため、家庭全体のデフォルト経路を一本化しやすいのが利点です。一方で刷り込みやアップデートのリスクはユーザー側に寄るため、「まず PC でルールを固めてからルーターへ移植する」という順序は依然として有効です。
サーバや VPS で常時 Mihomo を動かす場合の systemd 手順はLinux の記事を参照すると、YAML の責務分割やログの見方が近いです。ルーターは CPU が弱いので、同じ設定をそのまま持ち込むと詰まることがあります。
10 セキュリティと日常運用
ルーターは家の境界装置です。管理 Web を WAN に晒さない、強いパスワードと鍵認証、不要なサービス停止は基本中の基本です。OpenClash を有効にすると DNS やフォワーディングの挙動が変わるため、家族端末から「突然サイトに入れない」といったクレームが来やすくなります。変更前に告知し、問題が出たらすぐ戻せるバックアップを用意してください。
アップデートはセキュリティパッチのためだけでなく、OpenWrt 本体とパッケージの両方に留意します。メジャーアップグレードのたびに設定互換が壊れることがあるので、リリースノートを読み、ステージング環境が無いなら週末の昼間など復旧に時間を取れる枠で実施します。
11 トラブルシューティング
- Luci に入れない： フェイルセーフ起動や、事前に用意したシリアルコンソールでファイアウォールを一時緩和し、透明プロキシをオフに戻す。
- 一部端末だけ直連になる： その端末が固定 DNS（8.8.8.8 等）を直叩きしていないか、VPN アプリが別トンネルを張っていないか確認する。
- 速度が出ない： SQM／ハードオフロードと透過転送の相性、CPU 単核の限界、選んでいるアウトバウンドの地理的距離を疑う。
- ストリーミングだけ失敗する： ルールで該当 CDN が意図せず DIRECT／REJECT になっていないか、FakeIP と実 IP の取り違えをログで確認する。
- アップデート後に起動しない： コアバイナリとカーネルモジュールの組み合わせ、設定スキーマの変更をリリースノートで確認し、クリーンな最小 YAML で起動テストする。
12 まとめ
OpenClash on OpenWrt は、Clash 互換のルール分流をルーター層に持ち上げ、スマートフォン以外の端末まで含めて「設定の抜け漏れ」を減らすための現実的な選択肢です。透明プロキシと TUN、DNS ハイジャック、旁ルーターか一括置換か——どれを選んでも、ハードの余力と復旧手段が成功の鍵になります。まずは PC クライアントで YAML を固め、期待する挙動を確認してからルーターへ載せ替えると、夜中のブリック事故が減ります。
デスクトップ向けの GUI クライアントは、ルール編集やログ閲覧のしやすさで依然として強く、ルーター運用と併せて使う二段構えが現場では多いです。編集は手元のマシン、常時転送はルーター——役割分担をはっきりさせるとメンテナンスが楽になります。
ビルドの入手や各 OS 向けパッケージは ダウンロードページから辿ると、関連チュートリアルへ戻りやすいです。
