Mihomo 控制 API 是代理核心的管理接口，应与代理流量端口分别保护监听和凭证。将 HTTP 控制器限制在必要地址，设置强 Secret，使用可信面板，并同时验证未授权拒绝和授权成功。浏览器能打开页面，并不能证明管理接口安全。［1］

关键要点

代理认证与 HTTP 控制 API 认证保护不同接口。

loopback 缩小暴露面，不会让本机进程和浏览器代码自动可信。

Unix socket 与 Windows Named Pipe 不校验 HTTP API Secret。

远程管理须有受控入口、加密传输及可验证的撤销方法。

Mihomo 控制 API 能控制什么？

本文按 Mihomo v1.19.32 与官方全局配置核对 HTTP 控制字段及认证行为，未声明作者完成端到端部署，也不声称测试过所有面板和封装。变更前记录实际核心、封装、操作系统及面板来源。［1］［2］

自建运维责任框架帮助确定凭证、更新和退役所有者。管理访问可能暴露连接信息或改变路由，而开放代理的滥用风险属于另一边界。两类接口分别保护和验证，不假定一个密码能覆盖全部。

仅操作你有权管理的实例，私下备份有效配置，保留不依赖控制器的恢复通道。共享主机先约定窗口、查明凭证使用者，再轮换。不要关闭日常使用的代理、VPN 客户端或无关代理来腾端口。

步骤 1：识别监听与凭证所有者

登记真实核心进程、加载配置、全部控制监听、代理端口、面板文件及转发服务。Linux 本机可用 ss -lntup，其他平台使用原生监听检查器。将地址、端口与实际所有者对应，不盲目结束意外进程。

mixed-port、SOCKS 和 HTTP 代理监听承担应用流量；external-controller 提供管理 API，secret 用于其受保护 HTTP 路由。代理的 authentication 是另一组设置，因此仅改 allow-lan 不构成完整控制接口审计。［1］

同时记录 IPv4、IPv6、容器、转发端口和反向代理。容器内绑定 loopback 仍可能经另配中间服务访问；工作站 loopback 也不是服务器 loopback。核对每个获授权管理位置的实际入口路径。

订阅 URL 属于含凭证输入，按订阅链接保密边界保管。不要把完整配置或 Secret 粘贴到公开问题、在线 YAML 编辑器、未经评估的远程面板或截图。诊断记录描述监听与拒绝结果即可，不展示凭证。

步骤 2：设置最小 HTTP 监听和新 Secret

本地管理先使用 loopback 和新生成的随机 Secret。以下只列本次相关字段，不是完整代理配置；加载前替换占位内容，保留无关路由和代理凭证。［1］［3］

external-controller: 127.0.0.1:9090
secret: 'REPLACE_WITH_A_UNIQUE_RANDOM_SECRET'

用可信密码管理器或操作系统随机源在本机生成唯一、高熵值，公开占位文本不能当凭证。将 Secret 保存在私密配置并限制文件权限，不放进命令参数、URL、shell 历史或共享日志。

从预期配置移除不需要的其他控制监听，不假定这个字段自动覆盖全部接口。核对封装生成的覆写，应用后再次检查实际监听。先用所选版本的文档化检查功能验证配置，再经正常所有者重新加载。

为什么 socket 和 pipe 要独立检查？

官方说明 external-controller-unix 与 external-controller-pipe 不校验 Secret；前者依赖套接字路径权限，后者依赖 Named Pipe 访问控制。下面的 HTTP 拒绝检查不能证明这两种接口安全。［1］

不需要就不启用。必须使用时，将 socket 放进私密父目录，检查实际所有者和权限，pipe 仅允许预期账户访问；重启后再查，因为创建权限和服务身份可能与旧文件不同。

本次加固也不要顺便启用控制器可选 DoH 入口，官方文档同样说明它不检查 API Secret。DNS 服务暴露需要另定范围和策略；未使用的服务保持关闭，可减少独立访问边界。［1］

步骤 3：怎样控制 Mihomo 面板暴露与远程入口？

面板是在浏览器中接触管理凭证的代码。文件应来自可追溯的项目发行版，记录版本，变更期间避免未评估托管站和自动更新。熟悉的外观不证明来源可靠，本地托管也不免除对文件本身的信任判断。

使用 external-ui 时，指向预期本地目录并核对实际提供的文件。官方将 UI 文件、控制监听与 Secret 分开；登录表单不是 API 服务端认证证据，直接请求受保护路由仍须拒绝无凭证访问。［1］

跨域权限只允许真正需要的面板 origin。不要为消除浏览器错误而使用通配来源或开启私网访问；CORS 约束浏览器交互，不认证命令行客户端，也不替代 Secret。封装需要额外 origin 时，说明原因并验证有效配置。

偶尔远程管理可选窄绑定 SSH 本地转发。使用已核验主机密钥和既有授权服务器账户，核心 HTTP 仍留在服务器 loopback。下例在管理员工作站运行，替换账户与主机名；本地端口刻意与服务器不同。

ssh -o StrictHostKeyChecking=yes -o ExitOnForwardFailure=yes \
  -N -L 127.0.0.1:19090:127.0.0.1:9090 admin@controller-host.example

