Clash 外部制御ロック 2026：127.0.0.1・API Secret、Yacd／未承認RESTアクセスの防ぎ方

external-controller とは、何に触れる口か

「外部制御」という言葉は、インターネットに晒す前提ではなく、コア外の管理 UI や自前スクリプトから Clash 内部状態を遠隔的に扱うための REST 的な入り口 という理解が近いです。実装次第では、実行中のプロファイルに紐づくルール、選択中の proxy、遅延テスト、場合によっては設定の フル入れ替え やトラフィック断片の参照など、ネットワーク出口を事実上支配 できるレベルに到達します。だからこそ、ブラウザで開く Yacd、metacubexd、自前ダッシュボード は便利ですが、その裏の API が「同じ部屋の別端末」からも叩ける状態では、悪意がなくても誤接続・退勤後に残る実験用タブ といった人為ミスに弱くなります。

多くのデフォルト解説は 127.0.0.1:9090 を例に出します。これは、当該マシンのループバック上だけ で待受ける、という最も扱いやすい出発点を示すためです。ここを 0.0.0.0 や、ネットワークカードの IPv4 アドレスに置き換えると、「誰にそのポートが見えているか」が一変します。有線／無線、Hyper‑V や WSL ブリッジ、仮想スイッチ など、実際の到達性は 自宅ゲートウェイ同様に「図面どおり」にはいかない ため、開いている事実 を ss や netstat 相当の可視化で確認する姿勢が大切です。ヘッドレス Linux で常駐させる方は、systemd 常駐稿 とも併せて、マシン境界のトラッフィック方針を揃えてください。

0.0.0.0 / LAN 全開、ゲスト Wi‑Fi でも「見えたら終わり」

0.0.0.0 へのマージンは、OS のソケット実装の語彙で「全インターフェースで待つ」近い挙動を指しがちで、同一 L2 セグメント上の他ホスト から http://<あなたのローカルIP>:<port>/ にアクセスできてしまう典型パスが開きます。自宅内でスマートフォンから Yacd を触りたい、という都合の良さと引き換えに、セキュリティ更新の遅い IoT や共有タブレット も同じブロードキャスト空間に乗るなら、悪用の有無以前に 触られうる面積 だけは確実に増えます。さらに、ルーターで ポート転送 を手で開けたり、二重 NAT 下で意図せず到達性が出たり、雲上 VM のパブリックNIC など、LAN の外枠にまでポートが乗ると、一般的な ボットの水平スキャン の対象になり得る — 以前から「管理ポートを生で外向きに出さない」は鉄則のままです。

したがって本稿の第一候補は一貫して 127.0.0.1 です。どうしても 同一信頼あるセグメント からだけ、という要件があるなら、まず はループバック＋SSH トンネル やゼロトラスト的な中継、もしくは 厳格な境界ファイアウォール＋ACL のような補足とセットで、いきなり 0.0.0.0 に拡大しない、という段階を推奨します。そもそも Allow LAN は、プロキシの 入り口 を他端末向けに開ける話で、external-controller とは層が違います。混同すると「プロキシは閉じたのに 9090 だけ晒している」が起き得ます。LAN 越し手動プロキシの 手順と防火壁 は当サイトの専用稿へ寄せ、ここでは 管理 REST の非公開化 を主戦場に置きます。

127.0.0.1 に束ねる：設定ファイル上の出発点

多くの Clash 系プロファイルでは、トップレベルに external-controller キー（または external-controller-pipe の Unix ドメインソケット版など、実装拡張）が存在します。ここを 数値＋文字列 の address:port 形式で指定する例が多く、出発点としては 127.0.0.1:9090 のように、ループバックと一般的な空きポート帯（環境の競合に応じて 9090 以外へ）の組合せに寄せるのが無難です。GUI 付き Windows クライアント では、設定画面の「外部制御アドレス／ポート」に相当する文言で同一値が出るはずで、YAML 直編集 と GUI の二重定義に気をつけ、片方の変更が起動引数や別名設定で上書きされていないかを起動ログに残すと安心です。サーバー用途では、journalctl など既存のローテと一緒に、誤配を早期検知しやすくなります。

external-controller: '127.0.0.1:9090'
# Optional: Unix socket in some builds (if supported)
# external-controller: '/tmp/clash.sock'

上記のように アドレスを絞る だけで、横断的な到達面 の大半は一気に減ります。もちろん、ローカル上の悪性ソフト は依然として 127.0.0.1 を叩き得るため、OS 常駐の マルウェア防御 や、開発者用ラボ機では 最小特権 の利用者分離、などホスト内の清潔さは独立した話題ではあります。とはいえ、LAN 上の 偶発的な人為・IoT 由来のトラッフィック から 守る、という層 では 127.0.0.1 固定の効用が圧倒的に大きい、という点は紛れもありません。

