Release 下载Mihomo OpenWrt (vernesong fork) · GitHub Release 历史版本 · 三路反代镜像
本区块同步 Mihomo OpenWrt (vernesong fork) 的官方 GitHub Release，并为最近版本生成 三路反代镜像加速下载通道。 默认展开最新正式版；如果项目只有预发布版，会在版本旁单独标注。下载按钮会先进入本站确认页，可继续下载或复制真实链接。
暂无公开 Release 资产，请到 rufengsuixing/luci-app-mihomo Releases 页 查看后续发布。
luci-app-mihomo 这类 OpenWrt 插件先看来源，再谈安装。2026-05-22 比对时，https://github.com/rufengsuixing/luci-app-mihomo 和对应 GitHub API 都返回 404；这意味着旧镜像、第三方打包页或搜索结果里的版本号不能直接当作官方状态。
如果你已经有一份来自可信构建链的 .ipk，这篇可以帮你把安装、导入、日志、DNS/TUN、卸载顺序理清楚。如果你还没拿到可验证来源，先停在“来源比对”这一段，不要把路由器当测试机。
##比对项目来源，哪些信号算红灯？
把 luci-app-mihomo 当作“OpenWrt 上的 Mihomo LuCI 包装层”：LuCI 负责页面和配置入口，Mihomo 负责解析 YAML、DNS、TUN、规则和出站连接。真正影响安全和稳定性的不是页面标题，而是你装进去的 .ipk、内核文件和配置来源。
| 比对项 | 可以继续的信号 | 红灯信号 |
|---|---|---|
| 仓库来源 | GitHub 仓库可打开，owner、repo、Release、commit 能对上 | 直连 GitHub 404，只剩转载页或网盘包 |
| Release / feed | .ipk 来自明确的 Release、opkg feed 或你自己的构建产物 | 文件名里只有“最新版”，没有 tag、构建日期、架构 |
| OpenWrt 架构 | 包名或 feed 明确匹配 x86_64、aarch64、arm_cortex-a7 等架构 | 随机下载 all.ipk 后还附带不明二进制内核 |
| 依赖关系 | opkg install 能解析依赖，缺什么就补什么 | 要求长期使用 --force-depends 才能装上 |
| 内核来源 | Mihomo 二进制来自 MetaCubeX/Mihomo 或可追溯构建 | 内核被重命名，无法查看版本和来源 |
| 配置来源 | YAML、订阅 URL、provider 都能单独打开比对 | 只给整包配置，无法知道写了哪些 DNS/TUN/规则 |
OpenWrt 官方 opkg 文档写明，opkg update 会刷新软件包列表，opkg install <pkgs|url> 可以从仓库、URL 或本地 .ipk 安装，依赖解析失败时会停止。这个停止是保护机制，不要为了装一个插件就强行压过依赖错误。
哪些 OpenWrt 环境适合安装 luci-app-mihomo？
确认设备型号、硬件版本和固件分支。OpenWrt 快速开始文档强调，刷写和配置前要确认精确型号，并预期安装期间会有短时间离线；这类提醒对代理插件同样成立，因为 DNS、路由、防火墙一改错，整个局域网都会受影响。
| 环境 | 判断 | 处理建议 |
|---|---|---|
| x86_64 软路由，RAM 2GB 以上 | 最适合测试 | 先装在旁路由或非主网关，确认无误再接管主网络 |
| aarch64/armv7 路由，RAM 512MB 以上 | 可用但要控规则数量 | 订阅 provider 不要太多，日志不要长期 debug |
| 128MB RAM 或 16MB Flash 老设备 | 不建议 | Mihomo、规则集、Web UI、日志都容易挤爆资源 |
| Snapshot 固件 | 谨慎 | opkg 包和内核 ABI 变化快，不适合在主路由上试错 |
| 已运行 OpenClash / PassWall / Nikki | 先停旧方案 | 多个透明代理同时接管 DNS、防火墙、TUN，排错会变复杂 |
| 主路由承载家庭办公 | 做维护窗口 | 保存回滚路径，避免一次改动影响局域网设备 |
最低准备清单只留五项：SSH 可登录、LuCI 可登录、已备份 /etc/config/network、已备份 /etc/config/dhcp、已备份 /etc/config/firewall。没有这五项，先别动插件。
安装前要准备哪些文件和命令？
准备阶段不要先点 LuCI 上传，在 SSH 里记录系统状态，这样安装失败时能回到原点。
# 记录 OpenWrt 版本和架构
cat /etc/openwrt_release
opkg print-architecture
# 更新包索引；OpenWrt 文档说明索引会放在 /tmp/opkg-lists
opkg update
# 备份核心网络配置
cp /etc/config/network /etc/config/network.bak-before-mihomo
cp /etc/config/dhcp /etc/config/dhcp.bak-before-mihomo
cp /etc/config/firewall /etc/config/firewall.bak-before-mihomo如果你拿到的是本地 .ipk，安装命令按 OpenWrt opkg 规则走：
opkg install /tmp/luci-app-mihomo_*.ipk如果你使用的是可信 opkg feed，确认 feed 文件来源，再执行：
opkg update
opkg install luci-app-mihomo安装后先找实际落地文件，而不是猜路径：
opkg files luci-app-mihomo
ls /etc/init.d/
ls /etc/config/不同打包者可能把服务名写成 mihomo、clash 或其他名字。只要你还没看到 /etc/init.d/ 里真实存在的脚本，就不要写 service mihomo restart 这类命令到自动化脚本里。
配置导入应该先检查 YAML 还是 LuCI 页面？
检查 YAML。LuCI 页面只是把字段写入配置，Mihomo 能不能启动取决于最终 YAML 和内核版本。
Mihomo 配置文档可见的核心模块包括 dns、inbound、proxies、proxy-groups、rules。一个可用订阅至少要让你看到节点、策略组和规则；如果页面显示导入成功但节点为空，优先怀疑订阅返回内容，而不是 LuCI 按钮。
| 输入类型 | 应该看到什么 | 常见失败 |
|---|---|---|
| 订阅 URL | YAML 内容，包含 proxies、proxy-groups、rules | 返回 HTML、登录页、403、404、空文件 |
| 本地 YAML | 缩进、冒号、引号都能被解析 | 复制时丢空格，Windows 换行导致异常 |
proxy-providers | type 为 http、file 或 inline | url 不通、interval 太短、path 不可写 |
| health-check | 有 url、interval、timeout、expected-status 等字段 | 探测地址不可达，导致节点全部看似失败 |
| 自定义规则 | 规则引用的策略组名称真实存在 | rules 里写的组名和 proxy-groups 不一致 |
proxy-providers 的 interval 单位是秒。很多人把 3600 秒误写成 3600 分钟，或者把 300 秒设成频繁拉取，结果订阅源被限流，用保守更新周期跑通，再调自动更新。
如果同一条订阅要给 OpenWrt、桌面和手机一起用，确认提供方能输出 Mihomo/Clash YAML，而不是只给单一客户端格式。多端维护时，可以用兼容 Clash / Singbox / V2Ray 的订阅承载配置同步，但导入前仍要逐项比对 YAML 字段。
日志、服务和路径应该怎么查？
OpenWrt 官方日志入口是 logread。官方日志文档说明，logread 读取 RAM ring buffer，可以按关键字过滤，也可以跟随输出；日志守护进程是 logd，来自 ubox。
排错顺序这样走：
# 看最近系统日志
logread
# 按关键词过滤；关键词以实际服务名为准
logread -e mihomo
logread -e luci
# 跟随日志，复现一次启动失败
logread -f路径不要靠旧教程猜。安装后用这三类命令定位：
| 目标 | 命令 | 你要记录什么 |
|---|---|---|
| LuCI 插件文件 | opkg files luci-app-mihomo | 页面、脚本、默认配置写到了哪里 |
| 服务脚本 | ls /etc/init.d/ | 真实服务名是什么 |
| UCI 配置 | ls /etc/config/ | 是否出现 mihomo、clash 或插件自定义配置 |
| Mihomo 二进制 | which mihomo 或 opkg files mihomo | 内核路径和版本来源 |
| 运行状态 | `ps w | grep mihomo` |
排错时只抓失败前后的 50 行日志。Mihomo 的 debug 日志会刷出大量 DNS、规则匹配和连接记录，长期开 debug 会增加存储压力，也会把真正的启动错误淹没。
DNS、TUN、路由异常按什么顺序排？
把问题分成三类：DNS 解析错、流量没进 Mihomo、流量进了但规则走错。三类问题的修法完全不同。
| 表现 | 更可能原因 | 检查 |
|---|---|---|
| 域名打不开，IP 可访问 | DNS 没进 Mihomo，或上游 nameserver 异常 | Mihomo dns.enable、OpenWrt dnsmasq、nameserver |
| 所有设备突然断网 | TUN/防火墙/默认路由接管失败 | 先关 TUN，恢复网络，再看 auto-route |
| 只有部分服务异常 | 规则命中错误或策略组为空 | 看日志里的 rule、proxy-group、outbound |
| 开 TUN 后 DNS 泄到系统 | dns-hijack 未生效，或局域网 DNS 未被劫持 | 检查 TUN 配置和 OpenWrt DHCP 下发的 DNS |
| 内网设备互相访问异常 | strict-route、防火墙或 route-address 覆盖过宽 | 排除局域网网段，先恢复内网连通 |
| provider 更新失败 | URL 不通、证书时间错、health-check 地址不可达 | 校准系统时间，单独 curl 订阅 URL |
Mihomo DNS 文档显示，dns.enable: false 时会使用系统 DNS；enhanced-mode 可选 fake-ip / redir-host，页面写到默认是 redir-host。如果你改成 fake-ip，就要同步检查 fake-ip range、filter 和 OpenWrt 上的 DNS 转发链路。
Mihomo TUN 文档里，stack 可选 system、gvisor、mixed，页面提示无异常时可优先考虑 mixed；auto-route 负责把全局流量导入 TUN；auto-redirect 仅 Linux 可用，并且要先开 auto-route。OpenWrt 是 Linux，但不同固件的 nftables、iptables、firewall4 状态不一样，不能照搬桌面端配置。
strict-route 对路由一致性有帮助，也可能让局域网、虚拟网卡或旁路由场景出问题。家用路由器排错时，先保留最小配置：一个节点、一个策略组、基础 DNS、TUN 关闭；确认可用后再逐项打开 TUN、fake-ip、provider 和自定义规则。
什么时候该回滚或卸载？
出现下面任一情况，先回滚，不要继续叠加设置：
- GitHub 或 feed 来源仍无法核验，只能拿到不明
.ipk。 - 安装后
opkg files看不到清晰文件清单。 - 服务脚本名不明，LuCI 页面能打开但后台没有对应进程。
- 修改 DNS/TUN 后局域网设备都受影响。
- 日志反复出现 YAML parse error、unknown field、permission denied，且无法定位到具体字段。
- 设备内存持续吃紧，
logread里出现进程被杀或服务频繁重启。
回滚顺序按“先停服务、再还配置、最后卸载”走：
# 1. 停实际服务名；下面 mihomo 只是示例，用 /etc/init.d/ 确认
service mihomo stop
service mihomo disable
# 2. 恢复安装前备份
cp /etc/config/network.bak-before-mihomo /etc/config/network
cp /etc/config/dhcp.bak-before-mihomo /etc/config/dhcp
cp /etc/config/firewall.bak-before-mihomo /etc/config/firewall
# 3. 重启网络相关服务
service network restart
service dnsmasq restart
service firewall restart
# 4. 再卸载包；包名以 opkg list-installed 结果为准
opkg remove luci-app-mihomoOpenWrt opkg 文档也提醒，不要把“升级全部包”当作常规维护动作，尤其是 snapshot/trunk。修一个插件问题时，只更新相关包，别顺手 opkg upgrade 全系统。
安全更新清单怎么做？
更新 luci-app-mihomo 或 Mihomo 内核之前，先写一张 10 行以内的变更单。软路由不是桌面应用，失败影响的是局域网设备。
| 步骤 | 动作 | 通过标准 |
|---|---|---|
| 1 | 打开仓库、Release、feed 或构建日志 | 来源可访问，版本号可追溯 |
| 2 | 记录 OpenWrt 版本、架构、当前插件版本 | 能回填到故障记录里 |
| 3 | 备份 network、dhcp、firewall、插件配置 | 备份文件在路由器和本地各一份 |
| 4 | 保存当前可用 YAML 或订阅 URL | 回滚后能重新导入 |
| 5 | 停止旧服务再更新 | 没有两个透明代理同时接管 |
| 6 | 只更新目标包或目标内核 | 不做全系统升级 |
| 7 | 启动后看 logread | 没有 parse error、permission denied、端口占用 |
| 8 | 测 DNS、规则命中、内网访问 | 三项都通过再恢复自动更新 |
更新后的第一小时不要开太激进的自动 provider 更新，让路由器跑过日常高峰，再决定是否恢复订阅自动更新、health-check 和 debug 级别日志。