Web パネルを開く前に知っておきたいリスク

Clash Meta（現行のコア名は多くの場合 mihomo と呼ばれます）では、ブラウザから接続状況を眺めたり、外部ツールからノードを切り替えたりするために external-controller によって REST API が提供されます。ダッシュボード用の静的 UI は別途配布されることが多いですが、いずれもこの API に依存します。ここが「ただの見た目用ページ」ではなく、コアの動作に直結する管理口だという点が重要です。

API が広いアドレス（例：0.0.0.0）で待ち受け、かつ Secret（トークン）が空のままだと、同じネットワーク上の別端末から設定の取得・変更が可能になる場合があります。自宅 LAN であれば家族の端末やゲスト Wi‑Fi、職場であれば同僚の PC から到達しうる範囲が広がります。ルーターのポート転送やクラウド上の仮想マシンを運用している場合は、意図せずインターネット側に晒される危険もあります。検索エンジンやスキャナに「開いている管理ポート」として拾われる事例は他製品でも報告されており、Clash 系でも同様の前提で考えるのが安全です。

注意：本稿は一般的なセキュリティ上の指針です。組織ポリシーや契約がある環境では、必ず情報システム部門のルールに従ってください。

external-controller と REST API の役割

external-controller は「API をどの IP アドレスとポートで公開するか」を決める設定です。典型例は 127.0.0.1:9090 のようにループバックのみで待ち受ける形です。mihomo のドキュメントや各 GUI クライアントのデフォルトも、このローカル待受を前提にしていることが多いです。

REST API 経由では、バージョン情報の取得に加え、プロキシ一覧の読み出し、ルールの再読み込み、場合によってはランタイム設定の変更などが行えます。公式の挙動はバージョンにより差がありますが、「読み取りだけでなく書き換えもできる」という認識で Secret を必ず使うのがよいでしょう。コアの詳細な移行や新フィールドについては、Clash Meta から mihomo への移行ガイドも参照してください。

手順 1：bind-address / external-controller で待受を決める

最初にやるべきは「誰のネットワークインターフェースからこの API に届くか」を限定することです。bind-address（またはクライアントが生成する設定内の同等フィールド）と external-controller の組み合わせで決まります。

この PC だけでダッシュボードを使う（推奨の出発点）

ブラウザやローカルアプリからだけ操作するなら、external-controller を 127.0.0.1:9090 のようにループバックに固定するのが最もシンプルです。この場合、同じマシン上からしか API に接続できません。スマホや別 PC から同じ UI を見たい要件がなければ、まずはこの形に落とし込みましょう。 

# Example: API only on loopback (adjust port if needed)
external-controller: 127.0.0.1:9090

LAN 内の別端末からも触りたい場合

スマートフォンのブラウザから PC 上の mihomo を操作したいなど、同一 LAN からのアクセスが必要になると、待受を 0.0.0.0 に広げたくなります。しかし 0.0.0.0 は「そのマシンが持つすべてのインターフェースで待つ」ことを意味するため、意図しない経路からも到達しやすくなります。LAN 共有が目的なら、可能であればマシンの LAN IP（例：192.168.1.10:9090）に限定するか、OS のファイアウォールで送信元をサブネット単位に絞るなどの層を足してください。

allow-lan やプロキシ用の mixed-port と混同しやすいので注意が必要です。プロキシを LAN に公開する話は LAN で Clash を共有する手順で別途整理していますが、管理 API のポートとプロキシのポートは別物です。片方だけ塞いでも、もう片方が開いていればリスクが残ります。

手順 2：secret を必ず設定する

待受をどこに置くかが決まったら、次は Secret です。mihomo / Clash Meta 系では、設定ファイルのトップレベルに secret: "..." を書く形式が一般的です。値は推測されにくい長いランダム文字列にしてください。パスワードマネージャの生成機能や openssl rand などで十分です。 

# Example: set a strong API token (use your own random value)
secret: "replace-with-long-random-string"

