先确定旁路由承担哪些工作
旁路由是部署角色，不是一种特殊的代理协议。常见做法是在现有主路由旁接入一台 OpenWrt 设备，让选定终端把它作为默认网关。主路由继续负责宽带拨号、无线接入和外网出口，OpenWrt 则按规则处理经过它的流量。
mihomo 是由 Clash Meta 项目发展而来的代理内核，负责读取配置、匹配规则并建立连接。它本身不是完整的路由管理界面。将内核复制到设备上，只完成了部署的一部分；透明代理还需要路由、DNS 和防火墙规则配合。
选择一种接管路线
- 显式代理：在终端填写 HTTP 或 SOCKS 代理地址。适合确认订阅和节点是否可用，但只有遵守代理设置的应用会使用它。
- 透明代理：由 OpenWrt 拦截或路由终端流量。可以使用 TProxy，或配合 mihomo 的 TUN 虚拟网卡实现；两者对内核模块和路由的要求不同。
- 集成管理插件：由插件维护内核、配置和防火墙。适合需要 LuCI 图形界面的用户，但应先阅读该插件对当前 OpenWrt 版本的支持说明。
选定一种方案管理透明接管。不要让两个插件同时写入 DNS 劫持、策略路由和防火墙规则，也不要在插件自动生成配置后，再直接修改它的临时运行文件。
规划地址、默认网关与 DHCP
以下采用单网口、同一子网的示例：主路由为 192.168.10.1，OpenWrt 为 192.168.10.2，测试 Mac 为 192.168.10.50，子网掩码均为 255.255.255.0。这些地址是部署示例，实际操作前要替换成家中现有网段，并检查地址没有被占用。
| 设备 | 默认网关 | DNS 与职责 |
|---|---|---|
| 主路由 .1 | 运营商上游 | 负责拨号、外网 NAT 和 DHCP |
| OpenWrt .2 | 192.168.10.1 | 接收测试终端 DNS，执行规则分流 |
| 测试 Mac .50 | 192.168.10.2 | DNS 指向 192.168.10.2 |
先设置 OpenWrt 自身的上游
- 用网线连接主路由 LAN 口与 OpenWrt 的 LAN 接口。设备端口归属以当前网络配置为准，不要只看机壳标签。
- 打开 LuCI 的「网络」→「接口」→「LAN」→「编辑」，设置固定 IPv4 地址、掩码和指向主路由的 IPv4 网关。
- 为 OpenWrt 自身设置可用的上游 DNS，确保下载内核、解析代理服务器域名和更新订阅能在代理启动前完成。
- 若主路由继续提供 DHCP，在 OpenWrt 对应 LAN 的「DHCP 服务器」→「常规设置」中勾选「忽略此接口」。这只关闭该接口的 DHCP 地址分配，不等于关闭 DNS 服务。
DHCP 是自动分配地址、网关和 DNS 的服务。同一个广播域不要随意开启两套相互冲突的地址分配服务。否则终端可能这次拿到主路由网关，下次拿到旁路由网关，表现为时好时坏。
再修改测试 Mac
打开 macOS「系统设置」→「网络」→当前网络服务→「详细信息」→「TCP/IP」，记录原来的配置，再将测试地址、子网掩码与「路由器」地址按表填写；在「DNS」页填写 192.168.10.2。先确认测试地址已在 DHCP 池外或已绑定，避免地址冲突。
全网推广时，可由主路由 DHCP 下发选项 3（默认网关）和选项 6（DNS 服务器），均指向旁路由。部分家用路由器不能单独设置这两项，此时保留逐台配置更容易回退。修改 DHCP 后需要终端续租，已经获得的旧租约不会立即全部变化。
核对 CPU 架构与资源余量
路由器安装的是 Linux 内核程序，不是 macOS 的应用安装包。先通过 SSH 查看系统，再选择 mihomo 发布资源中匹配的架构。不能只凭“64 位处理器”判断：处理器支持 64 位，不代表当前固件的用户空间也是 64 位。
ubus call system board
uname -m
getconf LONG_BIT
free -m
df -h
cat /etc/openwrt_release精简固件可能没有 getconf，可结合系统板卡信息与固件目标判断。常见的 x86_64 对应 AMD64 架构，aarch64 对应 ARM64；MIPS 设备还要区分大小端、指令集和浮点约定。运行时出现 Exec format error，应先检查架构，不要反复增加执行权限。
把容量建议与实际占用分开
- 内存：把 256 MB 视为需要谨慎评估的设备档位；512 MB 或更多通常更便于给规则集、DNS 缓存与并发连接留余量。这是规划建议，不是内核的固定最低要求。
- 存储：检查
/overlay的可用空间。内核、规则数据库和更新时的新旧文件会共同占用空间，不要只按压缩包大小估算。 - 处理器：代理加密、规则匹配和大量连接都会消耗 CPU。宽带标称 1000 Mbps，不代表路由器经过代理后也能达到该速率。
安装后运行 mihomo -v 记录实际版本，排障时同时记录固件版本、接管方式和规则规模。分别在空闲、加载订阅后、持续传输 10 分钟后三个阶段查看 top 与 free -m。关注进程常驻内存和系统可用内存；Linux 用于缓存的内存不能简单算成泄漏。
分开配置内核、透明接管与 DNS
OpenWrt 22.03 及后续常见版本默认采用 firewall4，以 nftables 生成防火墙规则。旧教程中的 iptables 命令不能直接当作通用配置粘贴。使用插件时，核对它支持的防火墙后端；手动部署时，核对 TProxy 或 TUN 所需模块是否在当前固件中可用。
先检查配置，再接管终端
将运行配置与资源目录固定保存。下面命令假设内核已安装为 /usr/bin/mihomo，配置位于 /etc/mihomo/config.yaml；只有实际使用这些路径时才执行。
/usr/bin/mihomo -v
/usr/bin/mihomo -t -d /etc/mihomo -f /etc/mihomo/config.yaml配置检查成功只代表配置可加载，不代表订阅能更新、节点能连接或透明代理已生效。继续核对所选策略组、最终兜底规则，以及节点服务器域名是否能够解析。订阅 URL 往往含有访问凭据，日志与截图分享前应遮盖完整地址。
明确每个端口的用途
如果配置了 mixed-port: 7890，7890 是供应用显式连接的 HTTP/SOCKS 混合代理入口；如果配置了 tproxy-port: 7893，7893 是透明转发规则使用的入口。它们都是可修改的示例值，不是启动内核后必然存在的端口。只开放 7890 并不会自动接管局域网流量。
TUN 是虚拟网络接口，需要相应设备支持、权限和路由设置。即使启用了自动路由，也仍要检查 LAN 转发、防火墙区域及 DNS 入口，不能将其理解为自动完成所有旁路由配置。TProxy 则通常依赖流量标记和策略路由，让被拦截的数据交给本机代理处理。
让 DNS 形成单向链路
一种常见链路是：终端请求旁路由的 53 端口，由 dnsmasq 接收，再转给 mihomo 的本机 DNS 监听地址，例如 127.0.0.1:1053。1053 必须与实际配置一致。不要让 dnsmasq 转给 mihomo 后，mihomo 又把同一请求交回 dnsmasq，形成循环。
- 使用 fake-ip：内核向终端返回用于映射的地址，随后根据映射还原域名。常见地址池为
198.18.0.0/16，应避开已有网络与 VPN 使用的网段。 - 解析节点域名：为代理服务器本身保留可用的引导解析路径，避免必须先连代理才能解析代理服务器的依赖循环。
- 检查加密 DNS：浏览器自定义 DoH 可能绕过局域网 DNS。基于域名的规则和 fake-ip 映射因此可能与预期不同，测试时先统一 DNS 路径。
旁路由返回 fake-ip 后，终端连接必须继续经过同一套内核。若只把 DNS 指向旁路由、网关仍走主路由，主路由通常无法处理这些映射地址，常见表现就是域名能解析但网页打不开。
处理单臂路由、IPv6 与安全边界
单臂旁路由只有一个主要 LAN 接口，收包与向主路由发包可能经过同一接口。直连流量的去程经过旁路由，回程却可能由主路由直接交给终端，形成非对称路径。是否需要在旁路由上做源地址转换，要结合连接跟踪、防火墙和上游路由判断。
一些方案会对转发流量做 SNAT 或 masquerade，使主路由看到的来源变成旁路由地址，从而让回包也经过旁路由。这能简化某些单臂拓扑，但上游看到的终端来源会被合并。不要把“在 LAN 区域开启地址伪装”当成所有设备都必须执行的步骤。
IPv4 改好了，IPv6 也要单独检查
主路由可能继续通过 RA（路由器通告）向终端发布 IPv6 默认路由。只修改 IPv4 网关，并不能控制 IPv6 流量。应明确部署方案是否同时接管 IPv6、提供对应 DNS 和转发规则；测试时可临时停用测试终端的 IPv6 做对照，确认后再决定正式的双栈策略。
把管理端口限制在可信范围
- 不要把代理端口、DNS 服务或控制接口转发到公网。
- 确需提供 LAN 代理时，检查
allow-lan、监听地址、客户端认证及防火墙来源限制。 - 控制 API 优先只监听回环地址；需要远程面板时设置强密钥，并限制可访问的管理终端。
- 使用 OpenWrt 的 procd 服务机制或插件自带服务管理持久运行，避免只在 SSH 会话中启动进程。
按链路顺序排查断网与分流异常
排障时一次只改一个环节。先确认地址和路由，再检查 DNS，最后判断规则与节点。不要同时换订阅、改网关和重建防火墙，否则很难知道哪一步产生了影响。
在测试 Mac 上检查入口
route -n get default
scutil --dns
ping -c 3 192.168.10.2
dig @192.168.10.2 example.com
curl -I --connect-timeout 10 https://example.com默认 IPv4 网关应是示例中的 192.168.10.2；DNS 查询应得到响应，而不是一直超时。系统 DNS 输出可能包含 VPN 的独立解析域，要结合实际使用的网络服务判断。单个目标不响应 ping 也不能证明互联网断开，仍需看 DNS 和 HTTPS 结果。
在 OpenWrt 上检查转发与日志
ip route
ip rule
ip route show table all
logread | tail -n 80
nft list ruleset这些命令用于观察，不会清空现有规则。检查是否存在预期的默认路由、流量标记相关策略，以及 LAN 到目标处理链的转发入口。规则输出可能含局域网地址与服务信息，分享时只保留排障所需部分。
| 现象 | 优先检查 |
|---|---|
| 改网关后完全断网 | 旁路由地址是否可达，自身默认网关、IP 转发及防火墙是否允许该路径 |
| IP 连通，域名解析超时 | 53 端口是否监听、dnsmasq 转发目标是否正确、上游 DNS 是否循环 |
| 显式代理能用，透明代理不能用 | 透明入口、策略路由、转发规则和对应内核模块 |
| 部分网站绕过规则 | IPv6 默认路由、浏览器加密 DNS、规则顺序与实际连接记录 |
| 重启后失效 | 服务自启、配置保存位置、启动时网络与时间同步状态 |
若小请求正常、大文件传输卡住，再排查 MTU、路径 MTU 发现和上游 PPPoE 封装，不要上来就把所有接口强行改成同一数值。吞吐测试应先测直连基线，再用同一终端、同一连接方式测代理，避免把无线信号变化误判成内核性能问题。
保留回退方案，再扩大接管范围
- 保存初始状态。备份 OpenWrt 配置，记录主路由地址、DHCP 池和测试终端原来的自动获取设置。
- 验证基础功能。确认国内直连、需要代理的连接、局域网打印机与 NAS 访问均符合规则预期。
- 验证生命周期。分别重启内核和旁路由，再让 Mac 断开网络后重连，检查是否依然使用正确网关与 DNS。
- 演练旁路由离线。让测试终端恢复主路由网关及原来的 DNS，确认基础上网可恢复。使用 fake-ip 时还需刷新 DNS 缓存或重启相关应用。
- 逐步推广。先增加少量设备，再调整 DHCP 下发。保留一台可直接连接主路由管理界面的终端。
同网段旁路由通常没有天然的故障接管机制。终端仍把离线的旁路由当默认网关时，主路由不会因为自己还在线就自动接手。将地址规划、DNS 路径、服务自启和回退步骤一起记录，才能在更新内核或更换订阅后快速定位问题。
如果只需要让一台 Mac 使用代理，先采用桌面客户端更容易验证订阅与规则；确实需要电视、游戏设备或多台终端共享策略时，再将规则迁移到 OpenWrt。两种方式解决的是不同范围的接管需求，不必一开始就修改整个家庭网络。