API Secret：Authorization と「平文 secret の置き所」

secret（文脈によっては API Secret とUI表示される）を設定することで、多くのコアは Authorization 系ヘッダを伴わない要求を弾きます。Yacd では「Secret」欄、Base URL には http://127.0.0.1:9090 のように ループバック を入れ、トークンを合わせる、という一連操作が定番です。ここで陥りやすいのが、パブリックなサンプル secret: ""（空）の踏襲 や、短すぎる英数字、そして Git リポジトリにそのままコミット してしまうパターンです。購読 URL 自体が 平文 で書かれるプロファイルに、さらに API トークン を同梱するのは、漏えい時の被害が直線的に拡大します。チーム内では、ローカル専用の 別管理ファイル に secret を分離し、include や 起動前にマージ するなど、秘匿層 を分ける型が現実的です。ルール体系全体は YAML ルール の設計知見と併読できます。

secret: "put-a-long-random-string-here"

実測的には、手動 curl での疎通 も有効な検証手順です。起動中の external-controller がループバック上で生き、かつ secret が有効であれば、不適切な Authorization のリクエストは 401 等 に帰るはず—逆に、全否定応答のまま正常UIも繋がらないのであれば、トークン不一致 か 実際の URL / スキーム か 中間のプロキシ挙動 など、別要因の切り分けに進みます。ブラウザ拡張や社内 SWG による 局所的な localhost 例外 も、見落としがちです。

Yacd ／ metacubexd：Base URL、HTTPS、CORS 周り

Yacd や metacubexd は、静的フロントエンド＋ Clash 管理API という分離型が一般的です。ローカルに落とした index.html から、http://127.0.0.1:9090 へ CORS 下で叩く、あるいは 同一オリジン化したラッパー 経由、などクライアント配布物ごとに差があります。本稿の焦点は、いずれにせよ 到達点がループバック上の外部制御 であること、Secret をブラウザに入れるのは自端末の作業用プロファイル上に留める こと、共有PCではシークレットウィンドウや別ユーザーのプロファイル といった、オペ上の 誤人共有 まで含めたリスク管理です。どうしても HTTPS オフロード を挟む場合、リバプロ証明の正当性、Upgrade 系ヘッダ、下流への Authorization 透過 が崩れて UI しか見えないのに API が常に 401 等の症状に落ち着く、という層の切り分けも、運用者の 自己署名／社内 PKI スキルに依存します。

本サイトで Clash 本体を導入・比較する場合の起点は、常に 公式ダウンロード導線 であることを推し、名称酷似の偽物コア を避けることも、結果として 悪性に差し替えられた API 実装 という最悪の系を遠ざけます。外部制御の 仕様上の挙動 自体は、利用コア（Premium／Meta 系）の世代で微妙に違い得るため、困ったら 同梱ドキュメントと実際の GET / 系レスポンス の双方を、ローカルからだけ覗く、という ループバック徹底 の姿勢を保ちます。

疎通の見え方、OS 防火壁、そして WSL2 の罠

設定のあと、まず どのプロセスがどの IP で待っているか を、OS 付属のソケット一覧から確認するのは定石です。Windows なら リソース モニター や Get-NetTCPConnection 系、Linux なら ss -ltnp など、LISTEN 行 に 127.0.0.1:9090 があるか、誤って 0.0.0.0:9090 になっていないかを人間可読で一瞥します。ここに手を入れる用途で OS レベル防火壁 の 受信規則 を足す人もいますが、ループバック専用 なら外向き 穴あけ は不要、という当たり前を取り戻す意味でも、まずは 127.0.0.1 へ戻す アプリ内設定 を優先してください。

WSL2 や仮想化下では、Windows 本体の 127.0.0.1 と、Linux ゲスト内の 127.0.0.1 が 別世界 になるため、トンネル か host ネットワーク、あるいは wsl2 向け 特別扱いのポート番号 など、ドキュメント上の 相互到達図 を自環境用に一発描くのが衝突回避の近道です。外部制御を Linux サイドで動かしつつ、Yacd を Windows ブラウザで出したい、という 跨ぎ は、まさに 127.0.0.1 信仰だけでは破綻しがち、というレッスンが繰り返し起きるポイントです。もう一段深い 分離 は、WSL2 プロキシ稿 側の整理と接続し、本稿の 管理 REST 非公開化 とは、継ぎ手を誤解しないでください。

