家庭や少人数オフィスのソフトルーターとして OpenWrt を選ぶ理由のひとつは、標準の Web 管理画面 LuCI の上に拡張パッケージを載せやすいことです。そのなかでも検索需要が高いのが OpenClash と呼ばれる LuCI フロントエンドで、バックエンドには多くの場合 Clash Meta（別名で Mihomo と呼ばれるフォーク系実装）に相当するコアが載り、YAML のルールエンジンとプロキシチェーンをルーター常駐で回せます。本記事は「機種ごとの細かな書き込みボタン位置」よりも全体の線——OpenWrt のインストール、WAN／LAN とゲートウェイの役割、OpenClash と依存関係、カーネル種別の整合、購読 URL の取り込み——を日本語で一度つなぐことを目的にしています。実際の購読やノードの利用は、契約先の利用規約と法令に沿った範囲で行ってください。また機種固有のブートローダー操作はメーカー仕様差が大きいため、必ず自分のモデル向けの公式ドキュメントと復旧イメージを手元に置いてから作業してください。
OpenWrt と OpenClash が担う役割
OpenWrt はミニマムな Linux ディストリビューションであり、パケット転送、NAT、ファイアウォール、DNS、Wi-Fi ドライバといったゲートウェイ機能の土台を担います。対して OpenClash は、その土台のユーザー空間で動くプロキシ／ルールエンジンを LuCI から操作するためのレイヤーです。PC にだけクライアントを入れる構成では端末ごとの設定ばらつきやスリープ時の切断が課題になりやすい一方、ルーター側で出口戦略を一元化すると同一 LAN に繋いだ機器へゲートウェイ／DNS を配るだけで経路を揃えやすいという長所があります。反面、設定ミスは全クライアントの通信を巻き込むため、変更はセクションごとに切り、ログで確認しながら進めるのが安全です。
WAN／LAN と既定ゲートウェイを押さえる
WAN はインターネット側（上流 ISP や親機の LAN ポート）へ向くインターフェース、LAN は家やオフィス内部へ DHCP とスイッチングを提供する側です。OpenClash をメインゲートウェイにする場合、クライアントが獲得する既定ゲートウェイと DNS が OpenWrt の LAN アドレスを指している必要があります。バイパス構成（サイドルーター）では OpenWrt の WAN が親ルーターのサブネットからアドレスをもらい、OpenWrt の LAN は別セグメント（例：192.168.2.0/24）になります。このとき上流側でポート転送や静的ルートをどう扱うかで「外向きテストは成功するのに逆流だけ失敗する」ことがあるため、どのインターフェースを境界として NAT しているかを LuCI のファイアウォールゾーン表示とセットで理解しておくと復旧が速くなります。
ping と tracert／traceroute を軽く叩き、境界ホップが期待どおり OpenWrt を経由しているかを確認すると迷いが減ります。
ファームウェア書き込みと復旧前提（共通の注意点）
OpenWrt 本体は対応デバイス一覧とファクトリー／sysupgrade イメージの種類がページで明示されています。書き込みには TFTP、メーカー GUI からの転送、USB シリアル経由など機種固有の手順があり、本文ですべてを代替することはできません。ここで強調したいのは次の三点です。(1) 電源を落とさない・書き込み中に再起動しない。(2) 復旧用オリジナルファームや UART の情報を先に控える。(3) 最初から過剰なパッケージを詰め込まず、ベースが安定してから OpenClash を足す。ストレージが逼迫するとカーネルや GeoIP 類の展開に失敗し、症状だけが断片的に出ます。
LuCI と SSH：インストール後に確認すること
初期セットアップ後は LuCI でインターフェースのアドレスとゾーンを確認し、上流への接続が確立していることを見ます。CLI に慣れている場合は SSH で logread や ip route を併用すると、GUI と実状態のズレに気づきやすくなります。またNTP による時刻同期が機能しているかは購読 URL の TLS 検証にも効いてくるため、「証明書エラーばかり出るが別端末では問題ない」といったときの最初の切り分け候補にしてください。無線機能を使う場合は国コードやチャネル幅など規制系フィールドも早期に整え、後から OpenClash の DNS と競合しないよう名前解決の責務分界を意識します。
OpenClash（LuCI App）とパッケージ導入の考え方
実際の入手経路はビルドやフィードの方針で変わるため、特定 URL に縛らず自分の OpenWrt バージョンとアーキテクチャに一致した ipk を選ぶことが最重要です。LuCI から Software 画面で検索できる環境もあれば、作者リリースページから手動で opkg install する流れもあります。どちらの場合も依存ライブラリが自動で揃うかをログで確認し、不足しているとダッシュボードは開いてもデーモンが沈黙していることがあります。開発が活発なコンポーネントほど、内核と Luci プラグインの組み合わせバージョンが README に明示されているので、その表と自分の環境を突き合わせてください。
Clash Meta／Mihomo カーネルと名前の整理
検索語では Clash Meta と Mihomo が並列しがちですが、OpenClash の設定画面ではどの実行ファイルをコアとして呼ぶかが実務上のポイントです。ビルドによっては複数コアが同梱され、LuCI のラジオボタンで切り替えます。ここでファイルパスと権限ビットがずれると「更新は成功したのに起動しない」状態になりやすいので、アップデート後は一度実行ファイルの実体と設定画面の表示を突き合わせてください。またアーキテクチャが異なるバイナリを誤って配置すると当然実行できないため、uname -m の結果とパッケージ表記を常にセットで見ます。
依存関係：iptables／nft、DNS、バックエンドの競合
OpenWrt の世代によってデフォルトの防火墙スタックが iptables 寄りか nftables 寄りかが異なります。OpenClash は転送ルールを挿入するため、競合する別パッケージがすでに同じフックを占有していないかを確認します。DNS についても dnsmasq、AdGuard Home、上流フォワーディングなど誰が 53 番を握るかが重なるとループやタイムアウトが起きます。運用上は「OpenClash が faux-dns をListenしているポート」と「LAN クライアントが向かう DNS IP」を一枚のメモに書き出してから変更すると混乱が減ります。
初回起動とログで見るべき項目
サービスをオンにした直後は LuCI のステータス表示だけでなく プロセス生存とListen ポートを CLI で確認すると確実です。代表的にはミックスポートや Redir ポートが期待のアドレスにバインドされているか、エラー時にコアが落ちていないかです。ログに出る語はビルドにより微妙に違うものの、設定 YAML の文法エラー、ファイルパスの不存在、権限は共通のボトルネックです。設定をいじるたびにバックアップを取り、差分が読める状態を保つとロールバックが早くなります。
購読 URL の取り込みとプロファイル更新
プロバイダーが発行する HTTPS 購読を LuCI のサブスクリプション欄へ登録し、手動または定期更新で YAML を取得します。ラベルには契約プラン名や更新周期を埋め込んでおくと、複数線を持ったときに見分けがつきます。更新が失敗するときはHTTP ステータスコードとTLS アラート文言をログから拾い、WAN 側 DNS が購読ホストを正しく解決しているかを確認してください。社内ネットではキャプティブポータルや独自 CA により検証が落ちることがあります。またダウンロードできてもルール集合が古いと実効経路が想定と異なるため、更新後はプロキシグループの選択状態が意図どおりかを軽く見直します。
モード選択の全体像（ルール／グローバル／DNS の関係）
OpenClash は設定ファイルの書き方次第で挙動が大きく変わりますが、GUI ではしばしばルールベースとフォールバックの組み合わせが選べます。ゲーム機や特定ドメインだけ直進させたいときはルールの粒度が効きます。一方でトラブルシュート初期には過度に複雑なルールファイルを避け、購読だけが載った素朴な構成で外向き疎通を確認してから追記するのが安全です。DNS モードと fake-ip／redir-host の組み合わせは検索結果でも論点になりやすい領域なので、変更時はキャッシュを意識して段階的に進めてください。
親機あり構成での典型的なハマりどころ
親ルーターが既に DHCP を配っている場合でも、OpenWrt を別セグメントのゲートウェイにすることは一般的です。その際、二重 NAT により P2P やポート開放の期待が変わる点に留意してください。上流で静的 DHCP 予約をして WAN アドレスを固定すると、ログ解析やポート転送ルールが単純になります。また親機のDNS フィルタリングが購読ドメインを誤ってブロックしているケースもあり、WAN 側からの名前解決テストを挟むと切り分けが早いです。
性能とストレージ：小型機での現実的なライン
ARM の廉価ボードでも運用は可能ですが、ルールファイルや GeoIP データのサイズ、定期的な購読更新、ログ出力はフラッシュストレスになります。外部 USB ストレージへログやキャッシュを逃がせる構成もありますが、まずは余裕メモリと空きディスクを監視し、過剰なデバッグログを常時オンにしない運用が長持ちします。暗号化オーバーヘッドが気になる場合はルーター側で過度に高冗長なチェーンを組まず、実測でボトルネックを見ます。
動かないときの優先チェックリスト
- WAN が枯れている：上流リンク自体が落ちていると購読も再起動もすべて不安定に見える。
- 時刻と DNS：TLS エラーとタイムアウトの見かけ上の理由になりやすい。
- カーネルファイルと設定画面の不一致：更新後にパスが変わっただけの事例が多い。
- ゾーンとフォワーディング：LAN→WAN の許可が期待どおりか LuCI で再確認。
- 他製品との競合：同種の透明転送を二重に仕込んでいないか。
切り分けは感覚より順番です。上流疎通 → 本体プロセス → ポートバインド → 購読取得 → クライアント経路の順で見ると迷子になりにくくなります。
よくある質問
OpenClash が起動直後に止まる
A. カーネル実行ファイルの実在と権限、設定 YAML の文法、ディスク空きを確認してください。LuCI のエラー表示が乏しいときは CLI ログが早いです。
購読更新だけ失敗する
A. ルーターの時刻・DNS・上流フィルタを疑い、WAN から対象ホストへの HTTPS を単独で試験してください。
LAN 端末が経路を迂回する
A. ゲートウェイと DNS が OpenWrt を指しているか、別 NIC に静的設定が残っていないかを確認してください。
サイドルーターでポート開放が効かない
A. 上流でも転送が必要です。必要なら親機から OpenWrt WAN への転送を二段で整理してください。
ルーター運用を続けるならデスクトップ Clash との組み合わせも検討したい理由
単機能の商用 VPN アプリはウィザード完結で手早い反面、ドメイン単位の細かな経路制御や複数購読を YAML で再利用する柔軟さは限られがちです。ルーター側の OpenClash で LAN 全体の既定経路を整えつつ、開発用 PC では Clash Verge Rev のような GUI クライアントでターミナルや IDE のプロキシだけを局所的に上書きする、といった二段構えは現場ではよくある折衷です。外出先ではルーターの恩恵が受けられないため、モバイルやノートには別クライアントが必要になる点も頭に置いておくと運用設計がぶれません。
もし「ルーターだけで出口戦略を一本化したい」と考えている一方で、将来ノート単体でも同じルール思想を使いたいなら、Mihomo／Meta 系の設定ファイルの読み方を一度共通言語として覚える価値があります。Windows や macOS に閉じた手順書だけでは補えないのが OpenWrt の自由度であり、その自由度を事故なく使うにはログとバックアップの癖が効いてきます。