很多人在给 AI 应用接接口时，手里已经有一个 Nginx，又被推荐加一层 API 网关，于是卡在「到底要不要多这一跳」。这篇不堆功能清单，只按转发、鉴权、限流三件事逐项对照两者各自擅长什么，再给一套从试跑、压测到正式切流的落地顺序，以及什么情况下继续用 Nginx 就够、什么情况下该补网关。
给 AI 应用接接口时，很多人手里已经有一层 Nginx 在跑，又被推荐再加一层 API 网关，于是卡在一个很实际的问题上：多这一跳到底值不值。回答之前先把问题拆开，转发、鉴权、限流三件事各自看重什么、谁能做得更省事，想清楚这三项，选型基本就定了。
这篇不罗列功能对照表，只按这三件事逐项说明差异，再给一条从小流量试跑到正式切流的落地顺序。需要先说明的是：下面所有「谁更擅长」都是倾向性判断，不是绝对结论，团队规模、服务数量、是否有外部客户，都会让结论反过来。
转发这一层：两者都在做，但管的对象不一样
Nginx 是通用反向代理，擅长的是静态资源、TLS 终止、按域名或路径把请求丢给后端。它的配置视角是「位置」，一个 location 对应一组后端。API 网关的视角是「接口」，它天然知道一个请求该落到哪个服务、哪个版本、哪条上游渠道，路由规则的表达能力更贴近业务。
- 只是把请求转给一个固定后端：Nginx 几行配置就够，加网关属于给自己找事
- 要按业务身份、按渠道、按版本分流：网关的路由模型更省事，Nginx 硬写也能实现，但配置文件会迅速变得难维护
- 两者都在做转发时，先问一句：这些分流规则多久改一次，改的人是不是运维
这里容易踩的坑是「两层都做 TLS 终止」或者「两层都设了不同的超时」，排障时根本分不清是哪一层把请求掐断的。如果决定双层都留，就把证书和连接管理统一交给最外层，内层只做路由，责任写进配置注释里。
鉴权与限流：谁做得更细
鉴权上，Nginx 原生只认得简单的 header 或 Basic 认证。要做 Key 校验、配额归属、按租户区分，基本得靠 Lua 脚本或者额外挂一个鉴权服务，这部分逻辑一旦复杂，就会变成没人敢动的配置。网关一般内置 Key 的签发、校验与吊销，这块是它的主场。
| 能力 | Nginx 的典型做法 | 网关的典型做法 |
|---|---|---|
| 请求鉴权 | header 透传、Basic 认证，复杂逻辑靠 Lua 或旁挂服务 | 内置 Key 管理，签发、校验、吊销一体 |
| 限流粒度 | 按连接数、按 IP、按请求速率，偏粗粒度 | 按 Key、按套餐档位、按接口分别计 |
| 计量与配额 | 要自己拼日志算账 | 原生带用量统计，能和套餐对齐 |
| 适合挡什么 | 突发流量、恶意刷接口 | 长期配额、多租户计费 |
限流这块的差异更明显：Nginx 的限流是「挡」，网关的限流是「算」。挡突发流量 Nginx 又快又稳；但要按客户档位分别计配额、月底能对得上账，网关省下的工作量是实打实的。判断标准很简单：如果限流规则里出现「不同客户不同额度」，就该考虑网关。
什么情况下不适用：团队只有一两个服务、调用方就是自己人，上面这些细粒度能力多半用不上，多一层网关反而多一个故障点和一份运维负担。这时候 Nginx 配好超时和缓冲就足够。
落地顺序：先跑通，再压测，最后切流
- 第一步：先把单层链路跑通不要一上来就双层代理，排错会很痛苦。先用一个后端、一条路由验证请求能通、超时符合预期，再考虑加层。
- 第二步：固定口径压测按接口类型分别跑，固定并发和请求量，记录失败率、P95 延迟、限流触发点。不同类型接口的超时差异很大，别混在一起算平均。
- 第三步：灰度切流先切一个渠道或一个客户端，观察错误码分布再放量。切流期间保留回滚开关，能一键退回原路径，回滚路径要提前演练一次。
- 第四步：对齐日志两层都要带同一个请求 ID，出问题时才分得清是网关慢、Nginx 慢还是上游慢。
如果需要压测，建议先到站内的 Agent 常用 API 清单（/stacks/agent-apis） 把要跑的接口类型拉全，再按类型分别定压测口径。漏掉流式接口，压出来的结论就是偏的。
一张对照清单，帮你当场定方案
- 只管转发、单后端、无多租户：Nginx 一层就够，配好超时与流式缓冲
- 需要按 Key 计配额、按套餐限速、要能随时吊销：在 Nginx 前面补一层网关，两层要能对上同一套 Key
- 已有网关但抱怨慢：先分清是网关慢还是上游慢，别急着换，到 真假在线实测（/tools/verify） 做一轮对照
- 两者都要：定好职责边界，Nginx 管连接与证书，网关管身份与配额，日志带同一个请求 ID
- 拿不准要不要加：先用网关试跑一个小渠道，观察规则变更频率再决定是否长期保留
这张清单也有失效的时候：如果业务要在多个云之间迁移、或者要对接第三方计费，网关的价值会被放大，Nginx 那条「一层就够」的结论就不适用了。反过来，如果团队没有人能长期维护网关的规则和升级，加了也是闲置。
下一步选型定完，接下来最该核的是上游渠道稳不稳，去中转站目录看看各家的可信度检测与实测记录，再决定流量往哪切。→常见问题
已经有 Nginx 了，再加一个 API 网关是不是多此一举？
取决于你要不要按身份分开计配额和限流。只做转发和证书终止，Nginx 够了；一旦需要按 Key、按租户区分额度并能吊销，网关省下的自研成本通常比多一跳的延迟更值。中间用同一个请求 ID 串起来，排错就不难。
Nginx 自己做鉴权，会不会比网关差很多？
不差，只是要写 Lua 或配合额外服务，维护成本落在自己身上。人数少、Key 不多时完全可行；难在 Key 的签发、过期、吊销这些生命周期管理，那部分自研容易出洞，这也是网关存在的主要理由。
限流放在 Nginx 还是网关，哪个更靠谱？
粗粒度挡洪水放在最外层（Nginx）更省资源，细粒度按业务配额放在网关更准。两边都配时注意阈值别打架：外层比内层宽松，否则请求进不来内层，你看到的限流数据全是假的。
