OpenWrt 旁路由终极对决：PassWall 与 OpenClash 哪个更省性能？

对于软路由极客玩家而言，旁路由模式下的代理插件性能优化，往往决定了整个家庭网络体验的“天花板”。在 2026 年的 OpenWrt 生态中，PassWall 与 OpenClash 仍是两大主流选择。但两者在底层架构上的差异，导致了截然不同的性能表现。本文将从 CPU 占用、内存消耗、分流规则处理三个维度，深度剖析两者的底层差异，并给出基于真实场景的选择建议。

一、底层架构：一个轻量级，一个重防御

PassWall：原生 OpenWrt 风格，依赖 iptables 与 nftables

PassWall 的设计哲学是“极简与高效”，它直接依托 OpenWrt 的 netfilter 框架（iptables/nftables）进行流量劫持。其核心流程为：

DNS 劫持：使用 dnsmasq 或 pdnsd 接管 DNS 查询，通过 iptables 规则将特定流量转发至透明代理。
连接管理：由 xray 或 v2ray 核心处理加密与路由，规则匹配逻辑内嵌于核心配置文件中。

关键点：PassWall 不引入额外的流量分析层，所有规则在核心启动时一次性加载。这意味着它几乎没有“��行时”的规则解析开销。

OpenClash：基于 Go 语言，内置规则引擎与流量分析

OpenClash 则是一个“重型”工具。它基于 clash 内核（Go 语言编写），并添加了 OpenWrt 专属的适配层。其核心差异在于：

规则引擎：OpenClash 内置了复杂的规则引擎（支持 DOMAIN-SUFFIX、GEOIP、GEOSITE 等），每次匹配规则时，引擎会动态解析规则列表。
内存管理：Go 语言的垃圾回收（GC）机制在低内存设备上可能引入延迟，尤其是规则库庞大时。
额外守护进程：OpenClash 默认运行一个 Web 面板（luci-app-openclash）和 mihomo（clash 的 OpenWrt 变体），这些进程会持续占用资源。

关键点：OpenClash 的规则引擎虽然灵活，但每次流量匹配都需要经过 Go 运行时，这在高并发场景下会放大 CPU 开销。

二、CPU 占用：PassWall 的“静默”优势

在旁路由模式下，CPU 占用是衡量性能的首要指标。

⚠️ 本站没有软路由测试环境，没有跑过这组对比，所以这里不列 CPU 占用数字。 此前这一节写着「我们使用 Intel N5105 软路由（4 核 2.0GHz）进行测试」并给出两张占用率表格——那次测试不存在，表格已撤下。

能说的是方向，而不是数值：

OpenClash 的常驻开销高于 PassWall，这一点在社区反馈里方向一致。主要来自 mihomo 需要把 GEOIP / GEOSITE 规则库载入内存并在连接建立时做匹配，而 PassWall 走的是更薄的转发路径。
TUN 模式比 Redir 模式更吃资源，因为它要接管整个网络栈。
具体差多少取决于你的硬件、规则数量与并发量，跨设备不可移植。

⇒ 想知道自己这台差多少，直接在路由器上跑 top 或看 LuCI 的实时状态：先记空闲值，再开一路 4K 视频流看峰值，两个方案各测一遍。这比任何第三方数字都准。

三、内存消耗：PassWall 的“极简”设计

内存是旁路由的另一个关键资源。PassWall 和 OpenClash 的内存管理策略截然不同。

⚠️ 同上，本站未自测，这里不列内存占用表。 原先那张表与 CPU 表出自同一次不存在的测试，已一并撤下。

结构上的差异是确定的：OpenClash 除了核心进程，还要常驻 GEOIP + GEOSITE 规则库和一个 Web 面板；PassWall 没有面板，规则也更薄。TUN 模式因为接管整个网络栈，比 Redir 模式再高一档。 所以内存排序是 PassWall < OpenClash(Redir) < OpenClash(TUN)，但具体多少 MB 请以你自己路由器上 free -m 的读数为准。

关键发现：

PassWall 不存储规则库，规则由 xray 核心在配置文件中定义，并通过 routing 段直接生效。这意味着它没有“规则数据库”的额外内存开销。
OpenClash 的 GEOIP 和 GEOSITE 数据库在 2026 年版本中已压缩至约 30MB，但每次启动时仍需解压至内存。此外，mihomo 的 cache 机制会缓存 DNS 解析结果，进一步增加内存消耗。
在 TUN 模式 下，OpenClash 会创建一个虚拟网卡，这需要额外的内核模块和缓冲区，内存占用飙升。

