先确定流量经过哪台设备

在 OpenWrt 上启动 mihomo，只代表代理内核已经运行，不代表局域网设备已经进入透明代理。完整链路至少包含三个部分：终端把流量交给旁路由，旁路由把符合条件的连接交给内核，内核按规则选择直连或代理出口。DNS 还需要单独规划，不能只改默认网关就认为配置完成。

mihomo 是 Clash Meta 延续发展的代理内核，不等于带界面的桌面客户端。路由器上的插件通常负责下载内核、生成配置、创建防火墙规则和管理服务；直接部署内核时，这些工作需要自行处理。已有插件接管网络的设备，不宜再叠加另一套手写透明代理规则。

先用一台终端验证

保留主路由原有 DHCP 设置，只给一台测试电脑修改网关与 DNS。确认管理页面、局域网访问和代理连接都正常后，再考虑向全网下发。操作前保留本地管理入口，避免通过正在调整的代理链路远程修改网络。

三种常见部署位置

部署方式流量入口主要检查项
主路由运行内核终端默认网关就是 OpenWrtWAN 出口、转发区域、DNS 与路由接管
同网段单臂旁路由终端把旁路由设为默认网关同接口转发、回程路径、ICMP 重定向
独立网段旁路由终端连接旁路由下游网段上游静态路由或 NAT、下游 DHCP、跨网段访问

主路由方案路径直接，但故障影响范围较大；同网段单臂方案便于分批测试，却更容易出现去程经过旁路由、回程直接返回终端的情况；独立网段方案边界清晰，但需要管理额外的路由或 NAT。选型依据应是现有网络拓扑，而不是设备有几个网口。

网关与 DNS 的指向方式

以下使用一组说明性地址，不代表实际测量结果：主路由为 192.168.10.1，OpenWrt 旁路由为 192.168.10.2，测试终端为 192.168.10.100，子网掩码均为 255.255.255.0。旁路由的默认路由仍指向主路由，测试终端的默认网关则指向旁路由。

测试终端 192.168.10.100
  默认网关：192.168.10.2
  DNS：192.168.10.2
        ↓
OpenWrt 旁路由 192.168.10.2
  默认网关：192.168.10.1
        ↓
主路由 192.168.10.1
        ↓
互联网

网关决定路径，DNS 决定查询入口

  • 只改 DNS：域名查询可以到达旁路由，但业务连接仍可能直接经过主路由，不能据此认定透明代理已生效。
  • 只改网关：业务流量可能经过旁路由，但终端仍向原来的 DNS 服务器查询，基于域名的识别与解析策略可能不符合预期。
  • 同时修改：更容易建立一致的测试路径，但仍需确认旁路由允许转发，并已完成实际的流量接管。

在常见 LuCI 界面中，可从「网络」→「接口」→「LAN」→「编辑」检查静态地址；默认网关与 DNS 的具体页签随固件版本而异。主路由负责 DHCP 时，全网下发通常对应 DHCP 选项 3（默认网关）和 6（DNS 服务器）。不要让主路由与旁路由在同一广播域同时开启未协调的 DHCP 服务，否则不同终端可能取得不同网关。

同网段单臂转发还应检查 ICMP 重定向：某些路由行为可能提示终端直接使用主路由，从而绕过原定路径。是否需要源地址转换取决于回程路由和接管方式，不能把“开启伪装”当成通用修复；它会改变内核或上游看到的源地址，也可能影响按终端区分的规则与日志。

部署前检查系统与内核

先确认架构、可用存储和防火墙体系，再选二进制。OpenWrt 的软件包架构名称与上游发布包名称不一定完全一致，不能只凭设备商品名选择。ARM 设备还需要区分 32 位、64 位及具体指令集；x86 设备也应确认 CPU 能否运行所选构建。

ubus call system board
uname -m
df -h /overlay
free
command -v fw4
command -v nft
ls -l /dev/net/tun
ip route show
ip -6 route show

以官方 OpenWrt 23.05、24.10 系列常见环境为例，防火墙通常由 firewall4 使用 nftables 管理。第三方固件可能修改相关组件，应以设备上的检查结果为准。旧版教程里的 iptables 命令不能直接视为当前系统的正确方案，尤其不能同时让两套规则管理同一批连接。

