开启 TUN 后 metacubexd 后端退出，优先升级 v1.273.1 桌面包。9 月 10 日的这次更新专门修复 native TUN helper 启动与恢复。刷新网页面板、换订阅，都不能替换桌面 helper；升级后应从普通代理运行状态开始重试。

网页能打开，为什么 TUN 仍会失败？

metacubexd 有静态网页面板，也有包含 Mihomo 的桌面应用。网页负责调用已有后端；桌面版还负责内核进程和本机 helper。系统代理改变应用使用的代理入口，TUN 则涉及系统路由，需要管理员服务参与。

Issue #2149 的报告涉及 Linux、Windows：从主界面开启 TUN 返回 500，托盘操作又暴露不同错误。这是用户反馈，不表示每台机器都会复现。Linux 报告中的错误为：

TUN enable failed connect ENOENT /run/metacubexd-helper.sock

主界面的五百错误只说明控制请求失败，信息量不如托盘给出的底层原因。应保存两个入口的错误原文，尤其是路径缺失、进程退出或授权取消等细节。订阅内容相同而入口报错不同，并不矛盾：界面可能只显示了外层请求结果。

这个 socket 报错指向 helper 通信入口。不要自己创建同名文件，更不要把它当作 DNS 服务器地址。v1.273.1 Release 明确关联该问题和修复提交。

1.273.1 改了哪段启动过程？

提交 81b9f81 补齐 helper 所依赖的解包模块，并改动服务启动、协议兼容和恢复逻辑。新版对 socket 尚未出现或拒绝连接的情况，按 250 毫秒间隔最多重试二十次。已安装的 helper 不可达、协议不兼容或返回权限错误 EACCES 时，会尝试一次重装修复，可能再次请求管理员授权。

桌面安装包与驻留服务可能处于不同版本状态。仅看到窗口已更新，不能证明旧 helper 已被替换。首次安装后的连接失败不会进入这条旧服务重装修复分支。

若启用失败，应用会移除 TUN 设置并尝试启动普通代理后端。这是失败后的补救行为，不能解释成任何断网都能自动恢复，也不是新增了 TUN 功能。

用报错所在层决定下一步，比反复切换开关有效：

看到的表现更可能涉及此时检查什么
网页打开，但读不到连接列表网页与 Clash API 通信实际端点、认证与跨域错误
开 TUN 报 helper socket 缺失本机 helper 启动桌面版本、管理员提示和 helper 错误
Windows 提权命令失败服务安装与提权原始错误、官方桌面包及系统架构
内核运行，开 TUN 后断网路由或配置Recover network 的恢复结果

下载同平台、同架构的桌面包

保留现有 profile 内容，正常退出旧版后安装同平台、同架构桌面包。Release 的 compressed-dist.tgz 是网页资源，不能拿它修复本机服务。Windows x64 选择 MetaCubeXD-1.273.1-win-x64.exe，Apple Silicon 选择 MetaCubeXD-1.273.1-mac-arm64.dmg；Intel Mac 使用 mac-x64。

Linux 要同时匹配发行版包格式和 CPU。例如已下载官方 amd64 Debian 包，在文件所在目录执行以下安装示例：

sudo apt install ./MetaCubeXD-1.273.1-linux-amd64.deb

其他发行版按 固定版本 README 选择 rpm、pacman 或 AppImage。官方说明这些构建未签名，批准管理员提示前要核对发布仓库与资产。不要从不明附件补装 helper 或 DLL。桌面发行形态可参照metacubexd 客户端页。

激活 profile 后，怎样判断 helper 已接管？

重新打开应用，激活原有配置，等普通代理内核进入运行状态，再开启 TUN。配置激活会执行内核校验；已有 YAML 错误时，不应跳过校验来测试 helper。控制界面显示的 Mihomo 版本也应记下，桌面版本号不能代替内核版本。

macOS 使用 root LaunchDaemon，授权由系统提示完成；Windows 安装自动启动的 metacubexd-helper 服务，随包提供 wintun.dll。Linux 使用 root systemd unit 与 pkexec 授权；缺少 Polkit agent 的无桌面环境可能无法完成交互授权。

不要把服务列表里存在名称当成接管成功。服务能够响应、特权内核能够启动、应用流量进入预期规则，是三个不同结果。如果普通代理已经失败，先修内核启动；如果只有开启隧道后失败，再沿 helper 错误查下去。

观察内核是否继续运行，再让原先需要 TUN 的应用发起连接。普通后端启动异常看 Kernel logs；规则与 DNS 看 Logs。但该版 helper 源码 启动特权内核时使用 stdio: ignore，不能期待 Kernel logs 收到它的标准输出。TUN 启动失败应保留应用提示与 helper 原始错误。本文依据文档和源码整理，未完成各系统安装实测。

本机 controller 需要手动改成 9090 吗？

不用。桌面版自动配置本机端点，每次启动为控制 API、Clash API、mixed proxy 分别选择互不相同的空闲回环端口。以应用及日志报告的地址为准，不把 /api/control 请求发往 Clash API，也不为解决 helper 错误把监听改成所有网卡。

自己维护独立 Mihomo 后端时，官方全局配置 支持下面的本机示例。它放在该后端实际加载的 YAML 中，不能照抄覆盖桌面版自动生成的端口：

external-controller: 127.0.0.1:9090
secret: "替换为你自己的长随机密钥"

面板填写相同密钥。跨设备访问的监听与认证设计另见external-controller 密钥与面板安全，与本次 helper 升级分开处理。

开启后断网，怎么撤回？

点击应用的 Recover network。源码在当前为 TUN 模式时尝试停止特权内核、移除配置中的 tun: 并重启普通后端；普通代理模式下不会重复重启。恢复失败会记录错误，按钮返回并不证明联网已经恢复。也可以正常退出应用，关闭窗口留在托盘不算退出。若曾强制结束进程，重新打开后使用恢复按钮。

仍失败时，向项目提交应用版本、系统及架构、原始错误和恢复按钮结果，删去订阅链接与密钥。内核运行而只有域名异常，才继续阅读Mihomo macOS TUN 权限与 DNS 排查，不要把启动修复扩大成整套网络重配。