OpenWrt 旁路由直跑 Clash 内核：透明代理部署思路与网关 DNS 设置

部署边界：内核运行不等于透明代理生效

OpenWrt 上直接运行 Clash 类内核，需要分别处理进程、流量入口与 DNS。进程启动成功，只说明配置能够加载；客户端流量还必须经过旁路由，再由防火墙送入透明代理端口。本文以 mihomo 为例，讲清这三层之间的衔接。

• 进程层：二进制匹配设备架构，配置放在 /etc/mihomo/config.yaml，服务交给 OpenWrt 的 procd 管理。
• 转发层：客户端默认网关指向旁路由，旁路由能够继续把直连流量送到主路由。
• 接管层：防火墙选择需要代理的连接，DNS 由明确的本地解析链处理。

如果设备已经安装代理管理插件，先检查它是否负责启动内核、生成配置和写入防火墙规则。同一台路由器上再手工启动第二套接管，容易出现端口冲突、重复重定向或配置被覆盖。直接运行内核与使用管理插件，应明确选择一套作为控制入口。

网关拓扑：先让一台设备经过旁路由

以下地址仅用于说明单网口、同网段旁路由。实际配置时按现有网段替换。主路由继续承担互联网出口和 DHCP，旁路由使用固定地址，测试电脑单独修改网关与 DNS。

OpenWrt 接口与转发检查

在 LuCI 的「网络」→「接口」→「LAN」→「编辑」中检查固定地址。不同主题的标签可能略有差异，以接口、IPv4 地址和网关字段为准。不要把主路由地址误填成旁路由自己的默认网关。

ip -4 addr show
ip -4 route show
sysctl net.ipv4.ip_forward
ping -c 3 192.168.10.1

路由表应有指向 192.168.10.1 的默认路由；转发开关应为 1。还需检查防火墙是否允许对应接口之间的转发。单臂旁路由的流量可能从同一 LAN 设备进入并离开，不能只照搬双网口的 LAN→WAN 规则。

同网段转发还涉及返回路径：直连连接可能经旁路由发出，却由主路由直接回到电脑。非对称路径、ICMP Redirect 和连接跟踪策略都可能影响结果。源地址伪装可以在部分拓扑中使回程重新经过旁路由，但也会隐藏原始客户端地址；是否启用，应结合实际路由与防火墙检查，而不是作为固定开关照抄。

内核文件：确认架构、配置目录与启动参数

先通过 uname -m 查看硬件架构，再通过 ubus call system board 查看系统信息。架构名称相近不代表二进制一定兼容，还要核对 CPU 指令集与发布文件的运行要求。不要把桌面客户端安装包当成路由器内核执行。

uname -m
ubus call system board
df -h /overlay
free -m

确认设备有足够的持久存储和运行内存。规则集、地理数据库与连接数量都会增加资源占用，没有适用于所有配置的固定内存门槛。不要把唯一的配置副本放在重启后会清空的 /tmp。

以下命令假设已经取得匹配设备的 mihomo 二进制，保存为 /usr/bin/mihomo，并已把完整 YAML 配置放到指定目录。先测试，再启动服务：

mkdir -p /etc/mihomo
chmod 0755 /usr/bin/mihomo
chmod 0600 /etc/mihomo/config.yaml
/usr/bin/mihomo -v
/usr/bin/mihomo -t -d /etc/mihomo -f /etc/mihomo/config.yaml

-v 用来记录当前实际内核版本；-t 用来检查配置。若日志提示缺少规则文件、数据库或下载失败，先补齐对应资源。配置测试通过不代表远端节点可用，也不代表防火墙接管已经完成。

Redir、TProxy 与 TUN：按流量类型选择入口

本文以 Redir 和 TProxy 为主。Redir 的 TCP 入口不能替代通用 UDP 接管；只配置 Redir 后，QUIC、游戏或语音应用的 UDP 不会因此自动走代理。TProxy 能接住 UDP，也仍要求所选节点协议和服务端支持相应转发。

mihomo 端口配置片段

以下是合并到已有配置中的片段，不是可独立完成代理部署的订阅。保留原有的节点、策略组与规则，避免在 YAML 顶层重复定义同名键。两个透明入口可以同时监听，但同一股流量应由明确的一条防火墙路径处理。

mode: rule
log-level: info
redir-port: 7892
tproxy-port: 7893

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

这里使用 redir-host 作为较易观察的起点，DNS 返回真实地址。223.5.5.5 是上游解析器示例，应按所在地连通性和解析需求选择，并验证能够直连。域名分流所需的解析策略、节点域名解析及加密 DNS，应在基础链路稳定后分别补齐。

如改用 fake-ip，还要让客户端到合成地址段的连接被内核接住，并按应用兼容需求配置过滤项。不要只切换 DNS 模式，却让合成地址流量绕过旁路由。

防火墙接管：区分 firewall4 与旧规则体系

先运行下面的只读命令，确认设备使用的防火墙工具。OpenWrt 22.03 起官方默认转向 firewall4 与 nftables，但实际设备可能来自不同固件或经过修改，应以本机结果为准。

command -v fw4
command -v nft
command -v iptables
nft list ruleset
ip -4 rule show
ip -4 route show table all

不要把网上的 iptables 接管脚本直接塞进 firewall4 配置。即使存在兼容命令，也要确认规则究竟进入哪套规则集，以及防火墙重载后是否仍然保留。TProxy 还依赖相应内核模块和用户空间表达式支持，只有监听端口并不足够。

接管规则至少要覆盖四件事

