正向代理代表客户端发起外部请求。反向代理代表接收内部请求的服务器。 在正向代理与反向代理的决策中，首先要确定您想要控制的流量是：发起请求的个人或应用程序，还是接收请求的网站。
两者都是中介，并且都可以将请求继续发送。它们的名称描述了它们在架构中的角色，而不是对安全性、匿名性或性能的承诺。网站网关并不会自动成为外部浏览服务，购买外部代理也不会将您的应用程序公开给访客。
TL;DR
- 当客户端需要定义的外部路线或访问策略时，使用正向代理。
- 当访客需要访问您操作的应用程序的入口点时，使用反向代理。
- 身份验证、加密、缓存和日志记录取决于实际配置，而不仅仅是代理标签。
- 这两种角色可以在一个系统中共存，但它们有各自的所有者、凭据和故障模式。
- 住宅、ISP或数据中心标签描述的是网络提供；它并不取代正向与反向的区分。
一张表中的区别
| 问题 | 正向代理 | 反向代理 |
|---|---|---|
| 它是为谁服务的？ | 一个客户端或客户端组 | 一个服务器或服务器组 |
| 典型请求路径 | 应用程序 → 代理 → 目标 | 访客 → 代理 → 应用程序 |
| 通常由谁选择？ | 客户端操作员或网络管理员 | 网站或服务操作员 |
| 直接目标是什么？ | 控制或路由外部访问 | 接收和路由内部访问 |
| 典型身份验证关注点 | 这个客户端可以使用代理吗？ | 这个访客可以访问这个应用程序吗？ |
| 常见操作关注点 | 端点访问、凭据和外部策略 | 上游健康、路由、证书和源访问 |
| 它不自动提供什么？ | 您自己网站的公共入口点 | 与无关浏览器流量不同的外部身份 |
这些是典型角色，而不是对特定软件包的限制。一个有能力的网关可以支持多个功能，但每个功能仍然需要明确的配置。MDN关于代理服务器的概述区分了HTTP请求路径中的转发中介和网关。
正向代理的工作原理
想象一个报告应用程序向外部服务发起授权请求。它不是直接连接，而是通过配置的正向代理发送请求。代理建立下一个连接，并通过相同的逻辑路径返回响应。
客户端操作员可能希望集中管理外部策略、控制网络路线或支持应用程序到达目标的方式。确切的结果取决于协议、客户端的代理支持和提供商的配置。一些应用程序有自己的代理设置；其他应用程序则继承系统或环境设置。
重要的操作问题是，预期的应用程序是否实际使用了代理。在一个工具中更改设置并不能证明计算机上的每个进程都遵循它。后台服务、浏览器和命令行客户端可以具有不同的有效配置。
正向代理也不能保证目标不看到其他识别信息。请求可能包括账户凭据、cookie和应用程序数据。为合法的技术需求选择路线，并将数据处理与用于网络连接的地址分开评估。
示例：定期数据集成
考虑一个假设的集成，每天早上检索允许的供应商数据。其操作员希望请求通过一个文档化的端点发出。操作员配置集成的HTTP客户端，将代理凭据与供应商API令牌分开存储，并检查路线和应用程序行为。
代理凭据回答集成是否可以使用中介。供应商令牌回答它是否可以读取供应商的数据。一个有效的代理并不授予第二个权限。将这些责任分开使身份验证失败更容易诊断。
反向代理的工作原理
现在想象一个公共网站，其应用程序在一个私有服务端口上运行。访客连接到网站的前门。反向代理接收该流量并将其转发到配置的上游应用程序，然后返回应用程序的响应。
网站操作员选择上游并控制入口点。根据设计，反向代理可能处理TLS终止、服务之间的路由、缓冲或负载分配。这些是配置的能力，而不是假设每个部署都包括的功能。
NGINX反向代理文档解释了如何使用proxy_pass将请求传递给上游、设置请求头和控制缓冲。此指南专注于选择角色；安装和指令细节属于您实际部署的软件文档。
反向代理不能使不健康的应用程序变得健康。如果上游数据库不可用，在其前面放置另一个组件并不能恢复丢失的数据。它只能在架构设计为如此时提供受控的故障响应或路由到另一个健康实例。
示例：一个域下的两个内部应用程序
假设一个小团队操作一个仪表板和一个文档服务。这是一个假设的设计，而不是基准。反向代理可以提供一个定义的公共入口点，并根据配置的主机或路径将请求发送到适当的应用程序。
团队仍然需要决定谁可以访问每个应用程序，证书如何续订，以及源服务是否可以直接访问。整洁的域结构是有用的，但并不能取代访问控制。测试预期的公共路线和任何意外的替代入口点。
身份验证和信任在每一方都是不同的
正向代理可能在转发流量之前需要用户名和密码。应用程序也可能需要自己的目标凭据。在配置、日志和事件报告中保持这两种身份的分开。
使用反向代理时，访客可能会对应用程序或其前面的访问层进行身份验证。应用程序必须理解它可以信任哪些头部或身份声明。接受访客提供的身份头而没有受信边界可能会破坏预期的控制。
例如，应用程序可能希望在流量通过网关后记录原始访客地址。这需要一个故意的受信代理配置。仅仅读取转发的头部并不能确立其内容是权威的。应用程序和网关设置需要就哪些组件被允许提供它达成一致。
在任何设计中，定义谁可以更改路由配置。代理管理员可以影响请求的去向以及通过中介传递的信息。将该权限视为有意义的操作权限，而不是无害的便利设置。
任一代理是否自动加密所有内容？
不。单独识别连接。可能存在从客户端到代理的连接，以及从代理到目标或上游的另一个连接。在一个连接上的加密并不能确立另一个连接上的加密。
对于终止HTTPS的反向代理，决定与应用程序的连接是否也需要TLS，并验证相关的证书和信任设置。对于正向代理，将目标URL与用于到达代理端点的协议区分开。
将这些选择记录在架构记录中。避免标记整个路线为“安全”的图表，而不解释加密的开始和结束位置。有效的审查询问每个中介可以观察到什么，凭据在哪里传输，以及哪个方管理信任配置。
一个实用的选择过程
1. 用简单语言写请求
使用诸如“我们的工作人员调用外部API”或“客户打开我们的仪表板”的句子。命名请求者和目标。这个小练习通常会在任何产品比较开始之前识别出相关的代理区分方面。
如果需求仅说“我们需要一个代理”，请询问需要更改的内容：外部路由、内部应用访问、身份验证或流量管理。这些目标可能需要不同的组件。
2. 确定您控制的边界
列出客户端、中介和目标。标记您的团队操作的系统和属于其他组织的系统。不要设计一个假设对第三方网站拥有管理控制的解决方案。
对于您拥有的应用程序，您可以选择一个内部网关并配置源。对于第三方API，您控制您的客户端及其授权路线，但API的账户权限和使用规则仍然在该边界之外。
3. 定义所需的协议和行为
包括应用程序协议、身份验证方法、请求大小、流行为和预期连接持续时间。成功的短页面请求并不能证明长期流或大文件上传会正常工作。
使用代表性的授权测试，并记录客户端版本。避免将“代理”一词视为每个协议或身份验证机制都能正常工作的证据。兼容性是完整连接路径的属性。
4. 为每个故障分配所有者
决定谁检查客户端配置、代理可用性、应用程序健康和证书续订。给支持人员足够的清理信息，以区分代理身份验证失败与上游应用程序失败。
还要决定如何禁用或回滚路由更改。可逆配置比在故障期间每个人都发现的未记录依赖关系更容易操作。
5. 验证实际结果
对于正向代理，测试预期的应用程序是否遵循所选路线并完成其实际任务。对于反向代理，测试公共主机名、路由、身份验证和预期的上游行为。检查在您的设计要求的地方是否限制了意外的直接访问。
将结果保留为小的接受记录，而不是成功请求的屏幕截图。包括正常行为、一个受控故障和恢复步骤。这为未来的更改创建了参考。
系统可以同时使用两者吗？
可以。一个Web应用程序可以通过反向代理接收访客，同时其后台工作者使用正向代理进行授权的外部集成。这是不同的请求路径，即使组件在同一基础设施中运行。
保持它们的凭据、日志和配置名称的不同。“代理密码”在部署包含多个中介时是一个模糊的秘密标签。更喜欢能够识别服务和目的而不透露秘密本身的名称。
还要考虑故障独立性。如果外部代理不可用，公共应用程序是否应保持可用，而计划的集成暂停？如果内部网关失败，操作员是否仍然可以访问恢复控制台？这些问题揭示了一个组件是否意外地成为无关工作的依赖。
托管和代理产品的适用位置
服务器为您提供了运行软件的地方。转发服务为兼容客户端提供了请求的路线。它们可以结合使用，但没有一个自动包括另一个。现有的VPS与住宅代理的比较扩展了这一区分。
对于托管应用程序或网关，评估Cloud VPS的运行时和维护责任。如果您选择NGINX代理管理器，现有的NGINX代理管理器部署指南涵盖了该单独安装任务。更广泛的VPS管理指南与维护底层服务器相关。
外部代理的ISP或数据中心分类是一个不同的决定。它并不能告诉您您的网站是否需要反向代理，也不会消除配置身份验证和应用访问的需要。首先选择架构，然后根据特定需求评估网络提供。
常见问题
正向代理与反向代理的主要区别是什么？
正向代理为发起外部请求的客户端服务；反向代理为接收内部请求的应用程序服务。在选择软件或服务之前，确定您操作的哪一方以及您希望改变的流量行为。
反向代理可以改变我浏览器的外部IP吗？
仅仅通过存在于您网站前面是不行的。它处理发给其服务的应用程序的请求。通过中介路由无关的浏览器流量需要单独支持的正向代理或网络配置。
反向代理与负载均衡器是一样的吗？
不是。负载均衡是反向代理设计的一个可能功能。反向代理可以转发到单个上游，而负载均衡系统可以以不同的方式运行。检查实际配置，而不是假设标签的冗余。
正向代理使请求匿名吗？
没有这样的保证。账户登录、cookie、请求数据和操作员日志仍然重要。评估发送和保留的信息，并仅将该服务用于您被授权执行的访问。
我需要两个代理来处理一个小网站吗？
不一定。首先从应用程序的要求开始。托管服务可能已经处理了内部入口点，普通的外部请求可能不需要额外的代理。仅在它解决了文档化的需求并且有人可以维护时添加组件。
透明代理是第三个方向吗？
不是。透明性描述了在特定上下文中拦截或客户端意识的工作方式；它是一个与中介服务的请求方无关的独立维度。使用精确的流量路径描述，而不是将每个代理标签视为竞争架构。