53.NginxAPI-Gateway与鉴权如何保护大模型接口

Nginx、API Gateway 与鉴权：如何保护大模型接口？

码海寻道 · 大模型、智能体与 RAG 工程组件系列第 53 篇

大模型接口通常具有响应慢、连接长、调用贵和权限敏感的特点。把 API 直接暴露在公网，容易遭遇未授权访问、暴力调用、Token 消耗和错误配置。Nginx 或 API Gateway 可以在业务服务前面增加统一的流量和安全边界。

一、反向代理解决什么问题？

text 复制代码

客户端
  ↓ HTTPS
Nginx / API Gateway
  ├── TLS 终止
  ├── 路由
  ├── 鉴权
  ├── 限流
  ├── 请求大小与超时
  └── 日志和追踪头
       ↓
FastAPI / Worker API

应用服务不必直接处理所有公网连接，但真正的业务授权仍需在应用层再次验证。

二、Nginx 反向代理示例

nginx 复制代码

server {
    listen 443 ssl;
    server_name ai.example.com;

    client_max_body_size 50m;
    proxy_read_timeout 300s;

    location /api/ {
        proxy_pass http://rag_api:8000;
        proxy_http_version 1.1;
        proxy_set_header Host $host;
        proxy_set_header X-Request-ID $request_id;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_buffering off;
    }
}

SSE 接口通常需要关闭代理缓冲，并设置合理的读取超时。上传接口、普通 API 和流式接口不一定使用相同的超时和大小限制。

代理配置应按接口类型拆分：上传关注 body 大小和上传时长，聊天关注长连接与读取超时，普通查询关注低延迟，管理接口还要限制来源网络和操作频率。不要用一个全局超时和一个全局限流值覆盖所有请求。

三、API Gateway 和 Nginx 怎么区分？

Nginx 可以完成反向代理、TLS、路由和基础限流；API Gateway 往往还提供：

API Key、JWT、OAuth/OIDC；
租户和消费者管理；
配额、计费和用量统计；
版本路由；
插件和策略中心；
多服务聚合。

小团队可以从 Nginx 加应用鉴权开始，等 API 数量、团队和治理需求增长后再引入专门 Gateway。

无论使用哪一层，必须明确可信代理边界：应用只信任经过验证和清理的 X-Request-ID、用户身份和转发头，不能让公网客户端伪造 X-User-ID 或 X-Tenant-ID。网关与应用之间应使用 TLS、内网访问控制或服务身份认证。

四、鉴权和授权不是一回事

鉴权 Authentication

确认"你是谁"，例如验证 JWT、Session 或 API Key。

授权 Authorization

确认"你能做什么"，例如能访问哪个租户、知识库和工具。

text 复制代码

Gateway：验证令牌基本有效
应用服务：验证资源权限和业务规则
数据库/向量库：执行最后的数据范围约束

不能因为 Gateway 验证了 JWT，就跳过应用层权限检查。

五、JWT 校验要关注什么？

签名算法和密钥来源；
iss、aud、exp 和 nbf；
密钥轮换和 JWKS 缓存；
Token 撤销和登出策略；
租户、角色和权限声明是否可信；
时钟偏差和过期处理。

JWT 中的 tenant_id 只能作为身份声明的一部分，最终资源权限仍应由服务端根据数据库关系判断。

JWT 校验失败、过期、签名密钥轮换和 JWKS 不可用应分别记录原因；不要为了"保证可用"在无法验证签名时接受旧 Token。长任务和 SSE 连接还要确认 Token 过期后的续期、取消和断线重连语义。

六、限流和配额

大模型接口至少设置多层限制：

text 复制代码

IP：防止明显攻击
用户：限制个人并发
租户：控制总预算
模型：保护上游配额
接口：上传、聊天、Agent 分别限流

返回 429 Too Many Requests 时，应提供重试提示和 trace_id。限流可以在 Gateway 做第一层，Redis 或应用服务做精细配额。

配额要按用户、租户、接口、模型和成本分别统计，并区分并发数、请求数、Token 和文件大小。限流存储故障时要有明确策略：高风险写操作倾向于拒绝，普通问答可以短时降级，但不能因为 Redis 故障就无限放行昂贵调用。

七、超时、重试与长连接

大模型请求可能需要较长时间，但不能把所有超时无限放大：

API Gateway 读取超时要覆盖正常生成时间；
上游模型超时要有预算；
重试只针对明确的暂时性错误，并携带幂等键；
客户端断开后要取消或回收下游模型、工具和任务；
网关超时、应用超时和供应商超时要能通过 trace_id 区分。
重试只针对明确的临时错误；
SSE 断开后不要自动重复扣费；
取消请求应传递到模型和工具层。

八、保护错误和日志

公网响应不应返回：

数据库连接串；
内部服务地址；
完整 SQL；
模型供应商密钥；
其他租户的资源 ID。

访问日志要记录请求 ID、用户、租户、路由、状态码、延迟和用量，但对 Prompt、文件名和敏感内容脱敏。

九、生产检查清单

全链路使用 HTTPS；
Gateway 和应用均有鉴权/授权边界；
JWT 校验和密钥轮换可用；
上传、聊天、Agent 有独立限流；
SSE 缓冲和超时已配置；
大模型错误不会直接暴露内部信息；
请求 ID 与 Trace ID 可关联；
生产 API 禁止调试接口和默认账号。

结语

Nginx 和 API Gateway 负责把公网流量变得可控，鉴权负责确认身份，应用和数据层负责授权。大模型接口还需要额外关注长连接、成本限额、取消和重试，不能直接套用普通 CRUD API 的默认配置。

下一篇将讨论 Kubernetes：RAG 系统什么时候真的需要它。

参考资料

本文为"码海寻道"原创技术文章。鉴权、限流和 TLS 配置需要结合部署环境与安全评审验证。