Mihomo TUN 模式权限不足怎么办？按报错与系统排查
简答：Mihomo TUN 提示“权限不足”时，先关闭 TUN并恢复网络，再用 Mixed、HTTP 或 SOCKS 验证普通代理，随后记录完整错误行。Windows 重点检查管理员授权、辅助服务和防火墙；Linux 检查 /dev/net/tun、运行用户与 CAP_NET_ADMIN；macOS 检查网络扩展；Android 检查 VPN 授权、其他 VPN、始终在线 VPN 和私人 DNS。
定义：Mihomo TUN 模式权限不足，是内核无法创建或接管系统级虚拟网卡、路由或 DNS 流量的提示，不一定代表当前账户本身没有管理员权限。
30 秒处理卡：先恢复网络，再按错误行分流
本文是第三方使用指南，页面不代表任何客户端或服务的官方支持。遇到 TUN 开关自动关闭、permission denied 或 cannot create TUN 时，先不要改 DNS、MTU、IPv6 或默认路由。
- 关闭 TUN：先在客户端关闭 TUN；如果客户端提供“恢复网络”或“重置网络”功能，优先执行。退出后检查系统代理是否仍指向本机端口。
- 验证普通代理：用 Mixed、HTTP 或 SOCKS 入口打开一个普通网页或应用。普通代理可用而 TUN 失败，说明节点和基础代理未必有问题，排查重点转向系统权限、虚拟网卡和路由。
- 复制完整错误：不要只记录“Start TUN listening error”，还要记录冒号后面的完整内容，以及客户端版本、Mihomo 内核版本和系统版本。
- 只改一项：备份 YAML 后，每次只修改一个字段；启动失败或全网断开时，立即关闭 TUN并恢复备份。
| 现象或日志 | 先查什么 | 停止条件 |
|---|---|---|
permission denied | 系统授权、辅助服务、TUN 设备或 Android VPN 授权 | 授权后仍失败时，保留第一条完整错误，不要继续盲改路由 |
cannot create TUN | 虚拟网卡、/dev/net/tun、旧进程和其他 VPN | 确认设备不存在或被占用后，再处理系统层问题 |
Start TUN listening error | 查看冒号后的具体原因，可能是端口、IPv6、路由或权限 | 不能只根据前半句认定为权限问题 |
| TUN 已启动但全网断 | auto-route、DNS、strict-route、防火墙和默认路由 | 关闭 TUN并确认原网络恢复后再继续 |
| 只有部分应用异常 | 规则、应用分流、DNS 或其他网络过滤器 | 先确认普通代理和系统网络本身可用 |
关键结论：“权限不足”只是错误表现，不是完整诊断结果。当前 Mihomo 文档说明，顶层 tun 配置适合一般用户；TUN listener 更偏向高级场景。Mihomo 入站配置文档
最小配置怎么复测：只保留 TUN 创建相关字段
如果普通代理可以使用，但完整配置一开启 TUN就失败，可以先备份原 YAML，再在现有配置中临时缩小 tun 部分。下面只是字段示例，不是完整配置文件，也不应覆盖订阅中的全部内容：
tun:
enable: true
auto-route: false这个复测目的只是判断内核能否创建 TUN，不主动接管全局路由。若当前内核或客户端不接受某个字段，应以当前 Mihomo 文档和客户端校验结果为准，不要强行添加旧教程中的字段。
协议栈字段可以使用当前文档列出的值，但协议栈不能替代系统授权。官方文档当前列出 system、gvisor、mixed、mips，并说明不同协议栈在防火墙和网络处理方式上存在差异；本文不把更换协议栈作为权限错误的默认修复。Mihomo TUN 字段文档
如果最小配置仍然无法创建 TUN，优先排查系统权限、虚拟网卡和授权流程；如果最小配置可以启动，之后再逐项恢复 auto-route、dns-hijack、strict-route、IPv6 和其他路由字段。
Windows：没有授权弹窗时，先查管理员运行与防火墙规则
最短路径：完全退出客户端，确认任务管理器中没有残留的 Mihomo 进程；然后右键客户端，选择“以管理员身份运行”测试一次。管理员运行只是定位步骤，不建议长期依赖高权限启动。
- 如果出现 UAC 授权弹窗，批准后只测试一次 TUN。Windows 的 UAC 会在操作需要管理员级权限时提示批准或拒绝。Microsoft UAC 说明
- 如果没有弹窗，检查 Windows 安全中心的保护历史、应用控制或组织策略；公司设备可能禁止安装服务、驱动或修改防火墙。
- 如果客户端提供“安装服务”“修复服务”“服务模式”或类似入口，优先使用客户端自身入口。不同封装的名称可能不同，不能按其他客户端的菜单名操作。
- 若日志指向防火墙，进入“Windows 安全中心→防火墙和网络保护→允许应用通过防火墙”，只对确认来源的内核程序添加必要例外，不要直接关闭防火墙或开放端口。Microsoft 明确建议，允许应用通常比开放端口风险更低，并提醒只允许认识的应用。Microsoft 防火墙应用放行说明
停止条件：授权、服务和防火墙处理后仍失败，就记录“授权后第一条失败日志”、客户端版本、内核版本和系统版本；不要继续修改 MTU、DNS 或默认路由。若同时运行其他 VPN、虚拟网卡工具或流量过滤器，先退出其他程序，只保留一个 TUN 实例。
Linux：检查 TUN 设备、进程能力和容器限制
Linux 下，文件权限和网络管理能力是两件事。内核文档说明，程序需要打开 /dev/net/tun 并创建或连接网络设备；创建不属于当前用户的网络设备通常还需要 CAP_NET_ADMIN。Linux 内核 TUN/TAP 文档
先执行以下检查：
ls -l /dev/net/tun
test -c /dev/net/tun && echo TUN_DEVICE_OK || echo TUN_DEVICE_MISSING
ip link
ip route- 显示
TUN_DEVICE_MISSING：说明设备节点不存在，先检查内核模块、发行版配置或容器挂载，不要先改 YAML。 - 设备存在但仍提示权限错误：确认 Mihomo 的运行用户，以及是否在容器、systemd 服务或受限沙箱中运行。
- 若已知二进制路径，可执行
getcap /path/to/mihomo；没有输出不等于一定错误，但说明该文件没有显示额外 file capability，需要结合启动用户和服务配置判断。 - 如果通过 systemd 启动，使用
systemctl status 服务名查看实际运行用户和失败日志；服务名因安装方式不同而不同，不能直接套用固定名称。
若在容器中运行，检查容器是否拥有创建网络设备所需的权限和设备映射；这类权限应由宿主机管理员确认，不建议为了测试直接给不可信容器长期开放高权限。
路由分支：只有 TUN 已成功创建、但流量不通时，才检查 auto-route、Linux 防火墙、iptables/nftables 和默认路由。Mihomo 文档说明，auto-redirect仅适用于 Linux，并要求同时启用 auto-route。修改前保存 ip route输出，关闭 TUN后确认原路由恢复。Mihomo Linux TUN 字段说明
macOS：查网络扩展授权，不要手动套用 tun0
最短路径：关闭 TUN，退出其他 VPN、网络过滤器和旧客户端；然后重新打开当前客户端，观察系统是否出现网络扩展或 VPN 授权请求。
- 打开“系统设置”，使用搜索框搜索“网络扩展”或“VPN”，进入与“登录项与扩展”相关的页面，查看对应扩展是否被阻止或未启用。Apple 说明，网络扩展可用于配置 VPN 或内容过滤器。Apple 网络扩展说明
- 如果没有出现授权对话框，先完全退出并重新打开客户端，再查看系统设置中的网络扩展状态；不同 macOS 版本和客户端封装的页面名称可能不同。
- 如果日志显示设备名称错误，不要把 Linux 的
tun0直接填到 macOS。Mihomo 文档说明，macOS 的 TUN 设备名只能使用以utun开头的名称；这属于字段约束，不代表所有情况下都应手动指定设备名。Mihomo TUN device 字段说明
停止条件：授权后仍失败时，记录网络扩展状态和 Mihomo 第一条完整错误；若 TUN启动后断网，先关闭 TUN并确认 Wi‑Fi 或有线网络恢复，再检查路由、DNS 或防火墙，不要先改 MTU 和 IPv6。
Android：先查 VPN 授权、其他 VPN 与私人 DNS
Android 的 TUN通常通过系统 VPN 服务建立。Android 官方文档说明，VPN 应用首次变为活动状态前，系统会显示连接请求对话框；系统设置中的 VPN 页面可以查看已批准的 VPN 应用。Android VPN 官方开发文档
- 打开“设置”，搜索“VPN”，进入“网络和互联网→VPN”或厂商对应页面，关闭其他 VPN、始终在线 VPN和“无 VPN 不允许连接”等选项后，再回到客户端重新发起授权。
- 如果没有授权弹窗，先检查是否已有其他 VPN占用、客户端是否被系统省电策略清理，或系统设置中是否已经保留旧的 VPN 授权。Android 官方帮助也说明，部分设备可以在 VPN 设置中关闭始终在线选项。Android VPN 设置说明
- 如果 TUN已启动但只有域名打不开，进入“设置→网络和互联网→私人 DNS”检查当前模式。Android 官方说明，私人 DNS可选择关闭、自动或指定提供商；厂商界面可能不同。Android 私人 DNS 设置说明
- Mihomo 文档指出，Android 开启私人 DNS 时，DNS 请求不能被自动劫持。因此，私人 DNS更适合放在“启动后 DNS异常”分支，不应作为创建 TUN 时权限不足的首个原因。Mihomo Android DNS 劫持说明
IPv6 例外：如果完整错误行明确包含 IPv6、inet6-address 或接口配置提示，再核对顶层 IPv6 设置与 TUN IPv6字段是否匹配；没有日志证据时，不要把 IPv6冲突当成所有 Android 权限错误的通用原因。
不要先改的项目：MTU、DNS、IPv6、strict-route
| 配置项 | 什么时候检查 | 为什么不适合先改 |
|---|---|---|
stack | 内核创建 TUN后仍有协议栈或防火墙相关错误 | 不能替代系统授权，且不同协议栈的防火墙行为不同 |
mtu | 已确认是特定链路的分片或极端传输问题 | 没有统一适用值，不能用来修复权限错误；官方建议一般用户保留默认值 |
dns-hijack | TUN已启动但域名解析异常 | 属于 DNS流量处理，不负责创建虚拟网卡 |
strict-route | 已确认需要严格路由或 DNS防泄漏行为 | 可能影响虚拟机等软件，也可能让错误扩大到全网断开 |
inet6-address | 日志和系统环境明确指向 IPv6 | 需要与顶层 IPv6开关和系统接口状态匹配 |
安全顺序应是：关闭 TUN并恢复网络 → 备份配置 → 验证普通代理 → 记录错误 → 只改一个字段 → 启动测试 → 失败就回滚。任何需要管理员、root 或系统 VPN授权的操作，都应先确认软件来源和当前配置可恢复。
仍然失败时，收集什么信息才有用
提交问题或继续定位前，先关闭 TUN并确认普通网络恢复，然后整理：
- 系统名称和版本；
- 客户端名称与版本、Mihomo 内核版本和 CPU 架构；
- 完整错误行，特别是冒号后的具体原因；
- 启用前后 Linux 的
ip link、ip route结果，或 Windows/macOS/Android 的网络状态； - 是否运行其他 VPN、虚拟网卡、网络过滤器、容器或组织管理策略；
- 修改防火墙、DNS、路由或配置后的具体结果。
分享 YAML 前，删除订阅链接、节点地址、密码、UUID、密钥、真实 IP 和内网域名。不要直接公开完整配置；优先提供脱敏后的 TUN片段和单条错误日志。若曾修改路由、防火墙或 DNS，先恢复原设置并记录恢复是否成功。
常见问题
Mihomo TUN 显示 permission denied，一定是管理员权限不够吗？
不一定。也可能是辅助服务未运行、Linux 缺少 CAP_NET_ADMIN、TUN 设备不存在、Android VPN授权被其他应用占用、网络扩展未批准或旧虚拟网卡冲突。先关闭 TUN并验证普通代理，再根据完整错误行分流。
Mihomo TUN 开启后自动关闭，第一步应该做什么？
停止反复点击开关，先关闭 TUN并确认网络恢复，然后记录启动日志中冒号后的完整错误。没有授权弹窗时，Windows查授权和安全策略，macOS查网络扩展，Android查其他 VPN，Linux查 /dev/net/tun 和运行能力。
可以直接把 stack 改成 mips 解决权限不足吗？
不能把更换协议栈当作通用修复。当前文档列出 system、gvisor、mixed、mips，但协议栈不会替代系统授权或 Linux 网络管理能力。只有在确认当前内核、客户端封装和防火墙条件适配后，才适合单独测试协议栈。
TUN 已经启动但无法上网，还是权限问题吗？
不一定。能创建 TUN但流量不通时，应转查 auto-route、DNS、strict-route、auto-redirect、防火墙、默认路由和其他 VPN冲突。先关闭 TUN恢复网络，再逐项恢复配置。
排查时可以直接关闭防火墙或修改 MTU吗？
不建议。先确认内核程序来源，再按系统文档添加必要的应用例外；不要直接关闭防火墙或长期开放端口。MTU没有统一适用值，权限错误也不能靠固定 MTU保证解决。
相关阅读
- 继续看桌面客户端 TUN 开关灰色与断网排查
- 如果普通代理也无法上网，查看端口、模式与 DNS 排查
- 如果日志明确指向 IPv6，再看 IPv6、DNS 与路由处理
- TUN 能启动但 DNS 异常时，继续检查 DNS 与回滚