先验证配置，再启动服务

下面约定内核位于 /usr/bin/mihomo，工作目录为 /etc/mihomo，配置文件为 /etc/mihomo/config.yaml。这是本文采用的本地路径，不是所有插件的默认目录。规则文件、地理数据和缓存也应按实际配置放置，避免仅复制 YAML 后忽略运行依赖。

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

-v 用于记录实际内核版本，-t 用于测试配置。测试通过只能说明内核接受配置及相关加载条件，不代表终端路由和防火墙已经正确。首次排查可在前台启动，确认日志后再交由 OpenWrt 的 procd 管理；若由插件维护，就使用插件的服务入口，避免启动第二个内核进程。

先建立本机代理与 DNS 基线

建议先验证显式代理，再接入透明代理。下列配置只建立本机监听与直连基线，不含代理节点，也不会让终端自动使用代理出口。实际部署时，应合并到一份有效配置，而不是在文件末尾追加第二个同名顶层字段。

mixed-port: 7890
allow-lan: false
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:
    - 1.1.1.1
    - 8.8.8.8

rules:
  - MATCH,DIRECT
  • mixed-port: 7890：供显式 HTTP/SOCKS 代理使用，不是透明代理入口。要让测试电脑访问该端口，需要另行配置 LAN 监听与严格的访问限制。
  • allow-lan: false：此基线不向局域网开放显式代理服务。TUN 对转发流量的接管并不等同于开放这个端口。
  • 127.0.0.1:9090：控制接口仅在本机监听。需要远程管理时应单独设计认证和访问范围，不应直接向公网开放。
  • 127.0.0.1:1053：DNS 只接收本机转发。这里没有使用端口 53，是为了避免与 dnsmasq 的监听直接冲突。
  • MATCH,DIRECT：所有未匹配连接直连，用于先验证通路。要使用代理出口，仍需加入有效节点、策略组和相应规则。

如果设备已有 curl 和 nslookup，可分别在旁路由上测试显式代理与 LAN DNS。示例域名仅用于连通性检查，响应时间不能代表代理节点质量。

curl --proxy http://127.0.0.1:7890 -I https://example.com
nslookup example.com 192.168.10.2

为 DNS 选择单一转发链

一种容易核对的设计是：终端查询旁路由的 53 端口，dnsmasq 再转发到本机 mihomo 的 1053 端口。常见 LuCI 路径为「网络」→「DHCP/DNS」→「常规设置」→「DNS 转发」，填写 127.0.0.1#1053；同时检查是否仍从上游获取其他解析服务器。若要所有外部查询都经过内核，需要按固件界面调整“忽略解析文件”等设置，并保留必要的本地域名处理。

避免 DNS 环路

dnsmasq 已经把查询交给 mihomo 时，mihomo 的上游就不能再指回同一条 dnsmasq 转发链。这里的数值 IP 上游仅用于说明链路，并非统一推荐。若改用带域名的加密 DNS，还需要考虑上游域名的引导解析，以及上游连接究竟走直连还是代理。

透明代理的三种接管方式

透明代理的含义是终端应用不必逐个填写代理地址，不是所有协议都会自动获得代理能力。实际覆盖范围由接管方式、内核支持、节点协议和防火墙规则共同决定。UDP、IPv6 与局域网目的地址必须分别检查。

方式基本机制部署注意点
REDIRECT防火墙把连接重定向到透明代理监听端口常用于 TCP；不能把 TCP 重定向规则照搬为完整 UDP 接管
TPROXY透明套接字配合流量标记和策略路由可用于 TCP 与 UDP，需要匹配的内核模块、路由和防火墙规则
TUN通过虚拟三层设备把 IP 流量交给内核需要 TUN 支持与权限，还要核对路由和 LAN 转发是否进入接管路径

选定一种主要方案后再配置，不要为了“覆盖更全面”同时开启插件 TPROXY、自建 REDIRECT 和另一套 TUN 自动路由。这种叠加可能造成连接重复进入内核、标记冲突或路由环路，表现往往是部分网站能打开、部分连接一直超时。

TUN 字段示意

