平台部署 预计阅读 15 分钟

路由器与旁路由部署 Clash 内核概览：OpenWrt、树莓派方案与 DNS 接管思路

梳理在主路由、旁路由两种拓扑下直跑 Clash 内核的整体思路，比较 OpenWrt 插件与树莓派裸机方案的取舍，并解释透明代理与 DNS 接管需要注意的地方。

先确定拓扑：主路由部署还是旁路由部署

把 Clash Meta（现常用内核名称为 mihomo）放进家庭网络，与在电脑上运行桌面客户端有明显区别。桌面客户端通常只处理本机流量；路由器方案需要同时处理转发、策略路由、DNS、IPv4 与 IPv6，并避免代理程序再次接管自己的上游连接。部署前先画清数据路径，比直接安装插件更重要。

方案一：Clash 内核运行在主路由

主路由直接负责拨号、DHCP、NAT、防火墙和透明代理。终端的默认网关天然指向这台设备，不需要逐台修改网络设置。以 OpenWrt 为例，路由器 LAN 地址可以是 192.168.10.1，DHCP 地址池为 192.168.10.100–192.168.10.249，客户端网关与 DNS 都由 DHCP 自动下发为 192.168.10.1。

  • 优点：流量入口统一，终端接入后即可应用规则，访客网络与独立 VLAN 也能分别控制。
  • 限制：代理、拨号、无线和 NAT 共享同一台设备的 CPU 与内存，配置错误可能影响整个局域网。
  • 适合：已有性能充足的 x86 OpenWrt、小型软路由，或四核 ARM64 路由设备。

方案二：Clash 内核运行在旁路由

旁路由与主路由位于同一 LAN。假设主路由为 192.168.10.1，旁路由为 192.168.10.2，旁路由自身的默认网关仍指向 192.168.10.1。需要代理的终端则把默认网关和 DNS 设置为 192.168.10.2。数据先进入旁路由，经透明代理判断后，再由主路由访问互联网。

这种单臂旁路由只有一个以太网接口，入站与出站流量会经过同一网卡。千兆网络中的一次互联网转发会在该接口上产生双向收发，但一般不会因此直接减半；实际瓶颈更多来自加密吞吐、规则匹配、USB 网卡质量和主路由回程路径。

比较项 主路由运行 旁路由运行
终端改动 通常不需要 需修改网关、DNS 或 DHCP 下发
故障影响 可能影响全网出口 可将网关切回主路由恢复
硬件选择 受路由设备规格约束 可使用树莓派、迷你主机或旧电脑
网络复杂度 转发路径直接 需检查回程、DHCP 与 IP 转发

OpenWrt 插件与树莓派裸机方案如何选择

OpenWrt 插件方案把内核、配置订阅、规则更新、防火墙接管和运行日志放在同一管理界面中。树莓派裸机方案则通常直接运行 mihomo 二进制，再用 systemd、nftables 和 dnsmasq 组成完整链路。两种方案的核心能力接近，差别主要在维护方式和故障定位粒度。

OpenWrt 插件方案

以 OpenWrt 24.10 系列和 OpenClash 管理界面为例，常见操作路径是「服务」→「OpenClash」→「配置文件订阅」，添加订阅地址并设置更新时间；随后进入「服务」→「OpenClash」→「插件设置」，选择运行模式、DNS 接管方式和访问控制。不同插件版本的菜单名称可能略有变化，但配置逻辑基本一致。

  1. 确认设备架构，例如 x86_64、aarch64_cortex-a53 或 mipsel_24kc，内核文件必须与架构匹配。
  2. 预留持久化空间。规则集、Geo 数据、日志与多个配置文件可能占用 80 MB 以上，仅有 16 MB 闪存的旧设备不适合长期保存大量数据。
  3. 先用规则模式启动，再分别测试 TCP、UDP 和 DNS；不要一次开启所有实验选项。
  4. 在「运行状态」或「调试日志」中确认配置解析完成、透明代理规则写入成功、DNS 监听端口未冲突。

