OpenClash の Web コンソールでノード測定・モード・ポリシーグループを運用する実務ガイド（OpenWrt／LuCI）
OpenWrt で OpenClash を「動いた」ところまで持っていけたら、次は日常運用でどこを触るかが焦点になります。LuCI はサービス制御やインポート寄り、ブラウザのダッシュボード（外部コントローラー）はノードのレイテンシ確認やポリシーグループのワンクリック切替、Connections（接続一覧）の眺めやすさが強みです。本記事ではインストール手順そのものではなく、すでにコアが立っている前提でWeb コンソールから何を確認し、どう出口やモードを変えるかを実務順に整理します（メニュー名はビルドやスキンで異なるので、「機能の意味」として読み替えてください）。導入〜全屋構成の俯瞰は別稿の全屋ガイドと組み合わせると迷いが減ります。
LuCI とダッシュボードの役割分担
OpenClash はOpenWrt の Web 管理画面（LuCI）と、コアが公開するYacd／メタダッシュボード相当のブラウザ UIの二枚看板になりがちです。前者はパッケージ更新・ログレベル・起動オプション・ファイアウォール連携のチェックボックスなど「ルーターに宿っているサービス」をいじる場所です。後者は実行中プロファイルを読みながらノードやグループをさばく運用 UIで、実際にゲームや動画がどのチェーンへ載っているかをConnectionsから眺めるときにも向きます。
ダッシュボードを開く経路は環境によってLAN IP＋ポート／reverse proxy／一時的な SSH トンネルなど複数あります。インターネット側へポート開放だけで済ませると総当たりログインや証明書問題が増えるので、まずは宅内 VLAN や VPN で閉じた経路から試すのが安全です。secret／token相当の認証がある構成ではブラウザをシークレットにしたうえで再ログインするとキャッシュ起因のズレが消えやすくなります。
用語メモ
Clash／Mihomo 系ではプロキシ（単体ノード）が複数寄ってポリシーグループ（選択ロジック）になり、さらに上位ルールがRULE／MATCHでどのグループへ送るか決めます。画面が多言語でも、この三層さえ頭にあると説明書やログが読みやすくなります。
ノードのレイテンシ（スピードテスト相当）を読む
ダッシュボードにはボタン一発でレイテンシを並べるビューや、URL テスト／フォールバック／自動選択といった名前のグループ設定があります。やりたいことは単純で「今この一覧の中から体感とログ整合が取れるノードはどれか」を決めることです。ポイントは次のとおりです。
- テスト URL が ICMP と無関係な HTTPS になっているケースでは ping が良くても一覧ではタイムアウトします。項目ごとの説明文か設定ファイル側で確認しましょう。
- UDP を前提とするサービスではレイテンシだけ見て安心しない——音声チャットなどは別タブやログで実際の Dial を確認します。
- サーバー側がレート制限していると連打すると一時的に失敗が増えるので、朝昼晩で分散させてベースラインを取ります。
- IPv6 が混ざる環境ではテスト結果が二系統になることがあります。Luci の WAN と dnsmasq の挙動もあわせてDNS／fake-ip の整理へリンクすると原因が見えやすいです。
fallback 型グループではしきい値を超えたら自動で別ノードへ寄せる設計になりますが、しきい値がタイトすぎると通勤時間帯だけヒステリックに切り替わります。むしろ上位ルールでドメイン単位に優しい経路へ寄せるほうが安定することがあり、ダッシュボードを見ながらタイムアウトが続くホスト名をメモしておくとルール調整がしやすくなります。
ポリシーグループで出口を変える（実戦）
PROXY／自動選択／手動選択など名前はプロバイダのテンプレ依存ですが、実務ではどのグループがゲーム・どれが動画・どれが一般ブラウズのデフォルトかを自分の言葉にマッピングしておくと迷いません。RULE モードではヒットしたルールがどのグループにバインドされているかがすべてなので、「一覧でノードが変わらない」ときは上流グループが別にあること自体が原因になりがちです。
| よくあるグループ種別 | 触ったときに期待すること |
|---|---|
| 手動選択（select） | 自分が選んだ単一ノード／サブグループへ固定。検証や強制迂回に向く。 |
| URL テスト（url-test） | 定期的なチェックで勝ち続けるノードへ自動スライド。テスト URL と間隔設定が効く。 |
| フォールバック（fallback） | 優先リストを順に試し、最初に健全だったものへ落ち着く。障害時の冗長向け。 |
| ロードバランス系 | 複数ノードへ分散するためログも分散する。単一路線検証には不向き。 |
- RULE で問題のドメインがどのチェーンへ流れたかを Connections で確認する。
- 実際に効いているグループをダッシュボードで選び直すか、上位ルール側で別グループへ付け替える。
- 変更直後はブラウザのキャッシュや DNS を挟んだアプリを一度閉じて再試行する。
LuCI 側にもワンショットで再起動や設定適用をかけるボタンがありますが、ノード選択だけならダッシュボードだけで十分終わるケースが大半です。再起動まで踏むとファイアウォールチェーンの再構築が走るので家族端末まで瞬断するタイミングを選びましょう。
プロキシモードと動作モードを切り替えるときの勘所
「RULE と GLOBAL」「Redir と TUN」「ファイアウォール dns ハイジャック」のような上位モードと実装モードの組み合わせがズレていると、ダッシュボードではノードが切り替わっているのにブラウザだけ直結するといった現象が出ます。RULE はドメイン／GEOIP／プロセス情報を読んだうえでグループへ配送する標準運用モードです。GLOBAL は検証や緊急時にすべてを単一出力へ強制するショートカットとして割り切ると混乱が減ります。
Redir／TUN／ハイブリッドといった実装側モードは OpenClash のビルドや内核バージョンで選択肢が増えますが、共通してOpenWrt の fw／nft と dnsmasq がどこまで関与するかが変わります。切り替えたあとは①DNS がどこで握られたか②UDP が期待どおりコアへ届いたかをセットで確認するとトラブルの芽を早めに摘めます。
WAN 公開とログに残る情報
ダッシュボードには宛先ホストやプロセス名が並ぶため、共有 PC で見せっぱなしにしないほうが無難です。また公開ポート経由でアクセスすると総当たり試行や証明書ミスマッチが増えるので可能なら VPN や限定 VLAN に閉じてください。
Connections で見るべき列と切り分けの順番
Connections はその瞬間アクティブなフローの一覧です。RULE が効いているかはチェーン名／ポリシー名／実際に選択されたノードが揃っているかで判断できます。ドメイン単位で詰まっているときは検索ボックスでホストを絞り、HTTPS で見えないレイヤではログ側の Dial メッセージと突き合わせます。
- 同名ホストでもポートが違えば経路が別になるので、アプリが複数ソケットを張るタイプでは複数行が並ぶのが普通です。
- 長時間だけ張られた TCPは動画 CDN のキープアライブなどで放置されているだけかもしれません——異常値かどうかは転送方向や再利用の跡も見ます。
- IPv6 が迂回していた場合は一覧では気付きにくいので WAN でどちらが優先されているかもチェックします。
PC やスマホ単体で細かく検証したい読者は、Windows クライアントや macOS の GUI クライアントでも同様の Connections ビューを利用できます。ルーター運用との違いはどこまでゲートウェイ配下を強制できるかだけです。
ログで読むべき行とログレベルの落としどころ
OpenClash／コア側ログにはDNS 応答／Dial 成功／証明書検証／ルールヒットのサマリーが並びます。INFO で足りないときだけ一時的に DEBUG に上げるとノイズ対有用情報の比率が崩れやすいので、まずは問題ホストとタイムスタンプを決めてから grep 気味に読むほうが現実的です。Luci にログビューワーやファイル出力のパス設定がある場合はストレージ逼迫に注意し、ローテーションやサイズ上限を確認してください。
fake-ip を使っている構成では一覧と実際の出口が見え方だけズレることがあります。ブラウザでは問題なくてもゲームだけ落ちるときはキャッシュされた IP と実際の Dial の不一致を疑うので、ログと Connections を時間軸で突き合わせます。'つながったのにページが開かない'系の記事とセットで読むと DNS レイヤの想像がクリアになります。
おすすめの日常チェック順（短時間）
ルーターを家族共有しているほど短時間で異常検知できる動線が重要になります。忙しいときは次の順だけでも十分効きます。
- Luci でサービス緑／コア PID が安定しているかざっと見る。
- ダッシュボードで代表的なノードグループにレイテンシ異常が無いか確認。
- RULE を維持したまま問題サイトだけ別グループへ寄せられるか検討。
- Connections でホスト／チェーンが期待どおりかをスポットチェック。
- ログに連続エラーが並んだタイミングだけレベルを上げて原因を特定。
よくある質問
ブラウザからダッシュボードへ入れない
IP を誤っている、ポートが競合している、fw でブロックされている、HTTPS で証明書を拒否している、といった順で潰します。バインドが LAN のみなのに WAN から試しているケースも多いので、Luci の外部コントローラー設定を見直してください。
測定は良いのに実サービスだけ悪い
テスト URL と実サービスの経路・プロトコル・キャッシュ TTL が一致していません。IPv6 を強制しているアプリやDNS を独自キャッシュしているブラウザでは一覧より体感が悪化することがあります。
RULE と GLOBAL をどう住み分けるか
日常は RULE。特定サイトだけ検証したい短時間だけ GLOBALへ寄せて因果を切り分け、済んだら RULE に戻すのがおすすめです。GLOBAL のまま運用すると国内 CDN をまで迂回不適切に載せることがありコストも増えます。
運用チェックリスト
- LuCI とダッシュボードのどちらで何を変えるか説明できる。
- ノード測定がタイムアウトするときテスト URL と UDP を疑える。
- ポリシーグループが RULE にどうバインドされているかを追える。
- Connections とログで同一イベントを時系列で突き合わせられる。
- 公開ポートより VPN／限定 VLAN で管理 UI に触れる運用を選べる。
まとめ
OpenClash はOpenWrt の LuCI でサービスとインフラ連携を握り、ブラウザのダッシュボードでノードとグループを運転する二段構成になりやすいです。インストール記事が終わったあとのユーザーほどレイテンシ一覧／ポリシーグループ／Connections／ログの四点セットを一度なぞっておくと、家族からの「だけ遅い」報告にも冷静に応えられます。
一方ルーター GUI は機能追加で項目が増えやすく、ビルドごとにメニューが微妙にズレるため「説明書どおりに項目が並んでいない」と感じることもあります。個々の PC で設定ファイルと Connections を同一画面で見比べられるデスクトップ／ノート向けクライアントなら、アプリアップデートの透明性や複数構成の複製にも強みがあります。
家中と自分のデスクで同じルール思想を再現したいというニーズには、YAML に収束させたワークフローをそのまま端末へ広げられる Clash が向きます。ルーター側で全体を統括しつつ、細かな検証や開発ツールだけローカルで切り替えたい場合も含め、自分の運用パターンに合わせて ダウンロードページから Clash を入手 し、静かな接続チェックまで試してみてください。