外部控制 API 是什么：方便之处与真实攻击面
在 Clash 系内核中，外部控制通常指在本地开启一个基于 HTTP 的 REST 接口，让图形客户端、Yacd、自写脚本去读取运行状态、切换策略组、热加载部分配置。你在浏览器里能打开一个面板地址、看到「连接 / 规则 / 代理组」，背后多半就是 external-controller 在响应 JSON，而不是让浏览器直接去碰磁盘上的 config.yaml 全文。
这个设计把「用界面管理」和「本机起内核」解耦，却天然带来一个事实：谁能让 HTTP 请求命中这个端口，谁就在网络协议层面拿到了与你同一台机器上面板几乎等价的能力，除非内核侧再做鉴权。很多事故并不是「被黑客 0day」，而是 误监听在 0.0.0.0、未设 secret、在不可信热点上长期开着默认端口。扫到开放端口的成本极低；一旦命中，你担心的「未授权访问改规则、导走订阅链接」在技术上并不夸张。
与「上代理、翻网站」不同，外控不一定要在系统代理里出现。读者有时会觉得「我明明没开局域网共享，为什么还被人改到了」：原因往往是外控和混好的 HTTP/SOCKS 代理端口职责不同。下文会把三条线拆清：控制面（external-controller）、数据面（mixed / http(s) / socks）、以及允许局域网入站那一类开关。读完你可以按一张清单做自检，而不是在客户端里点来点去凭感觉。
典型风险长什么样：同网段、公网与空密钥
第一类场景是 Wi‑Fi 同网段。咖啡馆、合租、公司访客网中，你笔记本上的 Clash 如果让外控监听在「所有网卡」或 0.0.0.0:9090，同网内任意设备只要猜中或扫到常见端口，就能用浏览器或 curl 去访问。若 未配置 secret（API Secret） 或等效未启用鉴权，很多接口会直接返回状态或允许改配置。别人未必关心你上什么网站，但导出订阅、替换规则、把流量导向恶意节点都是现实后果。
第二类是 公网可路由。少数用户会在路由器、云主机上跑 Headless 实例，为省事把控制端口映射出去，或装在默认监听「全网卡」+ 防火墙全放行。公网扫描器对 9090、7890 一类端口不陌生。即便你设了 secret，若走明文 HTTP 且同链路可被嗅探，仍有中间人重放与泄露风险。生产级远程管理应叠仅内网、反向代理、TLS 与强密码，而不是只依赖一个字符串。
第三类是 本机多用户或多会话。同一台电脑若有其它账号、恶意软件、不可信扩展，在本机访问 127.0.0.1 并无 OS 级社交隔离的「高墙」——外控只保证「远程 IP 不进来」，不自动保证「本机进程都可信」。这属于纵深防御里更靠后的层；至少先把网络暴露面锁到 只回环、带密钥，再谈终端安全。
external-controller 绑定地址和 secret 是否对内核生效，请在生成的有效配置里核对，而不是仅看应用商店截图。
第一步：把 external-controller 收束到 127.0.0.1
在多数发行版/内核文档里，external-controller 接受 地址:端口 形式。为只让本机进程连上控制面，应使用回环地址：127.0.0.1 表示 IPv4 回环，若环境同时起 IPv6，可查阅你的内核与系统是否还需单独管 ::1 或 localhost 解析行为。关键是语义：不要在不理解的前提下写 0.0.0.0，那代表「本机所有 IPv4 地址上监听」，包括有线网卡获得的局域网 IP 对应的入站连接。
只写 :9090 而省略地址时，各客户端封装可能用自己的默认值。有的偏保守只绑回环，有的等价于 0.0.0.0。你在 GUI 里看到「外控已开」但不确定绑在哪时，办法是用本机与局域网双向验证：同一台机访问 http://127.0.0.1:9090/... 应成功；在同网段另一设备上访问 http://<你电脑局域网 IP>:9090 若也成功，就说明此刻监听面不止回环。此时应回配置把地址写死为 127.0.0.1 或关外控的「对局域网开放」类选项，直到行为符合预期。
与仅本机相关的另一个细节是 面板 URL。Yacd 等静态面板的「Base URL / API 地址」在单机场景应使用 http://127.0.0.1:端口，而不是用局域网 IP 去填——后者即便能通，也往往在暗示你把控制面当「远程服务」用，和最小暴露原则相反。若你必须从手机访问同机或旁路由上的面板，应走 SSH 隧道、VPN 回连到受控内网、或带身份校验的反向代理，不要直接把 9090 摊在 0.0.0.0 上给全世界。
# Minimal safe pattern (adjust port; comments in English per project style) external-controller: 127.0.0.1:9090 secret: "use-a-long-random-string"
第二步：配置 API Secret 并理解何时会 401
在 Clash 系配置里，secret 即常见的 API Secret 来源：未设置时，很多控制接口不校验；设置后，客户端应在请求中附带与服务端配置一致的凭据。广泛使用的写法是在 HTTP 头中发送 Authorization: Bearer <secret>。你更换密钥后，已开的浏览器标签、旧版面板进程若仍用旧头或空头，会遇到 401 Unauthorized，这是预期现象，说明鉴权已生效而非「坏了」。
设密钥的实操建议很朴素：足够长、随机、不要与订阅地址或邮箱密码复用。长字符串可以通过密码管理器生成。若你担心写在 YAML 里「看得见」，要明白能编辑这份配置的人本来就有高权限，真正该防的是网络路径上的未授权访问。若多人共用一台机器、配置文件位于共享盘，那属于操作系统与文件权限层的问题，与 secret 是否存在于明文 YAML 是两条线，不要混在一起否定「设密钥没用」。
部分高阶环境会把控制面只留给本机环回 + Unix 域套接字 / 命名管道，从而连 TCP 入站都省掉。这类能力因内核、操作系统与包装壳而异。若你维护的是 Linux 无头部署，可延伸阅读《Linux 无图形界面部署 Clash Meta》，把 仅本机、systemd 权限与日志当作同一安全债一起还。
secret 与 HTTP 头对应关系。排错时优先打开开发者工具，看实际发出的 Authorization 头是否存在、是否与正在运行的热加载后配置一致，而不是只改一个输入框的显示状态。
Yacd 与第三方面板：地址栏、HTTPS 与跨域的坑
Yacd 一类前端通常是静态资源，用浏览器打开；它们通过你填的 Clash / mihomo API 基址去拉 JSON。最稳妥的单机模式是：API 基址为 http://127.0.0.1:端口，secret 在面板里单独填，由前端拼接请求头。若你改成 https:// 而本地控制面只提供 http://，会表现为握手失败；若用 CDN 上托管的 Yacd 在线页去指你本机 127.0.0.1，还会触及浏览器是否允许该网页访问你的本机这类策略，排错时要把「我能不能从命令行 curl 通」和「浏览器里混合内容 / 安全策略」分开看。
对多数读者，把面板 HTML 也跑在本机（或随客户端内置）是噪音最少的路径。若你坚持在公网或另一台机子上打开网页版 Yacd 再指回家里设备，这已是远程运维结构，应前面所述一样叠认证与 TLS，不要指望在聊天软件里发一个长链接就长期安全。面板作者更新频繁，字段名与路径若随内核有细微差异，以你当前 mihomo / Clash 版本文档为准，本文不锁死单一路径字符串。
自写脚本时，用 curl 带上头即可在终端验证 先鉴权、再调敏感路径 是否成立。若 curl 127.0.0.1 在不带头时仍能改配置，说明要么未设 secret，要么命中了未保护的兼容路径——都应视为高优先级修复，而不是「能用就行」。
external-ui 与「只读」：减少误触与暴力尝试
一些内核与客户端提供 external-ui 或内置静态资源目录，让浏览器直接通过控制端口或单独路径打开面板。安全角度它解决的是「文件从哪来」，并不自动替代 secret。若存在只读或「禁止通过 API 改某些项目」的选项，可在多用户、演示机上降低被误点导致大面积改组的风险。需要强调的是：只读不替代传输加密，也不替代监听地址；网络仍应先收束在可信路径上。
对订阅更新 URL、规则提供方等敏感字段，若你的面板或脚本可以导出现有配置，请把「能导出」与「能改」同样视为高敏能力，在共享设备上配合系统账户锁、磁盘加密与及时锁屏。这些都是「安全是一层层叠起来」的常识，和 Clash 单点配置不矛盾。
和「允许局域网」「混合端口」别混：三条线各管什么
很多新手会把开代理给手机用和开外控给面板用想成同一件事。实际上：mixed-port 或 port / socks-port 解决的是应用把流量送进来走规则，而 external-controller 解决的是管内核。你可以在不对外开外控的情况下，只给局域网开放混合端口，用于 HTTP 代理，这在家庭网络里是常见需求；但一旦你同时把外控绑到 0.0.0.0，就等价于在同一张家庭网里多放了一个高权限入口。
若你照《Windows 局域网共享 Clash》为手机配好了代理，建议回头核对本机 Windows 防火墙入站：通常你会放行的是代理端口，不是控制端口。这样即便家人设备误扫，也不会扫到一个无鉴权外控。与路由器 OpenWrt 上跑服务时同理——网关设备本身就是攻击热点，外控更应收束，不要把「我能在内网用」误当成「内网都可信」。
系统级「系统代理 / TUN」与本文主题相邻但不同。全局接管更多应用流量，却不替你自动关掉一个绑错地址的 external-controller。若你刚排查过 TUN 相关现象，可对照《Clash TUN 与系统代理总览》，但外控安全请仍以本文第一节清单为准。
路由器、NAS 与公网头：更小的暴露面、更严的前置机
在软路由、NAS、小主机上跑 Clash 时，设备往往7×24 小时在线，比笔记本更适合被扫。默认策略应是：external-controller 只监听 127.0.0.1 或内网管理接口后的反代，由 nginx/Caddy/Traefik 等提供 TLS 与基本认证 / IP 白名单。若你暂时只会「端口转发」，那至少应确保有 secret、不映射到公网、或只映射在 VPN 入口之后。
多实例场景注意端口冲突与配置覆盖：一个系统里同时跑两个内核却共用 9090，会表现为「我明明改了配置却不生效」或「A 的接口其实是 B 在应」。这既是稳定性问题，也是安全盲区——排错时记得用 ss -lntp 类命令看清谁占用了哪个端，不要假设 GUI 上写的端口一定进到了你以为的那个进程。长期无人值守设备还应依赖自动更新、日志轮转与崩溃重启，与 mihomo 升级节奏可参见《Clash Meta 升级指南》。
自检清单：用本机与局域网各测一次
把下列步骤当固定清单执行，能筛掉大量「以为锁了、其实没有」的问题。第一步：在本机用 curl -sS 或浏览器访问 http://127.0.0.1:9090/... 的健康或版本类路径（以你当前内核为准），在已设 secret 时，故意不带头与带头各试一次，确认未授权时确实被拒绝。第二步：在同网段另一台设备上重复访问你电脑的 局域网 IP 与同一端口。若你已将外控收束在 127.0.0.1，这里应连接被拒绝或超时；若仍能打开，说明仍在全网卡或存在端口转发/容器桥接的二次暴露，需要回滚配置重查。
第三步：打开客户端的实际运行中配置（不是教程模板），确认「你改的 YAML 就是进程加载的那一份」。热加载失败、工作目录多份 config.yaml 时，界面显示「有 secret」与内核真用的不一定一致。第四步：若使用 Docker，注意容器里 127.0.0.1 指容器自己，宿主机和面板若在两侧，要改为可路由的宿主机地址或把网络模式调成 host，但这又牵涉新的暴露面，须与网桥/NAT/防火墙联调，不展开也能记住一句：别在不懂 Docker 网桥时把 9090 当魔法端口乱映射。
这些步骤与渗透测试无关，是普通用户能独立完成的最小验收集。做完，你对「仅本机」与「未授权访问」心里会有数，再遇到陌生热点或要借电脑给别人用时，也记得把外控、面板和高敏导出能力一并纳入决策。
常见问题
外控一定要开吗？
不必。你完全可以只用系统托盘里的客户端、从不打开 Yacd。但若要用实时连接日志、远程切换、脚本自动化，外控是多数方案的基础，那就按本文把它锁到本机 + 设密钥。
设了 secret 之后旧书签打不开？
在面板里更新密钥输入框、清缓存、或重开内嵌 WebView。根本原因是新密钥未随请求发出，不是内核「坏了」。
手机也要管面板，怎么办？
不要为此把 0.0.0.0:9090 开给公网。优先 SSH 反向隧道、Tailscale/WireGuard、回家 VPN 等，把管理流量放进你已信任的通道，再在隧道终端访问 127.0.0.1。这与「直接暴露端口」的安全代差是数量级的。
写在最后：外控是工具，不是敞开的后门
把 Clash 外部控制 用在 Yacd、自写面板或脚本上，能明显减少对着 YAML 手抖的概率；可只要还存在「监听面过大、API Secret 为空、在不可信网络长期在线」的任意一条，未授权改组、导订阅 的风险就不会因为你「觉得自己只是普通用户」而消失。把 external-controller 写牢在 127.0.0.1 上、为 REST 设好密钥、分清楚和代理端口、局域网共享的边界，你就已经比大多数误配置领先一大截。相比其它同类方案，Clash 在可观测性与可脚本化上仍然突出，而安全与稳定性往往来自这种琐碎却可复制的习惯。
全平台安装包与免费订阅链接的维护，建议以本站 下载中心 为准，避免在不明渠道下载被篡改的壳程序。更系统的规则、策略组与规则集写法，可继续阅读《YAML 规则分流完全指南》；技术专栏里也有更多与安全、分流相邻的主题可供对照在专栏中浏览。