OpenWrt と OpenClash をゲートウェイで使う狙い

ノートやスマホそれぞれにクライアントを並べて運用すると、運用ログの分散と接続単位でのルールゆれが増えやすくなります。OpenWrt ベースのソフトルータの背後にすべての端末を置き、ひとつの Clash メタコア／Mihomo 系レイヤーへ集める構成は、アプリを入れなくて済むLANクライアントも含めた共通ゲートウェイとして理にかなっています。本稿では OpenWrt での OpenClash 導入に焦点をあて、ブラウザ管理のLuci プラグインを起点に、アプリ画面上で読み込む設定プロファイルとサブスクリプションの考え方、そして初めて選択したノードが実効するところまでを具体化します。

ルーター側のセットアップには、フラッシュ済みフェームウェア、アーキテクチャ適合依存パッケージ、十分なフラッシュまたは USB パーティション、そして自分が契約するサービス側で発行されたインポート用 URLが必要になります。OpenWrt でのクラッシュ関連の Luci アプリによるフィルタリング設定は、プラグインメニューにあるルールセットや機能トグルによって段階的に触れられるため、すべてを一度に読み込まなくてよいというのも運用上の強みです。リモートワーク端末だけをプロキシに寄せて国内のテレビや NAS は直経路など、複数 VLAN をまたぐケースがある場合でも、上流をここでひとつのポリシーに束ねられるイメージを持ちやすくなります。

準備フェーズ：モデル・アーキ・容量とアクセス経路

事前に確認しておくとトラブルが半減するのが、実行 CPU（多くが mipsel、arm、x86 系いずれか）と、その版向けビルドの OpenWrt リリース、そして/overlay もしくは拡張マウント点の書き込み可能容量です。依存バイナリを含んだアプリ単体だけでなく、ログやダウンロードしたリストを保持するので、ギリギリの空きでの導入は後からのアップデートで詰みやすいです。WAN 側が PPPoE で固定されておらず、デュアル WAN 構成のときは上流の名前解決順と競合しないかにも目を向けます。初見で詰まりやすいのは別途入れている広告ブロック Dns 改変と転送チェーンの二重適用であり、競合しないように役割分担を決めておくと Luci での順序が頭に入ってきやすくなります。

OpenWrt 管理者画面には SSH コンソールと Luci の両線があり、プラグインパッケージ導入はシステムのソフトウェア画面からでも、ターミナルでの opkg update と opkg install ででも問題ありません。GUI を主軸にする読者には「ソフトウェア」カテゴリーでソースを最新化したあとリストを検索する流れで十分であり、コンソール側はログを貼れる利点だけ押さえると運用効率が上がります。メモリストレージへのシンボリックや外部ルート読み込みを使っている場合、アップデートでパッチが書き換わると復元ミスがあるため、アプリ側の自動バックアップ設定とあわせ手元でも日時付 YAML を退避させる運用も検討したいものです。

Luci で OpenClash パッケージを導入する

一般的な順序としては、(1) パッケージインデックスの更新、(2) 本体と記載 Dependencies の導入、(3)ブラウザ再読込や /etc/init.d 側のリスト反映確認——です。OpenWrt と OpenClash のインストールを語るとき、コミュニティ配布のアプリ単体とは別に、メタ／コア側の適合チェックがセットになっている構成がほとんどです。画面上に「未取得コア」を示す帯がある場合、その誘導に従い公式あるいは推奨ストレージへの取得を済ませるとサービス開始ボタンが有効になります。OpenClash プラグイン関連の項目はサービス状態、構成ファイルリスト、上流 DNS、ポリシーチェーン概要が同じ視界に並ぶので、順に左メニューを下へ辿れば迷子になりにくいです。

アップグレード互換についてはフェームウェア メジャーをまたぐときに Luci メタデータの残骸と実体ファイルのずれが出ることがあるため、問題が出たら一度アンインストールして依存も含め入れなおすのが時間対効果で早いことがあります。セキュアブートとは無縁でも、ソースを信頼できる場所だけに限定し、チェックサム確認が提供されているときは読み取って照合しましょう。外部リポジトリを足すときは競合しないよう公式と混ぜ方に注意してください。

メタ／コアの整合と運用ファイルの選択

OpenClash から見える「プロファイル一覧」には、自分で貼り付け生成したほかにもテンプレ残りが並ぶことがあります。OpenWrt とサブスクをつなぐ第一歩は、契約先が配る URL をアプリ側の入力欄にセットしインポートを押してローカルの YAML が生成されるところまでです。名前解決と TLS チェインで止まったら、上流の時刻ずれ証明書失効、およびルータ側の CA ストア不足をログで追います。サブスクを保存しても自動更新タイマを止めていたり、上流がアクセスごと署名を変える実装だったりするとリストが空白のままに見えるので、コンソールのフェッチログ行をひとつずつ見ることが近道です。サブスクリプション取り込みの一般論はブラウザ向けにも共通するため、並行読みで用語だけ揃えておくと迷いが減ります。

コアのバージョンとプロファイル側の機能フラグが食い違うとランタイムで警告が増え、そのまま機能がミュートになることもあります。画面にある「チェック」「更新」をワンセットで済ませ、必要なときだけ手動 ZIP を流し込む癖をつけると復旧が楽です。OpenWrt と Mihomo アップデート運用でも同じですが、自動で上書きする前に現在動いていた YAML を退避させるだけで心理的な安全マージンが大きくなります。

ランタイムモード／DNS と既存機能の両立の考え方

