NGINX Plus R24 正式发布

我们很高兴地宣布，NGINX Plus Release 24 (R24)现已发布。NGINX Plus基于NGINX Open Source，将软件Web服务器、负载均衡器、反向代理、内容缓存和API网关功能集于一体。

NGINX Plus R24 的新功能包括：

• 加密的JSON Web令牌：在早期版本支持签名JSON Web令牌（JWT）的基础上，NGINX Plus现已支持加密JWT，可在敏感信息存储于Web浏览器及其他客户端时，帮助保障其机密性和数据完整性。
• NGINX JavaScript Module 开发进程中的重要里程碑：新增功能，尤其是针对 HTTP 标头和正文的响应过滤功能，以及对 TCP/UDP 连接和会话使用基于 HTTP 的身份验证服务的支持，可实现多种强大的新用例。
• 与F5 Device ID+集成：这款实时、高精度的设备标识工具会为访问您网站的每台设备分配唯一标识符，从而加强对已知恶意行为者的防护，并为回访用户提供定制化体验。

本次发布还包括两项功能：可选择在重新加载配置后保留强制运行状况检查的结果，以及为Cookie标志设置动态值。

重要行为变更

已弃用的 Cookie-Flag 模块

正如在发布NGINX Plus R23时所宣布的，第三方Cookie-Flag模块已弃用，并将在NGINX Plus R26中从动态模块存储库移除。该模块中定义的set_cookie_flag指令已由proxy_cookie_flags指令取代。建议尽快将配置中的所有set_cookie_flag指令替换为proxy_cookie_flags指令。另请参阅“动态Cookie标志”。

平台支持变更

• 新增支持的操作系统：
  • Alpine Linux 3.13（aarch64、amd64）
  • CentOS 7.4+（除x86_64和ppc64le外，还支持aarch64）
  • FreeBSD 13（amd64）
  • SLES 15 SP2
• 已移除旧版操作系统：
  • 不再支持Debian 9；支持的最低版本为10
• 已弃用并计划在NGINX Plus R25中移除的旧版操作系统：
  • Alpine Linux 3.10
  • Amazon Linux 1（2018.03+）
  • FreeBSD 11
  • Ubuntu 16.04 LTS

Amazon Linux 2 依赖 OpenSSL 1.1

适用于Amazon Linux 2的NGINX Plus软件包现在依赖OpenSSL 1.1，从而支持TLS 1.3，并在许多其他方面增强安全性。将Amazon Linux 2系统升级到NGINX Plus R24时，请确认系统中使用OpenSSL的其他软件仍可与OpenSSL 1.1正常配合使用。

NGINX Plus 安装过程变更

我们重新组织了NGINX Plus软件包存储库，因此安装流程也有所调整。

此次存储库结构调整反映了我们产品组合的扩展，以及依赖NGINX Plus的产品生态系统的壮大。具体而言，对于NGINX Plus，pkgs.nginx.com/plus存储库取代了旧的plus-pkgs.nginx.com存储库。

安装和升级NGINX Plus时，操作系统的软件包管理器（apt、yum或同类工具）会配置为使用NGINX Plus软件存储库。对于已配置为使用plus-pkgs.nginx.com存储库的现有系统，需要更新软件包管理器，使其指向pkgs.nginx.com/plus（并在末尾添加表示操作系统的路径元素）。

有关将现有系统升级到NGINX Plus R24的说明，请参阅F5知识库。有关更新后的初始安装说明，请参阅《NGINX Plus管理指南》中的“安装NGINX Plus”。

整合HTTP连接处理指令

随着HTTP/3标准接近完成，以及HTTP/2的使用日益增多，我们简化了长连接的配置方式。在NGINX Plus R24及更高版本中，以前仅适用于HTTP/1.1的配置指令也适用于HTTP/2。无需再仅仅因为协议版本不同，就为相同功能使用不同的指令。

已弃用指令 替代指令http2_idle_timeout keepalive_timeouthttp2_max_field_size
http2_max_header_size large_client_header_buffershttp2_max_requests keepalive_requestshttp2_recv_timeout client_header_timeout

更主动地关闭连接

在NGINX Plus R23及更高版本中，lingering_close、lingering_time和lingering_timeout指令同时适用于HTTP/2和HTTP/1.1。使用这些指令配置更高效的HTTP/2连接处理方式，可提升NGINX Plus的整体HTTP/2能力。

NGINX Plus R24 对这些指令的作用进行了重要调整，并消除了一个潜在错误：如果空闲工作进程连接池耗尽，NGINX Plus 不仅会开始关闭 keepalive 连接，还会关闭处于 lingering-close 模式的连接。

已更改所记录运行状况变化的严重性级别

当上游服务器的健康状态发生变化时，NGINX会将相应条目写入错误日志。这是监控和分析基础设施整体健康状况的重要工具。HTTP和TCP/UDP（stream）上游服务器记录状态变化时所采用的严重性级别均已更改：

