部署选择：先确定网关位置，再选择接管方式

主路由性能充足、需要统一管理全网设备时，可以直接在 OpenWrt 上运行 mihomo；需要保留现有主路由、只让部分设备接入时，旁路由更便于分批测试。初次部署建议先验证手动代理，再接入 DNS，最后启用透明代理，避免同时修改三处后无法判断故障来源。

mihomo 是由 Clash Meta 演进而来的代理内核，负责协议连接、规则匹配和 DNS 等功能。它不是路由器固件，也不自带完整的路由管理界面。OpenWrt 插件通常负责生成配置、管理进程、安装防火墙规则和提供 LuCI 页面；直接运行二进制则需要自行完成这些工作。

部署位置接入方法主要维护点
OpenWrt 主路由在统一出口接管 LAN 流量防火墙、DNS、硬件转发加速
OpenWrt 旁路由指定设备把网关指向旁路由回程路径、DHCP、同网段转发
Linux 小主机手动代理或配置为网关服务管理、转发、路由和防火墙
容器中的 mihomo先提供显式代理，再评估透明接管网络命名空间、设备映射和权限

硬件要求：核对架构、可用内存与存储

架构以操作系统为准

先通过 SSH 执行下面的命令。CPU 支持 64 位，不代表当前安装的固件也是 64 位；下载二进制时要匹配实际系统架构。ARM 还需要留意指令集等级，MIPS 则需要区分大小端。支持高级指令集的构建不能直接用于较旧的处理器。

uname -m
cat /etc/openwrt_release
free -m
df -h /overlay
df -h /tmp

例如，aarch64 通常对应 ARM64，x86_64 对应 64 位 x86。遇到启动后提示非法指令，应先核对构建要求；提示无法执行时，还要检查文件架构、执行权限和运行环境，而不是反复更换订阅。

容量按运行余量规划

  • 256 MB 内存设备：属于紧张场景。应减少规则集和订阅规模，并在更新规则时观察剩余内存，不能只看启动后的占用。
  • 512 MB 内存设备：可作为轻量家庭部署的评估起点，但还要扣除无线服务、文件共享和其他插件占用。
  • 1 GB 及以上内存：更适合同时运行多项服务或使用较大的规则集，仍需根据实际连接数观察占用。
  • 存储空间：建议至少预留 100 MB 可写空间作为初始规划，存放内核、配置、规则数据及更新临时文件；这不是所有配置通用的最低要求。

OpenWrt 的 /tmp 通常使用内存文件系统。把大文件放进去会消耗内存，重启后也可能消失。吞吐则受 CPU 单核性能、加密协议、网卡驱动和透明代理路径共同影响，不能根据千兆网口推断代理一定能达到千兆。

安装方式：插件托管、原生服务与容器

OpenWrt 插件：由一个管理入口负责配置

选用适配当前固件版本和防火墙体系的插件。较新的 OpenWrt 通常使用 firewall4 与 nftables，较旧环境可能仍使用 firewall3 与 iptables；安装前应核对插件文档，不要把旧版防火墙脚本直接套到新系统。

  1. 备份当前网络、DHCP 和防火墙配置，记录路由器 LAN 地址及 SSH 登录方式。
  2. 通过插件安装或选择匹配架构的 mihomo 内核，再添加支持该内核的订阅配置。
  3. 先关闭透明接管，只验证配置能加载、节点能连接，再逐项启用 DNS 与流量接管。
  4. 确认插件是否会重新生成配置。需要长期保留的修改应放在插件提供的覆写或附加配置入口。

插件的菜单名称随项目和版本变化，不能统一按桌面客户端的设置路径操作。也不要让两个代理插件同时接管 DNS 或透明转发，否则可能出现端口冲突、规则互相覆盖和重复代理。

原生二进制：自行管理进程与开机启动

下面示例假定内核已安装在 /usr/bin/mihomo，配置保存在 /etc/mihomo/config.yaml。先检查语法，再以前台方式启动查看日志：