アプリ側で選べる転送タイプにはざっくり Tproxy と Redir 系の違いなど説明があります。自分のモデルでのカーネル転送機能の有効化状況、さらにはすでに dnsmasq と連携していたホスト名書き換えや別 DNS 転送プラグインの有無を踏まえると適合が読みやすくなります。OpenWrt と OpenClash と DNS：fake-ip 方式をオンにすると局所キャッシュとの整合が細かくなる一方、開発用途でホスト単位確認がしたいときは視認性優先もあります。このあたりの概念は単体環境での TUN モード総説と照らしつつ、ゲートウェイでは「上流クライアントがどの名前解決結果をキャッシュ済みか」まで含め読む癖をつけると切り分けが速くなります。

ファイヤウォールのゾーンはデフォルトの LAN→WAN と矛盾しないようにゾーン越えの許可リストを増やさないままサービス側が設定するフックを活用する構成がほとんどですが、手で iptables/nftables を弄っているときは競合しないかだけは必ずチェックしましょう。IPv6 が有効なネットワークだと DHCPv6 と RA の経路とも干渉しうるので、まずIPv4のみで検証から入る読者にはラクなことがあります。

ポリシーグループ確認とブラウザ・端末側の検証

プロファイル側に書かれた名前付きセットを Luci で開くと自動選択規則と手動切替リストが並びます。OpenWrt と Clash とアプリ側のグループ名は YAML の文字列依存なのでインポート直後だけでなく上流がテンプレ差し替えしたあともラベルを見直しましょう。LAN 下の単一 PC でだけプロキシを指定するときはポート番号競合や混合ポート構成を避け、アプリ画面上の推奨値にそろえるのが確実です。全体ゲートウェイにしたいときは DHCP で配っているデフォルト GW がルータ自身であることを改め確認し、そのルータのアウトゴーイングが OpenClash チェーン経由になるようサービス状態を点灯させます。ログでルール命中を追う話はゲートウェイでも応用効くので、アプリ側のイベントを開きつつ別ターミナルで tcpdump を張るときの観察ポイントが合います。

速度や遅延の体感はモデルにもよりますが、まず上流と下流の両方で同じ名前解決順を確認し、競合プラグインを切った最小構成で試すと環境依存の問題を見分けやすくなります。ストリーミングや UDP 音声はプロファイルのノード許可と上流の許諾両方が絡むため、ここだけ個別許可リストを足す構成も現場では見かけます。

よくあるつまずきと切り分け

OpenWrt OpenClash インストール周辺で頻繁に話題になるのは容量不足での中途解凍エラーです。ログに出る「書き込み不能」類はマウント一覧で実際どこへ展開されているか確認しつつ、アタッチメント領域の移行またはオーバレイ拡張を検討します。次によくあるのが上流時刻ずれ証明書で HTTPS フェッチのみ失敗するパターンで、単純な NTP 同期で直ることもあります。さらに OpenWrt と OpenClash とルールが効かないときはサービス順序だけでなく、クライアントがまだキャッシュ済み名前に引っ張られていませんか。dig やブラウザの開発者コンソールのネットワークタブでもう一段細かく追うと分岐がはっきりします。

十分なフラッシュ領域がない

USB または内蔵 eMMC が使えるモデルでは extroot 構成を読むだけでもアイディアが得られます。不可能なモデルでも不要言語パックや開発用ヘッダの削除だけでギリギリ足りることもありますが、ログ肥大に備えlogreadのローテ構成も忘れずに。

サービス競合または起動順

同一ホストでの別トラフィック処理アプリとの優先順位が噛み合わないときは、アプリ側の「起動遅延」や init スクリプトの並び替え検討、もしくは片方機能のスコープを狭めるしかないケースがあります。両方ともフル Transparent しない設計への割り込み回避も現実解です。

インポートは成功ログだがリストが空白

上流が返している本文がリスト形式でも Clash メタ側の読み取りフラグによっては空解釈されることがあり、アプリ側のバージョン更新とセットで読み直すと復旧します。並行してルールプロバイダのダウンロード失敗行があれば同一時刻で止めているだけの可能性があります。

開発リポジトリとドキュメントの参照について

プロジェクト側のソースや Issue でのディスカッションは深掘りすると有益ですが、初回導線としてはプラグイン側に同梱された README と推奨手順、アプリ画面上の状態表示をヒント優先順に並べましょう。デスクトップ向けにもまとめがある当サイトダウンロードページは各クライアントの位置づけ整理に有用で、ゲートウェイとは別レイヤでの比較材料になります。またルール思想を補強するなら 分流ルール関連の読みものと合わせると上流・下流両方での判断が読みやすくなります。

まとめ

ここまでの流れでは、モデル適合フェーム確認から OpenWrt と OpenClash の Luci 画面での導入、コアとプロファイル整列、OpenWrt サブスク インポート、ランタイムと DNS とファイヤウォールの両立視点、そのうえでのクライアント検証までを一続きとして整理しました。OpenWrt OpenClash インストールは一回通せば運用側の自動更新と上流契約側のリスト差し替えが主になりますが、最初の転送チェーン競合だけは環境ごとに差があるので最小構成から昇格させる姿勢が安定につながります。

一方でブラウザや PC だけに単体インストーラを並べ続ける構成は、アップデート波が来たときの適用順序のばらつきや、同一サブスクを複数端末へ貼ったときの状態の見えなくなりやすさという摩擦が残りやすくなります。ClashFast はそうした運用ノイズを減らす前提で一覧からの適切クライアント選定と接続状態の視認やすさに気を遣った導線を用意しており、ゲートウェイとは別レイヤでの補完にも向きます。もし複数プラットフォームをまたいだ安定運用も見据えているなら、自然な選択としてClash を無料ダウンロードして各環境向け一覧と比較してみてください。