注：本文在大模型辅助下完成。

2026年2月，NGINX官方博客发布了一篇颇为罕见的技术文章：《The Complex Dance of Lua and NGINX: Power, Pitfalls, and Performance Challenges》。

文章没有宣传新功能，也没有介绍最佳实践，而是系统梳理了Lua嵌入NGINX后可能带来的稳定性、性能和安全风险。

对于长期关注网关架构演进的人来说，这篇文章真正值得关注的并不是Lua本身，而是它折射出的一个更深层次的问题：

现代网关究竟应该走脚本驱动路线，还是编译型路线？

这不仅是OpenResty与BFE之间的差异，也是过去十年乃至未来十年网关架构持续演进的核心方向。

原文链接：The Complex Dance of Lua and NGINX: Power, Pitfalls, and Performance Challenges

一、为什么NGINX官方突然开始讨论Lua风险？

过去十多年里，Lua几乎成为NGINX生态最成功的扩展机制之一。

借助OpenResty提供的Lua运行时能力，开发者可以在请求处理链路中动态实现：

• 路由决策

• 灰度发布

• 限流熔断

• 鉴权认证

• 动态配置

• 流量治理

在这种模式下，NGINX从一个反向代理逐渐演化为一个可编程平台。

也正因为如此，诞生了一批著名的网关产品：

• Kong

• Apache APISIX

• ingress-nginx

• 多家互联网公司的自研网关

Lua给网关带来了前所未有的灵活性。

但与此同时，也把脚本语言运行时引入到了整个流量入口层。

而流量入口恰恰又是系统中最敏感、影响面最大的基础设施之一。

于是，一个长期存在但经常被忽视的问题开始浮现：

当灵活性与可预测性发生冲突时，网关应该优先选择哪一个？

NGINX官方这篇文章，本质上是在回答这个问题。

二、NGINX官方总结的六类风险

文章系统总结了Lua嵌入NGINX后常见的六类问题。

1. 请求生命周期错乱

NGINX采用严格的阶段化处理模型：

rewrite ↓ access ↓ content ↓ header filter ↓ body filter ↓ log

Lua可以插入其中任何阶段。

但如果在中间阶段提前退出，可能导致：

• 日志记录异常

• Header状态不一致

• 请求变量失效

• 后续模块行为异常

NGINX官方特别指出一个极易被忽略的细节：在access_by_lua阶段使用ngx.exit(200)会中断后续的请求处理阶段（如 content、balancer），但不会中断响应处理阶段（如 header filter、body filter、logging）。这意味着请求"已经结束"，但日志可能没记、Header可能泄露——这种问题往往在线上运行很久才会被发现，排查极为困难。

2. 共享运行时带来的并发风险

Lua运行在Worker共享VM中。

官方特别强调：

全局变量污染

多个请求可能共享同一个状态。

阻塞Worker

错误使用标准Lua I/O会阻塞整个Worker。NGINX官方原文使用了极为严厉的措辞：使用标准Lua I/O是Lua嵌入NGINX的"头号大罪"（Cardinal Sin），会直接导致整台网关实例的所有并发请求出现高延迟和超时。

Cosocket泄漏

连接管理不当会造成资源泄漏。一个常见场景是：超时或错误发生后，cosocket连接未能正确释放回keepalive池，下一个请求可能拿到过期或损坏的连接。

这些问题都会直接影响整台网关实例。

3. 动态配置系统复杂度失控

以ingress-nginx为例。

大量动态逻辑通过Lua实现。

可能出现：

• shared dict耗尽

• reload频繁抖动

• worker回收异常

• 僵尸进程积累

NGINX官方特别警告：Lua驱动的频繁动态更新可能导致NGINX master进程无法正确回收worker子进程，导致僵尸进程在宿主机上持续累积，消耗系统资源并使进程管理复杂化。系统规模越大，问题越明显。

4. 内存泄漏与负载倾斜

官方提到：

• Lua闭包泄漏

• 第三方模块泄漏

• Pod热点问题

这些问题不会立刻暴露。

但会在长期运行中逐渐放大。

5. 配置注入与安全漏洞

官方引用了多个ingress-nginx历史漏洞。

包括：

• CVE-2021-25742

• CVE-2025-1097

• CVE-2025-1098

• CVE-2025-24514

共同特点都是：

配置最终被解释执行。

当配置变成代码时，攻击面也随之扩大。

NGINX官方详细分析了CVE-2021-25742的攻击链：用户通过自定义代码片段注解注入任意Lua代码，获取ingress-nginx服务账户令牌，进而访问集群中所有命名空间的Secret，实现对整个Kubernetes集群的接管。这充分说明：当配置变成可执行代码，并且受用户输入影响时，传统的安全边界就会失效。

6. 第三方生态稳定性不可控

Lua生态丰富。

但同时也意味着：

• 版本兼容问题

• 模块质量差异

• 运维复杂度增加

基础设施系统需要长期稳定运行，而不是快速迭代。

这是两种不同的诉求。

三、这其实是两条不同的网关技术路线

很多人看完NGINX文章后，会得出一个简单结论：

Lua有问题。

实际上并不准确。

真正值得关注的是：

网关领域一直存在两条不同的技术路线。

路线一：脚本驱动型网关

代表项目：

• OpenResty

• Kong

• Apache APISIX

• ingress-nginx

核心思想：

保持内核简单高效，

将业务能力放到脚本层实现。

优势非常明显：

• 功能开发快

• 灵活性高

• 扩展成本低

很多互联网公司都从这条路线获益。

但代价同样存在：

• 调试复杂

• 状态难追踪

• 故障边界模糊

• 运维成本逐渐增加

随着系统规模扩大，这些问题会越来越明显。

路线二：编译型网关

代表项目：

• Envoy

• MOSN