以下片段适用于具备相应字段支持的 Linux mihomo 构建，用来解释 TUN 接管方向，不是适用于所有 OpenWrt 固件的一键配置。应先用实际内核测试配置，并核对其运行日志、生成规则与路由；较旧的构建可能不接受其中部分字段。

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-redirect: true
  strict-route: true
  dns-hijack: []
  • enable：启用 TUN。系统需要可用的 TUN 设备及相应网络管理权限。
  • stack: mixed：选择混合协议栈，不能理解为同时启用多个透明代理入口。
  • auto-route：让内核配置相关自动路由。它不能替代 LAN 到路由器的网关设置，也不能保证固件所有转发策略都允许通过。
  • auto-redirect：在受支持的 Linux 环境中配合自动路由创建接管所需的规则。与 firewall4、已有插件及策略路由是否协调，需要现场检查。
  • strict-route：收紧接管路由行为，仍不等于已经完成 IPv6 与所有旁路路径的审计。
  • dns-hijack: []：此示例不由 TUN 劫持 DNS，继续使用前面明确的 dnsmasq 转发链，避免首次部署时叠加两套 DNS 接管。

如果改为由 TUN 接管 DNS，应重新检查查询入口、上游解析和排除规则，而不是直接复制一个 any:53 就结束配置。传统 UDP/TCP 53 查询、应用自带 DoH 和系统私人 DNS 是不同路径，端口 53 的接管不会自动覆盖应用内加密解析。

IPv6、回程与防火墙边界

IPv4 测试成功，不代表双栈终端的所有连接都经过旁路由。主路由可能仍通过 IPv6 路由通告向终端提供默认路由，终端访问具有 AAAA 记录的站点时，就可能走另一条路径。只调整 DHCPv4 的选项 3 和 6 无法控制这条 IPv6 路径。

  1. 先在测试终端查看 IPv4、IPv6 默认路由，确认实际下一跳。
  2. 明确采用完整双栈接管，还是先在测试范围收敛为 IPv4；不要只关闭 mihomo 的 IPv6 DNS 结果就认为系统 IPv6 已关闭。
  3. 检查 LAN 到上游的转发权限、同接口转发和相关防火墙区域。不要为排障直接把所有区域的输入与转发都改为允许。
  4. 确认路由器管理地址、内网网段和代理服务器自身连接的绕行处理，避免把出口连接重新送回接管入口。

可以使用 nft list ruleset 查看防火墙规则，使用 ip rule show 和 ip route show table all 查看策略路由。命令输出应结合现有插件和固件判断；不要仅按某个固定表号或规则名称判断成功，因为不同实现的命名与优先级可能不同。

按层验证与安全回退

排障应从入口向出口逐层确认，每次只改变一个变量。能打开网页只说明某条路径可用，不能区分它是直连、显式代理还是透明代理。应结合终端路由、内核连接日志以及实际命中的策略一起判断。

现象优先检查下一步
终端无法打开旁路由管理页地址、掩码、地址冲突、输入规则先恢复局域网管理，不继续修改透明代理
IP 连通但域名解析失败53 与 1053 监听、dnsmasq 转发、解析环路分别验证 LAN DNS 入口和内核上游
本机显式代理正常，终端没有连接日志默认网关、IPv6、转发与接管规则核对流量是否真的进入旁路由
TCP 正常，游戏或语音异常UDP 接管、节点 UDP 支持、防火墙用对应协议复测，不以网页结果替代
重载防火墙后连接失效自动接管规则是否仍存在通过所属服务重建规则，检查服务启动顺序

回退顺序先终端、后服务

测试失败时，先把测试终端的默认网关恢复为 192.168.10.1，DNS 恢复为原来的有效设置，再停止新增服务并清理由该服务创建的接管规则。TUN 退出后的路由清理也需要检查，不能只删除二进制文件。若已修改全网 DHCP，应恢复原设置并让终端更新租约。

部署稳定后，再设置 procd 自启动、日志容量和配置更新流程。每次更新配置先运行测试，确认节点名称与策略组引用一致，再重载服务。涉及防火墙和路由的更新，还应重新验证一次终端 DNS、TCP、UDP、IPv6 与局域网访问。字段说明可查阅配置参考，基础导入与客户端操作可对照安装与配置教程。