OpenWrt に OpenClash を入れる：購読インポートから全屋プロキシまで段階的に
家族のスマホ・PC・ゲーム機まで、同じ家の機器をまとめてプロキシ出口に乗せたいとき、デスクトップの Clash よりルーター側で Clash 系コアを動かすほうが運用しやすい場面があります。OpenWrt 上の OpenClash（luci-app-openclash）は、Web UI（LuCI）から購読の取り込み・モード切替・ログ確認まで一気通貫で扱えます。本記事ではサブスクリプションのインポート手順の考え方、メインルーター運用とサブルータ（いわゆる旁路由）運用の違い、そして PC クライアントではあまり表に出ないDNS・ファイアウォール・転送の注意点を整理します（固有名詞の UI ラベルはビルドやスキンで多少異なるため、画面は「項目の意味」として読み替えてください）。
なぜルーターで Clash 系を動かすのか
PC 1 台だけなら、Windows 用 Clash や macOS の Verge Rev で十分なことが多いです。一方、LAN 内の複数端末に同じルールと出口を適用したい、端末ごとにプロキシ設定を触りたくない、といった要件ではデフォルトゲートウェイ配下のトラフィックをルーターで捕捉する設計が向きます。OpenWrt はパッケージ管理と fw3／nftables、dnsmasq などが揃っており、Clash の TUN や Redir と組み合わせやすいのが利点です。
すでに「PC の Clash を mixed-port で LAN に開放する」構成は、LAN 共有の記事で扱っています。ルーター型の OpenClash は、ゲートウェイを向け先にする／透明プロキシで奪うという点でスケールの置き方が異なり、ファイアウォールのゾーンとフォワーディングが表に出てきます。
トポロジ：メインルーターか、サブルータ（旁路由）か
よくある二通りを押さえておくと、以降の DNS とデフォルトルートの説明が素直になります。
- メインルーター直書き換え：WAN から入る回線に OpenWrt 単体を直結し、そのルーターが DHCP のデフォルトゲートウェイになる。設定は一本化できるが、既存の ISP ルーターを挟む構成を変える手間がかかる場合がある。
- サブルータ（旁路由／ダブル NAT 近傍）：既存のメインルーターの下に OpenWrt 機を置き、特定の端末だけこのサブの LAN IP をゲートウェイにする、または静的ルートで一部トラフィックを流す。既存ネットを壊しにくい反面、二重 NAT や上位ルータの DNS 上書きに注意が要る。
どちらでも OpenClash は動きますが、「誰が DNS を握るか」と「クライアントのデフォルト GW がどこを指すか」がズレると、接続ログでは通っているのにブラウザだけ開かない、といった症状が出やすくなります。旁路由では、メイン側の DHCP が端末に自分を DNS として配っていると、Clash 側の fake-ip や DoH 設定と噛み合わないことがあるため、DNS の配布先を意識的に揃えるのが近道です。
インストールの流れ（イメージ）
機種名・ファームウェアの世代ごとに「推奨パッケージの入れ方」は異なりますが、多くの場合は次のような段取りになります。ここでは順序の理解用に示します。
- OpenWrt のバージョンとアーキテクチャ（aarch64、x86 など）を確認する。
- 公式／コミュニティの手順に従い、OpenClash に必要な依存（コアや iptables／nft 周り）を満たす。
luci-app-openclashを導入し、LuCI に OpenClash のメニューが出ることを確認する。- サービスが起動したら、まずはログとバージョン表示でコアが期待どおり動いているか見る。
ストレージが小さいルーターでは、コアの種類を絞る・ルールセットを肥大化させすぎない、といった運用面の制約も出ます。常時稼働させる前提なら、発熱とメモリ使用量も見ておく価値があります。
購読（サブスクリプション）のインポート
GUI では「プロファイル／購読 URL／プロバイダ」などの名称で、HTTPS の購読リンクを登録する画面があります。ポイントは次のとおりです。
- URL の形式：トークン付きの長い URL はそのまま貼り、余計な改行やスペースを混ぜない。
- 自動更新：更新間隔は負荷と鮮度のバランスで。失敗ログが続くときは一時的に間隔を伸ばし、TLS エラーか 403 かを切り分ける。
- ルールセットのマージ：リモートの巨大ルールとローカル追記の優先順位に注意。最終
MATCHや GEOIP が意図せず上書きされないか、インポート後にざっと確認する。
購読自体の考え方は、デスクトップ Clash と同じですが、ルーターでは設定の文法エラーで WAN 全体が不安定になるリスクがあるため、変更は小さな単位で入れ、都度バックアップを取る習慣が安全です。
動作モードと「全屋」への載せ方
OpenClash では、実装とビルドによりラベルは異なりますが、ざっくり Redir／TUN／ファイアウォール連携といった選択肢があります。全屋プロキシにしたい場合は、LAN→WAN のフォワードと DNS の流れが同じ絵として頭に入っているかが重要です。
| 観点 | ルーター（OpenClash）で気にしやすい点 |
|---|---|
| トラフィックの入口 | ブリッジ／ルーティング、ゲスト VLAN、隔離 SSID があると例外が増える |
| DNS | dnsmasq と Clash の DNS モード（fake-ip 等）の二重解決、DoH の向き先 |
| NAT とループ | Hairpin やポート開放が絡むと挙動が変わる。テストは有線クライアントから |
PC クライアントとの違い
デスクトップでは「システムプロキシ」や「TUN ドライバ」が主役になりがちです。ルーターでは fw のチェーンと DHCP が配る DNS が同じ舞台に乗り、ここが噛み合わないと DNS 記事で述べたタイプの不具合が起きます。
DNS とファイアウォールでハマりやすい所
fake-ip を使う構成では、クライアントが取得した仮想 IP と、実際に出口で解決される名前の対応がズレると「一部のアプリだけ失敗」が起きます。ルーターでは dnsmasq のリダイレクトや上流 DNS の指定が重なるため、OpenClash のドキュメントに沿って「誰が上流に問い合わせるか」を一本化することが多いです。
ファイアウォールでは、LAN からルーター自身への転送、ルーターから WAN へ、そして OpenClash が作る仮想インタフェースまわりの許可が論点になります。ゾーン（lan／wan／vpn など）の定義がファームプリセットと異なる場合、テンプレ通りにチェックを入れても期待どおりに流れないことがあるため、変更後は ping→DNS→HTTPS の順で切り分けると早いです。
リモート管理と公開ポート
管理 UI を WAN 側に晒さない、SSH は鍵認証にする、不要なポート開放をしない——ルーターは常時オンラインなので、クライアント PC より攻撃面が大きいと考えてください。
動作確認の順番
一気に「全屋プロキシ」へ寄せると切り分けが難しくなるので、次の順で確認するのがおすすめです。
- ルーター自身から
pingと名前解決（nslookup等）が通るか。 - 有線でつないだ 1 台の PC で、意図した出口 IP が返るか（検索エンジンで「IP 確認」など）。
- 同じ SSID のスマホで、キャプティブポータルやプライベート DNS（Android）が干渉していないか。
- 必要ならゲストネットワークや IoT VLAN を別ポリシーに分ける。
よくある質問
旁路由にしたら二重 NAT で速くなくなった
物理的なホップが増えるだけでなく、DNS が二重にかかったり、メインルータの QoS が先にかかることがあります。計測は有線で行い、メイン／サブのどちらで詰まっているかを切り分けてください。
一部の端末だけプロキシに乗らない
静的 IP や別 DHCP サーバ、端末側の「プライベート DNS」や VPN アプリが優先されている可能性があります。ゲートウェイと DNS の実値を端末のネットワーク詳細で確認してください。
ルール更新でストレージが足りない
外部ルールの本数を減らす、軽量なセットに差し替える、USB ストレージで overlay を伸ばす、といった対処が現実的です。
チェックリスト
- トポロジ（メイン／サブ）とデフォルト GW、DNS の配布が説明できる。
- 購読 URL の更新ログにエラーが残っていない。
- ファイアウォールと OpenClash のモードが意図どおり連携している。
- 主要端末で HTTPS と UDP（必要なサービス）が期待どおり。
- 設定ファイルのバックアップを取ったうえで本番運用に入る。
まとめ
OpenWrt 上の OpenClash は、購読を取り込みルールを回すという意味ではデスクトップの Clash と近い一方、全屋へ広げるときのボトルネックは DNS とファイアウォールの設計に現れやすいです。トポロジを誤魔化さずに書き出せれば、トラブル時の切り分けも速くなります。個別端末で細かく調整したい場合は、引き続き各 OS のクライアントと組み合わせてもよいでしょう。