OpenClash で購読の更新が失敗します。まず何を見ればよいですか？

LuCI のログで TLS エラーや DNS 解決失敗、403／404 を確認します。URL の期限切れや User-Agent 制限、ルーター本体の時刻ずれもよくある原因です。詳細なログ読みの発想は PC 向けの購読記事も参考になります。

遅延テストは全部タイムアウトに見えます。設定が壊れていますか？

テスト先 URL がブロックされている・WAN が不安定・ノード側が ICMP を返さない構成などでタイムアウトばかりになることがあります。別ノードや別テスト URL で切り分け、実アプリの体感とあわせて判断してください。

策略グループでノードを変えても特定サイトだけ変わりません。なぜですか？

ルールで別の策略へ固定されている・DNS が別経路・ブラウザのセキュア DNS が有効など、出口以外の要因がよくあります。ルールの優先順位と DNS モードを確認し、必要なら DIRECT／GLOBAL 系の落ちどころを見直します。

OpenWrt OpenClash運用

1. 本稿の前提と対象読者

対象はOpenWrt 系ファームウェアに OpenClash が導入済みで、いまから日常的な運用画面の入口を整理したいという方です。インストールやカーネルモジュール、サードパーティフィードの追加などはファームごとに差が大きいため、本稿では触れません。OpenClash は Clash／mihomo 系コアをルーター上で動かし、YAML プロファイル・購読・ルール・策略グループをひとつのパネルに束ねるツールです。用語の対応やルールの読み方はルールルーティングの解説と購読インポートガイドが横の参照になります。

ルーターでの運用は、「ゲートウェイ配下の複数端末を透明プロキシ／DNS まわりとセットで一括制御できる」反面、GUI は機能密度が高く初見で迷いやすいです。逆に PC 向けの Clash Verge Rev のようなクライアントは、ログや接続一覧を自分のユーザー権限でそのまま見られるためトリアージが速い場面もあります。用途に応じて両方を持つと運用が楽になります。

2. LuCI で OpenClash を開きサービスを確認する

ブラウザでルーター管理 IP（例：192.168.1.1）へ入り、メニューから サービス → OpenClash または同名のトップレベル項目を開きます。まず実行状態／稼働スイッチがオンになっているかを確認してください。オフのまま購読だけ更新してもコアが読み込んでいなければ期待どおりに動きません。メモリやフラッシュが逼迫している環境では、コアの種類や機能セットを抑えたプロファイルの方が安定することがあります。

ダッシュボード相当の画面が別タブや別ポートで開ける構成もありますが、初期導線はほぼ LuCI からです。HTTPS 管理画面を WAN 側に晒さない、管理者パスワードを既定のままにしない、といったセキュリティ前提はクラッシュ対策以前に必須です。

3. 購読 URL の登録（インポート）と名前・間隔

「購読情報」「Profiles のサブスク」「Subscribe」など、名称は版によりますが、入力するのはプロバイダから発行された HTTPS の購読リンク本体です。メモ帳に貼って余計な空白や改行が混ざっていないかを確認し、エイリアス（表示名）をわかりやすく付けます。自動更新間隔は提供側の利用規約に合わせ、短すぎるポーリングはサーバ負荷とフラッシュ書き込みの両面で避けるのが無難です。

複数購読を並行させる場合、後からマージや上書きの関係が複雑になるので、どの購読がどのプロファイルに束ねられるかだけはメモしておくと復旧が早いです。ノードのタグ付けや改名ルールはプロバイダ側仕様に依存します。

4. 購読の更新：手動・自動・ログでの確認

購読追加後は手動更新ボタンで一度取得成功させると安心です。ログには HTTP ステータス、バイト数、パース結果が出ることが多く、空レスポンス・証明書エラー・DNS タイムアウトなどがそのまま理由として残ります。自動更新は cron 風のスケジュールやプラグイン内タイマーに載るので、夜間にだけ走らせたいなど家庭内 PoE 機器への負荷も含めて調整します。

PC 環境向けに TLS／DNS をログから掘る深掘り記事として Windows の購読エラー整理があります。OS は違っても「ブラウザでは開けるのにルーターの wget／curl 相当だけ失敗する」といった切り分けは共通です。ルーター側では本体時刻の同期（NTP）がずれていると証明書検証に失敗することがあり、見落としがちです。

5. 設定の適用とコア再起動のタイミング

購読やルールの変更を保存したあと、環境によっては設定をデプロイするボタンやコア再起動を明示的に求められます。ここを飛ばすと「ノード一覧は更新されたように見えるのに通信経路が古いまま」という状態が起きます。適用完了まで数十秒かかることもあるので、連打せずログでreload／restart 完了を待つのが安全です。

メジャーアップデート直後は互換性のないディレクティブが混ざりやすいので、パースエラーが出たら最小構成のプロファイルで立ち上げ→購読を一段ずつ足すのが実務的です。

6. 策略グループでノードを手動選択／自動切替する

Clash では proxy-groups が UI 上の策略グループ（ポリシーグループ）に対応します。select 型はユーザーがノードを手動で選び続けるタイプで、地域別レンジを運用で切り替える用途に向きます。url-test や fallback は計測や死活で自動的に出口を切り替えるタイプです。メニュー名が「プロキシ」「ポリシー」「Overrides」などに分散していても、見るべきはどのグループがルール側から参照されているかという一点です。

