代理是位于客户端（例如应用程序）和目标服务器（如后端 API）之间的中间服务器。 当应用程序发送请求时，代理会首先接收它。 然后，代理可以将请求转发到目标服务器、修改请求、阻止请求或直接返回响应。
简言之，代理代表客户端或服务器进行调解通信。
代理的工作原理
代理通过接收传入请求并执行以下一个或多个作，在 HTTP 级别（或其他应用程序协议）上运行：
- 将请求转发 到目标服务器，然后将响应中继回客户端。
- 转发之前修改标头、URL 或有效负载。
- 在本地截获 和响应请求，而无需联系目标服务器。
- 根据规则或访问策略拒绝请求。
从客户端的角度来看，它只是将请求发送到 URL。 代理处理幕后其他所有工作。 模式是客户端到代理再到目标服务器。
此模式引入了一层控制和抽象，可用于提高安全性、可观测性、性能和可测试性。
代理的类型
有不同类型的代理。 每个组件都适合系统架构中的特定角色。
转发代理
正向代理位于 客户端前面。 当应用程序发出请求时，它会通过代理，该代理决定是否以及如何转发它。 转发代理通常用于：
- 控制对外部资源的访问。
- 将客户端流量匿名化。
- 记录传出流量进行监视。
- 应用内容筛选或转换。
反向代理
反向代理位于 服务器前面。 客户端不知道底层后端基础结构。 反向代理接收传入的请求并将其转发到多个后端服务器之一。 反向代理通常用于：
- 跨多个服务对流量进行负载均衡。
- 提供缓存响应以减少后端负载。
- 终止 TLS/SSL 连接。
- 对公共 Internet 隐藏内部服务详细信息。
透明代理
透明代理会截获流量，而无需显式配置客户端来使用它。 此类型用于企业或 Internet 服务提供商环境，以强制实施策略或监视使用情况。
为什么代理对应用程序开发人员很重要
基础结构或网络团队通常管理代理。 但是，代理直接影响应用程序行为，尤其是在开发和测试环境中。 以下是影响日常工作的一些实际方法。
调试和可观测性
代理可以捕获和检查 HTTP 流量。 开发代理、Fiddler、Proxyman、Charles Proxy 或 mitmproxy 等工具充当本地转发代理。 可以通过它们运行应用程序来分析请求和响应、发现错误以及验证标头或身份验证令牌。
API 网关和路由
在许多生产系统中，发往应用程序的后端的流量通过 API 网关或反向代理（例如 NGINX）或 Azure API 管理等云原生服务进行路由。 这些代理处理路由、身份验证、速率限制等。
设计 API 或生成分布式服务时，必须了解代理如何影响标头（例如 X-Forwarded-For）、超时和请求大小限制。
CORS 和本地开发
在本地开发期间，尤其是在 Web 应用程序中，从浏览器调用 API 时，可能会遇到跨域资源共享（CORS）限制。 开发代理可以在重写标头以绕过 CORS 限制时将请求转发到目标 API。 重写 CORS 请求的开发人员工具的常见示例包括 Express 或 ASP.NET Core 等框架中的 vite、webpack-dev-server或自定义代理中间件。
服务虚拟化和测试
代理可以模拟后端 API。 当实际服务不可用、不稳定或测试期间使用成本高昂时，此功能非常有用。 通过拦截和模拟响应，可以在不同场景下测试应用程序的行为，例如超时、错误或格式错误的数据。
开发代理或自定义代理实现等工具通常用于集成和端到端测试。
身份验证和安全性
代理通常是保护应用程序时防御的一线。 他们可以强制实施访问控制、注入身份验证标头或终止 TLS/SSL 连接。 作为开发人员，请务必了解应用程序在代理后面的行为方式，以及如何访问携带身份验证或标识信息的标头。
常见标头和代理注意事项
当请求通过代理传递时，会添加或修改某些标头以保留重要的元数据。 例如：
-
X-Forwarded-For：指示客户端的原始 IP 地址。 -
X-Forwarded-Proto：指示原始协议（HTTP 或 HTTPS）。 -
X-Forwarded-Host：指示客户端请求的原始主机。
当您的应用程序在反向代理后面运行时，请确保您的框架或平台已配置为信任并正确解析这些请求头。
使用代理测试应用如何处理 API 失败
由于转发代理会看到应用发送的每个请求，因此它还可以以失败响应其中一些请求，而不是转发它们：一个 500、一个带有 Retry-After 标头的 429 Too Many Requests，或者一个需要 8 秒的响应。 应用会持续调用真实的 API URL，因此你可以像在生产环境中一样对应用进行测试，包括其 HTTP 客户端、SDK 和重试策略。
与其他测试 API 失败的方法相比：
| Approach | 你找到的内容 | 您错过了什么 |
|---|---|---|
| 等到投入生产后 | 真实故障 | 所有内容，直到用户遇到故障 |
| 在测试中模拟 API，或让编码代理编写模拟对象 | 错误分支是否会运行 | API 的实际状态代码、标头和错误正文，以及 SDK 的重试策略。 你的应用还需要一个仅限测试的开关才能访问模拟服务。 |
| 调用真正的 API 并希望它失败 | 实际行为 | 无法按需触发故障 |
| 通过可模拟故障的代理运行应用 | 实际 URL 的错误、限流和延迟（按需） | 隔离状态下的你的代码。 保留你的单元测试以验证这一点。 |
开发代理充当用于开发和测试的转发代理
Dev Proxy 是在计算机或 CI 中运行的转发代理，用于截获和修改从应用程序到所选 API 的请求。 通过 Dev Proxy（开发代理），您可以：
- 了解应用如何响应 API 错误。
- 验证应用如何处理 API 速率限制和节流。
- 了解应用如何处理慢速 API。
- 无需编写一行代码即可快速搭建模拟 API。
- 获取有关如何使用 API 的情境指导。
若要在你的应用调用的 API 上试用，请下载预设并使用它启动 Dev Proxy。 例如，对于GitHub：
devproxy config get github-rate-limiting
devproxy --config-file "~dataFolder/configs/github-rate-limiting/.devproxy/devproxyrc.json"
预设也可用于 OpenAI（openai-throttling）、Anthropic（anthropic-throttling）和Microsoft Graph OneDrive和SharePoint终结点（microsoft-graph-rate-limiting）。
亲自试一试
选择一个与你正在构建的内容相匹配的场景：
- 测试应用如何处理 API 错误 （5 分钟）
- 模拟任何 API 的速率限制 （10 分钟）
- 模拟 API 响应而不更改代码 （10 分钟）
- 开发时使用本地模型而不是 OpenAI （15 分钟）
