宣布推出 NGINX Plus R24

我们很高兴地宣布NGINX Plus Release 24 (R24) 已经推出。 NGINX Plus 基于 NGINX 开源，是唯一集 Web 服务器、负载均衡器、反向代理、内容缓存和 API 网关于一体的软件。

NGINX Plus R24的新功能包括：

• 加密的 JSON Web 令牌- 在早期版本对签名的 JSON Web 令牌 (JWT) 的支持基础上，NGINX Plus 现在支持加密的 JWT，以确保敏感信息存储在 Web 浏览器和其他客户端时保密性和数据完整性。
• NGINX JavaScript 模块开发的一个重要里程碑——新功能——特别是对 HTTP 标头和正文的响应过滤，以及对 TCP/UDP 连接和会话的基于 HTTP 的身份验证服务的支持——解锁了许多强大的新用例。
• 与 F5 Device ID+ 集成– 此实时、高精度设备标识符为访问您网站的每个设备分配一个唯一的标识符，从而能够更有效地防范已知的不良行为者，并为回访者提供定制的用户体验。

完善此版本的功能包括，在配置重新加载时可选保留强制性健康检查的结果和 cookie 标志的动态值。

行为方面的重要变化

弃用的 Cookie-Flag 模块

正如NGINX Plus R23发布时宣布的那样，第三方 Cookie‑Flag 模块已被弃用，并将从NGINX Plus R26中的动态模块库中删除。 该模块中定义的set_cookie_flag指令被proxy_cookie_flags指令取代。 我们建议您尽快用proxy_cookie_flags指令替换配置中的所有set_cookie_flag指令。 另请参阅动态 Cookie 标志。

平台支持变更

• 支持的新操作系统：
  • Alpine Linux 3.13（aarch64、amd64）
  • CentOS 7.4+（aarch64，以及 x86_64 和 ppc64le）
  • FreeBSD 13（amd64）
  • SLES 15 SP2
• 删除较旧的操作系统：
  • Debian 9 不再受支持；最早支持的版本是 10
• 较旧的操作系统已弃用并计划在NGINX Plus R25中删除：
  • Alpine Linux 3.10
  • 亚马逊 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 repo 取代了旧的plus-pkgs.nginx.com repo。

当您安装和升级 NGINX Plus 时，操作系统的包管理器（ apt 、 yum或同等软件）会配置 NGINX Plus 的软件存储库。 在配置为使用plus-pkgs.nginx.com repo 的现有系统上，您需要更新包管理器以引用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。 您不再需要仅仅因为协议版本不同而对相同功能使用不同的指令。

更积极的连接关闭

在 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 不仅会开始关闭保持活动连接，还会开始关闭处于延迟关闭模式的连接。

已记录健康状态变化的严重性级别已更改

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

• 从健康到不健康的变化记录在警告级别（原为信息）。
• 从不健康到健康的变化记录在通知级别（原为信息）。

新功能详情

加密的 JSON Web 令牌

JSON Web Tokens ( JWT ) 的使用持续增长。 此前，NGINX Plus 支持签名令牌（ RFC 7515中定义的 JSON Web 签名 [JWS] 标准），它为令牌中编码的声明提供数据完整性。 然而，JWS 不提供声明的机密性——任何有权访问令牌的组件都可以读取它们。 TLS/SSL 减轻了传输过程中令牌的暴露，但存储在 Web 浏览器和其他客户端中的令牌仍然会暴露。

NGINX Plus R24 引入了对加密令牌（ RFC 7516中定义的 JSON Web 加密 [JWE] 标准）的支持，该令牌为整个声明集提供机密性和数据完整性。 现在可以将敏感信息或个人身份信息 (PII) 编码到 JWT 中，而不会存在数据被不安全的客户端泄露的风险。

NGINX Plus R24 及更高版本支持签名和加密的 JWT。 签名令牌是默认的，不需要明确配置。 新的auth_jwt_type指令配置 JWT 加密。

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

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 模块的用例。 ]

响应过滤

作为 API 网关或反向代理部署的 NGINX Plus 最强大的功能之一是响应过滤，它涉及根据正则表达式匹配拦截来自上游服务器的响应并替换响应正文、标头或两者中的字符串。 对于未使用 NGINX JavaScript 模块处理的流量，在Substitution模块中实现响应过滤。