• BFE

核心思想则完全不同：

尽可能将问题暴露在编译期和配置加载阶段。

特点包括：

• 强类型

• 显式依赖

• 声明式配置

• 严格生命周期管理

优势：

• 行为可预测

• 故障边界清晰

• 更适合大规模基础设施

代价：

• 灵活性下降

• 开发成本更高

• 扩展周期更长

本质上，这是另一种工程权衡。

四、为什么连Envoy也在降低脚本的重要性？

很多人会问：

既然Lua这么灵活，为什么近年来越来越多大型平台选择Envoy？

原因很简单。

Envoy虽然支持Lua Filter。

但Lua从来不是其核心设计。

Envoy真正强调的是：

• 声明式配置

• 数据面稳定性

• 类型安全

• 可观测性

Lua只是补充能力。

而不是核心能力。

事实上，近年来Envoy社区投入更多精力的是：

• WASM

• xDS

• Gateway API

• Service Mesh

而不是进一步强化Lua。

这背后体现的是同一种思路：

流量入口层应该尽量减少不可预测行为。

从这个角度看，NGINX官方文章与Envoy的发展方向其实是一致的。

五、BFE的选择：追求可预测性

BFE从设计之初就做出了一个选择：

网关首先是基础设施，其次才是应用平台。

因此BFE更关注：

• 稳定性

• 可预测性

• 故障隔离

• 长周期运维成本

而不是运行时脚本能力。

这也是为什么BFE采用：

• Go实现核心逻辑

• 声明式配置

• 编译型插件体系

其目标并不是证明Go优于Lua。

而是尽可能减少运行时的不确定因素。

例如：

当配置加载时：

• 类型检查已经完成

• 依赖关系已经确定

• 生命周期已经明确

而不是等到生产流量进入后才发现问题。

对于基础设施而言：

越早发现问题，代价越低。

一个具体的例子：2021年B站那场著名的网关事故，根因是一个字符串"0"被错误地当成数值0使用，导致Lua代码进入死循环，所有Worker CPU 100%、全站雪崩。在BFE的Go实现中，这种类型不匹配在编译阶段就会被拒绝，根本不可能在生产环境触发。这正是"将问题暴露在编译期"的实际价值。

六、基础设施的第一原则：可预测性

过去很多年里，行业一直在追求灵活性。

从脚本语言到动态配置。

从热更新到运行时扩展。

这些技术推动了业务创新。

但随着系统规模不断扩大，另一个问题开始变得越来越重要：

当一个组件承载全站流量时，它是否仍然能够被预测？

对于业务系统：

灵活性通常更重要。

对于基础设施：

可预测性往往更重要。

对于普通应用：

运行时扩展是优势。

对于网关：

运行时扩展本身就可能成为风险源。

对于单个服务：

一次故障影响有限。

对于流量入口：

一次故障可能影响整个系统。

因此，网关架构的演进方向，最终不是追求无限灵活，而是在灵活性和可预测性之间寻找平衡。

七、一个值得关注的行业趋势

如果回顾过去十年的网关发展历程，会发现一个有趣的现象。

早期行业关注的是：

• 如何更快扩展功能

• 如何动态编程

• 如何减少Reload

而近年来越来越多项目开始关注：

• 类型安全

• 声明式配置

• 编译期校验

• 故障隔离

• 沙箱执行

无论是：

• Envoy

• Gateway API

• Service Mesh

• WASM扩展体系

还是新兴的AI Gateway

都在朝着同一个方向演进：

将不可预测行为限制在更小的范围内。

从这个意义上说，NGINX官方这篇文章讨论的并不仅仅是Lua。

它反映的是整个基础设施行业正在发生的一种转变：

从追求灵活性，重新回到追求可预测性。

结语

NGINX官方这篇文章的结尾，用了一个极为精妙的比喻：

"将Lua集成到NGINX中，就像是在赛车仍在运行时对其进行手术。赛车为速度而设计，要求一切操作都是非阻塞且即时的，但如果技师使用标准、慢速的工具，或在发动机舱内留下散落的零件，整辆车就会熄火或撞毁。"

这个比喻精准地描述了动态脚本语言嵌入基础设施核心的风险。

NGINX官方的这篇文章并不是对Lua的否定。

Lua依然是一门优秀的语言。

OpenResty依然是极具影响力的基础设施项目。

但对于承担全站入口职责的网关而言，一个越来越清晰的共识正在形成：

最大的风险往往不是功能缺失，而是不可预测。

当系统规模不断扩大、业务越来越依赖基础设施时，稳定、可控制、可预期的重要性正在重新超过灵活性。

而这，也许正是未来十年网关架构演进最值得关注的方向。

参考与延伸阅读

• 原文：The Complex Dance of Lua and NGINX: Power, Pitfalls, and Performance Challenges（NGINX 官方博客，2026 年 2 月, https://blog.nginx.org/blog/the-complex-dance-of-lua-and-nginx-power-pitfalls-and-performance-challenges）

• BFE 开源项目：https://github.com/bfenetworks/bfe

• 相关阅读：《B站网关事故背后：OpenResty 与 Lua 的稳定性代价》

作者简介

章淼，博士，1994年进入清华大学计算机科学与技术系学习，2004年获得博士学位，2004年至2006年在清华大学留校任教，在清华期间曾参与中国第一代核心路由器的研制工作。2012年起在百度工作超过十年，聚焦云网络基础架构的研发工作，是BFE开源项目的发起人。在百度期间积极推动软件工程能力提升，曾担任百度代码规范委员会主席，2021年10月被授予百度代码规范委员会荣誉主席。2022年出版《代码的艺术：用工程思维驱动软件开发》。2023年4月起担任瑛菲网络CEO，聚焦研发面向云和大模型场景的现代化流量管理平台。