NGINX 1.31.5 开源版发布为 AI Agent 时代重塑路由与性能NGINX 社区发布了NGINX 1.31.5开源版本这是近年来变化最大的一次更新。新版本在机制上进行了重大重构新增了谓词变量、请求体预读、原生 JSON 解析和 Control API 等核心功能。其中前三个功能直指 AI Agent 通信场景——当 Agent 的请求不再仅靠 URL 区分时NGINX 需要学会“读语义”。一、新旧架构对比全景NGINX 1.31.5 新处理流程客户端请求并行处理基于 URL 匹配 locationclient_body_early_read 预读请求体原生 C 解析 JSON提取字段赋给谓词变量谓词 location 路由决策转发到后端传统 NGINX 处理流程客户端请求基于 URL 匹配 location读取请求体调用 njs/Lua 解析 JSON提取字段做路由决策转发到后端对比维度传统 NGINXNGINX 1.31.5路由依据仅 URL 路径谓词变量四层子网/证书/请求头/JSON 字段请求体读取路由完成后串行读取与路由并行预读client_body_early_readJSON 解析需 njs/Lua 外部工具原生 C 语言解析零额外开销运维 API仅 Plus 版本社区版开放 Control API二、谓词变量路由从 URL 走向语义在过去location仅支持基于 URL 路径的路由。但随着 AI Agent 通信方式的巨大变化相同 URL 在不同场景下可能有多种含义仅靠路径匹配已经不够了。1.31.5 版本为location增加了谓词变量Predicate Variables可以根据四层子网、客户端证书、七层请求头等多种条件进行逻辑处理。# 根据 AI 爬虫标识做路由 location $is_ai_scraper { # 当 $is_ai_scraper 为 true 时进入此 location proxy_pass http://ai_backend; } # 根据客户端证书做路由 location $ssl_client_s_dn { if ($ssl_client_s_dn ~ CNinternal) { proxy_pass http://internal_backend; } }这意味着路由策略不再依赖单一维度而是可以灵活组合多种条件。NGINX 可以基于真实的通信上下文而非仅仅是路径字符串来决定请求走向。三、client_body_early_read请求体与路由并行处理过去NGINX 的处理顺序是先完成路由匹配再读取请求体。这种串行逻辑在大模型 Agent 场景下会成为瓶颈——因为 Agent 请求体通常很大包含工具调用、消息历史等而路由决策又可能需要依赖请求体内容。1.31.5 引入了client_body_early_read指令允许 NGINX 在路由匹配的同时并行读取请求体甚至将请求体内容用于路由决策。server { client_body_early_read on; # 启用请求体预读 location /mcp { # 在路由完成前请求体已经在并行读取 proxy_pass http://mcp_backend; } }旧方式 vs 新方式流程对比新方式 1.31.5并行处理并行匹配 location读取请求体原生 C 解析 JSON提取字段赋值给变量谓词 location 路由旧方式串行处理匹配 location读取请求体njs/Lua 解析 JSON提取字段路由决策过去处理 MCP 工具请求时需要借助 njs 模块但只有在location完成/mcp匹配后才能开始处理。而现在通过client_body_early_read、原生 JSON 解析第三个新功能和谓词location可以直接从请求体提取信息如tools/call方法名并赋值给谓词变量从而让 NGINX 根据语义而非 URL 完成路由全程不需要第三方模块零额外开销。四、原生 JSON 解析和变量提取这是与client_body_early_read配合使用的核心能力。过去要从请求体中提取 JSON 字段必须借助 Lua 或 njs 等外部工具不仅增加依赖还带来额外性能开销。1.31.5 新增了原生 JSON 解析能力直接在 C 层面实现 JSON 内容提取开销极小。通过json_set指令可以轻松将 JSON 中的字段值赋给 NGINX 变量# 从请求体中提取 method 字段赋给 $json_method 变量 json_set $request_body $json_method method; # 也可以提取嵌套字段 json_set $request_body $tool_name params.tool.name;组合示例根据工具名称路由server { client_body_early_read on; # 从 JSON Body 中提取 method 字段 json_set $request_body $tool_name method; # 根据工具名称做谓词路由 location $tool_name { if ($tool_name ~ ^(listTools|callTool)$) { proxy_pass http://mcp_backend; } if ($tool_name ~ ^(search|query)$) { proxy_pass http://search_backend; } } }整个过程不需要任何第三方模块完全在 NGINX 原生 C 代码中完成。这也是新机制中唯一不需要在location中用js或 Lua 触发即可生效的配置。渲染错误:Mermaid 渲染失败: Parse error on line 3: ... A1[{method: callTool, param -----------------------^ Expecting SQE, DOUBLECIRCLEEND, PE, -), STADIUMEND, SUBROUTINEEND, PIPE, CYLINDEREND, DIAMOND_STOP, TAGEND, TRAPEND, INVTRAPEND, UNICODE_TEXT, TEXT, TAGSTART, got STR五、Control API运维能力下放社区版这是第四个大功能点主要面向运维人员。过去NGINX 的运行状态查询如进程列表、配置状态仅限 NGINX Plus 收费版本使用。1.31.5 将这些能力下放到了开源社区版。通过/1/control/processes、/1/control/config等 Control API 端点运维人员可以实时了解 NGINX 的运行状况。注意该功能必须以Unix Socket形式绑定到 NGINX不支持端口绑定。# 查询 NGINX 进程信息curl--unix-socket /tmp/nginx.sock http://localhost/1/control/processes# 查询当前配置状态curl--unix-socket /tmp/nginx.sock http://localhost/1/control/config# 动态更新配置PATCH 请求curl--unix-socket /tmp/nginx.sock-XPATCH http://localhost/1/control/config-d{method: reload}Control API 端点速查端点方法功能/1/control/processesGET查看 NGINX 进程列表/1/control/configGET查看当前配置状态/1/control/configPATCH动态更新配置如 reload/1/control/connectionsGET查看当前连接状态此外Control API 还支持查询当前连接状态/1/control/connections方便运维快速定位是否有请求积压、连接泄漏等问题。六、功能总结功能解决的问题对 AI Agent 的意义谓词 location路由维度单一支持多条件组合路由适应 Agent 多样化请求client_body_early_read请求体读取与路由串行并行处理降低延迟原生 JSON 解析依赖外部工具提取 JSON零开销解析语义路由成为可能Control API运维能力仅限商业版社区版运维能力补全前三个功能充分考虑 AI Agent 运行场景尤其是client_body_early_read 原生 JSON 解析 谓词 location的组合让 NGINX 能够根据请求语义而非仅仅 URL 进行路由。过去处理 MCPModel Context Protocol工具请求时需要借助 njs 模块但只有在 location 完成/mcp匹配后才进行。现在可以直接从请求体提取tools/call方法名并赋值给谓词变量从而让 NGINX 根据语义而不是 URL 完成路由不需要第三方模块零额外开销。这是 NGINX 在 AI Agent 时代的一次重要转身。从“路径匹配”到“语义感知”NGINX 正在从一个纯粹的 Web 服务器演变为 AI 流量感知和路由的基础设施层。
NGINX 1.31.5 开源版发布：为 AI Agent 时代重塑路由与性能
NGINX 1.31.5 开源版发布为 AI Agent 时代重塑路由与性能NGINX 社区发布了NGINX 1.31.5开源版本这是近年来变化最大的一次更新。新版本在机制上进行了重大重构新增了谓词变量、请求体预读、原生 JSON 解析和 Control API 等核心功能。其中前三个功能直指 AI Agent 通信场景——当 Agent 的请求不再仅靠 URL 区分时NGINX 需要学会“读语义”。一、新旧架构对比全景NGINX 1.31.5 新处理流程客户端请求并行处理基于 URL 匹配 locationclient_body_early_read 预读请求体原生 C 解析 JSON提取字段赋给谓词变量谓词 location 路由决策转发到后端传统 NGINX 处理流程客户端请求基于 URL 匹配 location读取请求体调用 njs/Lua 解析 JSON提取字段做路由决策转发到后端对比维度传统 NGINXNGINX 1.31.5路由依据仅 URL 路径谓词变量四层子网/证书/请求头/JSON 字段请求体读取路由完成后串行读取与路由并行预读client_body_early_readJSON 解析需 njs/Lua 外部工具原生 C 语言解析零额外开销运维 API仅 Plus 版本社区版开放 Control API二、谓词变量路由从 URL 走向语义在过去location仅支持基于 URL 路径的路由。但随着 AI Agent 通信方式的巨大变化相同 URL 在不同场景下可能有多种含义仅靠路径匹配已经不够了。1.31.5 版本为location增加了谓词变量Predicate Variables可以根据四层子网、客户端证书、七层请求头等多种条件进行逻辑处理。# 根据 AI 爬虫标识做路由 location $is_ai_scraper { # 当 $is_ai_scraper 为 true 时进入此 location proxy_pass http://ai_backend; } # 根据客户端证书做路由 location $ssl_client_s_dn { if ($ssl_client_s_dn ~ CNinternal) { proxy_pass http://internal_backend; } }这意味着路由策略不再依赖单一维度而是可以灵活组合多种条件。NGINX 可以基于真实的通信上下文而非仅仅是路径字符串来决定请求走向。三、client_body_early_read请求体与路由并行处理过去NGINX 的处理顺序是先完成路由匹配再读取请求体。这种串行逻辑在大模型 Agent 场景下会成为瓶颈——因为 Agent 请求体通常很大包含工具调用、消息历史等而路由决策又可能需要依赖请求体内容。1.31.5 引入了client_body_early_read指令允许 NGINX 在路由匹配的同时并行读取请求体甚至将请求体内容用于路由决策。server { client_body_early_read on; # 启用请求体预读 location /mcp { # 在路由完成前请求体已经在并行读取 proxy_pass http://mcp_backend; } }旧方式 vs 新方式流程对比新方式 1.31.5并行处理并行匹配 location读取请求体原生 C 解析 JSON提取字段赋值给变量谓词 location 路由旧方式串行处理匹配 location读取请求体njs/Lua 解析 JSON提取字段路由决策过去处理 MCP 工具请求时需要借助 njs 模块但只有在location完成/mcp匹配后才能开始处理。而现在通过client_body_early_read、原生 JSON 解析第三个新功能和谓词location可以直接从请求体提取信息如tools/call方法名并赋值给谓词变量从而让 NGINX 根据语义而非 URL 完成路由全程不需要第三方模块零额外开销。四、原生 JSON 解析和变量提取这是与client_body_early_read配合使用的核心能力。过去要从请求体中提取 JSON 字段必须借助 Lua 或 njs 等外部工具不仅增加依赖还带来额外性能开销。1.31.5 新增了原生 JSON 解析能力直接在 C 层面实现 JSON 内容提取开销极小。通过json_set指令可以轻松将 JSON 中的字段值赋给 NGINX 变量# 从请求体中提取 method 字段赋给 $json_method 变量 json_set $request_body $json_method method; # 也可以提取嵌套字段 json_set $request_body $tool_name params.tool.name;组合示例根据工具名称路由server { client_body_early_read on; # 从 JSON Body 中提取 method 字段 json_set $request_body $tool_name method; # 根据工具名称做谓词路由 location $tool_name { if ($tool_name ~ ^(listTools|callTool)$) { proxy_pass http://mcp_backend; } if ($tool_name ~ ^(search|query)$) { proxy_pass http://search_backend; } } }整个过程不需要任何第三方模块完全在 NGINX 原生 C 代码中完成。这也是新机制中唯一不需要在location中用js或 Lua 触发即可生效的配置。渲染错误:Mermaid 渲染失败: Parse error on line 3: ... A1[{method: callTool, param -----------------------^ Expecting SQE, DOUBLECIRCLEEND, PE, -), STADIUMEND, SUBROUTINEEND, PIPE, CYLINDEREND, DIAMOND_STOP, TAGEND, TRAPEND, INVTRAPEND, UNICODE_TEXT, TEXT, TAGSTART, got STR五、Control API运维能力下放社区版这是第四个大功能点主要面向运维人员。过去NGINX 的运行状态查询如进程列表、配置状态仅限 NGINX Plus 收费版本使用。1.31.5 将这些能力下放到了开源社区版。通过/1/control/processes、/1/control/config等 Control API 端点运维人员可以实时了解 NGINX 的运行状况。注意该功能必须以Unix Socket形式绑定到 NGINX不支持端口绑定。# 查询 NGINX 进程信息curl--unix-socket /tmp/nginx.sock http://localhost/1/control/processes# 查询当前配置状态curl--unix-socket /tmp/nginx.sock http://localhost/1/control/config# 动态更新配置PATCH 请求curl--unix-socket /tmp/nginx.sock-XPATCH http://localhost/1/control/config-d{method: reload}Control API 端点速查端点方法功能/1/control/processesGET查看 NGINX 进程列表/1/control/configGET查看当前配置状态/1/control/configPATCH动态更新配置如 reload/1/control/connectionsGET查看当前连接状态此外Control API 还支持查询当前连接状态/1/control/connections方便运维快速定位是否有请求积压、连接泄漏等问题。六、功能总结功能解决的问题对 AI Agent 的意义谓词 location路由维度单一支持多条件组合路由适应 Agent 多样化请求client_body_early_read请求体读取与路由串行并行处理降低延迟原生 JSON 解析依赖外部工具提取 JSON零开销解析语义路由成为可能Control API运维能力仅限商业版社区版运维能力补全前三个功能充分考虑 AI Agent 运行场景尤其是client_body_early_read 原生 JSON 解析 谓词 location的组合让 NGINX 能够根据请求语义而非仅仅 URL 进行路由。过去处理 MCPModel Context Protocol工具请求时需要借助 njs 模块但只有在 location 完成/mcp匹配后才进行。现在可以直接从请求体提取tools/call方法名并赋值给谓词变量从而让 NGINX 根据语义而不是 URL 完成路由不需要第三方模块零额外开销。这是 NGINX 在 AI Agent 时代的一次重要转身。从“路径匹配”到“语义感知”NGINX 正在从一个纯粹的 Web 服务器演变为 AI 流量感知和路由的基础设施层。