SSH 加密远程链路，本地 loopback HTTP 仍须 API Secret。不要改成通配绑定；结束后关闭该 SSH 连接，确认本机 19090 不再监听。主机密钥不能核验就停止，不盲目接受。

HTTPS 入口是另一设计，需要有效证书、客户端正常验证、认证和暴露限制，并检查有无直连 HTTP 绕过入口。TLS 错误不能靠跳过证书验证或公开原始 HTTP 控制器补救。不要只为让面板可用就增加 WAN 转发。

步骤 4：验证 Mihomo API Secret 是否生效

对你自己的受保护 /configs 检查：第一个请求不带凭证，第二个故意带错误值，两者都不能返回受保护配置。示例为本机 9090；走 SSH 转发时换成 19090。［2］

curl --noproxy '*' --max-time 5 --silent --show-error \
  --output /dev/null --write-out '%{http_code}\n' \
  http://127.0.0.1:9090/configs
curl --noproxy '*' --max-time 5 --silent --show-error \
  --header 'Authorization: Bearer intentionally-wrong-secret' \
  --output /dev/null --write-out '%{http_code}\n' \
  http://127.0.0.1:9090/configs

v1.19.32 的预期认证失败为 HTTP 401。超时或拒绝连接不证明 Secret 已被检查，只说明该次未成功访问。再通过可信本地面板或私密 curl 配置文件使用正确凭证，预期能访问受保护路由；不要把真实 Secret 写进公开命令或查询参数。［2］

检查方法	预期现象	失败处理
检查实际监听套接字	仅有预期控制地址和端口	移除意外监听或转发所有者
匿名请求受保护路由	HTTP 401，不返回数据	停止外部访问并修认证
错误 Secret 请求	HTTP 401	查有效配置及中间服务
正确当前 Secret 请求	受保护路由成功	查凭证加载与路由归属
从被排除的授权测试主机访问	无意外路径可达控制器	关闭转发或防火墙暴露
关闭远程入口后再连	入口不可用	查仍运行的转发服务

这些是读者验收条件，不是作者结果。直接核心和中间服务分别验证；反向代理拒绝可能掩盖没有认证的后端。另查面板只完成预期管理动作，凭证不保存在共享浏览器配置中。

步骤 5：轮换凭证并撤销远程访问

生成新 Secret，经配置所有者更新私密有效配置，再用正常生命周期加载。更新每个可信客户端，重复正反检查。新凭证成功不够，旧凭证必须在新的受保护请求中被拒绝。

按所选生命周期结束旧面板会话和管理连接；已有流不是新认证请求。清除浏览器存储、私密客户端文件和转发配置中的旧令牌。发生泄漏时，不为修客户端而从备份恢复旧 Secret。

配置错误需要回退时，恢复原监听设置，但保留未泄漏的 Secret。关闭测试 SSH 转发，只撤销本次入口规则，再检查监听；核对普通代理操作与独立管理通道，不全关防火墙来恢复面板。

路由器管理的 Mihomo 可能由插件重新生成设置，可参照OpenClash 部署和网络恢复。若任务不值得承担面板、凭证和服务器维护，在保留管理面之前比较自建与托管方案的责任。

总结

控制监听及中间服务与代理端口分别登记。
HTTP 控制器即使在 loopback 也保留认证。
核验拒绝、授权成功、轮换及入口撤销。
socket 权限、浏览器信任与 TLS 分开验收。

常见问题

allow-lan false 能保护控制 API 吗？

该设置针对代理流量访问，控制器有自己的监听和认证。应检查实际控制地址，再单独测试受保护 API 路由。

loopback 可以省略 Secret 吗？

loopback HTTP 控制器仍应认证。本地进程和浏览器代码不自动可信，后加的转发服务也可能扩大实际暴露范围。

面板登录框能证明认证有效吗？

界面要求密码，不代表后端已经强制认证。应直接验证核心拒绝匿名及错误凭证访问受保护路由。

Unix socket 也检查相同 Secret 吗？

文档说明 Unix socket 和 Named Pipe 不校验 API Secret。应限制操作系统权限或不启用，HTTP 测试不能证明它们的权限安全。

CORS 能代替访问控制吗？

CORS 限制特定浏览器交互，不约束所有 HTTP 客户端。即使明确允许来源，也要保留认证、窄监听和受控远程入口。

私密 SSH 转发本身就够了吗？

核验过的 SSH 保护远程传输，不取消 HTTP API 的认证要求。保持本地窄绑定，并在管理结束后撤销转发。

怎样证明 Secret 轮换成功？

新凭证应有效，旧凭证应在新受保护请求中被拒绝。还要按客户端生命周期结束旧管理会话并移除保存的旧值。

免责声明：本文说明文档支持的管理控制及读者检查，不声明作者测试结果。仅在获授权系统操作，保留不依赖 API 的恢复通道。

来源:

Mihomo — General configuration — https://wiki.metacubex.one/en/config/general/
Mihomo — v1.19.32 controller routing and authentication — https://github.com/MetaCubeX/mihomo/blob/v1.19.32/hub/route/server.go
Mihomo — v1.19.32 configuration source — https://github.com/MetaCubeX/mihomo/blob/v1.19.32/config/config.go

Sources checked 2026 年 10 月 11 日。

延伸阅读:

Mihomo 控制 API 加固：监听、认证与远程入口验证