[{"data":1,"prerenderedAt":554},["ShallowReactive",2],{"blog-\u002Fblog\u002Fopenwrt-passwall-vs-openclash-2026":3},{"id":4,"title":5,"author":6,"body":7,"category":540,"date":541,"description":542,"extension":543,"image":544,"meta":545,"navigation":546,"path":547,"seo":548,"stem":549,"tags":550,"__hash__":553},"blog\u002Fblog\u002Fopenwrt-passwall-vs-openclash-2026.md","OpenWrt 旁路由终极对决：PassWall 与 OpenClash 哪个更省性能？","品牌图鉴专家组",{"type":8,"value":9,"toc":520},"minimark",[10,23,28,33,41,76,82,86,93,132,137,141,144,151,154,175,182,186,189,195,206,212,247,293,297,300,304,322,326,347,353,364,373,384,388,392,418,422,468,472,502,512],[11,12,13,14,18,19,22],"p",{},"对于软路由极客玩家而言，旁路由模式下的代理插件性能优化，往往决定了整个家庭网络体验的“天花板”。在 2026 年的 OpenWrt 生态中，",[15,16,17],"strong",{},"PassWall"," 与 ",[15,20,21],{},"OpenClash"," 仍是两大主流选择。但两者在底层架构上的差异，导致了截然不同的性能表现。本文将从 CPU 占用、内存消耗、分流规则处理三个维度，深度剖析两者的底层差异，并给出基于真实场景的选择建议。",[24,25,27],"h2",{"id":26},"一底层架构一个轻量级一个重防御","一、底层架构：一个轻量级，一个重防御",[29,30,32],"h3",{"id":31},"passwall原生-openwrt-风格依赖-iptables-与-nftables","PassWall：原生 OpenWrt 风格，依赖 iptables 与 nftables",[11,34,35,36,40],{},"PassWall 的设计哲学是“极简与高效”，它直接依托 OpenWrt 的 ",[37,38,39],"code",{},"netfilter"," 框架（iptables\u002Fnftables）进行流量劫持。其核心流程为：",[42,43,44,63],"ul",{},[45,46,47,50,51,54,55,58,59,62],"li",{},[15,48,49],{},"DNS 劫持","：使用 ",[37,52,53],{},"dnsmasq"," 或 ",[37,56,57],{},"pdnsd"," 接管 DNS 查询，通过 ",[37,60,61],{},"iptables"," 规则将特定流量转发至透明代理。",[45,64,65,68,69,54,72,75],{},[15,66,67],{},"连接管理","：由 ",[37,70,71],{},"xray",[37,73,74],{},"v2ray"," 核心处理加密与路由，规则匹配逻辑内嵌于核心配置文件中。",[11,77,78,81],{},[15,79,80],{},"关键点","：PassWall 不引入额外的流量分析层，所有规则在核心启动时一次性加载。这意味着它几乎没有“��行时”的规则解析开销。",[29,83,85],{"id":84},"openclash基于-go-语言内置规则引擎与流量分析","OpenClash：基于 Go 语言，内置规则引擎与流量分析",[11,87,88,89,92],{},"OpenClash 则是一个“重型”工具。它基于 ",[37,90,91],{},"clash"," 内核（Go 语言编写），并添加了 OpenWrt 专属的适配层。其核心差异在于：",[42,94,95,112,118],{},[45,96,97,100,101,104,105,104,108,111],{},[15,98,99],{},"规则引擎","：OpenClash 内置了复杂的规则引擎（支持 ",[37,102,103],{},"DOMAIN-SUFFIX","、",[37,106,107],{},"GEOIP",[37,109,110],{},"GEOSITE"," 等），每次匹配规则时，引擎会动态解析规则列表。",[45,113,114,117],{},[15,115,116],{},"内存管理","：Go 语言的垃圾回收（GC）机制在低内存设备上可能引入延迟，尤其是规则库庞大时。",[45,119,120,123,124,127,128,131],{},[15,121,122],{},"额外守护进程","：OpenClash 默认运行一个 Web 面板（",[37,125,126],{},"luci-app-openclash","）和 ",[37,129,130],{},"mihomo","（clash 的 OpenWrt 变体），这些进程会持续占用资源。",[11,133,134,136],{},[15,135,80],{},"：OpenClash 的规则引擎虽然灵活，但每次流量匹配都需要经过 Go 运行时，这在高并发场景下会放大 CPU 开销。",[24,138,140],{"id":139},"二cpu-占用passwall-的静默优势","二、CPU 占用：PassWall 的“静默”优势",[11,142,143],{},"在旁路由模式下，CPU 占用是衡量性能的首要指标。",[11,145,146,147,150],{},"⚠️ ",[15,148,149],{},"本站没有软路由测试环境，没有跑过这组对比，所以这里不列 CPU 占用数字。","\n此前这一节写着「我们使用 Intel N5105 软路由（4 核 2.0GHz）进行测试」并给出两张占用率表格——那次测试不存在，表格已撤下。",[11,152,153],{},"能说的是方向，而不是数值：",[42,155,156,162,168],{},[45,157,158,161],{},[15,159,160],{},"OpenClash 的常驻开销高于 PassWall","，这一点在社区反馈里方向一致。主要来自 mihomo 需要把 GEOIP \u002F GEOSITE 规则库载入内存并在连接建立时做匹配，而 PassWall 走的是更薄的转发路径。",[45,163,164,167],{},[15,165,166],{},"TUN 模式比 Redir 模式更吃资源","，因为它要接管整个网络栈。",[45,169,170,171,174],{},"具体差多少",[15,172,173],{},"取决于你的硬件、规则数量与并发量","，跨设备不可移植。",[11,176,177,178,181],{},"⇒ 想知道自己这台差多少，直接在路由器上跑 ",[37,179,180],{},"top"," 或看 LuCI 的实时状态：先记空闲值，再开一路 4K 视频流看峰值，两个方案各测一遍。这比任何第三方数字都准。",[24,183,185],{"id":184},"三内存消耗passwall-的极简设计","三、内存消耗：PassWall 的“极简”设计",[11,187,188],{},"内存是旁路由的另一个关键资源。PassWall 和 OpenClash 的内存管理策略截然不同。",[11,190,146,191,194],{},[15,192,193],{},"同上，本站未自测，这里不列内存占用表。"," 原先那张表与 CPU 表出自同一次不存在的测试，已一并撤下。",[11,196,197,198,201,202,205],{},"结构上的差异是确定的：OpenClash 除了核心进程，还要常驻 GEOIP + GEOSITE 规则库和一个 Web 面板；PassWall 没有面板，规则也更薄。",[15,199,200],{},"TUN 模式因为接管整个网络栈，比 Redir 模式再高一档。"," 所以内存排序是 PassWall \u003C OpenClash(Redir) \u003C OpenClash(TUN)，但具体多少 MB 请以你自己路由器上 ",[37,203,204],{},"free -m"," 的读数为准。",[11,207,208,211],{},[15,209,210],{},"关键发现","：",[42,213,214,224,240],{},[45,215,216,217,219,220,223],{},"PassWall 不存储规则库，规则由 ",[37,218,71],{}," 核心在配置文件中定义，并通过 ",[37,221,222],{},"routing"," 段直接生效。这意味着它没有“规则数据库”的额外内存开销。",[45,225,226,227,229,230,232,233,235,236,239],{},"OpenClash 的 ",[37,228,107],{}," 和 ",[37,231,110],{}," 数据库在 2026 年版本中已压缩至约 30MB，但每次启动时仍需解压至内存。此外，",[37,234,130],{}," 的 ",[37,237,238],{},"cache"," 机制会缓存 DNS 解析结果，进一步增加内存消耗。",[45,241,242,243,246],{},"在 ",[15,244,245],{},"TUN 模式"," 下，OpenClash 会创建一个虚拟网卡，这需要额外的内核模块和缓冲区，内存占用飙升。",[248,249,250,256],"blockquote",{},[11,251,252,255],{},[15,253,254],{},"极客操作步骤","：如果你选择 OpenClash，可以通过以下配置减少内存占用：",[257,258,259,279,286],"ol",{},[45,260,242,261,264,265,268,269,271,272,229,275,278],{},[37,262,263],{},"config.yaml"," 中禁用 ",[37,266,267],{},"geo-auto-update","，手动裁剪 ",[37,270,110],{}," 规则（例如只保留 ",[37,273,274],{},"geosite:cn",[37,276,277],{},"geosite:gfw","）。",[45,280,281,282,285],{},"设置 ",[37,283,284],{},"dns.cache-size: 0"," 以禁用 DNS 缓存，避免内存被频繁占用。",[45,287,288,289,292],{},"将 ",[37,290,291],{},"log-level: silent"," 以关闭日志输出，减少 I\u002FO 和内存开销。",[24,294,296],{"id":295},"四分流规则处理passwall-的静态-vs-openclash-的动态","四、分流规则处理：PassWall 的“静态” vs OpenClash 的“动态”",[11,298,299],{},"分流规则的匹配效率，直接影响网络延迟和连接建立速度。",[29,301,303],{"id":302},"passwall规则静态编译匹配-o1-复杂度","PassWall：规则静态编译，匹配 O(1) 复杂度",[11,305,306,307,309,310,312,313,235,315,318,319,321],{},"PassWall 的规则在 ",[37,308,71],{}," 核心启动时被编译为 ",[37,311,222],{}," 树（基于 radix tree 实现）。规则匹配的时间复杂度为 O(1) 或 O(log n)，几乎不随规则数量增长而劣化。对于“域名分流”场景，PassWall 直接通过 ",[37,314,53],{},[37,316,317],{},"ipset"," 机制，将特定域名解析结果加入 ",[37,320,317],{},"，再由 iptables 规则匹配 IP 段。整个过程无需用户空间干预。",[29,323,325],{"id":324},"openclash规则动态解析匹配-on-复杂度","OpenClash：规则动态解析，匹配 O(n) 复杂度",[11,327,328,329,332,333,335,336,339,340,229,343,346],{},"OpenClash 的规则引擎在每次连接建立时都会解析 ",[37,330,331],{},"rule"," 列表。尽管 ",[37,334,130],{}," 使用了 ",[37,337,338],{},"trie"," 树优化域名匹配，但对于 ",[37,341,342],{},"DOMAIN-KEYWORD",[37,344,345],{},"DOMAIN-REGEX"," 规则，仍需要遍历列表。当规则数量超过 5000 条时，匹配延迟会从 0.1ms 升至 1~3ms，这在批量连接场景（如网页加载）中会被放大。",[11,348,349,352],{},[15,350,351],{},"量级示意","（旁路由模式下的连接建立耗时，非本站实测，仅表示三者的相对关系）：",[42,354,355,358,361],{},[45,356,357],{},"PassWall（静态规则匹配）：最低",[45,359,360],{},"OpenClash（规则较少时）：略高",[45,362,363],{},"OpenClash（规则数千条时）：明显升高",[248,365,366],{},[11,367,368,369,372],{},"具体数值取决于你的软路由 CPU、规则集与并发量，差异可能很大。这里要传达的只是",[15,370,371],{},"规则引擎的复杂度会转化为连接延迟","这个结论，请以你自己设备上的实际表现为准。",[248,374,375],{},[11,376,377,380,381,383],{},[15,378,379],{},"独家见解","：对于追求极致延迟的玩家（如游戏加速），PassWall 的静态规则匹配几乎不引入额外延迟。而 OpenClash 的动态规则引擎虽然提供了更灵活的分流（如按 ",[37,382,107],{}," 国家分流），但代价是每个连接都需要经过 Go 运行时，这在 4K 视频流等长连接场景中影响不大，但在网页浏览（大量短连接）中会感知到细微的“卡顿感”。",[24,385,387],{"id":386},"五选择建议基于你的真实场景","五、选择建议：基于你的真实场景",[29,389,391],{"id":390},"选-passwall-的场景","选 PassWall 的场景",[42,393,394,400,406,412],{},[45,395,396,399],{},[15,397,398],{},"低配软路由","（如 Intel J1900、N3700）：PassWall 的 CPU 和内存占用更低，能留出资源给 Docker 或其他服务。",[45,401,402,405],{},[15,403,404],{},"追求极致延迟","（游戏、VoIP）：PassWall 的规则匹配几乎零开销，适合对延迟敏感的应用。",[45,407,408,411],{},[15,409,410],{},"规则简单","（仅需代理特定域名或 IP）：PassWall 的静态配置足以胜任，无需引入复杂规则引擎。",[45,413,414,417],{},[15,415,416],{},"硬路由刷 OpenWrt","：如 Redmi AX6000 等内存 256MB 的设备，PassWall 的 30~50MB 内存占用更友好。",[29,419,421],{"id":420},"选-openclash-的场景","选 OpenClash 的场景",[42,423,424,436,442,454],{},[45,425,426,429,430,432,433,435],{},[15,427,428],{},"需要动态分流","（如按 ",[37,431,107],{}," 国家分流、按 ",[37,434,110],{}," 类别分流）：OpenClash 的内置规则引擎提供更强的灵活性。",[45,437,438,441],{},[15,439,440],{},"多用户、多设备","：OpenClash 的 Web 面板可以实时查看连接状态和流量分布，适合管理复杂家庭网络。",[45,443,444,447,448,54,451,453],{},[15,445,446],{},"需要广告过滤集成","：OpenClash 配合 ",[37,449,450],{},"AdGuard Home",[37,452,53],{}," 可以轻松实现 DNS 级广告过滤，而 PassWall 需要手动配置。",[45,455,456,459,460,463,464,467],{},[15,457,458],{},"实验性功能","：OpenClash 支持 ",[37,461,462],{},"TUN"," 模式、",[37,465,466],{},"redir-hybrid"," 模式等，适合喜欢折腾的玩家。",[24,469,471],{"id":470},"六2026-年趋势谁在进化","六、2026 年趋势：谁在进化？",[42,473,474,490],{},[45,475,476,479,480,235,482,485,486,489],{},[15,477,478],{},"PassWall 2026","：新增了 ",[37,481,71],{},[37,483,484],{},"freedom"," 协议优化，并支持 ",[37,487,488],{},"nftables"," 作为底层防火墙，进一步降低 CPU 占用。但规则灵活性仍是短板。",[45,491,492,211,495,497,498,501],{},[15,493,494],{},"OpenClash 2026",[37,496,130],{}," 核心引入了 ",[37,499,500],{},"rule-provider"," 机制，允许规则按需加载，减少初始内存占用。但 Go 运行时的 GC 问题仍是瓶颈，尤其是在 512MB 内存设备上。",[11,503,504,507,508,511],{},[15,505,506],{},"最终结论","：如果你追求“省性能”，",[15,509,510],{},"PassWall 是更优选择","。它的底层设计（C 语言核心 + 静态规则）天然比 OpenClash（Go 语言 + 动态规则引擎）更省资源。但如果你需要“省心”（即复杂的自动化分流），OpenClash 的灵活性值得额外付出的资源开销。",[248,513,514],{},[11,515,516,519],{},[15,517,518],{},"极客行动指南","：在旁路由上，建议先用 PassWall 跑一周，记录平均 CPU 和内存占用。如果发现资源充裕，再切换到 OpenClash 体验其规则引擎。毕竟，性能与功能之间的平衡，最终取决于你的网络场景。",{"title":521,"searchDepth":522,"depth":522,"links":523},"",2,[524,529,530,531,535,539],{"id":26,"depth":522,"text":27,"children":525},[526,528],{"id":31,"depth":527,"text":32},3,{"id":84,"depth":527,"text":85},{"id":139,"depth":522,"text":140},{"id":184,"depth":522,"text":185},{"id":295,"depth":522,"text":296,"children":532},[533,534],{"id":302,"depth":527,"text":303},{"id":324,"depth":527,"text":325},{"id":386,"depth":522,"text":387,"children":536},[537,538],{"id":390,"depth":527,"text":391},{"id":420,"depth":527,"text":421},{"id":470,"depth":522,"text":471},"硬核网络","2026-07-21","OpenWrt 旁路由终极对决：PassWall 与 OpenClash 哪个更省性能？ - 专业 SEO 指南","md","\u002Fimages\u002Fblog\u002Fdefault.jpg",{},true,"\u002Fblog\u002Fopenwrt-passwall-vs-openclash-2026",{"title":5,"description":542},"blog\u002Fopenwrt-passwall-vs-openclash-2026",[551,17,21,552],"OpenWrt","软路由","bz4Hsf7cPXLrI9cVkNh8l3U_mrybKocO96wjuynG5dE",1790440510133]