本文目录
先把 OpenClash 插件和 Mihomo 内核装到能稳定运行
这篇教程先把路由器本身跑通，再谈订阅和全屋接入。开始前到“状态 → 概览”记下 OpenWrt 版本、CPU 架构和可用内存，再到“系统 → 备份与升级”导出一份配置。路由器空间本来就紧张，先确认 /overlay 还有余量，能避免软件包装到一半才失败。
先通过 SSH 运行下面的只读命令。command -v opkg 有输出，才继续使用本文的 opkg 安装路径；如果设备只有 apk，就不要把 opkg 命令硬套上去，应按 OpenClash 当前发布页里的 apk 说明安装。
ubus call system board
df -h /overlay
free -h
command -v opkg下载只使用 vernesong/OpenClash 的发布页。LuCI 可以走“系统 → 软件包 → 上传软件包”，把官方 ipk 上传后安装；SSH 方式则把同一个文件传到 /tmp/openclash.ipk。
OpenWrt 23.05 之后常见的是 firewall4 与 nftables，较老固件可能仍是 iptables。下面两组依赖只能按自己的防火墙选一组，不能两组一起装。
# 仅适用于 command -v opkg 有输出的固件
opkg update
# firewall4 / nftables 固件选这一行
opkg install bash dnsmasq-full curl ca-bundle ip-full ruby ruby-yaml kmod-tun kmod-inet-diag unzip kmod-nft-tproxy luci-compat luci luci-base
# 老的 iptables 固件改用这一行，不要和上一行同时执行
# opkg install bash iptables dnsmasq-full curl ca-bundle ipset ip-full iptables-mod-tproxy iptables-mod-extra ruby ruby-yaml kmod-tun kmod-inet-diag unzip luci-compat luci luci-base
opkg install /tmp/openclash.ipk
opkg status luci-app-openclash安装结束后刷新 LuCI，入口应出现在“服务 → OpenClash”。进入“插件设置 → 版本更新”，确认内核编译版本与路由器架构一致，然后下载或更新 Meta 内核。
手动放置内核时，官方要求目录为 /etc/openclash/core/，文件名为 clash_meta。这一步没有完成，luci-app-openclash 页面能打开也不能处理流量。
回到 OpenClash 首页启动服务，然后看运行日志。若进程几秒后退出，先按日志处理缺少依赖、空间不足或 exec format error，不要继续导入订阅。插件、内核和日志这三处都正常，安装阶段才算结束。
opkg status luci-app-openclash
ls -l /etc/openclash/core/
/etc/init.d/openclash enable
/etc/init.d/openclash restart
sleep 3
pgrep -af clash_meta
logread | grep -i openclash | tail -n 80安装完成的判断
- LuCI 的“服务 → OpenClash”可以打开
- 版本更新页显示的内核架构与路由器一致
- /etc/openclash/core/clash_meta 存在且能启动
- 重启服务三秒后仍能看到 clash_meta 进程
- 日志没有缺少依赖、空间不足或执行格式错误
- 停用 OpenClash 后 OpenWrt 仍可直连上网
在“配置文件订阅”里导入，并确认它真的被加载
进入“配置文件订阅”，添加服务方提供的 Clash 或 Mihomo 订阅地址，再手动更新一次。真正导入成功应同时看到：文件更新时间变化、代理组和节点出现、配置检查通过，而且状态页显示的当前配置就是刚更新的这份。
如果页面提示任务结束但节点仍为空，查看下载日志。HTTP 401、403、跳转到登录页、套餐提示或空文件，说明订阅内容没有正常取回；YAML 行号、unknown field 或 group not found 则属于解析问题。排查时隐藏 URL 中的个人 token。
第一次启用订阅
手动更新
确认文件时间和大小变化，并记录下载阶段的 HTTP 错误。
执行配置检查
先处理 YAML 行号、未知字段和策略组引用。
设为当前配置
回到状态页确认实际加载的文件名。
固定一个节点
先不要使用会自动切换出口的测速组。
订阅能用后，只选一种运行模式做第一次测试
OpenClash 的 Fake-IP、Redir-Host、TUN 或混合模式解决的是不同接管需求，不是同时打开才完整。第一次运行先采用当前插件推荐的常用模式，让一台电脑产生连接记录，再处理少数应用的兼容问题。
Fake-IP 便于内核较早拿到域名并执行规则，但局域网域名和少数应用可能需要排除；Redir-Host 返回真实解析结果，行为更直观；TUN 能接住更多不读取系统代理的流量，也更容易与 VPN、策略路由或硬件加速冲突。
切换模式后，让测试电脑重新获取网络地址并清理 DNS 缓存，再访问同一个站点。旧缓存不清掉，新模式很容易被误判为没有生效。
准备全屋接入前，先确定 OpenWrt 是主路由还是旁路由
OpenClash 能否处理手机、电视和 NAS 的流量，取决于这些设备的默认网关，而不是插件页面是否显示运行。OpenWrt 做主路由时，LAN 设备本来就经过它；做旁路由时，只有把网关交给 OpenWrt 的设备才会进入 OpenClash。
旁路由第一次测试只改一台电脑的网关和 DNS。它能同时打开普通网站、需要代理的站点和路由器管理页以后，再修改 DHCP。直接切换全家设备，一旦 DNS 或防火墙出错，连管理页面都可能打不开。
两种家庭网络接法
| 接法 | OpenWrt 负责什么 | 回退方式 |
|---|---|---|
| OpenWrt 主路由 | 接入、DHCP、DNS 和防火墙都在同一台设备 | 停用 OpenClash 后仍由 OpenWrt 直连 |
| OpenWrt 旁路由 | 原主路由继续联网，指定设备把网关交给 OpenWrt | 把测试设备的网关和 DNS 改回主路由 |
网关决定连接去向，DNS 决定规则能否认出域名
OpenWrt 做主路由时，DHCP 通常把它的 LAN 地址同时作为默认网关和 DNS 发给终端。旁路由测试阶段则可在一台电脑上手动填写旁路由地址，确认无误后再让主路由 DHCP 对指定设备下发。两个 DHCP 服务同时在同一网段发地址，会造成时好时坏，而不是可靠的冗余。
浏览器安全 DNS、Android 私人 DNS 和某些电视应用的内置 DoH 可能绕过路由器。排查时先暂时关闭这些独立入口，让查询经过 dnsmasq 与 OpenClash；规则命中稳定后，再决定哪些加密 DNS 需要恢复。
IPv6 也要一起看。设备拿到公网 IPv6、但 OpenClash 只接管 IPv4 时，部分连接会从 IPv6 直接出去。此时应明确处理 IPv6 路由和解析，而不是简单把所有“偶尔直连”归咎于节点。
- NAS、打印机和路由器后台
- 私有网段和本地域名应保持直连，先确认管理入口不会被接管。
- 游戏机和电视
- 它们很少给出详细错误，放在电脑和手机验证完成以后再加入。
- 旁路由
- 测试设备的网关和 DNS 都要指向旁路由，只改其中一个只能证明半条路径。
- 手机或电脑从 DHCP 获得网关和 DNS
- OpenWrt接收终端的连接和解析请求
- OpenClash按配置和规则选择出口
- 目标服务从直连或代理路径收到请求
旁路由场景不能只改网关或只改 DNS。两者不一致时，常见表现就是网页偶尔能开，但规则命中和解析结果不稳定。
验证顺序从路由器本机走到一台终端
一次能说明问题的验证
先测路由器本机
确认系统时间正确、WAN 能联网、订阅域名可以解析。
再看内核状态
配置加载成功，固定节点有连接结果，日志没有持续重启。
接入一台电脑
不设置浏览器扩展代理，只依赖新的网关和 DNS。
对照三类地址
分别访问国内站点、需要代理的站点和路由器管理页，并核对连接记录。
路由器本机能访问、下游电脑不能访问时，优先检查 DHCP、网关和防火墙转发；域名失败而 IP 请求有响应时，再查 DNS；连接记录已经出现但出站错误，才回到规则和策略组。按这条顺序处理，比反复重启 OpenClash 更快。
全屋上线要按设备类型逐批进行
一台电脑和一部手机稳定后，再加入电视、游戏机和智能家居。每新增一类设备都保留原网关与 DNS，出现异常就先让这类设备退回直连；家庭网络恢复以后，日志和规则才有条件慢慢看。
最终修改 DHCP 前，记录停用 OpenClash、恢复原 DNS 和进入 failsafe 的方法。订阅更新、固件升级或内核替换都可能改变行为，有一条不依赖 OpenClash 的管理路径，后续维护才不会把一次插件故障变成全家断网。