• 从healthy变为unhealthy时，将按warn级别记录（原为info级别）。
• 从“unhealthy”变为“healthy”的更改将以“notice”级别记录（原为“info”级别）。

新功能详解

加密的JSON Web令牌

JSON Web Token（JWT）的使用日益广泛。此前，NGINX Plus支持签名令牌（RFC 7515中定义的JSON Web Signature［JWS］标准），可确保令牌中所编码声明的数据完整性。但是，JWS无法为声明提供保密性，任何有权访问令牌的组件都可以读取这些声明。TLS/SSL可降低令牌在传输过程中暴露的风险，但存储在Web浏览器和其他客户端中的令牌仍可能暴露。

NGINX Plus R24新增了对加密令牌（在RFC 7516中定义的JSON Web Encryption［JWE］标准）的支持，可为整个声明集同时提供机密性和数据完整性。现在，可以将敏感信息或个人身份信息（PII）编码到JWT中，而不必担心这些数据因客户端不安全而泄露。

NGINX Plus R24及更高版本同时支持签名JWT和加密JWT。默认使用签名令牌，无需显式配置。新的auth_jwt_type指令用于配置JWT加密。

正在加载代码示例…

在由auth_jwt_key_file指令指定的JWT密钥文件中定义加密（或签名）算法和密钥用法。NGINX Plus R24及更高版本支持以下加密方法。

JWE密钥管理算法

• A128KW，A192KW，A256KW

• A128GCMKW，A192GCMKW，A256GCMKW

• dir，配置为直接使用共享对称密钥作为内容加密密钥

JWE内容加密算法

• A128CBC-HS256，A192CBC-HS384，A256CBC-HS512

• A128GCM，A192GCM，A256GCM

NGINX JavaScript模块迈向成熟的重要里程碑

NGINX Plus R24标志着NGINX JavaScript模块（njs）的开发取得重大进展，该模块现已更新至0.5.3。两项重要增强功能支持使用自定义解决方案扩展NGINX Plus，以满足各种使用场景的需求：

• 响应过滤，同时适用于HTTP响应标头和响应正文
• 一个嵌入式HTTP客户端，可在HTTP或TCP/UDP处理期间发出HTTP请求

如果您不熟悉NGINX JavaScript模块，请阅读我们博客上的这篇介绍<.htmla>。

［本节介绍的用例只是NGINX JavaScript模块众多用例中的一部分。有关完整列表，请参阅《NGINX JavaScript模块用例》。］

响应过滤

将NGINX Plus部署为API网关或反向代理时，一项非常强大的功能是响应过滤。该功能会拦截来自上游服务器的响应，并根据正则表达式匹配结果，替换响应正文、响应头或两者中的字符串。对于未使用NGINX JavaScript模块处理的流量，响应过滤通过Substitution模块实现。

NGINX Plus R24在NGINX JavaScript模块中引入了另一种响应过滤实现方式，其中包含两个指令，可利用JavaScript的强大功能分析和修改响应正文及标头。与基于正则表达式的简单字符串替换相比，JavaScript大幅扩展了检查和处理能力，可实现比Substitution模块更强大的响应过滤。

使用js_body_filter指令过滤响应正文

使用js_body_filter指令，可以通过JavaScript检查和修改代理服务器返回的响应正文。用例包括：

• 使用正则表达式扫描复杂模式
• 转换数据格式
• 在响应中插入动态内容

在此示例中，我们会扫描响应中任何疑似AWS访问密钥的内容，并将其替换为掩码值。

正在加载代码示例…

要执行此代码，只需在相关的“maskAwsKeys”函数中引用“location”块。

正在加载代码示例…

使用js_header_filter指令筛选响应标头

可以使用js_header_filter指令检查响应标头的内容，甚至可以拦截并修改这些内容。假设某个后端服务器发出多个Set-Cookie标头，其中包含敏感信息，但这些信息对于正常运行至关重要。NGINX Plus可以拦截响应、读取Set-Cookie标头，并将其保存在键值存储中。可以创建一个替代Set-Cookie标头，用于引用键值存储，并将其注入原始响应中。

显示js_header_filter与键值存储交互的请求流

在NGINX Plus配置的第4至5行中，我们定义了键值存储：

正在加载代码示例…

然后，在第12–13行中，我们将引用Cookie替换为键值存储中的内容，并使用JavaScript代码拦截所有新Cookie。

正在加载代码示例…

JavaScript代码会遍历每个新的Set-Cookie响应标头，并创建一个新的键值条目来存储该标头。

正在加载代码示例…

使用简单的HTTP客户端为TCP/UDP调用HTTP服务

API网关的主要用例是控制对特定资源的访问。NGINX Plus在第7层为HTTP请求提供一套强大的身份验证和访问控制功能，但现代API实现也会使用TCP/UDP作为底层协议，这带来了新的身份验证挑战。

借助内置的NGINX JavaScript ngx.fetch函数，现在可以在TCP/UDP连接上下文中实例化一个简单的HTTP客户端。这样便可在stream上下文中使用基于HTTP的身份验证服务进行访问控制，例如在代理数据库连接时调用本地OpenPolicy Agent守护进程。

