OpenClash の使い方：OpenWrt へのインストール、サブスクリプションのインポート、家全体のプロキシ設定

このチュートリアルでは、まずルーター本体を動作させ、その後にサブスクリプションと家全体への接続へ進みます。最初に「ステータス → 概要」で OpenWrt のバージョン、CPU アーキテクチャ、空きメモリを記録し、「システム → バックアップ / アップグレード」から設定をエクスポートしてください。ルーターは元々ストレージに余裕がないことが多いため、パッケージのインストールが途中で失敗しないよう、先に /overlay の空き容量を確認します。

まず SSH 経由で次の読み取り専用コマンドを実行します。command -v opkg から出力がある場合だけ、本記事の opkg によるインストール手順を続けてください。デバイスに apk しかない場合は opkg コマンドを無理に使わず、OpenClash の最新リリースページにある apk 向けの説明に従ってインストールします。

ダウンロードには vernesong/OpenClash のリリースページだけを使用してください。LuCI では「システム → ソフトウェア → パッケージをアップロード」から公式 ipk をアップロードしてインストールできます。SSH を使う場合は、同じファイルを /tmp/openclash.ipk へ転送します。

OpenWrt 23.05 以降では firewall4 と nftables の組み合わせが一般的ですが、古いファームウェアでは引き続き iptables が使われている場合があります。次の二組の依存関係から、自分のファイアウォールに合う一組だけを選び、両方を同時にインストールしないでください。

インストール完了後に LuCI を更新すると、「サービス → OpenClash」に入口が表示されます。「プラグイン設定 → バージョン更新」を開き、コアのビルドがルーターのアーキテクチャと一致することを確認してから、Meta コアをダウンロードまたは更新します。

コアを手動で配置する場合、公式に指定されたディレクトリは /etc/openclash/core/、ファイル名は clash_meta です。この手順が完了していなければ、luci-app-openclash のページが開いてもトラフィックは処理できません。

OpenClash のホームへ戻ってサービスを起動し、実行ログを確認します。プロセスが数秒後に終了する場合は、サブスクリプションをインポートする前に、ログに従って依存関係の不足、空き容量不足、exec format error を解決してください。プラグイン、コア、ログの三項目がすべて正常になって初めて、インストール段階は完了です。

「設定ファイルのサブスクリプション」を開き、サービス提供者から受け取った Clash または Mihomo のサブスクリプションアドレスを追加して、一度手動更新します。正常にインポートできた場合は、ファイルの更新日時が変わり、ポリシーグループとノードが表示され、設定チェックに合格し、ステータスページの現在の設定にも更新したファイルが表示されます。

ページに処理完了と表示されてもノードが空のままなら、ダウンロードログを確認します。HTTP 401、403、ログインページへのリダイレクト、プランに関する案内、空ファイルは、サブスクリプション内容を正常に取得できていないことを示します。YAML の行番号、unknown field、group not found は解析上の問題です。トラブルシューティング時は URL 内の個人 token を隠してください。

OpenClash の Fake-IP、Redir-Host、TUN、混合モードは、それぞれ異なるトラフィック取り込み要件に対応するもので、すべて同時に有効にすれば完全になるわけではありません。初回は現在のプラグインが推奨する一般的なモードを使い、一台のコンピューターから接続記録を作成してから、一部アプリの互換性問題へ対処します。

Fake-IP はコアが早い段階でドメインを取得してルールを適用するのに役立ちますが、内部ネットワークのドメインや一部のアプリは除外が必要になる場合があります。Redir-Host は実際の名前解決結果を返すため、動作を理解しやすくなります。TUN はシステムプロキシを使わないアプリのトラフィックも多く取り込めますが、VPN、ポリシールーティング、ハードウェアアクセラレーションとも競合しやすくなります。

モードを切り替えた後は、テスト用コンピューターでネットワークアドレスを再取得し、DNS キャッシュを消去してから、同じサイトへアクセスします。古いキャッシュを残すと、新しいモードが機能していないと誤判定しやすくなります。

OpenClash がスマートフォン、テレビ、NAS のトラフィックを処理できるかどうかは、プラグインページの動作表示ではなく、各デバイスのデフォルトゲートウェイによって決まります。OpenWrt が主ルーターなら LAN デバイスは元々そこを通ります。サブルーターの場合は、ゲートウェイを OpenWrt に設定したデバイスだけが OpenClash へ入ります。

サブルーターの初回テストでは、一台のコンピューターだけでゲートウェイと DNS を変更します。通常のウェブサイト、プロキシが必要なサイト、ルーターの管理ページをすべて開けることを確認してから DHCP を変更してください。家中のデバイスを一度に切り替えると、DNS やファイアウォールの設定に問題があった場合、管理ページさえ開けなくなる可能性があります。

OpenWrt を主ルーターにする場合、通常は DHCP がその LAN アドレスをデフォルトゲートウェイ兼 DNS として端末へ通知します。サブルーターのテスト段階では、一台のコンピューターへサブルーターのアドレスを手動で入力し、確認後に主ルーターの DHCP から指定デバイスへ通知できます。同じサブネット上で二つの DHCP サービスが同時にアドレスを配布すると、信頼できる冗長化ではなく、不安定な接続になります。

ブラウザのセキュア DNS、Android のプライベート DNS、一部のテレビアプリに組み込まれた DoH は、ルーターを迂回する可能性があります。トラブルシューティング時はいったんこれらの独立した経路を無効にし、問い合わせが dnsmasq と OpenClash を通るようにしてください。ルールが安定して一致した後で、どの暗号化 DNS を再び有効にするか決めます。

IPv6 も併せて確認する必要があります。デバイスが公開 IPv6 を取得している一方、OpenClash が IPv4 しか取り込んでいない場合、一部の接続は IPv6 から直接出ていきます。この場合は、断続的な直接接続をすべてノードのせいにせず、IPv6 のルーティングと名前解決を明示的に処理してください。

ルーター本体は接続できても下流のコンピューターが接続できない場合は、DHCP、ゲートウェイ、ファイアウォールの転送を優先して確認します。ドメインが失敗して IP リクエストには応答がある場合は、次に DNS を調べます。接続記録が現れているのに送信時のエラーが出る場合だけ、ルールとポリシーグループへ戻ってください。この順序で対処するほうが、OpenClash を何度も再起動するより速く解決できます。

コンピューター一台とスマートフォン一台が安定してから、テレビ、ゲーム機、スマートホーム機器を追加します。新しい種類のデバイスを加えるたびに元のゲートウェイと DNS を記録し、問題が起きたら、まずその種類のデバイスを直接接続へ戻してください。家庭内ネットワークが復旧した後なら、ログとルールを落ち着いて確認できます。

DHCP を最終変更する前に、OpenClash の停止、元の DNS の復元、failsafe への移行方法を記録します。サブスクリプション更新、ファームウェアのアップグレード、コアの置き換えはいずれも動作を変える可能性があります。OpenClash に依存しない管理経路があれば、一度のプラグイン障害で家全体がオフラインになる事態を防げます。