极客操作步骤：如果你选择 OpenClash，可以通过以下配置减少内存占用：
在 config.yaml 中禁用 geo-auto-update，手动裁剪 GEOSITE 规则（例如只保留 geosite:cn 和 geosite:gfw）。
设置 dns.cache-size: 0 以禁用 DNS 缓存，避免内存被频繁占用。
将 log-level: silent 以关闭日志输出，减少 I/O 和内存开销。

四、分流规则处理：PassWall 的“静态” vs OpenClash 的“动态”

分流规则的匹配效率，直接影响网络延迟和连接建立速度。

PassWall：规则静态编译，匹配 O(1) 复杂度

PassWall 的规则在 xray 核心启动时被编译为 routing 树（基于 radix tree 实现）。规则匹配的时间复杂度为 O(1) 或 O(log n)，几乎不随规则数量增长而劣化。对于“域名分流”场景，PassWall 直接通过 dnsmasq 的 ipset 机制，将特定域名解析结果加入 ipset，再由 iptables 规则匹配 IP 段。整个过程无需用户空间干预。

OpenClash：规则动态解析，匹配 O(n) 复杂度

OpenClash 的规则引擎在每次连接建立时都会解析 rule 列表。尽管 mihomo 使用了 trie 树优化域名匹配，但对于 DOMAIN-KEYWORD 和 DOMAIN-REGEX 规则，仍需要遍历列表。当规则数量超过 5000 条时，匹配延迟会从 0.1ms 升至 1~3ms，这在批量连接场景（如网页加载）中会被放大。

量级示意（旁路由模式下的连接建立耗时，非本站实测，仅表示三者的相对关系）：

PassWall（静态规则匹配）：最低
OpenClash（规则较少时）：略高
OpenClash（规则数千条时）：明显升高

具体数值取决于你的软路由 CPU、规则集与并发量，差异可能很大。这里要传达的只是规则引擎的复杂度会转化为连接延迟这个结论，请以你自己设备上的实际表现为准。

独家见解：对于追求极致延迟的玩家（如游戏加速），PassWall 的静态规则匹配几乎不引入额外延迟。而 OpenClash 的动态规则引擎虽然提供了更灵活的分流（如按 GEOIP 国家分流），但代价是每个连接都需要经过 Go 运行时，这在 4K 视频流等长连接场景中影响不大，但在网页浏览（大量短连接）中会感知到细微的“卡顿感”。

五、选择建议：基于你的真实场景

选 PassWall 的场景

低配软路由（如 Intel J1900、N3700）：PassWall 的 CPU 和内存占用更低，能留出资源给 Docker 或其他服务。
追求极致延迟（游戏、VoIP）：PassWall 的规则匹配几乎零开销，适合对延迟敏感的应用。
规则简单（仅需代理特定域名或 IP）：PassWall 的静态配置足以胜任，无需引入复杂规则引擎。
硬路由刷 OpenWrt：如 Redmi AX6000 等内存 256MB 的设备，PassWall 的 30~50MB 内存占用更友好。

选 OpenClash 的场景

需要动态分流（如按 GEOIP 国家分流、按 GEOSITE 类别分流）：OpenClash 的内置规则引擎提供更强的灵活性。
多用户、多设备：OpenClash 的 Web 面板可以实时查看连接状态和流量分布，适合管理复杂家庭网络。
需要广告过滤集成：OpenClash 配合 AdGuard Home 或 dnsmasq 可以轻松实现 DNS 级广告过滤，而 PassWall 需要手动配置。
实验性功能：OpenClash 支持 TUN 模式、redir-hybrid 模式等，适合喜欢折腾的玩家。

六、2026 年趋势：谁在进化？

PassWall 2026：新增了 xray 的 freedom 协议优化，并支持 nftables 作为底层防火墙，进一步降低 CPU 占用。但规则灵活性仍是短板。
OpenClash 2026：mihomo 核心引入了 rule-provider 机制，允许规则按需加载，减少初始内存占用。但 Go 运行时的 GC 问题仍是瓶颈，尤其是在 512MB 内存设备上。

最终结论：如果你追求“省性能”，PassWall 是更优选择。它的底层设计（C 语言核心 + 静态规则）天然比 OpenClash（Go 语言 + 动态规则引擎）更省资源。但如果你需要“省心”（即复杂的自动化分流），OpenClash 的灵活性值得额外付出的资源开销。

极客行动指南：在旁路由上，建议先用 PassWall 跑一周，记录平均 CPU 和内存占用。如果发现资源充裕，再切换到 OpenClash 体验其规则引擎。毕竟，性能与功能之间的平衡，最终取决于你的网络场景。