OpenWrt 路由器与旁路由运行 mihomo 内核:部署方式概览

部署选择：先画网关路径，再选接管方式

在 OpenWrt 上运行 mihomo，需要分别解决两件事：内核运行在哪台设备，以及局域网连接怎样进入内核。把二者分开，才能判断故障属于配置文件、DNS，还是路由与防火墙。

mihomo 是 Clash Meta 项目延续使用的内核名称，负责解析配置、匹配规则并选择出站。LuCI 管理插件属于管理层，通常还会生成配置、安装防火墙规则和管理进程。仅把内核复制到路由器上，并不会自动接管全家设备的流量。

硬件架构：确认指令集、内存与存储

先在 OpenWrt 的 SSH 终端查看系统信息，再选择对应的 Linux 内核文件。不要根据路由器外壳型号或处理器宣传名称猜架构；同系列设备也可能使用不同芯片。

uname -m
ubus call system board
cat /etc/openwrt_release
df -h /overlay /tmp
free -m

• x86_64 通常对应 amd64，但还需区分发布文件要求的 CPU 指令集等级，旧处理器不一定支持较新的优化构建。
• aarch64 通常对应 arm64；32 位 ARM 要继续确认 ARM 版本与浮点支持，不能直接套用 arm64 文件。
• MIPS 设备要区分大小端与具体构建条件。OpenWrt 软件包架构名称与上游二进制文件名不一定完全相同。
• /tmp 通常位于内存文件系统，重启后清空。下载、解压和日志都会占用可用内存，不能把剩余闪存当成可用内存。

容量判断看运行负载

订阅节点数量、规则集大小、连接数量、DNS 缓存和日志级别都会影响内存。不能用一个固定内存门槛保证可运行。先加载实际配置观察，再考虑开机启动；大型规则集还可能需要额外的下载空间与持久化存储。

如果进程启动后很快消失，查看 logread 中是否出现内存不足或进程被终止的记录。出现 Exec format error 优先检查架构、压缩包是否已解开；出现 Illegal instruction 则重点检查 CPU 指令集兼容性。

内核与配置：先验证文件，再交给服务管理

以下路径用于说明手动部署：内核放在 /usr/bin/mihomo，工作目录设为 /etc/mihomo，主配置为 /etc/mihomo/config.yaml。如果已经安装 LuCI 管理插件，应使用该插件规定的内核目录与配置入口，不要额外启动第二份实例。

手动部署的检查顺序

1. 备份现有网络、防火墙和 DNS 设置，确认可以通过本地网线重新进入路由器。
2. 将匹配架构、已经解压的内核上传到 /tmp/mihomo；配置文件单独准备，避免覆盖原有可用配置。
3. 确认目标目录空间足够，再复制内核并赋予执行权限。
4. 先运行版本查询和配置测试，测试通过后再前台启动观察日志。

mkdir -p /etc/mihomo
cp /tmp/mihomo /usr/bin/mihomo
chmod 755 /usr/bin/mihomo

/usr/bin/mihomo -v
/usr/bin/mihomo -t -d /etc/mihomo -f /etc/mihomo/config.yaml
/usr/bin/mihomo -d /etc/mihomo -f /etc/mihomo/config.yaml

执行前应确保 config.yaml 已经存在。-v 用于记录实际版本，-t 用于测试配置；测试成功不代表上游节点可达，也不代表局域网流量已经进入内核。某些配置还依赖规则集、地理数据或外部文件，首次测试失败时要同时检查工作目录与下载日志。

最小直连配置：只验证进程与监听

下面是独立测试文件，不含代理节点，所有连接最终直连。它用于排除 YAML、端口和进程启动问题，不能用于验证代理出口。

mixed-port: 7890
allow-lan: false
bind-address: "127.0.0.1"
mode: rule
log-level: info

external-controller: "127.0.0.1:9090"

dns:
  enable: true
  listen: "127.0.0.1:1053"
  enhanced-mode: redir-host
  nameserver:
    - 223.5.5.5

rules:
  - MATCH,DIRECT

7890 是本例的 HTTP/SOCKS 混合入口，9090 是控制接口，1053 是 DNS 监听端口，三者不能互相替代。完成前台验证后，再通过管理插件或 OpenWrt 的 procd 服务管理启动、停止和重启；不要同时使用插件、自建服务与后台命令启动同一份内核。

主路由直跑：集中接管与 DNS 衔接

主路由部署的优势是终端本来就经过这台设备，不必逐台修改网关。风险也集中：防火墙或 DNS 配错可能影响整个局域网。因此应先只选择一台测试终端或一个测试网段，再逐步扩大接管范围。

LuCI 中先核对现有配置

• 进入「网络」→「接口」→「LAN」→「编辑」，记录 LAN 地址与子网掩码。
• 在 LAN 的「DHCP 服务器」中检查地址池与 DHCP 选项，确认没有其他设备同时分配冲突的网关。
• 进入「网络」→「防火墙」，确认 LAN 到 WAN 的原有转发关系没有被误删。
• 进入「状态」→「系统日志」检查内核与 DNS 服务日志。不同固件翻译或主题可能略有差异。

常见 DNS 路径是终端查询路由器的 53 端口，由 dnsmasq 再转发到 mihomo 的本地 1053 端口。此时必须确认上游方向没有反过来指回 dnsmasq，否则可能形成解析循环。仅配置 dns.listen 不会让终端自动使用它，还需要明确转发或接管规则。

旁路由网关：用一台终端验证去程与回程

单网口旁路由常与主路由处于同一网段。示例中，主路由是 192.168.50.1/24，旁路由是 192.168.50.2/24，测试终端是 192.168.50.100/24。这些地址只是拓扑示例，部署前要避开现有 DHCP 地址池和地址冲突。