插件适合希望通过 LuCI 管理订阅和访问控制的环境。升级 OpenWrt 前应记录插件设置、配置文件位置和自定义防火墙规则，因为防火墙 3 与防火墙 4 的底层实现不同。OpenWrt 22.03 之后主流版本采用 firewall4 与 nftables，旧教程中的大量 iptables 命令不能直接照搬。

树莓派或 Debian 裸机方案

树莓派 4B、树莓派 5、运行 Debian 12 的 ARM64 小主机都可以承担旁路由。建议使用 64 位系统、有线网口和稳定电源。树莓派 4B 的板载千兆网口适合常规家庭链路；若接入 USB 3.0 网卡，应确认芯片驱动稳定，并持续观察丢包与重连日志。

裸机方式可把 mihomo 放在 /usr/local/bin/mihomo，配置目录设为 /etc/mihomo，通过 systemd 常驻。以下服务文件展示必要结构，实际部署时还应创建专用用户，并让该用户拥有配置目录读写权限：

[Unit]
Description=mihomo proxy core
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
User=mihomo
Group=mihomo
ExecStart=/usr/local/bin/mihomo -d /etc/mihomo
Restart=on-failure
RestartSec=5s
LimitNOFILE=1048576
CapabilityBoundingSet=CAP_NET_ADMIN CAP_NET_BIND_SERVICE CAP_NET_RAW
AmbientCapabilities=CAP_NET_ADMIN CAP_NET_BIND_SERVICE CAP_NET_RAW
NoNewPrivileges=true

[Install]
WantedBy=multi-user.target

保存为 /etc/systemd/system/mihomo.service 后，可依次执行 systemctl daemon-reload、systemctl enable --now mihomo 和 journalctl -u mihomo -n 100。在写透明代理规则之前，先运行 mihomo -t -d /etc/mihomo 检查 YAML 语法。解析失败时不要继续写入开机防火墙规则，否则会出现流量已被重定向、内核却没有监听的断网状态。

透明代理：REDIRECT、TProxy 与 TUN 的差异

路由器部署的关键不是开放一个 HTTP 或 SOCKS 端口，而是让不支持手动代理的电视、游戏机和 IoT 设备也能被规则处理。常见实现包括 REDIRECT、TProxy 和 TUN。三者都需要正确排除局域网地址、内核自身连接与代理服务器地址，否则容易产生代理回环。

REDIRECT：主要处理 TCP

REDIRECT 会把经过防火墙的 TCP 连接重定向到 mihomo 的透明代理端口，例如 redir-port: 7892。实现简单，适合先验证网页与应用的 TCP 流量。它不能完整覆盖需要保留原始目标信息的全部 UDP 场景，因此语音、游戏和 QUIC 可能仍需 TProxy 或 TUN。

TProxy：同时处理 TCP 与 UDP

TProxy 通常使用独立端口，例如 tproxy-port: 7893，并依赖策略路由、数据包标记和内核模块。防火墙先为流量设置 fwmark，再通过 ip rule 与本地路由表把数据交给 mihomo。UDP 透明代理、DNS 查询和部分实时通信对规则完整性要求更高。

  • 必须排除回环地址、组播地址、局域网网段和路由器管理地址。
  • 必须让代理节点服务器的连接直达上游，不能再次进入透明代理。
  • 应排除 mihomo 进程自身流量，或通过路由标记区分已处理的数据包。
  • 需要检查内核是否包含 TPROXY、策略路由与 nftables 对应支持。

TUN：由虚拟网卡接收 IP 流量

TUN 模式会创建虚拟网络接口，由 mihomo 接收 IP 层流量。它在桌面系统上较常见，在旁路由上也可使用，但仍然需要转发、路由和 DNS 配合。一个基础配置可能包含以下部分：

mixed-port: 7890
redir-port: 7892
tproxy-port: 7893
allow-lan: true
bind-address: "*"
mode: rule
log-level: info
external-controller: 127.0.0.1:9090

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-redirect: true
  auto-detect-interface: true
  strict-route: true

mixed-port: 7890 用于显式 HTTP 与 SOCKS 代理测试；透明代理则使用 REDIRECT、TProxy 或 TUN 链路。管理接口绑定到 127.0.0.1:9090，可避免直接暴露到整个 LAN。若确实需要从其他设备访问控制接口，应通过防火墙仅允许管理网段，并设置控制器密钥。

