路由器运行 Clash 内核：旁路由部署方式与资源要求

把 Clash 或 mihomo 内核运行在路由器上，核心目的不是把桌面客户端界面搬到网络设备，而是让路由器集中执行规则匹配、DNS 处理和流量转发。电视、游戏机、移动设备及其他不方便安装客户端的终端，可以通过网关或策略路由接入同一套规则。与此同时，路由器也会成为转发链路中的关键节点，配置错误可能影响整个局域网，因此部署前必须先明确拓扑、回退路径和设备负载。

本文所说的“路由器运行 Clash”主要指在 OpenWrt、衍生系统或通用 Linux 网关上运行 Clash 兼容内核。当前常见实现以 mihomo 为主，它延续了 Clash 配置结构，并提供 TUN、规则集、流量嗅探等扩展能力。不同管理插件对配置文件、服务脚本和防火墙规则进行了封装，但底层仍然离不开三个环节：内核监听端口、系统把目标流量送入内核、内核根据规则选择直连或代理出口。

主路由与旁路由的架构选择

主路由直接运行内核

主路由方案是让承担拨号、DHCP、NAT 和无线接入的设备同时运行 Clash 内核。终端的流量天然经过这台设备，转发路径最短，也较容易统一接管 DNS。对于硬件性能充足、系统可维护且已经熟悉防火墙规则的用户，这种方式结构清楚：上游接口连接运营商网络，下游接口连接局域网，代理程序只需要处理被防火墙导入的流量。

它的主要代价是故障影响范围较大。内核占满内存、防火墙规则加载失败或 DNS 服务端口冲突，都可能同时影响拨号、局域网解析与管理页面。系统升级还可能改变 nftables、iptables 或插件生成规则的方式。因此，主路由部署更适合能够通过串口、救援模式或备用设备恢复网络的环境，不宜把第一次实验直接放在唯一的家庭出口上。

旁路由作为独立网关

旁路由方案保留现有主路由负责拨号和基础网络，把 Clash 内核放到另一台设备。最常见的单臂旁路由与主路由处于同一局域网，例如主路由地址为 192.168.1.1，旁路由地址为 192.168.1.2。需要接入代理规则的终端把默认网关指向 192.168.1.2，旁路由完成策略处理后再把流量转发给主路由。

这种结构便于分批迁移。可以先只调整一台测试电脑的网关与 DNS，验证规则、UDP 和域名解析，再决定是否通过 DHCP 把旁路由下发给更多设备。旁路由停止服务时，终端可以把网关改回主路由，不必改动宽带拨号配置。维护边界也更明确：主路由保证基础联网，旁路由负责透明代理和附加策略。

单臂旁路由并不等于只填写一个网关地址。若旁路由直接转发数据包而不做源地址转换，返回流量可能由主路由直接发送给客户端，形成去程经过旁路由、回程绕过旁路由的非对称路径。具体是否产生问题取决于透明代理方式、连接跟踪和主路由路由表。常见处理方法是在旁路由出口执行适当的 NAT，或者在主路由添加指向客户端网段的明确路由，使往返路径符合设计。

双网口旁路网关

具备两个独立网口的设备还可以部署为串联网关：一个接口连接主路由，另一个接口连接单独的下游交换机或无线接入点。旁路由为下游建立独立子网，并承担该子网的 DHCP、转发和代理处理。与单臂结构相比，双网口方案的上下游边界清晰，返回流量通常会自然经过旁路由，也更容易针对整个子网实施策略。

代价是网络层级增加。端口映射、局域网发现、投屏和跨网段访问需要额外处理；如果主路由与旁路由都执行 NAT，还会形成双重 NAT。家庭设备依赖 mDNS 或广播发现时，应评估是否需要中继服务，而不是把所有跨网段问题归因于 Clash 内核。

CPU、内存与存储资源要求

Clash 内核对硬件的实际需求取决于吞吐量、规则规模、连接数量、协议加密开销和是否启用 TUN。不能只根据“内核可以启动”判断设备适用性。路由器还要为系统服务、DNS 缓存、防火墙连接跟踪和管理界面保留资源；一旦内存耗尽，服务重启或系统失去响应往往比单纯降速更难排查。

处理器与加密吞吐

CPU 决定规则匹配、加密传输和用户态转发的上限。较旧的单核 MIPS 设备可以承担轻量规则和少量连接，但在高速宽带、多个终端或复杂协议下容易成为瓶颈。现代 ARM64 或 x86_64 平台通常更适合持续运行 mihomo。选择内核文件时必须匹配系统架构，常见标识包括 arm64、armv7、mipsle 和 amd64；架构选错时，程序通常会直接报告无法执行。

硬件 NAT 或流量分载可能绕过透明代理所依赖的防火墙链。启用代理后速度异常时，应先确认软件流量分载、硬件流量分载与透明代理插件之间的兼容性。追求跑满接口速率之前，先以单台有线终端测试直连、规则代理和 UDP 三类流量，观察 CPU 单核占用是否持续接近上限。

内存与规则规模

