NGINX Full Version

隆重推出 NGINX Plus R31

很高兴宣布推出 NGINX Plus Release 31（R31）版本。NGINX Plus 基于 NGINX 开源版构建而成，是唯一一款将软件 Web 服务器、负载均衡器、反向代理、内容缓存和 API 网关集于一身的多合一产品。

NGINX Plus R31 的新增特性和增强特性包括：

此外，该版本还包括从 NGINX 开源版继承的新功能和漏洞修复，以及对 NGINX JavaScript 模块的更新。

 

重要行为变更

注：如果您不是从 NGINX Plus R30 升级至 NGINX Plus R31，请务必查看之前公告博客中的“重要行为变更”部分，了解当前版本和最新版本之间所有版本的嬗变过程。

弃用 OpenTracing 模块

NGINX Plus R18 中引入的 OpenTracing 模块正逐渐被弃用，计划自未来的 NGINX Plus R34 版本起不再提供。但在此之前，该模块包将包含在所有 NGINX Plus 版本中。我们强烈建议您使用 NGINX Plus R29 中引入的 OpenTelemetry 模块。

未报告 NGINX 使用情况的警告消息

NGINX Plus 用户必须向 F5 报告其 NGINX 使用情况，以确保合规性。随着 NGINX Plus R31 的发布，向 NGINX Instance Manager 报告 NGINX 使用情况的功能已原生存在，并默认启用。如果 NGINX 实例因故无法向 NGINX Instance Manager 提供其使用信息，一条警告消息则会被记录到日志中。

如欲详细了解如何在您的环境中配置这一功能，请参阅本文下方“原生 NGINX 使用报告”一节。

平台支持的变更

全新操作系统支持：

不再支持的旧版操作系统：

以下旧版操作系统已弃用，并计划在 NGINX Plus R32 中移除：

 

新增特性详情

原生 NGINX 使用报告

NGINX Plus R31 引入了与您网络环境中的 NGINX Instance Manager 的原生通信功能，可自动实现许可合规性。若您使用 F5 灵活使用购买计划（FCP），则不必再手动跟踪您的 NGINX Plus 实例。

默认情况下，NGINX Plus 会尝试在启动时通过对 nginx-mgmt.local 主机名进行 DNS 查询来发现 NGINX Instance Manager。虽然主机名可以配置，但为了简单起见，我们建议将一条 A 记录添加到本地 DNS 中，从而将默认主机名与运行 NGINX Instance Manager 的系统的 IP 地址关联起来。然后，NGINX Plus 将与 NGINX Instance Manager 建立 TLS 连接，每 30 分钟报告一次其版本号、主机名和唯一标识符。

为了进一步加强保护，我们还建议使用可选的 mgmt 配置块以通过 mTLS 配置此连接。然后，NGINX Instance Manager 会定期向 F5 服务报告 NGINX Plus 实例的总体使用情况。

如果 NGINX Plus 在解析 nginx-mgmt.local 主机名或与 NGINX Instance Manager 通信时遇到任何问题，您将在错误日志中看到一条警告消息。

以下为显示 NGINX Plus 实例无法解析 nginx-mgmt.local 的错误消息示例：

2023/12/21 21:02:01 [warn] 3050#3050: usage report: host not found resolving endpoint "nginx-mgmt.local”

以下为显示 NGINX Plus 实例与 NGINX Instance Manager 通信时出现了问题的错误消息示例：

2023/12/21 21:02:01 [warn] 3184#3184: usage report: connection timed out

自定义 mgmt 配置块设置

如果您希望微调 NGINX Plus 实例与 NGINX Instance Manager 的通信方式，则可选择使用新增的 mgmt 配置块和相关指令，通过定义自定义解析器、使用 IP 地址或备用主机名来识别 NGINX Instance Manager 系统、指定 TLS 选项、使用 mTLS 增强安全防护，并指定其他自定义参数。

以下是自定义配置示例：

mgmt {
    usage_report endpoint=instance-manager.local interval=30m;
    resolver 192.168.0.2; # Sample internal DNS IP

    uuid_file /var/lib/nginx/nginx.id;

    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers DEFAULT;

    ssl_certificate          client.pem;
    ssl_certificate_key      client.key;

    ssl_trusted_certificate  trusted_ca_cert.crt;
    ssl_verify               on;
    ssl_verify_depth         2;
}

有关这些指令的更多详细信息，请参阅产品文档。

有关下载和安装 NGINX Instance Manager 的更多信息，请参阅《安装指南》。

注：如果您使用的是早期版本的 NGINX Plus，则仍可按照这些说明报告您的实例。

SNI 配置的增强功能

在此版本之前，NGINX Plus 假定上游组中的所有服务器别无二致。这意味着它们需要能够处理相同的请求，响应相同的 SNI 名称（使用 proxy_ssl_server_name 时），并返回与相同名称匹配的 SSL 证书。

但在某些情况下，仅这些行为是不够的。例如，多台虚拟服务器共享一个上游服务器，并需要通过不同的 SNI 和/或主机请求头进行区分，以便将请求路由到特定资源。亦或是，上游组中的所有服务器无法使用相同的证书，或者将上游服务器放入不同的上游组受到限制。

NGINX Plus R31 引入了 SNI 支持，可按上游服务器进行配置。变量 $upstream_last_server_name 指的是所选上游服务器的名称，可使用 proxy_ssl_server_name 和 proxy_ssl_name 指令传递给代理服务器。