TUN 的 auto-route 和 auto-redirect 能减少手工规则，但并不意味着所有路由器环境都可直接启用。OpenWrt 插件往往已有自己的防火墙管理逻辑，再叠加内核自动写路由可能造成重复接管。部署时应明确由插件、启动脚本还是 mihomo 本身负责路由，只保留一套控制来源。

DNS 接管：避免泄漏、污染与解析回环

透明代理只能决定连接如何转发，DNS 决定域名先解析成什么地址。若终端仍直接查询主路由或运营商 DNS，规则可能只能看到目标 IP，域名规则命中率会下降；如果 DNS 请求经代理与直连路径反复重入，还可能出现网页长时间等待、部分域名间歇失败等问题。

推荐的数据路径

旁路由可让 dnsmasq 监听 LAN 的 53 端口，再把请求转发到 mihomo 的 127.0.0.1:1053；也可以通过防火墙将终端发往其他 DNS 的 TCP/UDP 53 请求重定向到本机。mihomo 的 DNS 模块再根据域名规则选择直连解析器或代理解析器。

dns:
  enable: true
  listen: 0.0.0.0:1053
  ipv6: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "time.*.com"
    - "ntp.*.com"
  default-nameserver:
    - 223.5.5.5
    - 1.1.1.1
  nameserver:
    - https://dns.alidns.com/dns-query
    - https://1.1.1.1/dns-query

default-nameserver 使用 IP 地址，主要用于解析 DoH 服务器自身的域名，避免启动阶段出现先有域名还是先有 DNS 的依赖循环。nameserver 是实际查询入口。更复杂的配置还可通过 nameserver-policy 为指定域名选择不同解析器，但应先确认基础解析稳定，再增加策略。

fake-ip 与 redir-host 的取舍

fake-ip 会从保留地址池返回临时地址，mihomo 根据映射恢复原域名，因此域名规则匹配较直接。示例中的 198.18.0.1/16 属于基准测试保留网段，通常不会与公网地址冲突。局域网域名、打印机发现、NTP 和少数依赖真实 IP 的应用可加入 fake-ip-filter。

redir-host 返回真实解析结果，兼容路径直观，但透明代理阶段可能更多依赖嗅探或 IP 规则。遇到局域网设备发现失败时，不应立即关闭全部 DNS 接管，可以先检查目标域名并增加精确过滤项。

IPv6 需要单独验证

只接管 IPv4 而继续向终端下发 IPv6 默认路由，可能让支持 IPv6 的应用绕过既有策略。处理方式不是简单删除所有 AAAA 记录，而是根据网络能力选择：完整代理 IPv6、让指定 IPv6 网段直连，或在尚未准备好时停止向测试网段下发 IPv6 默认路由。至少应分别执行 A、AAAA 查询，并测试一个仅 IPv4 与一个支持 IPv6 的站点。

旁路由落地步骤：从单台设备测试到全网接管

旁路由适合分阶段上线。先让一台电脑使用旁路由，再逐步扩展到独立设备组，比直接修改全网 DHCP 更容易定位问题。以下示例继续使用主路由 192.168.10.1、旁路由 192.168.10.2。

  1. 固定旁路由地址：将 LAN 地址设为 192.168.10.2/24，默认网关设为 192.168.10.1，避免地址落入主路由 DHCP 动态分配范围。
  2. 开启 IP 转发：Linux 可检查 sysctl net.ipv4.ip_forward，结果应为 1。需要 IPv6 转发时再单独检查对应参数。
  3. 验证普通转发：暂不开 Clash，让测试电脑把网关改为 192.168.10.2。如果此时无法联网，应先修复路由、NAT 或回程，不能把问题归因于代理配置。
  4. 验证显式代理：启动 mihomo 后，在测试电脑手动设置 HTTP 或 SOCKS 代理为 192.168.10.2:7890，确认节点、订阅和规则可以工作。
  5. 开启透明代理：先处理 TCP，再测试 UDP。观察日志中的入站类型、目标地址、命中规则与最终代理组。
  6. 接管 DNS：把测试电脑 DNS 改为 192.168.10.2，使用 nslookup 或 dig 检查响应服务器、耗时和 A、AAAA 结果。
  7. 扩大范围：确认稳定后，在主路由 DHCP 中把指定终端的网关和 DNS 下发为旁路由地址，或通过 VLAN 仅接管一个测试网段。