64 MB 内存设备通常只适合非常精简的系统与小型配置，加载大型域名规则、GeoIP 数据、控制面板和多个附加服务后余量有限。128 MB 可以作为基础部署起点，但仍需控制规则集和并发服务。256 MB 或更多内存更适合同时启用 mihomo、DNS 增强模式、较大规则集和 Web 管理界面。连接数量多、规则提供者频繁更新或启用流量嗅探时，应继续增加余量。

Swap 可以缓解瞬时内存压力，但闪存交换速度较慢，也不应替代足够的物理内存。发现内核周期性退出时，可先查看系统日志是否出现内存回收或进程被终止的记录，再考虑缩减规则、关闭暂不使用的服务或迁移到资源更充足的设备。

存储空间与写入策略

内核本体、GeoIP 数据、规则集、订阅缓存和日志都会占用存储。路由器板载闪存较小时，可以把数据目录放在扩展存储或外置磁盘，但服务启动顺序必须保证挂载点先就绪。日志等级不宜长期保持 debug；详细日志适合短时定位问题，持续写入会占用空间，也会增加低速闪存的写入负担。

透明代理、TUN 与 DNS 的转发路径

路由器部署中最容易混淆的是“内核已运行”和“局域网流量已进入内核”。mixed-port、HTTP 端口或 SOCKS 端口只是监听入口，适合终端手动填写代理。要让未设置代理的设备自动按规则转发，还需要 REDIRECT、TProxy 或 TUN 等接管方式，以及对应的防火墙与策略路由。

REDIRECT 与 TProxy

REDIRECT 常用于接管 TCP 连接，配置相对直接，但对 UDP 和保留原始目标地址的场景存在限制。TProxy 可以处理 TCP 与 UDP，并通过策略路由把透明流量送到内核监听端口。它依赖防火墙标记、策略路由表和内核相关模块，任何一环缺失都可能表现为 TCP 可用而 UDP 超时，或者局域网访问被错误转发。

防火墙规则应排除本机管理地址、局域网保留网段、组播、广播和代理服务器自身连接。否则可能形成代理回环：内核建立的出站连接再次被透明规则捕获，最终导致连接失败或 CPU 占用升高。插件通常会生成这些排除项，但自定义脚本仍应逐项检查目标网段、进程或防火墙标记。

TUN 模式

TUN 模式通过虚拟网络接口接收 IP 流量，对需要同时处理 TCP、UDP 和复杂应用的环境更统一。mihomo 的 TUN 配置可以启用自动路由与接口探测，但路由器平台已有 WAN、LAN、策略路由和防火墙区域，自动生成的路由不一定符合现有拓扑。部署时应核对默认路由、TUN 路由表和局域网转发链，而不是只确认配置文件语法通过。

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

这段配置只表示 mihomo 侧启用 TUN、自动路由和 DNS 接管意图，不等于路由器防火墙已经允许 LAN 流量进入 TUN。不同固件、插件和网络管理组件对接口名称及规则链的处理不同。若管理插件已经负责生成 TUN 配置，再在主配置中重复声明，可能出现设置被覆盖或重复路由。

DNS 请求路径

规则依赖域名时，DNS 路径必须与代理策略一致。常见做法是让终端把 DNS 请求发送给路由器，由 dnsmasq 或其他本地解析服务转发到 mihomo 的 DNS 监听端口；另一种做法是通过防火墙接管局域网的 53 端口请求。前者结构容易理解，后者可以处理终端手动填写公共 DNS 的情况，但加密 DNS 应用不会经过普通 53 端口。

fake-ip 模式会为域名返回保留地址，并由内核根据映射恢复原始域名，便于执行域名规则。某些局域网服务、游戏平台或依赖真实地址判断的应用可能需要加入 fake-ip-filter。redir-host 模式更接近传统解析，但在匹配效率和特定连接流程上有所不同。切换模式后应清理终端 DNS 缓存，避免旧解析结果干扰测试。

DNS 循环是旁路由常见故障：mihomo 把查询交给 dnsmasq，而 dnsmasq 又把请求转回 mihomo。判断循环时可查看两个服务的监听端口和上游地址，确保解析链只有一个明确方向。旁路由自身查询、局域网客户端查询和代理节点域名解析也应分别考虑，节点域名必须能够在代理通道建立前完成解析。

IPv6 不应遗漏

只接管 IPv4 时，支持 IPv6 的终端可能直接通过主路由获得 IPv6 默认路由，造成部分连接绕开既定策略。可以完整配置 IPv6 转发与规则，也可以在部署初期暂缓向测试终端下发 IPv6 路由，但最终选择应与家庭网络需求一致。排查“同一网站时而按规则、时而直连”时，应分别检查 A 与 AAAA 记录、IPv4 和 IPv6 默认路由，以及内核配置中的 IPv6 开关。

旁路由部署步骤与验证顺序

1. 固定旁路由管理地址。

   为旁路由设置与主路由同网段且不与 DHCP 地址池冲突的静态地址，默认网关指向主路由。先确认旁路由自身可以更新时间、解析域名和访问软件源。

