OpenWrt 路由器与旁路由运行 mihomo 内核：部署方式与硬件资源概览

先区分内核、管理界面与透明代理

mihomo 是延续 Clash 配置体系的代理内核，早期常称 Clash Meta。它读取 YAML 配置，处理节点连接、代理组、DNS 与分流规则。OpenWrt 则负责网卡、路由、防火墙和服务管理。把二进制文件放进路由器，并不等于局域网设备已经经过代理。

路由部署需要分别确认三个环节：服务能否启动，终端流量能否进入内核，以及内核是否选择了正确出口。LuCI 管理插件通常把这三部分整合起来；手动安装内核则需要自行连接这些环节。

• 显式代理：在电脑或浏览器中指定路由器地址和 HTTP、SOCKS 端口。只有遵循该设置的应用会使用代理。
• 透明代理：由网关通过重定向、策略路由或 TUN 接管流量，终端不必逐个填写代理地址。
• DNS 分流：决定域名由哪个解析器回答，并为规则匹配提供信息；它与流量转发相关，但不是同一个功能。

主路由与旁路由的拓扑差异

主路由部署：入口集中，影响范围也集中

主路由直接连接上级网络，通常同时承担拨号、DHCP、DNS 转发和 NAT。终端默认网关指向它，透明代理接管路径比较明确。配置更新、规则加载和代理进程的资源开销，也会与拨号、无线及其他服务竞争。

互联网
  │
OpenWrt 主路由：LAN 192.168.1.1
  │
交换机 / 无线接入点
  │
电脑：192.168.1.100，网关 192.168.1.1

适合已有受支持 OpenWrt 设备、需要集中管理全网流量的环境。上线前应保留本地管理入口；代理服务异常时，基本转发是否恢复直连，取决于插件的防火墙清理和故障处理方式，不能默认会自动恢复。

单臂旁路由：按终端试点，注意回程

常见旁路由只有一个 LAN 接口，与主路由接入同一交换网络。主路由仍负责联网；测试电脑把默认网关改为 192.168.1.2，旁路由自身的默认网关仍为 192.168.1.1。旁路由需要开启 IP 转发，并具有允许对应转发的防火墙规则。

主路由：192.168.1.1，负责上网与原有 DHCP
  │
同一 LAN 交换网络
  ├─ 旁路由：192.168.1.2，默认网关 192.168.1.1
  └─ 测试电脑：192.168.1.100，默认网关 192.168.1.2

这个拓扑中，直连流量可能出现去程经过旁路由、回程由主路由直接返回终端的情况。是否需要在旁路由做源地址转换，应按插件要求和状态跟踪结果判断。开启 SNAT 可以让部分回程经过旁路由，但也会隐藏原始终端地址；不要把“所有接口开启伪装”当作通用修复。

三种部署方式与维护成本

插件通常更便于管理订阅、代理组和运行日志，但必须核对其支持的内核与防火墙后端。OpenWrt 22.03 起默认使用基于 nftables 的 firewall4；旧插件若只生成传统 iptables 规则，不能仅凭“安装成功”判断透明代理可用。定制固件还可能更换组件，应检查实际环境。

原生运行适合需要控制配置来源和升级节奏的用户。可先使用内核的配置测试命令，再将服务交给 procd 管理。订阅文件中若没有路由侧 DNS、监听和接管配置，还需要合并本地配置；否则一次更新就可能覆盖本地设置。

容器适合资源较充足的设备，但不会消除透明代理的复杂度。TUN 通常需要可用的 /dev/net/tun 和相应网络管理权限；桥接网络中的监听地址，也不等于宿主机 LAN 地址。不要为了让容器启动就直接授予所有权限。

# 假设内核已放在 /usr/bin/mihomo
/usr/bin/mihomo -v
/usr/bin/mihomo -t -d /etc/mihomo -f /etc/mihomo/config.yaml

上面的路径是手动部署示例，不是所有插件的固定目录。测试时应使用插件实际调用的配置文件；部分插件会在临时目录生成最终配置，而不是直接使用下载的订阅文件。

架构选择与内存、存储预算

先查 CPU 与固件目标，再选内核文件

ubus call system board
uname -m
cat /proc/cpuinfo
free -m
df -h /overlay /tmp

ubus call system board 可查看设备和固件目标信息，uname -m 可辅助判断运行架构。常见对应关系包括 aarch64 与 ARM64、x86_64 与 AMD64。MIPS 还要区分大小端及软浮点等构建差异，不能只看到“MIPS”就选择文件。

ARMv7 和带特定 CPU 指令集要求的 x86 构建，也需要与硬件匹配。出现 Exec format error 时优先检查架构与文件格式；出现 Illegal instruction 时检查指令集要求。两者都不是修改订阅链接能够解决的问题。

容量数字用作规划，不等于性能承诺

这些是容量规划参考，不是实测吞吐或最低系统要求。实际开销取决于规则提供者、地理数据格式、连接数量、DNS 缓存和插件实现。不要把 free 输出中的低“空闲”直接等同于内存不足，应结合可用内存、进程驻留量与内核日志判断。

• 存储：将当前内核、配置和规则数据计入预算；更新时还可能同时保留旧文件、下载包和解压文件。
• 临时目录：OpenWrt 的 /tmp 通常使用内存文件系统，下载大文件会与运行内存竞争。
• 写入频率：避免把持续的调试日志写入小容量闪存；平时使用适当日志级别，定位时再短期开启详细日志。
• CPU：代理加密、用户态转发与规则匹配会消耗计算资源。千兆网口不代表所有代理协议都能达到千兆速率。

