为什么要在开面板之前单独谈安全
Clash Meta（上游内核常称 mihomo）除了转发流量，还带一套 REST API：图形界面、手机端遥控、自动化脚本，往往都通过它下发「重载配置、切换策略组、查看连接」等指令。接口能力越强，被误配时的后果就越不像「只是上不了网」——更接近别人能远程动你的代理大脑。
典型翻车路径有两类：一是把 external-controller 绑到 0.0.0.0 或局域网地址，却忘了配 Secret 或口令过短，导致未授权访问；二是在路由器上做端口映射、云服务器上裸奔管理口，把本该「仅本机或可信内网」的服务暴露到公网。本文不重复安装与订阅导入，而是对齐你已经会用的 YAML，把管理口当成一个独立面来加固。
external-controller 到底是什么
可以把 external-controller 理解成「内核对外暴露的 HTTP 控制面地址」，例如 127.0.0.1:9090 或 192.168.1.10:9090。Web 面板、Yacd、REST 客户端会向这个地址发请求；路径形如 /configs、/proxies 等（具体以你所用版本文档为准）。它和 mixed-port、port 这类业务代理端口不是同一个东西：前者管配置与状态，后者管日常上网流量。
若你刚做完 内核升级或迁移到 mihomo，建议顺便核对一遍管理段是否被旧配置继承成「宽监听 + 空口令」。升级能带来新的特性开关，也会把多年未动的危险默认值一起带过来。
第一步：先决定「谁能连上管理口」——监听地址与 bind-address
安全顺序的第一件事，是明确管理接口只应对谁可见。默认只监听 127.0.0.1 时，只有本机进程能连，这是家庭用户最常见的安全基线。只有当你确实需要从另一台设备打开面板（例如平板调试局域网 PC 上的内核）时，才把监听扩到局域网网卡或使用通配地址。
全局的 bind-address 在不少配置里同时影响代理监听与控制面行为，具体以你当前内核与客户端封装为准；实践上请用系统工具核对「最终监听在谁身上」。在类 Unix 系统上可用 ss -lntp，在 Windows 上可用 netstat -ano 查看控制端口是否落在 127.0.0.1 还是 0.0.0.0。看到 0.0.0.0:9090 并不代表你一定在「公网裸奔」，但它意味着所有网卡上可达该端口的客户端都能尝试握手——下一步就必须有强 Secret 与网络边界。
# Example: controller localhost-only (recommended baseline)
external-controller: 127.0.0.1:9090
secret: "replace-with-long-random-token"
# bind-address / allow-lan affect proxy listeners; verify with ss/netstat after reload.第二步：务必设置 Secret，并当作密码而不是装饰
Secret 是 REST API 的访问凭据。客户端与脚本应在请求头携带 Authorization: Bearer <你的 Secret>（具体拼写以官方文档为准）。若留空或沿用仓库示例里的弱字符串，任何能触达该地址的人都能调用接口，等价于远程 root 式控制你的代理栈：切节点、改规则、导出订阅链接的风险都现实存在。
设置建议尽量朴素：长度足够、随机、只存放在可信设备；不要与论坛账号、邮箱密码复用；图形客户端若把 Secret 显示在界面里，注意录屏与共享屏幕场景。更换 Secret 后记得同步更新面板地址栏参数、自动化脚本与环境变量，并重启或热重载使内核生效。
# Use a long random value; rotate if leaked or shared by mistake.
secret: "e6f1c2b8-9a7d-4c5e-8f0a-1b2c3d4e5f60-longer-is-better"第三步：仍要远程管理时，再谈「暴露」——优先隧道而不是端口裸晒
真需要从外网调试家中电脑上的 mihomo，优先顺序一般是：VPN 或 SSH 反向隧道回到内网，再访问 127.0.0.1 上的控制口，而不是把 9090 直接映射到公网 IP。若必须经由反向代理暴露，应叠加 TLS、访问控制列表、失败速率限制，并把源站继续绑在回环或内网地址上——这些属于通用 Web 安全工程，不在此展开细节，但原则只有一句：别把「能改代理配置的 HTTP 服务」当成普通静态页对待。
在宿舍、公司或公共 Wi‑Fi 下，即便只监听局域网，也要假设同网段存在不可信设备。能不开宽监听就不开；必须开时，Secret 与系统防火墙入站规则要同时到位。对服务器场景，可结合 systemd 与防火墙把管理口限制在管理网段或本机。
用 curl 做一次最小验证
改完配置并重启内核后，用命令行快速验证「未带 Secret 是否会被拒绝」和「带 Secret 是否返回预期 JSON」。把下列示例中的地址与端口换成你的 external-controller，把令牌换成你的 Secret。
# Should fail or be unauthorized when secret is required (expect 401/403 or empty deny)
curl -i http://127.0.0.1:9090/version
# Should succeed when Authorization matches your secret
curl -i -H "Authorization: Bearer YOUR_SECRET_HERE" http://127.0.0.1:9090/version若你在第二步把监听改成了局域网地址，请在另一台内网设备重复上述测试，确认「无令牌不得入内」在跨机器路径上同样成立。若仍能通过浏览器直接打开敏感接口，回到前两节检查是否走了独立的无鉴权兼容路径、是否被客户端本地代理改写、或是否连错了端口。
和 TUN、图形客户端的关系
打开 TUN 模式不会改变「管理口要不要鉴权」这一事实；它改变的是流量如何进隧道。某些图形客户端会在本机自动拼接带 Secret 的本地 URL 打开内置面板，这让你产生「好像没有密码」的错觉——实际上 Secret 仍然生效，只是被客户端替你填好了。若你手动把同一地址抄到浏览器另一台设备上，就会立刻暴露出问题配置。
收工前的短清单
把下面几条勾完再开面板，能挡住大多数粗心配置：① external-controller 的监听范围是否与真实需求一致；② ss / netstat 看到的绑定地址是否与预期一致；③ Secret 已设为高熵随机串且未泄露；④ 无令牌访问敏感路径会被拒绝；⑤ 未做多余的公网端口映射；⑥ 需要外网运维时优先 VPN/SSH，而不是直接晒控制口。
相比零散搜索「面板打不开」，把 REST API 当成与订阅、规则同级的重要配置项，一次性理顺监听与鉴权，后面无论是自建仪表盘还是自动化脚本，都会省心得多。Clash 生态在规则分流、多协议内核与客户端整合上已经相当成熟；把管理面收紧之后，日常折腾节点的体验会更接近「可控的玩具」，而不是「给全屋网络留的后门」。
若你尚未安装或准备换用带 mihomo 的图形客户端，建议优先从本站 下载页 获取与平台匹配的版本，再对照本文检查管理口配置；关注上游安全公告与发行说明时，可在独立段落访问 GitHub 仓库了解漏洞披露与更新记录，与安装包获取渠道区分开来。