测试时应记录具体数值。局域网到旁路由的有线延迟通常应低于 1 ms；DNS 首次查询若持续超过 2 秒，需要检查 DoH 建连、上游路由和回环；规则切换后可连续进行 20 次解析与连接测试，确认不存在间歇超时。速度测试只能反映某个时间点的吞吐，不能替代丢包、延迟和持续连接测试。

DHCP 下发的两种方式

  • 全网下发：DHCP 选项 3 指定默认网关为 192.168.10.2，选项 6 指定 DNS 为 192.168.10.2。适合旁路由已稳定运行的网络。
  • 按设备下发：为测试电脑、电视或游戏机建立静态租约，只对这些设备分配旁路由网关与 DNS。办公设备与管理设备继续走主路由。

部分家用主路由只允许统一下发网关，不能按终端设置。这时可以手动配置测试设备，或划分独立访客网络。不要使用重复 NAT、桥接、策略路由多种方法同时修补一个问题，链路层次越多，回程不一致越难定位。

常见故障与检查顺序

终端能访问旁路由，但不能访问互联网

先停止 mihomo 和透明代理规则，只检查基础转发。确认旁路由默认路由指向主路由，IP 转发已开启，主路由知道如何返回终端网段。单臂旁路由通常仍在同一 /24 网段，若使用独立子网，则需要在主路由增加静态路由，或在旁路由执行源地址转换。

网页可打开，游戏或语音失败

这通常说明 TCP 路径正常，但 UDP 没有进入代理，或代理节点不支持所需 UDP。检查 TProxy 或 TUN 是否启用、UDP 规则是否写入、防火墙是否加载相关模块，并查看连接日志中是否出现 UDP 入站。QUIC 使用 UDP 443，关闭浏览器 QUIC 只能用于定位，不能代替正确的 UDP 配置。

国内站点绕远或局域网设备无法访问

检查规则顺序。局域网网段、路由器管理地址和私有地址应在兜底代理规则之前直连。规则从上到下匹配，末尾的 MATCH 会接收所有未命中请求。若局域网域名使用 .lan 或 .local，还应同步检查 fake-ip 过滤和本地 DNS 转发。

重启后短暂断网

可能是防火墙规则先加载，而 mihomo 尚未完成配置解析和 DNS 初始化。systemd 服务应等待 network-online.target，防火墙脚本也应在内核监听端口可用后再接管流量。还要确认配置、Geo 数据与缓存位于持久化存储，而不是重启后清空的临时目录。

CPU 占用高或吞吐明显下降

先区分加密性能、规则处理和日志写入。将日志级别保持为 info，故障排查时短暂切换到 debug；检查是否启用了大量正则规则、持续连接嗅探或重复 DNS 查询。千兆宽带下，低频双核路由器可能先达到单核瓶颈，而内存占用正常并不代表转发性能充足。

部署结论：先保证路由正确，再扩展规则能力

OpenWrt 主路由部署的优势是入口统一，适合硬件性能充足、希望集中管理全网策略的环境。OpenWrt 旁路由保留了 LuCI 与插件管理能力，故障时也能把终端网关切回主路由。树莓派或 Debian 裸机方案提供更明确的 systemd、nftables 和日志控制，适合愿意维护 Linux 网络栈的用户。

无论选择哪一种方案，可靠顺序都是：先确认普通三层转发，再验证 7890 显式代理，然后启用 TCP 透明代理，继续补充 UDP 与 DNS，最后处理 IPv6 和全网 DHCP 下发。Clash Meta 或 mihomo 只是数据路径中的一个组件，真正决定稳定性的仍是网关、回程、防火墙与 DNS 是否保持一致。

下载 Clash 客户端