1. 给旁路由设置固定 LAN 地址 192.168.50.2，默认上游网关指向 192.168.50.1。
2. 暂时只保留主路由提供 DHCP，避免两台设备在同一广播域争抢地址分配。
3. 在一台测试终端上，把默认网关手动改为 192.168.50.2。
4. 如果旁路由已提供面向局域网的 DNS 服务，再把测试终端 DNS 指向 192.168.50.2；否则先单独验证路由。
5. 检查旁路由是否允许相应的转发路径，以及直连流量的回程是否与设计一致。

在这个同网段结构中，直连流量可能经旁路由到主路由，而回包由主路由直接送回终端，形成非对称路径。是否需要源地址转换、主路由静态路由或不同子网，要按防火墙状态跟踪与网络拓扑决定。不能用“旁路由一律关闭 NAT”或“一律开启 NAT”代替判断。

网关与 DNS 分别验证

修改网关只决定 IP 包下一跳，不保证域名查询也经过旁路由。浏览器的加密 DNS、终端静态 DNS，以及 IPv6 的路由通告都可能形成另一条路径。先检查测试终端实际获得的 IPv4 网关、IPv6 默认路由和 DNS 地址，再判断是否需要接管。

单机验证成功后，才考虑由主路由 DHCP 下发选项 3 指定 IPv4 默认网关、选项 6 指定 DNS。部分家用主路由不支持细分下发，此时保留手动设置或使用独立测试网段，比直接切换全网更容易回退。

透明代理：REDIRECT、TPROXY 与 TUN 的边界

显式代理要求应用主动连接 7890 等代理端口；透明代理则由路由和防火墙把原始连接送入内核。两种入口可以并存，但要防止同一连接被多套规则重复接管。

OpenWrt 22.03 起的常见默认环境使用 firewall4 与 nftables。旧教程中的 iptables 规则不能不加核对地粘贴到新环境；实际还要查看固件是否采用自定义防火墙后端，以及对应模块是否已安装。

TUN 开启不等于局域网接管完成

tun.auto-route 用于自动配置相关路由，但效果受系统、版本与网络结构影响；不能仅凭该字段推断转发流量全部进入 TUN。tun.auto-redirect 也有平台与版本前提，并非所有 Linux 环境都能直接套用。路由器上若由插件管理接管规则，应让插件统一生成，不要同时再叠加一套手写规则。

• 排除路由器管理地址、必要的本地网段，以及内核自身访问上游代理服务器的连接，避免形成循环。
• 使用 fake-ip 时，确保 DNS 返回的虚拟地址段具有对应路由与接管路径，否则会出现解析成功但连接失败。
• 需要 UDP 的应用要同时检查入口机制、节点协议支持与服务端能力，TCP 网页可用不能证明 UDP 正常。
• IPv4 与 IPv6 分别检查。只配置 IPv4 透明代理，不会自动覆盖 IPv6 连接。

局域网接入：先显式代理，再检查规则命中

正式接管前，可以先让一台终端使用显式代理，以隔离网络转发问题。若要把测试配置的 7890 开放给局域网，需要将 allow-lan 改为 true，并把 bind-address 设为实际 LAN 地址，例如 "192.168.50.2"。同时通过防火墙仅允许可信网段访问。

不要把代理端口或控制接口通过 WAN 端口转发公开。external-controller 保持本机监听通常更容易控制访问；如果确需远程管理，要配置强 secret，并限制访问来源。控制接口认证与混合代理端口认证是不同配置，不能互相替代。

按层缩小故障范围

1. 进程层：确认配置测试通过、内核持续运行，且没有第二个实例争用端口。
2. 入口层：确认终端能连接 LAN 地址的代理端口。连接拒绝优先查监听地址，超时优先查防火墙与路径。
3. 出站层：换入实际可用的节点和策略组，检查认证、协议与上游连通性。前面的直连测试文件不提供代理出口。
4. 规则层：确认 mode: rule，再看日志命中的规则和出站策略。规则从上到下匹配，过早出现的兜底规则会遮住后续规则。
5. 接管层：显式代理可用而透明代理不可用时，优先排查 DNS、策略路由、防火墙与 IPv6，不要先反复更换订阅。

内核资源与节点速度也要分开判断：网页首包慢可能涉及 DNS 或链路建立，大文件传输慢则还可能受到 CPU、加密处理、线路带宽与拥塞影响。记录具体时间、测试终端、目标服务和命中策略，比只记录“旁路由变慢”更便于复现。

更新与回滚：保留可用配置和独立管理入口

订阅更新、内核升级与防火墙变更应分开进行。订阅可能覆盖节点、策略组和规则；管理插件也可能在启动时重新生成运行配置。长期需要保留的修改，应写入插件支持的覆写或自定义规则入口，而不是只编辑临时生成文件。

• 升级前记录 mihomo -v 的输出，并保留可用内核、主配置和自定义规则。
• 停止旧进程后再替换二进制文件，先配置测试，再启动服务；不要直接覆盖正在执行的文件。
• 通过 logread 检查启动结果，确认规则资源能够加载，再验证 DNS、TCP 与需要使用的 UDP 应用。
• 保留一台能直连管理地址的设备。旁路由故障时，把测试终端网关与 DNS 恢复到原主路由；若改过 DHCP 下发，还要还原选项并让终端重新获取租约。

如果目标只是给一台电脑或手机使用代理，先运行对应平台客户端通常更省配置步骤。只有需要统一管理电视、游戏设备或多台终端时，再把网关、DNS 和透明接管迁移到路由器。YAML 的基础结构与规则顺序可继续查看配置文件结构和规则字段说明。