スマートフォンやノートPCごとにクライアントを入れる方式でも問題はありませんが、家族や複数端末を同じポリシーで揃えたいときは、ルーター側に出口を一本化するほうが運用が楽です。本記事では、すでに OpenWrt が載ったミニPCや単機能ルータを サブルーター（二段目） として置き、そこで Clash Meta（Mihomo） を動かして ゲートウェイ経由の透明プロキシ と LAN内の分流 を実現するまでの流れを、家庭向けの前提で整理します。
デスクトップ単体の手順は Linux 向けの Clash 設定記事、ルール表現の基礎は ルール構文の深掘り、設定全体の設計は Clash Meta の完全ガイド と線がつながります。ここでは「ルーターに載せるとき特有のネットワークの組み方」に焦点を当てます。
一、なぜサブルーター＋ゲートウェイなのか
メインルータ（光回線直結の親機）をそのままにし、WAN側を親のLANに接続したOpenWrt機 を別セグメントの「出口役」にする構成は、既存の固定電話やキャリア設定をいじらずに済むことが多いです。クライアントから見ると デフォルトゲートウェイがサブルーターのLANアドレス になれば、以降のTCP/UDPはそこを経由します。Clash側で REDIRECT／TUN などによりトラフィックをコアに流し込めば、端末ごとにアプリを入れなくても 同一のルールセット を適用できます。
ポイントは「誰がDNSを答えるか」と「ゲートウェイとDNSを同じポリシーに縛れるか」です。ゲートウェイだけClash配下にしてDNSだけ端末直叩き、というズレがあると、名前解決と実通信の経路が食い違い、分流が意図どおりにならないことがあります。ルーター運用では DHCPで配るDNSもサブルーター側に寄せる か、少なくとも 53番への問い合わせを捕捉 する設計が安定しやすいです。
二、物理配線とIP設計のざっくり像
典型例として、親ルータのLAN（例：192.168.1.0/24）に、OpenWrt機の WAN を接続します。OpenWrtの LANブリッジ 側は別サブネット（例：192.168.2.0/24）にし、家族端末は主にこちらに接続します。OpenWrtのWANは親から DHCPクライアント でアドレスをもらうか、親側の空きアドレスに 固定 します。重要なのは、家族端末の デフォルトゲートウェイが192.168.2.1（OpenWrt LAN） になっていることです。
親ルータの配下にだけ端末が残る場合でも、該当端末の静的設定でゲートウェイをOpenWrt LANに向ける、あるいは親の DHCPオプション でゲートウェイを上書きできる機種なら、同様に「出口の一本化」が可能です。メーカーごとにUI差は大きいので、ここでは 自宅のルータ管理画面で「既定ゲートウェイ／DNSの配布」がどこで決まるか を先に確認してください。
三、OpenWrt上でClash Metaを置くときの選択肢
OpenWrtでは、LuCI拡張やスクリプトで Clash系バイナリ を常駐させる構成がよく知られています。パッケージ名や手順はフォークや時代で変わるため、ここでは固定の画面操作に縛らず、「Mihomoコア＋設定ディレクトリ＋起動スクリプト」 という抽象度で捉えます。実装としては、コミュニティ製の統合パッケージを使う方法と、自前で /etc/mihomo などに展開して init／procd で起動する方法があります。
コアの設定ファイル（config.yaml）では、ルータ用途なら redir-port／tun／mixed-port のどれを主に使うか、allow-lan 相当のLANからの管理接続を許すか、bind-address をどう置くかが論点になります。また、ストレージが小さい機種では RULE-SET の更新頻度やキャッシュ に注意し、ログ出力を絞るとフラッシュへの書き込みが減ります。詳細キーは Clash Meta の設定解説 を参照してください。
四、透明プロキシ（リダイレクト／TUN）のイメージ
透明プロキシ とは、クライアントがプロキシを意識せず、ゲートウェイでトラフィックをコアへ転送する方式です。Linuxでは iptables／nftables でマークやREDIRECTを張り、Clashの redir ポートへ流すパターンが古典的です。Clash Meta では TUNモード を使い、カーネルに仮想インタフェースを立ててルーティング側から吸い上げる構成も選ばれます。ルータではカーネル・ドライバ・CPU負荷のバランスで、どちらが安定かは環境差が出ます。
# Conceptual nftables/iptables flow (illustrative only; adapt to your build)
# LAN -> gateway -> redirect to clash redir-port OR tun interface captures forwarded trafficどちらの方式でも共通するのは、フォワーディングが有効 で、かつ ループやDNSの再帰で自分自身を叩きすぎない ことです。OpenWrtのファイアウォールゾーン（lan／wan）と、Clashがlistenするインタフェースの関係を整理し、管理用Webにだけアクセスを絞るなど、誤ってWAN側にプロキシが晒れないようにします。
五、DHCP・DNSと「分流」の現実的な線引き
「分流」には二つのレイヤーがあります。一つはClashの ルール（DOMAIN／GEOIP／RULE-SET） による出口選択。もう一つは家庭内での 端末グループ分け です。後者を厳密にやるなら、VLANやSSIDごとにサブネットを分け、それぞれ別のdhcpオプションやポリシールーティングを当てることになりますが、一般家庭ではまず 全員同じ出口ポリシー に寄せ、必要な端末だけ静的ルートや例外を足すほうが現実的です。
DNSについては、ルータの dnsmasq をClashの上流に繋ぐ構成や、53番をClashに渡す構成など、派生パターンがあります。いずれにせよ 端末が勝手に8.8.8.8へ直行しない よう、IPv6がある環境では AAAA と IPv6 DNS の経路もセットで確認してください。IPv6が有効なのにIPv4だけClash、という状態はトラブルの温床になりがちです。
六、動作確認とよくある詰まり
まずサブルーター自身から 名前解決と外向き通信 が期待どおりかを確認し、次にLANクライアントで ゲートウェイとDNS が意図どおりかを見ます。親ルータ側で AP隔離 や ゲストSSID が有効だと、セグメント間で期待した転送ができないことがあるので、試験時はシンプルなSSIDに接続してください。
よくある論点は次のとおりです。(1) フォワーディング未許可 でLAN→WANが通らない、(2) MSS/PMTUD まわりで特定サイトだけ遅い、(3) ハードウェアオフロード がパケットをすり抜け透明プロキシの外に出す、(4) 二重NAT によるポートマッピングの混乱（ゲームやP2Pで顕在化）、(5) サブスクURL失敗 によるコアの再起動ループ。ログと ip route、OpenWrtの ステータス画面 を併用して切り分けます。
七、まとめ：出口を一本にしたときのメリット
サブルーターでClash Metaを動かし、ゲートウェイとDNSを揃えると、スマホ・PC・ゲーム機を個別に設定し直す回数が減り、ルール更新も一箇所 で済みます。Linuxマシン単体のTUN構成（Linux の記事）と思想は共通で、違いは「ネットワークの境界がルータのLANにあるか、PCのローカルか」です。家庭の事情に合わせて境界を選べばよく、本記事の構成はその中間に位置する実用解です。
同種の仕組みのなかでも、Clash Meta 系はルール表現とコミュニティの蓄積が厚く、長期運用での読み替えもしやすい面があります。ルータに載せるほど、設定の再現性とバックアップの習慣が成果を左右します。