なぜルータ層の Clash なのか

PC やスマホ単体で Clash 系クライアントを動かす構成は手軽ですが、LAN 内の複数端末を同じポリシーに載せたい場合、いちいち端末へ導入するよりゲートウェイに一本化するほうが運用が楽になることが多いです。ソフトルータに OpenWrt を入れ、その上で OpenClash（多くの場合、裏側は Clash Meta／Mihomo コア）を動かすのは、その代表例です。本稿の焦点は「インストール手順の画面キャプチャの羅列」ではなく、ブリッジ（AP）にしたあとも、デフォルトゲートウェイと DNS の鎖がどこでつながるかを押さえ、国内向けトラフィックをわざわざプロキシに乗せないための考え方までを、実務の言葉でそろえることにあります。

ルータ層では、上流の ONU／親ルータ、VLAN、IPv6、そして OpenWrt 側の firewall と dnsmasq が同時に絡みます。どこか一箇所でも「DNS だけ別ルート」「デフォルト GW だけ別機器」といったズレがあると、症状はブラウザだけ、ゲームだけ、といった形で現れがちです。まずはパケットがどのインターフェースから出るかと、名前解決が誰の手を通るかを分けて観測するのが近道です。

ℹ 整理：本稿は家庭向けの一般的な構成を想定した説明です。事業者回線・社内ポリシー・輸入機器の認証要件など、環境固有の制約がある場合は、契約と法令に沿ってから適用してください。

ブリッジ構成でもゲートウェイはどこか

OpenWrt 機器をブリッジ／AP モードにすると、L2 で上流ルータとつながり、無線／有線は同一セグメントのように見えます。それでも端末がインターネットへ出るときには、デフォルトルートを配る機器（多くは上流の DHCP サーバ）が存在します。ここでよく起きるのが、「OpenClash は動いているのに、端末の DNS が上流の 192.168.x.1 のまま」「IPv6 が有効で、DNS だけ別経路」といった中途半端な取り込みです。OpenClash 側の「リダイレクト」や「ファイアウォール連携」は、まさにこのギャップを埋めるための仕組みですが、上流とポートの衝突、IPv6 の RA、クライアントの静的 DNSが邪魔をすると、見かけ上だけ直っていないように見えます。

形態 押さえるポイント
ゲートウェイ型（NAT ルータ） LAN 側で DHCP を切り、OpenWrt がデフォルト GW と DNS を配る設計にしやすい。上流は単なるモデム／ブリッジに寄せられることが多い。
ブリッジ／AP 型 L2 は透過でも、DNS とデフォルト GW は上流の設定に引っ張られやすい。OpenClash の DNS ハイジャックや iptables／nft 連携とセットで見る。

OpenWrt と OpenClash の導入の流れ

実際のメニュー名やパッケージ名は版差があるため、ここでは順序だけを固定します。（1）対応ファームと必要パッケージ容量の確認、（2）初期アクセスと LAN アドレスの衝突回避、（3）OpenClash のインストールとサービス起動、（4）サブスクリプションまたはプロファイルの取り込み、（5）動作モード（redir／TUN 等）と競合する機能の整理、の五段です。いきなり購読 URL を入れる前に、ルータ単体で SSH／LuCI に安定して入れるところまで戻せるバックアップ（設定エクスポート、ファームの手元保管）を取っておくと安全です。

OpenClash は LuCI から有効化するタイプが一般的ですが、肝はコアのログにエラーが出ていないかと、使用するポートが dnsmasq や他の機能と被っていないかです。競合は「DNS ポート」「透明プロキシ／TUN の取り合い」「IPv6 の処理」に集中しがちです。コアの YAML を直接触るより先に、GUI の「動作モード」と「DNS 関連」の説明を読み、自宅のトポロジ（単層 NAT か、二重 NAT か）に合わせて選ぶと迷子になりにくいです。

⚠ 注意：機種ごとに無線ドライバや offload の挙動が違います。説明にない項目を無理に真似せず、利用中の OpenClash／コアのドキュメントを優先してください。

DHCP で配る DNS と「リダイレクト」

端末が「ルータの LAN アドレスを DNS サーバとして使う」状態にできれば、名前解決は OpenWrt 上の dnsmasq → OpenClash の DNS リスナ、という鎖に乗せやすくなります。しかし現実には、スマホの Private DNS、Windows の「暗号化 DNS」、ブラウザの DoH が割り込みます。対策は二段構えが現実的です。DHCP で配る DNS をルータに固定する努力に加え、外向きの 53／853／443 への DNS をファイアウォール側でコアへ寄せる（いわゆるリダイレクト）ことで、取りこぼしを減らします。どこまで強制するかは家庭内の運用と端末の許容範囲次第です。