遠隔から触る正攻法：SSH ローカルポートフォワーディング

出先から自宅 PC 上の 127.0.0.1:9090 へ、ブラウザで Yacd を当てたい、という要望に対し、まず生やすべきは外向き 9090 開放ではありません。多くの場合、既に信頼できる SSH 到達性（公開鍵認証、ポート22を外向きに晒さない跳躍点 など、組織方針に従います）の上に、ssh -L 19090:127.0.0.1:9090 user@自宅 のように ローカルポート 19090 を、リモートPCの 127.0.0.1:9090 へ中継 し、手元では http://127.0.0.1:19090 に Yacd 側 Base URL を合わせる、という 二重ループバック の方が、攻撃面の幾何学的な広がり方が読みやすいです。もちろん、SSH 先を奪取されたら全て玉砕 なので、端末紛失・キーチェーン汚染 といった、より上流の本人性担保が前提です。それでも、Clash プロセス単体の 0.0.0.0 化に比べ、ゼロから穴を拡大しない という点で、ホームラボ系の可搬性に優れます。

自宅 VPN（WireGuard 等）の 内側だけに管理サブネット を立て、そこに管理者端末からだけ 9090 を見せる、という ゾーニング も、人数の多いシェアハウス／寮ネット等では有効でしょう。いずれにせよ、「外から 9090 を生で開く」 は、メンテ不能な CA もないまま、管理用に旧世代TLSを生やす ケース群と、リスク顔付きが似通り、避けた方が得策の例が多い、という点は一貫しています。

未承認に触れたときの技術的イメージ

仮に誰かが、あなたの 外部制御 に、正当な Authorization なし、あるいは 漏えいしたトークン 付きで到達した場合、ルールを一括上書き して悪性プロキシへ誘導、購読URLを差し替え てフィッシング的な 偽 ruleset を注入、遅延の良い自前ノード へ誘導してトラフィック傍受、といった、いずれも プロキシ層 に着座した者に許される古典的な 中間者の悪夢 が、GUI のクリック一発で到達可能になり得ます。だから、外部制御の 秘密鍵的ストレージ（secret）と、到達面の最小化（127.0.0.1）の二層を、どちらか片方だけ に寄せるのは危うい、という 重ね掛け の思想が、本稿の背骨です。

よくある質問（Q&A）

Q. 127.0.0.1 なのに、別のローカルアプリに読まれる心配は？

A. 同一OSユーザー空間上の、悪性／脆弱な 他プロセス は 127.0.0.1 へ到達得ます。OS のアップデート、不要常駐の削減、管理権限の節度、等の ホストセキュリティ が別枠。LAN 上の 他人の端末 からの 偶発的な悪戯 を大きく減らす、という意味での 層分け です。

Q. 企業 端末のポリシーで 9090 が禁止される？

A. あります。別ポートや Unix ドメインソケット、管理者承認下の RDP 内だけ など、現場制約に合わせ、方針違反の抜け道を自宅機でこっそり など、職域倫理に触れる択は避けてください。IT 部門の ゼロトラスト導入 とも整合する道を選びましょう。

Q. ルール再読み込み後、外部制御のリッスンが変わる？

A. 実装は ホットリロード 時に、一部のキーだけ差し替え、という型もあれば、完全再起動を要する型もあります。変更直後、必ず 待受行の再確認 を。GUI の「再読み込み」は、内部で二重に上書き する実装差もある、という仮定で、ログを一度見る癖が身につきます。

まとめ

2026 年の時点でも、Clash 系の 外部制御（external-controller） を安全に扱う要点は、待受先を 127.0.0.1 へ戻し、API Secret（secret）で REST を実名化、Yacd 等 Web パネル では Base URL をループバックで固定 し、必要なら OS 防火壁 と SSH トンネル で、遠隔性と攻撃面を切り分ける、という 積み上げ に帰着します。LAN 上の プロキシ共有 とは別層、という整理も忘れないでください。導入の入口は一貫して こちらのダウンロード導線 から。設定の大枠を押さえた上で、ルール全般・Allow LAN 共有 と併せて、ご自身の 脅威モデル に合わせて厚みを足していくのが、長く穏やかに使う近道です。

他ツール同様、プロキシ層の設定ミスは 出口の乗っ取り へ直結しがちで、ルール可視化のしやすさ と 更新の手軽さ という、Clash 系の魅力と表裏一体の 責任 です。自宅利用でも、サブスクリプション用のURL や、Git に載せる設定の扱いは、秘密情報の一種 として再確認しておく価値があります。

関連：使い方ヘルプ、技術コラム一覧。