1. 限定来源：首次仅匹配测试电脑 192.168.10.100，不要直接接管整个 LAN，更不要匹配来自 WAN 的任意流量。
2. 先排除，再接管：保留本地管理地址、局域网目的地址、必要的广播与组播流量。IPv4 与 IPv6 的排除范围必须分别设计。
3. 匹配入口：TCP Redir 送到 7892；TProxy 送到 7893，同时配置与标记一致的策略路由，把被标记的流量本地投递。
4. 防止环路：内核自身向节点、DNS 和直连目标建立的出站连接，不能再次进入同一套接管。路由器本机的 OUTPUT 接管应单独设计。

TProxy 常见实现需要 fwmark、ip rule 与某个路由表中的本地路由配合。标记值、掩码、规则优先级和路由表编号要与现有 VPN、策略路由插件避让。不存在对所有设备都安全的固定编号，因此不在这里给出可直接覆盖现网的整套规则。

首次测试时关闭相关流量卸载选项，再观察计数。硬件或软件卸载可能改变后续数据包经过的路径；不能仅凭首个连接成功，就判断所有流量都被正确接管。

DNS 接管：dnsmasq 的 53 端口转发到内核 1053

建议先保留 dnsmasq 负责局域网的 53 端口，让 mihomo 只监听回环地址 127.0.0.1:1053。这样不会让两个进程争抢相同监听地址，也不需要对局域网直接暴露内核 DNS 端口。

1. 在「网络」→「DHCP/DNS」中找到 DNS 转发设置，添加 127.0.0.1#1053。这里是 dnsmasq 的服务器端口写法，不是 YAML 写法。
2. 检查其他转发服务器和 resolv 文件来源。若要求查询只经过 mihomo，应关闭从上游 resolv 文件读取其他服务器的路径，避免与本地转发并行。
3. 确认 mihomo 的上游不是旁路由自身的 53 端口，否则会形成“dnsmasq → mihomo → dnsmasq”的解析环路。
4. 重载服务后，在测试电脑执行 nslookup example.com 192.168.10.2，同时查看内核日志与 DNS 监听状态。

电脑的 DNS 字段只填 192.168.10.2，不要填写 192.168.10.2:1053。普通系统 DNS 设置通常不提供这种端口语法。DHCP 的 DNS 选项也只分发服务器地址。

若 dnsmasq 与内核同时启用缓存，配置变更后要考虑旧记录。先用显式指定服务器的查询验证，再刷新客户端缓存；不要把缓存命中误判成新解析链已经生效。

procd 自启：先管理进程，再安排接管规则

直接运行内核可用 OpenWrt 的 procd 管理。以下内容保存为 /etc/init.d/mihomo。这是最小进程服务示例，不会自动安装防火墙规则，也不会修改客户端网关。

#!/bin/sh /etc/rc.common

USE_PROCD=1
START=99
STOP=10

start_service() {
    procd_open_instance
    procd_set_param command /usr/bin/mihomo \
        -d /etc/mihomo \
        -f /etc/mihomo/config.yaml
    procd_set_param respawn 3600 5 5
    procd_set_param stdout 1
    procd_set_param stderr 1
    procd_close_instance
}

chmod 0755 /etc/init.d/mihomo
/etc/init.d/mihomo enable
/etc/init.d/mihomo start
logread -e mihomo
netstat -lnptu

在监听列表中核对 7892、7893 和 127.0.0.1:1053。命令可用性取决于固件所带工具；若 netstat 不支持相应参数，可用已安装的 ss -lnptu 检查。不要把管理 API 监听到公网接口。

示例服务以系统默认权限启动。透明代理与路由操作涉及权限，配置文件和服务脚本只应允许管理员修改。防火墙规则的持久化应使用与当前防火墙体系兼容的加载机制，并明确服务停止时如何解除接管；否则内核退出后，客户端仍可能被送往无人监听的端口。

验证顺序：路由、DNS、接管、远端逐层检查

1. 先测基本路由：在尚未启用透明接管时，确认测试电脑以旁路由为网关仍能正常联网。此时失败，应先修复转发和回程。
2. 再测 DNS：显式查询 192.168.10.2。超时先查 dnsmasq、1053 监听及解析环路；返回地址不代表对应网站一定可连接。
3. 再测 TCP 接管：从测试电脑访问 HTTPS 站点，查看相关防火墙计数和 mihomo 连接日志，确认来源地址、匹配规则与最终策略一致。
4. 单独测 UDP：使用确实需要 UDP 的应用，结合 TProxy 计数与连接日志观察。普通网页成功不能证明 UDP 代理可用。
5. 检查双栈：分别测试 IPv4 与 IPv6。若 IPv6 仍从主路由直出，应明确设计 IPv6 接管、DNS 下发与防火墙策略，不要把双栈行为当成偶发错误。
6. 最后测重载与重启：测试防火墙重载、内核重启和整机重启，确认没有重复规则，DNS 能恢复，停止内核后有明确的回退方案。

按现象定位，不反复更换节点

• 修改网关后完全断网：优先检查 IP 转发、防火墙转发、主路由出口和回程，不先怀疑订阅。
• IP 可达、域名打不开：检查电脑实际 DNS、dnsmasq 上游、内核 DNS 日志及浏览器安全 DNS。
• 网页正常、部分应用失败：检查 UDP、IPv6、规则命中与远端协议能力，区分未接管和已接管但连接失败。
• 只有路由器自身无法连接：检查 OUTPUT 与内核自身流量的豁免，避免代理出站再次被接管。
• 重启后失效：检查服务是否启用、依赖文件是否位于持久目录，以及防火墙是否重新加载了对应规则。

全网推广前，把一台设备的验证结果记录下来：地址、网关、DNS、透明端口、命中策略与重启结果。确认稳定后再调整 DHCP；续租不会总是立即发生，部分设备需要断开重连。需要回退时，先让客户端恢复主路由网关与原 DNS，再撤销透明接管，最后停止内核，避免把全网留在不可用的转发路径上。