Clash Meta（mihomo）の external-controller・Secret・bind-address：LAN で Web／REST を安全に触れる手順と注意（2026）

1. external-controller が担うもの

external-controllerは、実行中コアへのHTTP での外向き管理口です。ここにブラウザ向けの軽量 UI（例として Yacd-meta）をぶら下げたり、スクリプトや別アプリからREST 風のエンドポイントで設定の一部を読み書きしたりするのが典型です。トラフィックを中継するmixed-port や socks-portとは番号も役割も別なので、まず「管理用に開いているのは何番か」を設定画面か生成 YAML で確定させてください。そうしないと、プロキシは通るのに UI だけ真っ白、というよくあるパターンに落ちます。

クライアント実装やテンプレートによっては、コントローラのリッスン先と UI 静的ファイルの配置（external-ui 系）がセットで触れる画面になっています。いずれにせよ「誰がそのアドレスに届くか」は OS のソケットバインドとファイアウォールで決まるため、YAML 上は正しくてもLAN から届かないのは自然な帰結です。逆に、すべてのインターフェースにバインドしたまま Secret を空に近い状態にするのは最も避けたい構成です。次節で理由を短く固定します。

2. Secret（Bearer）を必ずセットする理由

mihomo／Clash Meta 系では、多くの場合secret に相当する共有鍵をコア設定に置き、リクエスト側はAuthorization: Bearer <あなたの secret>で送ります。これが一致しないと 401 などで弾かれます。逆に言えば、Secret を弱くする・配布する・チャットに貼るのは同じ管理面を他人に渡すのと同じです。家庭内 LAN でも、ゲスト Wi‑Fi や共有アパートの空間では同じ L2 に誰がいるかは固定できません。まずは十分な長さのランダム文字列にし、クライアントごとに共有方法を絞るのが基本です。

トラブルシュートで一時的に認証を緩めたくなる場面は理解できますが、「動作確認が終わったら元に戻す」までを一連の作業に含めるほうが安全です。ブラウザの履歴や拡張、会社のプロキシがヘッダを触るケースでは、意図した Bearer が届いていないこともあるため、後半の curl 手順で生の応答を一度見る価値があります。

3. バインド先：自分だけか LAN の端末までか

同一マシン上のブラウザだけから触りたいなら、多くのテンプレートで推奨される127.0.0.1（ループバック）へのバインドが第一候補です。こうすると、少なくとも通常のルーティングのもとでは他端末からそのポートへ SYN を投げても届かないのが期待どおりの形です。一方、スマホや別 PC のブラウザから「同じ家の Wi‑Fi 内で」ダッシュボードを開きたいなら、特定の LAN IPv4 にバインドするか、実装が許す範囲でワイルドカードに近い指定が必要になります。その瞬間から到達可能性の円が広がるので、Secret の強度と OS 側の受信規則をセットで見直すのが筋です。

VPN や別 NIC が同時に有効なノート PC では、想像より広いアドレスにソケットが載ることがあります。ホテルやカフェのネットワークでは管理面を LAN 向けに広げないのが無難です。企業端末ではポリシーでポート開放そのものが禁止されていることもあるため、手順を写す前に許諾の有無も確認してください。

4. YAML 断片とクライアント GUI の読み替え

以下は説明用の断片です。キー名や記法はビルド・ラッパーで微妙に差があるため、手元の生成物と必ず突き合わせてください。ポイントは管理ポート（例の 9090）とプロキシ用ポート（例の 7890）を混同しないこと、そしてループバックか LAN 向けかを意図して選ぶことです。

# Example: localhost-only control plane with auth (adjust ports and paths)
external-controller: '127.0.0.1:9090'
secret: 'replace-with-a-long-random-string'
mixed-port: 7890

GUI 系クライアントでは「外部コントロール」「API ポート」「ダッシュボード」といったラベルに分解されていることが多いです。表で触った値が実際にコアへマージされたかは、再起動後の YAML かログで一度確認しておくと、あとからの 404／接続拒否が減ります。購読やルールの初歩は サブスクリプション導入と ルールルーティングと合わせて押さえると、ダッシュボードで見える表現と設定ファイルの対応が追いやすくなります。

5. Yacd-meta／ブラウザ UI のつなげ方

Yacd-meta のようなフロントは、多くの場合静的ファイルをローカルや CDN から開き、そこに「バックエンドの API ベース URL」と Secret を入力する形です。つまりブラウザのアドレスバーに出ているドメインと、実際に叩いている API のホスト／ポートは一致しないことが普通です。ここでよくあるのが、API の方を 127.0.0.1 のまま書いていて、LAN 上の別端末のブラウザからは常にその端末自身のループバックを見に行ってしまうパターンです。別端末から触るなら、PC の LAN IPv4 と正しい管理ポートをペアで指定する必要があります。

通信経路は通常 HTTP ベースです。信頼できないネットワークで平文の管理面をさらすのは避けるべきで、どうしても離れた場所から触るなら SSH トンネルや VPN の内側に閉じるなど、別レイヤーで囲う考え方になります。本稿の範囲はあくまで家庭や開発用 LAN の閉じた前提での安全な序盤設定です。

6. curl で REST を叩いて切り分ける

ブラウザや拡張の影響を抜きにして、まずコアが応答するかを見るなら 同一マシン上で curl が確実です。例としてバージョン相当の情報を取るイメージです（パスは実装版に合わせて読み替えてください）。

# Example (run on the same host that runs the core; fix host:port and token)
curl -sS -H 'Authorization: Bearer YOUR_SECRET' 'http://127.0.0.1:9090/version'

ここで JSON が返るのに UI だけ失敗するなら、フロント側の URL か CORS 的な制約、オフラインの埋め込みパスを疑います。ループバックでは通るが LAN からはタイムアウトなら、バインドと OS の受信規則が主因です。コアのログレベルを上げると、着信自体がないのか、認証で落ちているのかが切り分けやすくなります。

7. allow-lan と混同しないために

当サイトの LAN 共有（allow-lan）の記事は、他端末から mixed-port などプロキシ口へ流し込む話が中心です。一方、本稿の external-controller は「誰がルールとコアを操作できるか」の面です。どちらもポートを開くとリスクは上がりますが、事故の内容が違うので設定を同時にいじるときは、番号をメモしてから進めると安全です。Docker や WSL からホストのプロキシへ寄せる話は別の導線になるため、必要なら Docker 経由の記事と併読してください。

TUN やシステムプロキシで「アプリのトラフィックをまとめて乗せる」構成は、TUN モードの解説が補助線になります。ただし管理 API のバインド方針とは独立である点だけは押さえておくと混線しません。

8. まとめ

（1）管理ポートとプロキシ用ポートを分けて番号を確定する（2）Secret を長くランダムにし、Bearer として一貫して送る（3）まずはループバックだけに閉じ、LAN から触るならバインドとファイアウォールと Secret を同時に設計し直す（4）curl で生の応答を一度見てから UI を疑う——この四段で、外部制御まわりの大半は整理できます。いったん広げた管理面は、作業後に狭める・止める習慣があると長期運用で差が出ます。

クライアントの見た目は世代で代わっても、「コアに HTTP で触る口をどこまで開くか」という設計判断は共通です。ログと設定をソースオブトゥルースに据えるほど、派手な UI の裏で起きるズレに振り回されにくくなります。

手元の OS に合うパッケージを選び、外部制御まわりを含めた初期構成を整えたい方は、当サイトの一覧から入手できます。 → 無料で Clash をダウンロードし、快適な接続体験を試す