/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

配置检查成功不代表远端节点可达，也不代表透明转发已生效。前台验证后，OpenWrt 应交给 procd 管理服务；使用 systemd 的 Linux 则创建对应服务单元，设置工作目录和重启策略。避免只通过 SSH 后台启动，否则退出终端或重启设备后可能失去服务。

容器：显式代理比透明网关更容易落地

普通桥接网络配合端口映射，可以先提供 HTTP 或 SOCKS 代理。TUN 通常还需要访问 /dev/net/tun、网络管理能力以及适当的网络模式。容器中的路由只影响其所在网络命名空间，不会自动接管宿主机或整个 LAN。不要为了排错直接开放全部权限，应先确认流量需要在哪一层进入内核。

旁路由拓扑：网关与 DNS 分开核对

以一个具体网络为例：主路由为 192.168.50.1，旁路由固定为 192.168.50.2，两者掩码均为 255.255.255.0。旁路由自身的默认网关指向主路由。初次测试只修改一台电脑，保留其他设备的原有设置。

测试模式终端设置验证目标
手动代理网关仍为 .1，应用代理指向 .2:7890内核、订阅和节点连通性
透明代理默认网关改为 .2，DNS 指向已配置的 LAN DNS 服务转发、规则和 DNS 接管
回退原网络网关与 DNS 恢复为 .1 或原 DHCP 设置区分旁路由故障与上游故障

只修改 DNS，不能让所有连接自动经过旁路由；只修改网关，也不能保证域名解析按预期进行。透明代理还需要系统允许 IP 转发，并配置正确的防火墙与回程路径。单网口旁路由尤其要注意：直连流量可能从旁路由转到主路由，而返回流量由主路由直接送回终端，形成非对称路径。

部分方案会使用源地址转换来稳定回程，但这会改变上游看到的源地址，不能不加区分地复制一条 NAT 命令。应按照所用插件的拓扑说明配置。确认单台设备正常后，再考虑通过 DHCP 下发网关选项 3 和 DNS 选项 6；同一广播域不要随意开启第二个 DHCP 服务。

配置要点：先开放受限的局域网代理入口

下面是前述网络的基础片段，不是完整订阅。它仅说明监听地址、混合代理端口和 DNS 入口的关系。节点、策略组与规则仍需来自有效配置；使用插件时，应通过插件支持的配置方式设置，避免直接修改生成文件。

mixed-port: 7890
allow-lan: true
bind-address: 192.168.50.2
mode: rule
log-level: info
ipv6: false

dns:
  enable: true
  listen: 192.168.50.2:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - 223.5.5.5
    - 1.1.1.1
  • mixed-port: 7890 同时提供 HTTP 和 SOCKS 代理入口。这个端口不是透明代理入口，终端需要显式配置代理才能使用。
  • allow-lan: true 允许局域网接入，但防火墙仍应只允许可信 LAN 访问。不要把 7890 端口映射到公网。
  • bind-address 绑定示例旁路由地址。部署时该地址必须真实存在于本机接口上。
  • 1053 是示例 DNS 上游监听端口，普通终端默认向 53 端口查询，不能通过 DHCP 单独指定 1053。

在 OpenWrt 上，可以让 dnsmasq 继续服务 LAN 的 53 端口，再把查询转给 mihomo 的 1053 端口。此时必须检查转发链：dnsmasq 指向 mihomo，而 mihomo 的上游不能又回到同一个 dnsmasq，避免 DNS 循环。示例中的公共解析器仅用于展示格式，实际应按本地网络可达性与分流需求配置。

透明代理与 TUN：不要重复接管同一批流量

常见透明代理方案包括防火墙重定向、TProxy 和 TUN。重定向通常用于 TCP；TProxy 可以处理 TCP 与 UDP，但依赖相应内核能力、策略路由和防火墙规则。TUN 则通过虚拟网络接口把流量交给内核处理，它并不等于自动解决所有路由与 DNS 问题。

