ほとんどのGUIクライアント(Clash Verge、Clash for Windows系列など)には既にダッシュボードが内蔵されており、通常の使用では追加設定は基本的に不要です。しかし、Mihomoコアを直接デプロイしている場合や、より高機能なサードパーティのダッシュボードでトラフィックを確認したい場合は、外部制御を手動で有効にし、ブラウザ用のダッシュボードプロジェクトと組み合わせて使う必要があります。

外部制御とは

Clashのコア自体は、設定で指定したアドレスとポートでリッスンするRESTful APIサービスを起動します。GUIクライアント、CLIツール、ブラウザダッシュボードは、本質的にすべてこのAPIを通じてコアと通信しています——現在のノードの確認、ポリシーグループの切り替え、リアルタイムログの取得は、すべてこのAPI経由で行われ、コア自体を再起動する必要はありません。

言い換えると、コアが実際のトラフィック転送を担い、ダッシュボードは単なる「メーターパネル」であり、両者は完全に分離されています。だからこそ、ノードの切り替えやDNSキャッシュのクリアといった操作は、ほとんどのダッシュボードで「即時反映」され、設定ファイル全体を再読み込みする必要がないのです。

外部制御を有効にする

設定ファイルに以下の2行を追加し、コアを一度再起動すれば有効になります。

config.yaml
external-controller: 127.0.0.1:9090
secret: 'replace-with-a-strong-secret'   # ダッシュボードのアクセスキー。必ず自分で変更してください

external-controller はダッシュボードが接続するアドレスとポート、secret はアクセスキーで、ダッシュボードを初めて接続する際に入力します。内蔵ダッシュボード付きのGUIクライアントを使っている場合、これらは通常あらかじめ設定済みで、設定画面から直接確認できるため、設定ファイルを手動で編集する必要はありません。

リッスンアドレスは127.0.0.1のままにしておき、0.0.0.0にバインドしてインターネットに公開しないでください——これは最も見落とされがちですが、最も重大な結果を招くステップです。

どのダッシュボードを選ぶべきか

ダッシュボード特徴おすすめの人
yacd 軽量でシンプルなUI。接続リストとトラフィックグラフが中心機能 接続状況だけをシンプルに確認したい人
metacubexd より高機能で、ルールテスト、サブスクリプション管理、複数テーマに対応 ダッシュボードで日常的な操作を一元化し、クライアントの切り替えを減らしたい人
クライアント内蔵ダッシュボード GUIクライアントと統合されており、追加デプロイが不要 すでにClash VergeやCFWなどのGUIクライアントを使っている人

yacdとmetacubexdはいずれもオープンソースの静的Webプロジェクトで、任意の静的サーバーにデプロイすることも、ブラウザでローカルファイルを直接開いて使うこともできます。接続時は、先ほど設定した external-controller のアドレスと secret を入力するだけです。

ダッシュボードで最もよく使う3つのビュー

  1. Connections(接続):現在のすべての接続をリアルタイムに表示し、宛先ドメイン、マッチしたルール、経由するノードを確認できます。「なぜこのサイトが直接接続になっているのか」を調べるときに最も役立ちます。
  2. Proxies(ノード):すべてのポリシーグループとノードの遅延を確認でき、手動でノードを切り替えたり速度テストを実行したりできます。クライアント内のノードパネルと同じ効果です。
  3. Logs(ログ):コアの実行ログをリアルタイムに出力します。ルールが効かない、サブスクリプションの解析に失敗した、といった場合は真っ先にここを確認しましょう。

セキュリティに関する注意点

外部制御は本質的に、レート制限がなく権限の粒度も粗い管理インターフェースです——アクセス権を得ることは、この Clash インスタンスをほぼ完全に乗っ取ることに等しく、すべての接続履歴を見られたり、ノードを変更されたり、設定内の機密情報を読み取られたりする可能性があります。そのため:

設定が完了したら、ダッシュボードを開いてアドレスとキーを入力するだけで、リアルタイムの接続リストを確認できます。設定を変更するたびにクライアントを再起動し、ノードを一つずつテストするよりも、この「見ながら調整する」方式のほうがずっと効率的です。特にルールをデバッグしたり、特定のサイトへのアクセス異常を調査したりする際に効果を発揮します。

複数デバイス・複数コアの管理方法

自宅のルーター、常時稼働のNAS、ノートPCのローカルテスト環境など、複数のデバイスで同時にClashを動かしている場合、同じダッシュボードでアドレスをその都度切り替えるのは面倒です。この場合、各インスタンスの external-controller に異なるポートを設定し、ダッシュボード側で複数の接続プロファイルを保存しておけば、ブラウザのブックマークのようにいつでも切り替えられ、毎回アドレスを入力し直す必要がなくなります。

また、secret は各インスタンスごとに個別に設定することをおすすめします。手間を省くために同じキーを使い回すのは避けましょう——一つのインスタンスのキーが漏洩しても、他のインスタンスには影響しません。ルーターやNASで長期間稼働しているインスタンスは攻撃対象になりやすいため、キーのローテーションを優先的に行うべきです。

ダッシュボードが開けないときのトラブルシューティング

ダッシュボードの接続に失敗する場合、原因はほぼ以下のいずれかです。順番に確認していけば、たいてい問題を特定できます。

  1. アドレスまたはポートの入力ミス:ダッシュボードに入力したアドレス・ポートが、設定ファイルの external-controller の値と完全に一致しているか確認してください。プロトコルの接頭辞やポート番号の抜け漏れにも注意しましょう。
  2. secretの不一致:設定ファイルの secret を変更した後にコアを再起動していない場合、新しいキーはまだ反映されておらず、ダッシュボードは認証失敗を表示し続けます。
  3. コアがそのアドレスでリッスンしていない:ダッシュボードを他のデバイスからアクセスしているのに、コアの external-controller がまだ 127.0.0.1 になっている場合、ローカルからしかアクセスできないため、外部デバイスからは当然接続できません。これが、リッスン範囲を安易に変更しないよう前述で強調した理由でもあります。リモートアクセスが必要な場合は、リッスンアドレスを直接開放するのではなく、SSHトンネルを使いましょう。
  4. ブラウザのクロスオリジン制限:一部のブラウザは、HTTPページからローカルアドレスへのアクセスに追加の制限を設けています。接続がブラウザによってブロックされる場合は、別のブラウザに切り替えるか、ダッシュボードプロジェクトが提供するローカルデプロイ方法を試してみてください。

これらの点を確認していけば、ほとんどの接続問題は解決できます。ダッシュボード自体は複雑なものではなく、「うまく使えない」というケースの大半は設定の細部が原因であり、ダッシュボードやコア自体に問題があるわけではありません。