代理已通，面板仍 401：先分清数据面与控制面

很多读者已经能用 Clash Meta 正常上网：系统代理或 TUN 下浏览器可以打开外站，策略组也能切换节点。但一旦打开 Yacd、metacubexd 或其它「网页控制台」，却看到 401 Unauthorized、空白页、或浏览器提示无法连接——这通常与节点质量无关，而是控制面（Control Plane）没配对：内核在另一个地址或端口上提供 REST API，而面板连错了地方，或没带对鉴权口令。

可以把流量转发理解成数据面：例如 mixed-port、port、socks-port 给应用走代理。相对地，external-controller 是管理面：查询连接、切换策略、热重载配置，都走这里。数据面通了不代表管理面已监听、更不代表浏览器里的面板会自动猜到你的 secret。若你刚接触图形客户端，建议先读 如何选择适合自己的 Clash 客户端，确认「设置里显示的 API 端口」与配置文件是否同源，避免 GUI 写了一套、YAML 里是另一套。

ℹ 排障顺序：先确认本机 external-controller 实际监听地址与端口 → 再核对 secret 与面板填写是否逐字符一致 → 最后用 curl 直连 API 验证。不要一上来把绑定改成 0.0.0.0 并暴露到公网来「碰运气」。

external-controller 与 mixed-port 不是一回事

在常见 YAML 顶层字段里，mixed-port（或单独的 port / socks-port）服务于代理协议：你的应用、终端环境变量或系统代理应指向这些端口。而 external-controller 指定的是HTTP(S) 管理接口的监听地址，例如 127.0.0.1:9090。Web 面板连接的是后者，不是 mixed-port。把面板 URL 填成 mixed-port，往往表现为连上了一个「不是 Clash API 的服务」或直接被拒绝。

部分发行版或 GUI 会启用 TLS、自定义路径或 Unix socket，这时浏览器里填写的协议（http 与 https）也要一致。若配置里写的是 external-controller: unix:/var/run/clash.sock，浏览器面板通常无法直接使用，需要改回 TCP 监听或借助客户端内置面板。若你使用 Docker，注意「容器内 9090」与「宿主机映射端口」不是同一个概念：面板在宿主机浏览器打开时，应访问映射到宿主机的那个端口。

推荐起步：本机绑定与安全 secret

对个人电脑而言，最稳妥的起步是把管理接口绑定在环回地址上，仅本机进程可直连，例如 127.0.0.1:9090。同时设置足够随机的 secret（文档与社区常称「密钥」或「token」）：Clash Meta 的 REST 请求在开启 secret 后，需要在头里携带 Authorization: Bearer <你的 secret>，缺失或拼写错误就会 401。

下面是一段示意配置，请把端口与口令换成你自己的；若与现有文件合并，注意 YAML 缩进与重复键（同一键以后者为准，取决于加载器，排障时应以「实际生效的配置」为准）。

external-controller + secret（YAML illustration） 
# Top-level keys — illustration only; merge with your real profile.
external-controller: 127.0.0.1:9090
secret: "replace-with-a-long-random-string"

# Optional: allow LAN devices to hit the API — use only if you understand the risk.
# allow-lan: true
# When allow-lan is true, binding may need 0.0.0.0 — tighten firewall accordingly.

修改后请重载配置或重启内核，再在客户端日志里确认 RESTful API listening at 一类信息是否出现在你预期的地址上。若 GUI 有「外部控制 / API 端口」开关，确保它没有把 YAML 里的值覆盖成空或另一个端口。

Yacd、metacubexd 如何指向正确的 API

Yacd 与 metacubexd 都是静态前端，通过浏览器向你的 external-controller 发 REST API 请求。部署方式可能是本地打开 HTML、也可能是托管站点；无论哪种，核心参数通常是：主机名（本机即 127.0.0.1）、端口（与 YAML 一致）、以及 secret（与 YAML 完全一致）。

常见误配包括：在面板里填了 localhost 而实际只监听了 127.0.0.1（多数情况等价，但若遇 IPv6 解析差异可改用 127.0.0.1）；HTTPS 面板页面却去请求 http://127.0.0.1:9090 触发浏览器混合内容拦截；或从旧书签打开了一份面板，仍缓存着上一版 secret。遇到 401 时，优先在面板里「清除连接信息」后重新输入，而不是反复刷新页面。