三处必须一起检查

  1. 接入：LAN 转发流量是否进入预期链或 TUN 路由。仅接管路由器自身流量，不能证明 LAN 设备也已接入。
  2. 排除：代理节点服务器地址、局域网地址、内核自身出站等流量是否被正确排除，防止再次进入代理形成循环。
  3. 返回：策略路由、防火墙标记及连接跟踪是否一致，UDP 和 TCP 是否都经过预期路径。

mihomo 的 TUN 可使用 auto-route 等选项协助建立路由；在支持的 Linux 环境中，auto-redirect 还可协助重定向。是否启用应服从插件设计。不要同时开启插件的 TProxy 接管和另一套独立 TUN 自动接管，再期待两者自动协调。

排错时可暂时关闭软件或硬件流量分载，再比较行为。某些加速路径可能绕过需要经过的处理链。若仅 QUIC 视频或游戏异常，要单独检查 UDP 转发和节点协议能力，不能用浏览器打开一个网页就认定全部流量正常。

DNS、Fake-IP 与 IPv6：保持解析和连接路径一致

Fake-IP 会为域名返回映射地址，示例使用 198.18.0.0/16。这些地址需要由 mihomo 识别并关联回域名，不能当作公网目标直接交给上游路由器。因此，终端取得 Fake-IP 后，其连接也必须进入同一套代理接管路径。

  • 局域网域名：打印机、NAS 和路由器管理域名应保留本地解析。需要时结合 Fake-IP 过滤与 DNS 策略处理，不能只加入过滤后就忽略本地解析来源。
  • 应用自带加密 DNS：浏览器的 DoH 可能绕过系统 DNS。传统的 53 端口接管并不能覆盖这类查询，测试时应记录浏览器是否另设了解析器。
  • IPv6：终端可能通过路由通告获得另一条默认路由。只改 IPv4 网关，IPv6 连接仍可能直出。
  • 恢复配置：关闭 Fake-IP 或切换 DNS 后，应清理终端与应用缓存，避免继续使用旧映射地址。

示例关闭了 mihomo 的 IPv6 使用和 AAAA 应答，但这不等于关闭整个 LAN 的 IPv6。部署前应明确选择：完整配置 IPv6 接管，或在测试网络中暂时停用 IPv6 路由通告与相关服务。不要把 IPv6 路径遗漏误判为规则随机失效。

验收与回退：按连接链路逐层定位

每次只改一个变量，并记录修改前后的设置。以下命令分别用于查看进程日志、监听端口、路由和 DNS；根据系统已安装的工具选择执行，不需要为一次排错一次性安装所有工具。

logread | grep -i mihomo
ss -lntup
ip route show
ip rule show
nslookup example.com 192.168.50.2
curl -I -x http://192.168.50.2:7890 https://example.com

nslookup 这条命令测试的是旁路由 53 端口的 LAN DNS 服务，不是示例里的 1053 监听。若没有部署前端 DNS 服务，不能据此认定 mihomo 的 DNS 模块故障。curl 则测试显式 HTTP 代理，与透明代理是两条不同的验证路径。

现象优先排查下一步
配置无法加载缩进、字段类型、内核兼容性运行配置检查，定位具体报错行
手动代理也无法连接监听地址、LAN 防火墙、节点可达性先恢复单个代理入口连通
手动代理正常，改网关后失败转发开关、接管规则、回程路径检查路由与防火墙计数
部分域名异常DNS 缓存、Fake-IP、本地域名解析比较系统与应用的解析来源
IPv4 正常，部分连接直出IPv6 默认路由与接管范围分别验证 IPv4、IPv6 路径

完成验收后再启用开机启动，并重启一次确认配置、规则数据与防火墙能按顺序恢复。若测试失败，先把终端网关和 DNS 恢复为原主路由，再通过插件关闭接管、恢复相应防火墙配置；仅停止内核可能留下指向失效接口的规则。保留一个不经过旁路由的管理入口，可以减少配置错误导致的整网失联。