反向代理和 API 网关可以位于网络图中的同一位置：两者都会在后端接收之前先接收客户端请求。区别在于您期望该层执行的工作。反向代理是用于转发、负载分配、TLS 终止和源站保护的实用入口。API 网关将请求视为一项 API 操作，并可添加身份识别、授权、配额、路由策略、可观测性以及受管理的开发者契约。任何一个标签本身都不能保证具备某项功能；请检查您实际部署的产品和配置。
对于 AI 应用，当多个模型、团队、凭证和账单汇集到一个端点时，这一区别就变得切实可行。本指南将在请求路径层面对比反向代理与 API 网关，说明何时其中一种已足够，并为 OpenAI 兼容的模型路由器提供评估清单。
简短回答
当您需要安全地暴露一个或少数几个后端服务，并且您的应用已负责 API 身份验证、使用策略和计费时，请使用反向代理。当多个客户端或服务需要一个通用 API 契约，并需要集中执行访问控制、速率或预算策略、路由、日志以及运营责任时，请考虑 API 网关。您也可以将 API 网关置于反向代理或 CDN 之后；这些组件并非互斥。
NGINX 反向代理指南介绍了将请求转发到上游服务器以及使用代理进行负载均衡。Amazon API Gateway 概述介绍了一个受管理的 API 入口，其具备流量管理、授权、监控和 API 版本管理功能。这些都是能力示例，并不意味着每个反向代理都缺少策略功能，也不意味着每个网关都会默认启用这些功能。
| 问题 | 反向代理 | API 网关 |
|---|---|---|
| 核心工作是什么？ | 接收流量并将其转发到源站或上游池。 | 在后端服务前发布和运营 API 契约。 |
| 如何选择路由？ | 通常基于主机、路径和上游配置。 | API 操作、身份、策略和已配置的后端路由都可能相关。 |
| 谁负责身份验证？ | 通常是应用或单独配置的身份验证层。 | 可在网关处强制执行，具体取决于其配置的机制。 |
| 如何查看使用情况？ | 访问日志和代理指标。 | API 或密钥级别的指标、日志、配额，有时还有计费记录。 |
| 运营工作包括什么？ | 代理配置、TLS、上游健康状况、扩缩容和日志记录。 | API 定义、密钥或身份、策略、配额、日志、版本和事件响应。 |
跟随一个请求了解每种设计
假设某个产品向提供模型服务的后端发送聊天请求。
使用反向代理时，客户端连接到一个公共主机名。代理终止 TLS，从配置的池中选择一个上游，转发 HTTP 请求，并返回响应。如果经过相应配置，它可能会重试或平衡流量。后端或其他组件仍需决定用户是否已获授权、他们可以调用哪个模型、可以花费多少，以及如何将使用量归因到团队。
使用 API 网关时，同一公共主机名还可以识别调用方、检查策略、选择获批准的路由、强制执行速率目标，并生成请求级记录。后端仍然执行推理，网关仍然需要正确配置。例如，AWS 对节流的文档说明了速率和突发设置，同时指出配额是尽力而为的目标，而非绝对上限。应将“速率限制”等营销术语视为可测试的行为，而不是自动保证。
两者存在重叠。NGINX 可以配置额外的身份验证和速率限制，API 网关也经常在内部使用反向代理机制。因此，选择的关键不在于是否可以转发数据包，而在于您的团队希望在何处定义、执行、观测并负责 API 策略。
负载均衡器的位置
负载均衡器在后端实例之间进行选择，以保持服务可用并分配工作负载。它可以在传输层或应用层运行。反向代理通常会执行负载均衡，但仅有负载均衡器并不能告诉您哪个 API 密钥属于某位客户，或者某个模型是否已获团队批准。API 网关可能包含负载均衡功能，也可能将其委托给上游服务。
使用这个快速测试：如果替换该组件只会移除流量分配和 TLS 处理，那么您主要是在评估代理或负载均衡层。如果它还会移除调用方策略、模型路由、配额、使用证据和 API 契约，那么您评估的是网关职责。
为什么模型 API 让差异显现
普通 Web 流量和模型流量都使用 HTTP，但模型请求带来了额外的运营问题。单个请求可能会长时间流式传输、使用大量输入和输出令牌、调用工具，或生成图像。两条模型路由可能具有不同的请求形态、延迟、可用性和成本单位。代理返回 200 并不足以说明客户是否获得了有用的答案，或哪个模型被计费。
因此，对 AI API 网关的评估至少应记录：
- 身份：哪个密钥、团队或服务发起了请求；凭据是否可以独立轮换。
- 路由：请求的模型别名、端点类别、实际路由，以及其不可用时会发生什么。
- 结果：HTTP 状态、提供商或模型错误、取消、超时、重试，以及最终被接受的响应。
- 用量：输入和输出单位、可计费事件，以及该路由所使用的成本来源。
- 控制：允许的模型、预算或配额范围、执行时机，以及负责例外情况的人员。
反向代理可以透传这些字段，但仅靠转发字节并不会建立一套统一认可的用量和计费模型。您可以自行构建这一层。问题在于，您的团队是否希望负责这项构建工作及其持续运营。
三种部署模式
1. 单一模型服务前的反向代理
对于只有一个模型、一个受信任应用程序且策略在应用程序中处理的私有服务，这是一个良好的起点。让代理负责入口流量、TLS、上游健康状况和基本请求日志记录。将密钥保留在服务器端。定义能够兼顾流式传输和长时间推理请求的超时设置，并测试取消功能，确保已放弃的流不会无限期占用资源。
失败模式是让代理变成一系列未文档化的模型别名、按团队划分的密钥、重试、支出规则和一次性标头的集合。如果这些功能不断累积，请记录下契约，并将其作为网关进行测试。
2. 自行运营的 API 网关或模型路由器
当平台团队需要自定义策略、网络部署位置、上游账户所有权或对日志和路由的深度控制时，请选择此方案。应为凭据存储、数据库或状态需求、升级、监控、备份、滥用控制和待命负责人做好预算。兼容 OpenAI 的端点可减少客户端迁移工作，但不会消除网关的运营负担。
如需单独比较购买与自建，请参阅我们的托管 AI 网关与自托管 LLM 代理指南。该指南讨论所有权和成本；本文的比较侧重于网络和 API 职责。
3. 托管 AI API 网关，可选择置于您的边缘代理之后
当团队需要统一的模型访问层、但不希望自行运营网关服务时，这种模式是合理的选择。Flatkey 的文档介绍了兼容 OpenAI 的路由器、模型访问、密钥和用量控制以及计费可见性。团队可以保留自己的边缘层或应用程序后端，同时将 Flatkey 用作上游模型 API。在切换到生产环境之前，请确认当前账户的模型别名、端点支持、限制、定价和策略行为。
对于Flatkey 快速入门中所述的兼容 OpenAI 路由，基础 URL 为 https://router.flatkey.ai/v1。请将 Flatkey 密钥放在后端环境中，而不是浏览器中。运行一个小型请求，检查 Usage & Logs，然后使用您打算使用的确切模型路由测试流式传输、工具、错误和回退。
揭示真正差异的迁移测试
选择一个具有生产环境特征的请求，并通过候选路径重放它。保持提示词、模型修订版本、输出上限、客户端超时和提供的负载不变。记录配置和结果，而不是将代理的最佳延迟与网关的冷启动或无关模型进行比较。
| 检查项 | 记录内容 | 重要的故障 |
|---|---|---|
| 身份验证 | 调用方密钥、权限、轮换路径 | 错误的团队可以调用模型，或已撤销的密钥仍然有效。 |
| 路由 | 请求和实际提供服务的模型、端点形式 | 回退在无提示的情况下改变能力或成本。 |
| 流式传输 | 首个 token、完整响应、取消 | 代理缓冲了流，或在取消后仍让工作继续运行。 |
| 限制 | 持续速率、突发流量、预算、重置窗口 | 过载到达模型，或配额阻断了正常流量。 |
| 可观测性 | 请求 ID、状态、用量、成本、延迟 | 您无法解释一笔费用或一次失败的请求。 |
| 恢复 | 超时、上游错误、重试上限 | 单个请求扩散为无限制的可计费重试。 |
然后衡量每个已接受响应的成本、p95 延迟、错误率和运营工作量。较低的代理开销很有价值，但不能替代缺失的策略或用量证据。功能丰富的网关只有在其控制机制与工作负载相匹配且确实已启用时才有价值。
常见问题
API 网关只是反向代理吗？
API 网关通常会转发流量，因此包含代理行为。该术语还意味着 API 层面的职责，例如调用方身份、策略、路由、监控和生命周期管理。实际功能因产品和配置而异。
NGINX 可以作为 API 网关吗？
NGINX 可以作为 API 流量的转发层，并可配置类似网关的控制功能。请确认您所需的确切身份验证、配额、日志记录和路由功能，然后明确由谁负责维护它们。仅凭产品名称并不能证明已部署的策略。
API 网关会取代负载均衡器吗？
不一定。网关可以选择一个上游池，而另一台负载均衡器负责实例级分发。绘制实际的请求路径，并确定哪个层负责健康检查、重试、TLS 和策略。
对于 AI API，何时简单的反向代理就足够了？
当一个受信任的后端负责授权、模型选择、用量计量和计费时，反向代理可满足入口需求。一旦多个团队、模型、外部客户端或支出策略需要共享一个统一边界，就应重新审视该设计。
实际的决策是将每项职责分配给一个明确命名的组件。如果您的图无法显示身份、路由、用量和成本在何处决定，那么再增加一个代理组件也无法修复缺失的约定。