网关、DNS 与端口的配置边界

明确每个地址承担的角色

在上述旁路由示例中，测试电脑的网关是 192.168.1.2。如果旁路由提供 LAN DNS，电脑的 DNS 也可设为该地址，但前提是旁路由确实监听 LAN 的 53 端口。只改变 DNS 不会让普通外网流量自动经过旁路由；只改变网关，也不保证 DNS 查询经过内核的解析逻辑。

一种常见设计是由 dnsmasq 对 LAN 提供 53 端口服务，再把需要的查询转发给 127.0.0.1:1053 上的内核。此时必须防止查询绕回自身：例如内核把 dnsmasq 当作上游，而 dnsmasq 又把所有请求发回内核，就会形成解析循环。管理插件若已接管 DNS，应通过插件设置调整，不要另加一套相同规则。

fake-ip 与 IPv6 要一起核对

fake-ip 模式通常使用 198.18.0.0/16 一类保留地址池返回映射地址。拿到这种地址本身不代表解析失败，但后续连接必须由同一套代理接管逻辑处理。如果终端收到 fake-ip，却绕过旁路由访问，就可能出现域名能解析、连接却超时的现象。

IPv4 网关修改不会自动覆盖 IPv6。主路由仍可能通过路由通告向终端发布 IPv6 默认路由和 DNS，使部分连接走另一条路径。应选择完整配置 IPv6 接管，或在试点阶段明确限制测试终端的 IPv6，再分别验证；不应凭一次 IPv4 成功就认定双栈流量都已接管。

透明代理、TUN 与防火墙如何配合

常见接管方法包括 TCP 重定向、TPROXY 和 TUN。TCP 重定向主要处理 TCP；TPROXY 可用于 TCP、UDP，但依赖相应内核模块、策略路由及防火墙规则。TUN 通过虚拟网络设备接收 IP 数据包，也需要正确的路由、权限和转发设置。

mihomo 的 tun.auto-route 用于自动配置相关路由，auto-redirect 则涉及 Linux 下的自动重定向能力，是否可用要结合内核版本及系统依赖确认。它们不是“接管所有 LAN 设备”的独立保证，特别是在已有插件生成规则的情况下，不应同时再启用另一套自动路由方案。

• 保留局域网管理与必要私网流量的正确路径，防止访问路由器界面也被送往代理出口。
• 确保代理节点自身的连接不会再次进入同一个接管入口，否则可能形成流量回环。
• 检查软件流量卸载与硬件流量卸载是否绕过当前接管方案；先关闭卸载做基准验证，再按插件兼容说明恢复。
• 只运行一套透明代理管理服务。两套插件可能争抢 DNS 端口、覆写路由或重复拦截同一连接。

# 在 OpenWrt 上查看现状；具体命令取决于已安装组件
ip route show
ip rule show
nft list ruleset
logread | grep -i mihomo
dmesg | grep -i -E 'oom|out of memory'

ip route show 默认主要显示主路由表；若策略规则引用其他表，还要继续查看对应表。日志中出现服务启动成功，只能证明进程运行，不能证明 LAN 转发、DNS 或 UDP 链路已经通过验证。

按单台终端逐步验收与回退

1. 保存基线。备份 OpenWrt 配置，记录主路由、旁路由、DHCP 范围和管理地址。保留一台网关仍指向主路由的管理终端。
2. 先验证内核。运行配置测试，确认订阅加载、代理组有可选节点，且服务不会反复退出。节点连接还依赖时间同步与上游连通性。
3. 先做显式代理测试。若已启用并允许 LAN 访问示例端口 7890，在测试电脑执行下方请求，区分节点问题与透明接管问题。
4. 再改测试电脑网关。设为 192.168.1.2，按实际 DNS 方案设置解析地址；确认局域网管理、直连网站和代理规则各自正常。
5. 检查规则与连接。在管理面板查看目标域名、命中规则、代理组和最终节点。网页能打开不一定表示经过代理，也可能匹配了 DIRECT。
6. 最后扩大范围。测试 UDP、IPv6、规则更新和设备重启。全部通过后，再调整 DHCP 下发策略或迁移更多终端。

# 在测试电脑执行；需先启用对应 HTTP 代理入口
curl -I --proxy http://192.168.1.2:7890 https://example.com/

# 确认旁路由已提供 LAN DNS 后，再执行
nslookup example.com 192.168.1.2

第一条命令验证 HTTP 代理链路，不代表所有应用、UDP 和透明代理都已可用。第二条只验证指定 DNS 服务器能否回答，也不代表答案经过了预期上游；应与内核查询日志及实际连接记录交叉检查。

回退时，先把测试电脑的网关和 DNS 恢复为原值，再停用代理服务，并确认插件已清理接管规则。若此前调整过 DHCP，需要让终端重新获取租约。不要只结束内核进程，却留下指向已关闭端口的防火墙重定向。

部署前的选择结论

已有稳定 OpenWrt 主路由且资源充足时，集中部署能减少额外的网关维护。希望分批验证、保留原有联网结构时，可先使用旁路由，但要承担终端网关下发、DNS 归属和回程路径的管理工作。旁路由不是自动接管全网的设备名称，而是一种具体的转发拓扑。

选型时先确认 CPU 架构、可用内存和持久化空间，再选择与固件防火墙兼容的管理方式。上线时遵循“显式代理 → 单台透明接管 → DNS 与双栈 → 全网扩展”的顺序。这样每一步都有明确边界，出问题时也能回到已验证的上一层，而不必同时修改订阅、网关和防火墙。