NGINX Plus R24 在 NGINX JavaScript 模块中引入了响应过滤的单独实现，其中两个指令使您能够利用 JavaScript 的强大功能来分析和修改响应主体和标头。 JavaScript 将检查和操作的可能性扩展到了基于正则表达式的简单字符串替换之外，甚至比使用替换模块具有更强大的响应过滤功能。

使用js_body_filter指令过滤响应主体

使用js_body_filter指令，您可以使用 JavaScript 检查和修改来自代理服务器的响应主体。 用例包括：

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

在此示例中，我们扫描响应中查找任何看起来像 AWS 访问密钥的内容，并用屏蔽值替换任何此类出现的内容。

要执行此代码，我们只需引用相关位置块内的maskAwsKeys函数。

使用js_header_filter指令过滤响应标头

您可以使用js_header_filter指令来检查——甚至拦截和修改——响应标头的内容。 考虑一个后端服务器，它发出许多Set-Cookie标头，其中包含敏感信息，但对于正确操作至关重要。 NGINX Plus 能够拦截响应，读取Set-Cookie标头并将其保存在键值存储中。 可以创建一个替换的Set-Cookie标头作为对键值存储的引用，并将其注入原始响应中。

在 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 客户端。 这使得可以使用基于 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 连接、缓存和代理模块中所有功能的支持。

其他 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 设备 ID+的说明，请参阅使用F5 设备 ID+减轻欺诈和风险。

使用 F5 Device ID+ 的优势

• 加强应用安全性——通过准确的设备识别加强攻击检测和缓解分析。 识别您的安全系统已标记为可疑的返回设备。
• 优化流量管理——将唯一的设备标识符纳入路由逻辑，以更好地管理和优化网络流量。 即使恶意行为者操纵第 7 层数据，也能识别设备。
• 减轻欺诈和风险——监控新账户创建、用户身份验证、电子商务结账和金融交易等操作中的客户行为，检测可能表明身份盗窃等威胁的异常模式。
• 个性化并加速在线体验——让已知的回访用户和设备能够无缝地进行登录、结帐和身份验证。 F5 的 A/B 测试表明，减少安全摩擦可以增加收入，而设备识别是任何减少摩擦策略中的重要元素。

F5 设备 ID+ 的工作原理

当每个用户访问您的网站时， F5 Device ID+都会利用 JavaScript 收集有关浏览器、设备操作系统、硬件和网络配置的信息。 这些属性被输入到基于 F5 Shape 业界认可的 AI 和机器学习功能构建的F5 Device ID+服务中。 数据被实时处理，并且为设备分配唯一的标识符，除非它已经是已知设备。 对于退回的设备，可以记录、学习和研究行为、动作和其他属性，以减少欺诈并为已知良好用户提供顺畅的体验。

NGINX Plus R24 中的其他增强功能

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

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

以前，重新加载配置后，上游服务器会被视为不健康，无论重新加载之前的状态如何。 因此，服务器直到通过第一次强制检查后才会接受客户端请求。

使用 NGINX Plus R24，您可以将强制 HTTP 运行状况检查标记为持久检查，以便在重新加载配置时记住其先前的状态。 将持久参数与强制参数一起添加到health_check指令。

动态 Cookie 标志

在 NGINX Plus 的先前版本中，我们引入了proxy_cookie_flags指令作为设置 cookie 标志的本机方法。 NGINX Plus R24通过启用 cookie 标志的动态值扩展了此功能。 这使得特定的 cookie 标志能够由 NGINX 变量控制。

笔记： proxy_cookie_flags指令弃用了 Cookie‑Flag 模块，该模块将在NGINX Plus R26中删除。 请参阅已弃用的 Cookie‑Flag 模块。

此示例使用映射在方案为https而非http时启用安全cookie 标志。

升级或尝试 NGINX Plus

如果您正在运行 NGINX Plus，我们强烈建议您尽快升级到NGINX Plus R24 。 您还将获得一些额外的修复和改进，当您需要提出支持单时，它将帮助 NGINX 为您提供帮助。

如果您还没有尝试过 NGINX Plus，我们鼓励您尝试一下 – 为了安全、负载均衡和 API 网关，或者作为具有增强监控和管理 API 的完全支持的 Web 服务器。 您今天就可以开始享受30 天免费试用。