若你使用自托管的 Web 面板域名访问本机 API，浏览器会执行 CORS 校验；官方面板一般已处理，若自行改源码或反代，需保证预检请求能通过。此类问题表现为浏览器控制台出现跨域错误，而不是 Clash 日志里的 401。

用 curl 自检 REST API（绕过面板）

在终端执行下列命令（把端口与 secret 换成你的值），若返回 JSON 而非 401，则说明API 与鉴权正常，问题集中在面板或浏览器侧：

curl — GET /version (example) 
curl -sS -H "Authorization: Bearer YOUR_SECRET_HERE" \
  http://127.0.0.1:9090/version

若此处仍 401，说明 secret 与内核不一致、或请求未带到正确的 Authorization 头。若连接被拒绝（Connection refused），则是端口未监听、被其它进程占用，或防火墙拦截——与鉴权无关。macOS / Windows 可在修改配置后用系统工具查看对应端口是否处于 LISTEN 状态。

连接被拒绝、端口冲突与多实例

「浏览器连不上」不一定是 401：有时是根本没有服务在听。典型原因包括：曾经安装过多个 Clash / Meta 衍生版，其中一个占用了 9090；GUI 把 API 改成了 9091，而你还按旧习惯打开 9090；或内核崩溃后托盘图标仍在，实际进程已退出。此时应打开系统监视器结束残留进程，再启动一份配置明确的实例。

若你把 external-controller 写成了 0.0.0.0:9090 却仍在本机浏览器访问，一般仍可用 127.0.0.1:9090 连上；若不行，检查本机安全软件是否对「外部入站」有额外提示。更复杂的场景是仅允许 Unix socket 或 TLS 客户端证书——那已超出「入门绑定」范围，需要对照你所用发行版的文档。

局域网访问与「不要公网暴露控制口」

当手机或其它设备要访问电脑上的面板时，才会考虑 allow-lan: true 与绑定非环回地址。请把防火墙规则收紧到「仅信任的子网」，并继续使用强 secret。更系统的子网绑定、网关与 DNS 协同，可参考 局域网共享与防火墙绑定。

切勿在未做 IP 白名单、未封端口的前提下，把 external-controller 直接映射到公网路由器端口——这等价于把整台代理的远程管理权摊在互联网上。若确有远程需求，应使用 SSH 隧道、VPN 或零信任方案把访问面缩到身份可信的通道内，而不是裸奔 9090。

⚠ 安全提醒：secret 一旦泄露，他人可在可达网络内操作你的策略与连接。截图、录屏、共享配置文件前请打码；不要把含 secret 的 YAML 发到公开群组。

控制面排通后，若仍感觉「网页打开慢、解析怪」，多半是 DNS 与规则层问题，而不是 API 端口。可继续阅读 Clash Meta DNS 配置详解，把解析链路与 fake-ip 行为理顺；若你同时开 TUN，可对照 TUN 模式深度解析，避免数据面与控制面混在一起排查。

日常使用中遇到「能上网但某一类站点异常」，仍建议从连接日志与规则命中入手，而不是反复改动 external-controller。API 稳定后，面板只是观察与操作的窗口；根因往往在策略与 DNS。

结语

Clash Meta 的 Web 面板依赖 external-controller 提供的 REST API 与 secret 鉴权：把控制口固定在本机、口令与内核一致，用 curl 先验证 API，再打开 Yacd 或 metacubexd，可以少走大量弯路。需要局域网共享时，再逐步提高暴露面并配合防火墙，而不是默认把管理接口摊到全网。

相比只解决「能上网」却不碰控制面的教程，把 API 安全与绑定地址一次写对，后续换节点、看连接、临时切规则都会更顺手；这也是 Meta 系内核在可观测性上的优势——前提是你愿意花几分钟把控制面当作正式组件来配置。

→ 立即免费下载 Clash，开启流畅上网新体验，用清晰的客户端与可控的 API，把日常排障稳在本机可验证的步骤上。