API に Secret が設定されている場合、クライアントは HTTP ヘッダ Authorization: Bearer <secret> を付けてリクエストする必要があります。ダッシュボードの URL にトークンをクエリで付ける方式に見える UI もありますが、根本は同じ「共有秘密による認証」です。Secret を空のままにすると、到達できる相手は認証なしでエンドポイントにアクセスできる可能性が高まります。

漏えいしたらすぐ差し替える

設定ファイルを共有したり、スクリーンショットを公開したりすると Secret が第三者に渡ります。漏えいが疑われる場合は、新しい乱数に変更してからコアを再読み込みしてください。GUI クライアントが生成する設定と手編集の設定が二重にある場合は、実際に読み込まれているファイル側を必ず更新します。

手順 3：インターネットや広い LAN に「露出」させる前に

リモートから自宅 NAS 上の mihomo を操作したい、クラウド VPS でヘッドレス運用したい、といった要件では、単に 0.0.0.0 と Secret だけでは不十分なことがあります。以下を検討してください。

  • OS ファイアウォール： 送信元 IP を信頼できる範囲に限定する（全世界向けに開かない）。
  • SSH トンネルまたは VPN： 管理 API 自体を公網に晒さず、既に信頼できるトンネル越しに 127.0.0.1 に届ける。
  • リバースプロキシと TLS： どうしても HTTPS で終端させる場合は、別ポートで正規の証明書を使い、Basic 認証などの第二層を検討する（設定ミスで設定ファイルや Upstream が漏れないよう注意）。
  • ポート転送の見直し： ルーターで 9090 番などを外向きに開いていないか、ゲスト VLAN から管理サブネットに届かないかを確認する。

「とりあえず動けばよい」で 0.0.0.0 と空の Secret を組み合わせるのは、後からスキャンされてから気づくパターンになりやすいです。順序としては、まずローカル待受と Secret で正常に動くことを確認し、その後に必要最小限の範囲だけ広げるほうが安全です。

動作確認：curl で REST API を叩く

設定を反映したら、ターミナルから簡単に確認できます。Secret ありの例では、次のように Bearer トークンを付けます（ポートは環境に合わせて読み替えてください）。 

# Without secret (should fail or be avoided in production)
curl -sS http://127.0.0.1:9090/version

# With secret
curl -sS -H "Authorization: Bearer YOUR_SECRET" http://127.0.0.1:9090/version

ローカルでは成功するのに LAN 越しでは失敗する場合は、bind 先・ファイアウォール・クライアントが参照している IP の取り違えを疑ってください。逆に、Secret なしで LAN からバージョンが取れてしまうなら、いまの待受範囲が広すぎるサインです。

GUI クライアント利用時の注意

Clash Verge 系や macOS 向けクライアントなどは、内部で external-controller を自動生成します。その場合でも「上書きされた設定に Secret が入っているか」「開発者ツールで表示される接続先がループバックか」を確認する価値があります。アプリの「外部コントローラーを有効にする」チェックは、設定ファイル上の待受と同義ではないケースがあるため、実際の YAML またはランタイム表示を一次情報として見てください。

まとめ：先に縁を決めてから扉を開く

Clash Meta / mihomo の管理 API は、快適に運用するための重要な機能です。一方で、bind-address と external-controller で「どこから届くか」を決め、Secret で「誰が使えるか」を縛ることで、LAN スキャンや誤設定による未認証アクセスのリスクを大きく下げられます。手順の順序はシンプルで、待受の限定 → Secret 設定 → 必要ならだけ露出を検討です。この順を守れば、Web ダッシュボードを有効にしても安心感の伴う構成に近づきます。

コアと GUI が一体となったクライアントであれば、こうした値を視覚的に確認しつつ、ダウンロードから初期接続までを短時間で済ませられる場合も多いです。個別に YAML を切り分けて管理する構成と比べ、設定の取りこぼしが減ることもあります。

Clash を無料ダウンロードして、安定した GUI とセットで試す → 各 OS 向けビルドをまとめて入手でき、mihomo コアとの組み合わせも分かりやすくなっています。