自動系のパラメータ（テスト URL・間隔・許容差・優先順位）を詰めたい場合は、デスクトップ向けの説明も参考になる url-test／fallback の整理記事を併読すると、eBPF や TUN を経由したルーター特有のブレも含めてイメージが揃いやすいです。

「GLOBAL を変えたが特定サービスだけ変わらない」ときは、ルールが別のグループへジャンプしているケースがほとんどです。上位ルールほど優先という Clash の基本を思い出し、該当ドメインがどの策略に落ちているかをログまたは接続ビューで確認します。

7. 遅延テストの入口と結果の読み方

OpenClash の Web コンポーネントにはノードごとの URL テスト／一括計測が用意されていることが多く、ボタン名称は「检测」「测速」「Check latency」など様々です。計測はあくまで設定されたテスト URL への HTTP 応答時間ベースであり、実サービスの体感や UDP 通信の安定性とは一致しない場合があります。タイムアウトばかりなら、WAN の輻輳・ノード側 ACL・テスト URL 自体のブロックを疑ってください。

代表的な運用は、(1) 手動で上位レイテンシのノードを除外、(2) url-test グループに任せて自動更新、(3) 時間帯によって select を切り替える、の三段です。数値が安定しているノードほど動画や VoIP に有利になりやすいですが、地域ロック目的ならレイテンシより出口地理情報の方が重要になる場面があります。

8. LAN 側端末が実際にプロキシを使うための前提

OpenClash は DNS と転送ルールをセットで触ることが多く、LAN クライアントがルーターを DNS サーバーとして参照していることが前提になる構成があります。一方で、端末が独自に DoH を使っているとルール評価より前に名前解決が抜けることがあります。またブリッジ AP 直下にだけ特定デバイスを置くなどゲートウェイがルーターではないネットワーク構成では、期待した透明プロキシが効きません。

IPv6 が有効な回線では、IPv4 だけプロキシに載せてもIPv6 がバイパスするケースがあるため、環境に応じて WAN／LAN の IPv6 設定やルール側の扱いを揃える必要があります。詳細はデバイスごとに異なるため、異常時は「DNS をルーター固定」「セキュア DNS をオフ」など一次切り分けを単純化してから詰めると早いです。

9. よくあるつまずき

購読は成功するが策略が空：YAML の互換性やプロファイル束ねのミスでパースに落ちていることがあります。特定アプリだけ繋がらない：ドメインルールの漏れ・QUIC・ピンニングを疑い、ログで実ホスト名を拾います。CPU が常に高い：ルールセットや DPI 系機能が重い場合があるので、機能を段階的にオフしてボトルネックを特定します。

本稿は一般的な設定手順の紹介であり、特定サービスの回避や規約違反に結びつく行為を推奨するものではありません。利用規約・法令・プロバイダポリシーを順守し、自己責任で運用してください。

10. よくある質問

購読更新が失敗します。最初に何を確認すべきですか？

LuCI ログで TLS／DNS／HTTP ステータスを確認し、URL の期限切れやルーター時刻のずれを除外します。詳細なログ読みのストーリーは別 OS でも応用できる購読エラー記事が参考になります。

遅延テストがすべてタイムアウトに見えます。壊れていますか？

テスト URL やノード側ポリシーによってはタイムアウト主体になり得ます。別ノード・別 URL・実アプリの体感を組み合わせて判断してください。

策略を変えても一部サイトだけ変わりません。

ルールの優先順位や DNS の経路、ブラウザのセキュア DNS が原因になりやすいです。該当ホストがどの策略へ割り当てられているかをログで追ってください。

11. まとめ

OpenWrt 上の OpenClash では、日常運用の中心が購読のライフサイクル（追加・更新・エラー確認）と策略グループでの出口管理、そして遅延テストによる品質の目安に収れんします。LuCI と内蔵ダッシュボードのラベルは版で変わっても、この三本柱は変わりません。家中のデバイスをまとめて扱えることはルーター運用の強みですが、メニュー階層が深く、個々の端末ログまで同一 UX で追うのは PC クライアントほど直感的ではありません。実際、単体 PC で接続ログやトラフィック統計を細かく見ながら調整したい場合は Clash Verge Rev のログ／統計記事で述べているようなデスクトップ GUI の見やすさ・更新サイクルの方が向くことも多いです。

つまりルーターはゲートウェイ全体の土台、PC／スマホ Client は自分の作業デバイスをきめ細かくトリアージする補助線という役割分担にすると、OpenClash の設定も迷いにくくなります。公式ビルドやダウンロード経路を一貫させておくと、コア更新やセキュリティ修正の追従も楽になります。

環境に合った Clash 系クライアントを公式チャネルから選びたい場合は、 → Clash を無料ダウンロードして、自分のデバイスに合うクライアントを入手するから各プラットフォーム向けの一覧に進めます。OpenClash で家中を整えたうえで、作業端末には GUI の優れたデスクトップ版を足す構成が、再現性の高い現実解になりやすいです。