nginx仅应承担连接层安全、基础鉴权兜底、连接/并发限制及静态资源托管等传统反向代理职责；流式响应控制、token计量计费、语义路由、内容合规后处理等ai核心能力绝不能依赖nginx实现，须由专用ai网关承担。
直接用 Nginx 做面向大模型与生成式 AI 的网关，是常见但高风险的起点——它能转发请求，但无法应对流式响应、token 计费、模型语义路由、上下文长度校验等核心需求。规范不是“怎么配 Nginx”，而是“哪些必须由 Nginx 承担、哪些绝不能交给 Nginx”。以下是基于多个企业生产事故复盘提炼出的关键规范。
必须由 Nginx 承担的基础层能力
这部分属于传统反向代理职责，Nginx 做得足够好，应保留：
- 连接层安全控制：强制 HTTPS、TLS 1.2+、禁用弱密码套件；对上游模型服务启用 mTLS 双向认证（尤其私有部署模型）
- 基础鉴权兜底：用 JWT 或 API Key 在入口做初步身份识别（如验证租户 ID、应用标识），但不处理细粒度权限（如“能否调用 RAG 工具”）
-
连接数与并发限制：用
limit_conn控制单 IP/单租户最大连接数，防慢连接耗尽资源；用limit_req对非流式接口（如健康检查、元数据查询）限速 - 静态资源与协议桥接：托管前端 SDK、OpenAPI 文档；将 WebSocket 请求（如语音链路）或 gRPC-Web 流量透传至后端推理网关
绝不能依赖 Nginx 实现的 AI 特性
这些能力若强行用 Lua 或 OpenResty 补丁实现，会迅速演变为技术债黑洞：
-
流式响应缓冲与背压控制：Nginx 默认按 chunk 缓存整个 SSE 响应体，50 个并发流即可打爆内存；它无法感知 token 生成节奏，也无法向客户端发送
retry:指令或动态调整流速 -
Token 级计量与计费拦截：Nginx 无法解析 JSON 结构中的
usage.input_tokens，更无法在响应返回前完成 token 核算、配额扣减、超限熔断 - 模型语义路由：比如根据用户提问是否含“代码”关键词，自动切到 CodeLlama；或根据历史对话长度，降级到上下文更短的模型——这需要自然语言理解，非正则匹配可胜任
- 输出内容合规后处理：脱敏姓名、过滤敏感词、标准化 JSON Schema 输出格式等，需结构化解析响应体，Nginx 的字符串操作极易破坏流式数据帧边界
可作为过渡方案的 Nginx 辅助配置
当短期无法替换网关时，可用以下配置降低风险，但需明确其临时性：
-
超时精细化分层设置：对
/v1/chat/completions接口设proxy_read_timeout 120（支持长流），对/v1/models元数据接口设proxy_read_timeout 5 -
Header 透传增强：用
proxy_set_header X-Request-ID $request_id和X-Model-Intent $arg_intent（从 query 参数提取）为下游网关提供原始上下文 -
主动健康检查扩展：配合 vLLM 或 TGI 的
/health接口，用 Nginx Plus 或自定义脚本探测 GPU 显存占用率，而非仅 HTTP 状态码 -
错误响应标准化：用
error_page 503 /503.json返回统一 JSON 错误体，避免前端解析 HTML 错误页
真正该投入的地方：用专用 AI 网关替代 Nginx 核心逻辑
规范的落脚点不是优化 Nginx，而是明确它的边界：
- Nginx 定位为边缘接入层，只管连接、加密、初步分流；所有 AI 语义层能力（路由、编排、计量、审计、缓存）必须下沉到专用 AI 网关（如自研网关、MAI Gateway、BentoML Router 或 KubeRay + LLM Orchestrator）
- 业务系统只对接 AI 网关的统一 REST/SSE 接口；AI 网关再通过 Nginx 或直连方式调度后端模型集群
- 所有可观测性指标（模型调用成功率、平均 token 成本、P95 延迟、工具调用分布）必须从 AI 网关埋点，Nginx 日志仅作辅助溯源