此示例演示如何使用端口 8085 上的本地 HTTP 身份验证服务，对每个新连接进行身份验证。js_access 指令与 ngx.fetch 函数共同在新实例化的 HTTP 上下文中实现类似于根据子请求结果进行客户端授权的功能（常规 HTTP 请求通过 auth_request 指令实现此功能）。根据 Response 对象中的 HTTP 状态码，允许（s.allow）或拒绝（s.deny）连接后端数据库。

正在加载代码示例…

正在加载代码示例…

注意： ngx.fetch函数可与NGINX JavaScript HTTP模块和NGINX JavaScript Stream模块配合使用，但与HTTP模块中的r.subrequest对象相比存在明显限制。对于大多数HTTP用例，建议使用r.subrequest，因为它支持TLS连接、缓存以及Proxy模块的全部功能。

其他njs增强功能

使用set［HTTP］［Stream］或js_set［HTTP］［Stream］指令定义NGINX变量时，如果请求处理过程中遇到重定向，该变量的值可能会被覆盖。新的js_var［HTTP］［Stream］指令支持通过JavaScript函数计算变量，并使其值在重定向后保持不变。

新的njs.on对象支持在njs虚拟机退出时执行JavaScript函数。例如，可用于在TCP连接结束时执行函数。

Stream会话对象新增的“s.status”属性可用于访问会话的总体状态（有关可能的值，请参阅“$status”）。

与F5 Device ID+集成

F5 Device ID+是一款实时、高精度的设备标识工具，利用先进的信号采集技术和经过验证的机器学习算法，为访问您网站的每台设备分配唯一标识符。部署简单，可立即为安全、网络、反欺诈和数字化团队带来助益。轻松识别访问应用的不同设备，从未如此简单。

有关在NGINX Plus实例上激活F5 Device ID+的说明，请参阅《使用F5 Device ID+缓解欺诈和风险》。

使用F5 Device ID+的优势

• 增强应用安全性：通过准确识别设备，增强攻击检测和缓解分析。识别安全系统已标记为可疑的再次访问设备。
• 优化流量管理：将唯一设备标识符纳入路由逻辑，以更有效地管理和优化网络流量。即使恶意行为者操纵第7层数据，也能识别设备。
• 缓解欺诈和风险：监控客户在新账户创建、用户身份验证、电商结账和金融交易等操作中的行为，检测可能表明身份盗用或其他威胁的异常模式。
• 个性化并加速在线体验：让已知的回访用户和设备顺畅完成登录、结账和身份验证。F5开展的A/B测试表明，减少安全环节的阻碍有助于增加收入，而设备识别是任何减少阻碍策略中的重要一环。

F5 Device ID+ 的工作原理

每位用户访问您的网站时，F5 Device ID+都会利用JavaScript收集有关浏览器、设备操作系统、硬件和网络配置的信息。这些属性会传送至F5 Device ID+服务。该服务基于F5 Shape获得业界认可的AI和机器学习能力构建。数据会实时处理；除非设备已被识别为已知设备，否则系统会为其分配唯一标识符。对于再次访问的设备，系统可以记录、学习和分析其行为、操作及其他属性，从而帮助减少欺诈，并为已知的正常用户提供顺畅体验。

NGINX Plus R24 的其他增强功能

强制健康检查状态可在重新加载配置后保留

强制健康检查用于为通过NGINX Plus API或DNS解析添加的上游服务器启用慢启动。它们可确保先对新节点执行健康检查，并在节点准备好接收流量后再进行慢启动。

以前，重新加载配置后，无论上游服务器在重新加载前处于何种状态，系统都会将其视为不健康。因此，在首次通过强制健康检查之前，这些服务器不会接受客户端请求。

借助NGINX Plus R24，可将强制HTTP健康检查标记为持久检查，以便在重新加载配置时保留其先前状态。将persistent参数与health_check指令的mandatory参数一起添加。

正在加载代码示例…

动态Cookie标志

在上一版本的NGINX Plus中，我们引入了proxy_cookie_flags指令，作为一种设置Cookie标志的原生方法。NGINX Plus R24通过支持Cookie标志的动态值扩展了此功能，从而可使用NGINX变量控制特定的Cookie标志。

注意： proxy_cookie_flags指令已弃用Cookie‑Flag模块，该模块将在NGINX Plus R26中移除。请参阅“已弃用的Cookie‑Flag模块”。

此示例使用map，在方案为Secure Cookie 标志，而非https时启用http。

正在加载代码示例…

升级或试用 NGINX Plus

如果您正在运行NGINX Plus，强烈建议尽快升级到NGINX Plus R24。升级后还可获得多项其他修复和改进，并有助于NGINX在您需要提交支持工单时提供帮助。

如果您尚未体验过NGINX Plus，不妨试用一下。它可用于安全防护、负载均衡和API网关，也可作为获得全面支持的Web服务器，并提供增强的监控和管理API。立即开始30天免费试用。

---