2. 安装匹配架构的内核与管理组件。

   确认 CPU 架构、系统 libc 环境和可用存储。先直接运行内核查看版本与配置加载结果，再交给服务脚本管理，避免把二进制兼容问题误判为防火墙故障。

3. 导入配置并验证出站。

   检查订阅生成的代理组、规则提供者和节点协议是否受当前内核支持。先通过显式 HTTP 或 SOCKS 代理测试内核出站；这一步成功后，再配置透明接管，可以把节点问题与路由问题分开。

4. 启用 IP 转发与透明代理。

   根据插件支持选择 TProxy 或 TUN，确认 LAN 到 WAN 的转发、防火墙区域和策略路由已经生效。不要同时启用多套透明代理脚本，以免重复标记或重复重定向。

5. 只迁移一台测试终端。

   手动把测试终端的网关和 DNS 指向旁路由，依次验证局域网访问、直连网站、规则代理、视频、语音通话与休眠唤醒。确认稳定后再修改 DHCP 下发内容。

6. 建立排除与分组策略。

   把打印机、NAS 管理地址、主路由页面和必要的局域网网段加入直连或绕过列表。对电视、游戏机和访客设备按源 IP 或 MAC 对应的固定地址分组，便于控制哪些终端进入代理。

7. 设置更新和恢复方式。

   订阅与规则集更新应避开设备负载高峰，并保留最近一次可用配置。服务启动失败时，可回退到基础配置，而主路由仍应维持 DHCP 与互联网出口。

验证透明代理时，不要只打开一个网页。浏览器可能使用缓存、HTTP/3 或自身的安全 DNS，结果不足以说明整个路径正确。更可靠的顺序是先检查终端获得的地址、网关和 DNS，再查看旁路由是否收到连接，随后确认规则命中与出站选择，最后测试 UDP、IPv6 和局域网访问。

ip address
ip route
ip rule
nft list ruleset
logread
ss -lntup

这些命令分别用于查看接口地址、路由表、策略规则、防火墙规则、系统日志和监听端口。使用 iptables 的系统可改查对应规则表。重点不是一次复制大量命令，而是沿数据路径定位：终端是否把包交给旁路由，防火墙是否标记或重定向，内核是否接收，出站是否发往主路由。

常见故障与维护边界

旁路由能联网，客户端不能联网

先检查客户端默认网关是否确实指向旁路由，以及旁路由是否开启 IPv4 转发。随后检查 LAN 转发区域、NAT 和回程路径。旁路由本机访问成功只说明它自身的 OUTPUT 流量可用，不能证明来自局域网的 FORWARD 流量已经获准通过。

网页可打开，游戏或语音应用超时

这通常需要检查 UDP。REDIRECT 方案可能只处理 TCP，TProxy 所需模块或策略路由也可能没有加载。查看规则是否把 UDP 送入内核，并确认所选节点协议和代理服务器能够承载对应 UDP 流量。若只是特定游戏异常，还应检查 NAT 类型、端口映射和游戏平台区域规则。

启用后局域网设备无法访问

透明代理排除列表可能遗漏私有地址、组播地址或本地服务端口。应确保常见局域网网段和路由器管理地址按本地路径转发。跨 VLAN 或跨子网访问还要检查防火墙区域，而不是简单地把全部私有地址永久直连；如果代理资源位于内部网段，仍需按实际拓扑建立精确规则。

CPU 占用高但吞吐量低

先关闭 debug 日志并观察单核负载，然后比较直连规则和代理规则的速度。如果直连也明显变慢，可能是透明转发关闭了硬件分载，或者包在防火墙链中被重复处理。如果只有代理连接较慢，则应检查加密协议、节点链路和 MTU。TUN 场景中的 MTU 不合适可能造成分片、部分网站卡顿或大文件连接停滞。

订阅更新后服务无法启动

常见原因包括配置字段与内核版本不匹配、规则提供者下载失败、YAML 缩进错误或数据目录权限变化。维护时应把“订阅原始内容”“插件生成后的运行配置”和“内核实际加载的配置”区分开。管理插件可能会合并模板、覆写端口或增加 DNS 字段，只查看订阅文件不一定能发现最终错误。

部署结论：先确定路径，再选择组件

路由器运行 Clash 内核的难点通常不在启动程序，而在于让流量按预期进入、离开并返回。主路由方案路径简洁，但维护风险集中；单臂旁路由适合渐进测试，需要处理 NAT 和回程；双网口网关边界明确，同时带来独立子网与跨网段管理成本。设备选择则应同时考虑 CPU 架构、单核性能、内存余量、规则规模和日志存储。

实际部署时，先用显式代理验证内核与节点，再启用透明转发；先让一台终端使用旁路由，再调整 DHCP；先确认 IPv4、TCP 和基础 DNS，再继续测试 UDP、TUN 与 IPv6。按照数据路径分层验证，可以把订阅、内核、防火墙、DNS 和局域网拓扑的问题分别定位，也能在配置变化后快速找到影响范围。