以下显示了如何将 proxy_ssl_server_name 设置为 on，以便服务器名称能够通过 SNI 传递：
proxy_ssl_server_name on;

下面是使用 proxy_ssl_name 传递所选上游服务器名称的方法：
proxy_ssl_name $upstream_last_server_name;

使用 NGINX JavaScript 定期执行任务

NGINX JavaScript v0.8.1 引入了一个新指令 js_periodic。该指令可在 http 和 stream 上下文中使用，允许指定一个 JavaScript 内容处理器定期运行。在自定义代码需要定期运行并可能需要访问 NGINX 变量的情况下，该功能非常实用。内容处理器会接收一个会话对象作为参数，而且还可访问全局对象。

默认情况下，内容处理器在 worker 进程 0 上运行，但也可将其配置为在特定或所有 worker 进程上运行。

该指令可在 location 上下文中使用：

example.conf:

location @periodics {

    # 在 worker 进程 1 和 3 中每隔 15 分钟运行一次
    js_periodic main.handler interval=900s worker_affinity=0101;

    resolver 10.0.0.1;
    js_fetch_trusted_certificate /path/to/certificate.pem;
}

example.js:

async function handler(s) {
    let reply = await ngx.fetch('https://nginx.org/en/docs/njs/');
    let body = await reply.text();

    ngx.log(ngx.INFO, body);
}

有关语法和配置详细信息，请参阅 NGINX JavaScript 文档。

提升 NGINX 启动体验

在 NGINX 配置包含大量“locations”的情况下，NGINX 启动可能会花费较长时间。在很多情况下，这可能是不可接受的。导致这个问题的根本原因是用于对 locations 列表进行排序的排序算法。

NGINX R31 引入了一项增强功能，可将现有排序算法从插入排序（时间复杂度为 O(n2)）替换为归并排序（时间复杂度为O(n*log n)）。

我们看到在此更新后，在具有 20,000 个 locations 的测试配置中，总启动时间从 8 秒缩短到了 0.9 秒。

QUIC+HTTP/3 优化和改进

NGINX Plus R31 为 QUIC+HTTP/3 实现引入了多项增强功能和性能优化，例如：

其他性能优化包括：减少发送确认数据包时可能出现的延迟、将确认（ACK）数据帧放在队列的前面以减少数据帧重传和 ACK 数据帧传送延迟，以及改进通用分段卸载（GSO）模式下的拥塞控制行为。

 

NGINX Plus R31 中的其他增强功能和漏洞修复

其他 mgmt 模块

在 NGINX Plus R31 中，ngx_mgmt_module 支持您向 NGINX Instance Manager 报告 NGINX 使用信息，其中包括 NGINX 主机名、NGINX 版本及唯一实例标识符。

该模块提供了多个指令，用于微调 NGINX 实例与 NGINX Instance Manager 的通信方式。有关可用指令和配置选项的完整列表，请参阅 NGINX 文档。

MQTT 模块中的漏洞修复

NGINX Plus R29 引入了消息队列遥测传输（MQTT），并针对 MQTT 模块中发现的问题进行了一些漏洞修复。

其中的一个重要的修复解决了在未提供密码的情况下 CONNECT 消息被拒绝的问题。以前，我们认为填写用户名字段后就必须输入密码。然而，在 MQTT 规范中有一些特殊情况，例如匿名身份验证不要求提供密码。该漏洞修复通过查看数据包的 cflags 字段，有条件地检查是否需要密码。如果未设置该标志，则表示不必提供密码。

另一漏洞修复是，当信息长度小于接收的字节数时，将停止解析 MQTT CONNECT 信息。

使用变量支持 HTTP/3 server_tokens

NGINX Plus R31 增加了对 HTTP/3 连接中缺失的 server_tokens 变量的支持。string 字段可用于明确设置错误页面上的签名和“Server”响应头字段值。如果 string 字段为空，则会禁用“Server”字段的生成。

从 NGINX 开源版继承的变更

NGINX Plus R31 基于 NGINX 开源版 1.25.3，继承了自 NGINX Plus R30 发布以来（NGINX 1.25.2 和 1.25.3）的功能变更、特性及漏洞修复。

特性

变更

漏洞修复

有关从最新版本继承的新变更、特性、漏洞修复及变通方案的完整列表，请参见 NGINX 变更文件。

NGINX JavaScript 模块的变更

NGINX Plus R31 包含 NGINX JavaScript（njs）模块版本 0.8.2 的变更。以下是 njs 自 0.8.0（NGINX Plus R30 版本的一部分）以来的重大变更列表。

特性

变更

漏洞修复

有关所有特性、变更及漏洞修复的完整列表，请参阅 njs 变更日志。

 

升级或试用 NGINX Plus

如果您是 NGINX Plus 用户，我们强烈建议您尽快升级到 NGINX Plus R31。除了上述所有新特性以外，您还将获得更多修复和改进。升级到最新版本有助于 NGINX 团队在您需要时为您快速提供支持。

如果您还不是 NGINX Plus 用户，我们建议您立即申请试用。您可将其用于安全防护、负载均衡及 API 网关用例，或者用作 Web 服务器 — 采用增强型监控和管理 API 并可获得全面的支持服务。请立即下载 30 天免费试用版。