ブリッジ構成では、上流 DHCP が配る DNS が変わらないことがあります。その場合でも、OpenClash が提示する「DNS リダイレクト」「ブリッジ用の追加オプション」などを有効にしつつ、実際に端末がどの IP に問い合わせているかを tcpdump やルータの接続ログで確認すると、設定ミスの当たりが早いです。上流の管理画面で DHCP の DNS を手で固定できるなら、OpenWrt の LAN アドレスへ寄せるのも有効です。

Concept: client DNS path (illustrative) 
# Client resolver chain (conceptual — adjust to your build)
# Client -> router LAN IP:53 (dnsmasq) -> OpenClash DNS listener -> Mihomo/Clash Meta core
# If client uses DoH/DoT directly, you may need firewall redirect or per-app settings.

コアの dns: と fake-ip の整合

OpenClash の背後では、結局 dns: ブロックの設計が体験を決めます。nameserver と fallback、fake-ip-filter、nameserver-policy の役割は、PC 向けクライアントのときと同じですが、ルータではLAN 名・プリンタ・NASが絡みやすい点が増えます。細部は Clash Meta（Mihomo）DNS の実践手順 に譲りますが、OpenWrt では「コアの listen アドレスとポートが dnsmasq の forward と矛盾していないか」を最初に確認してください。

enhanced-mode: fake-ip を使う場合、ローカル FQDN が仮想 IP に載ると、NAS や管理画面だけが静かに壊れます。プライベート帯や *.lan 系は fake-ip-filter とルール側の DIRECT をセットで見るのが定石で、端末側の挙動は Fake-IP と LAN の記事 と線でつながります。ルータでは Sniffer やハイジャックの有無も重なるため、ログを一画面で追える UI を選ぶと切り分けが速くなります。

国内トラフィックをプロキシに乗せない

「国内サイトが遅い／銀行アプリが不安定」といった報告の多くは、国内向け IP やドメインまで遠回りのプロキシに流していることが原因です。購読ルールが GEOIP や geosite ベースであっても、順序と集合の更新タイミングで挙動は変わります。基本形はシンプルで、プライベート帯と国内向けは DIRECT（または専用ポリシー）に寄せ、残りをプロキシ系グループへ回す、です。ルールの書き方全般は ルールとルーティングのベストプラクティス を参照しつつ、OpenClash では「ルール更新」「プロファイルの切替」「ログでのヒット順」をセットで確認すると、意図しない迂回を早く潰せます。

DNS 側でも、国内ドメインを意図したリゾルバへ寄せる nameserver-policy が有効な場面があります。ただし「国内＝必ず信頼できる」ではないため、購読元と自宅回線の実測に合わせてチューニングしてください。ここは文化・回線事情の差が大きいので、特定の公開リスト名に依存しすぎず、自分の端末で何がヒットしているかをログで見る姿勢が安全です。

詰まったときの切り分け

  1. ループや全不通：二重 NAT／誤ったデフォルト GW／TUN と既存の VPN クライアントの競合を疑う。上流のポート転送と OpenClash のモードを一度単純化する。
  2. DNS だけおかしい：端末が DoH に直行していないか、dnsmasq の forward がコアの listen とズレていないか、IPv6 の DNS が別経路になっていないかを順に見る。
  3. 国内だけ遅い：ルール順で DIRECT になる前にマッチしていないか、プロキシ側のノード遅延ではなくルール誤配かをログで確認する。
  4. LAN だけ死ぬ：fake-ip とプライベート帯、または静的ホスト名の取りこぼし。フィルタと rules の両面を見る。

切り分けの基本は、レイヤを混ぜないことです。L3 のルート、L4 のプロキシ、DNS、アプリ独自の DoH——どこで分岐しているかを一つずつ潰すと、設定ファイルの行数が多くても迷いません。一般的な DNS の考え方は よくある質問 も参照してください。

まとめ

OpenWrt 上の OpenClash は、単体 PC の Clash と同じコア概念を、ゲートウェイと dnsmasq、ファイアウォールという追加レイヤと束ねる作業です。ブリッジにしても、誰がデフォルト GW と DNS を配るかがぶれないようにし、コアの dns: と rules: を同じ前提で読むと、国内直結とプロキシ迂回のバランスが取りやすくなります。手元の PC で挙動を確認したうえでルータに載せ替えると、切り分けの往復も減ります。

ルータ構成は端末アプリより変更コストが高い反面、一度そろえば家族端末まで一括で効きます。クライアント側では、ルールとログを同じ画面から扱える製品を選ぶと試行が楽になります。一般的な単一トンネル型 VPN と比べ、ドメインとポリシーを細かく分けられる点が Clash 系の強みです。

→ PC やスマホでまず同じルールと DNS の感触を確かめたい方は、Clash を無料ダウンロードし、接続ログとプロファイル編集を同じ導線から試してから、OpenWrt 側の OpenClash へ載せ替えると安全です。