正向代理和反向代理的根本区别在哪？
一句话：代理的方向相反，服务的对象也相反。正向代理代表客户端，把请求"送出去"；反向代理代表服务器，把请求"接进来"。英文名也点明了视角，forward proxy沿请求方向向前伸，reverse proxy站在请求的背面替源站接应。
| 对比维度 | 正向代理 | 反向代理 |
|---|---|---|
| 部署位置 | 客户端与目标服务器之间，靠近客户端 | 目标服务器前方，靠近服务端 |
| 服务对象 | 客户端 | 服务器 |
| 谁来配置 | 客户端主动配置或程序内指定 | 服务端运维部署，客户端无感知 |
| 对端看到谁 | 目标服务器只看到代理出口 | 客户端只看到代理，以为它就是源站 |
| 典型代表 | HTTP代理、SOCKS5代理、代理IP池 | Nginx、HAProxy、CDN、WAF、API网关 |
对数据采集工程师来说，这个区分不是概念游戏。写采集任务时配置的代理IP，全部是正向代理；目标网站用来做负载均衡和访问频率控制的网关层，几乎全是反向代理。分清两者，等于分清自己手里的工具和对端站点的入口架构。
正向代理是怎么工作的？
正向代理是客户端的"全权代表"。客户端不直接连接目标服务器，而是把请求交给代理，由代理代为访问并把响应转回来。对目标服务器而言，发起访问的是代理的出口IP，真实客户端不出现在链路对端。
客户端 → 正向代理 → 目标服务器
（显式配置） （只看到代理出口IP）三个关键特征：
- 显式配置：浏览器代理设置、程序里的proxy参数、环境变量HTTP_PROXY，配置动作全部发生在客户端侧
- 协议形态：HTTP代理、HTTPS代理、SOCKS5代理都是正向代理在不同协议层上的实现
- 出口属性：代理的出口IP、地理位置、运营商，决定了目标服务器眼中这次访问的来源
在网站采集器场景里，代理IP池就是一组可轮换的正向代理出口。舆情监测类任务需要在短时间内从同一批站点拿到大量页面，单出口容易触发目标站点的访问频率控制，按任务或按频次轮换出口是常规做法。
反向代理是怎么工作的？
反向代理是服务器的"前台接待"。客户端把请求发给自己以为的源站地址，实际先接住请求的是反向代理，再由它转发给内部真实服务器。客户端全程不知道、也不需要知道背后是哪台机器在响应。
客户端 → 反向代理 → 内部真实服务器
（以为对面就是源站） （不直接对外暴露）反向代理在生产架构里承担四类典型职责：
- 负载均衡：把流量按策略分发到后端多台服务器，Nginx与HAProxy是常见选择
- 缓存加速：静态资源在代理层直接返回，CDN本质上就是部署在各地的分布式反向代理集群
- 安全网关：WAF与访问频率控制在流量进入源站之前完成校验，429 Too Many Requests状态码由RFC 6585定义，网关层常用它表达请求过于频繁
- 统一入口：API网关把鉴权、限流、路由收拢到一处，后端服务只处理业务逻辑
多数工程师其实每天都在和反向代理打交道，只是没有意识到。打开一个大型网站，响应头里的CDN特征字段、Via字段、缓存命中标识，都是反向代理层留下的痕迹。
数据采集工程师为什么要分清这两者？
因为采集失败时，问题可能出在两类代理的任何一层，处理方式完全不同。这是实战里最值钱的区分。
第一层：选型。采集任务需要的代理IP是正向代理，配置在请求发起侧。选型时关注的出口IP质量、协议支持、并发承载，全部是正向代理侧的属性，和目标站点用什么反向代理无关。
第二层：排错。请求返回403或429时，先判断响应来自哪一层：
| 现象 | 更可能的位置 | 排查方向 |
|---|---|---|
| 连接代理超时、代理认证失败 | 正向代理层 | 检查代理可用性、账密、并发额度 |
| 403且响应头带CDN或网关特征 | 目标站反向代理层 | 出口IP信誉、请求频率、请求头完整性 |
| 429 Too Many Requests | 目标站反向代理层 | 降低并发、拉开请求间隔、轮换出口 |
| 状态码200但内容异常 | 可能命中缓存或挑战页 | 核对响应头缓存标识与内容一致性 |
第三层：链路叠加。一次采集请求的真实路径往往是：客户端，正向代理，目标站CDN或网关，源站。两类代理在同一条链路上各司其职，把"代理"当单一概念排查，很容易在错误的一层耗掉大半天。
招投标数据、直播数据监控这类高频采集场景里，目标站反向代理层的响应策略直接决定采集任务的并发上限怎么设计。工程师接手任务的第一步，不是急着调并发参数，而是摸清目标站点入口的架构形态。
采集场景下两者分别对应哪些具体组件？
对照一张表，把抽象概念落到日常技术栈：
| 正向代理侧 | 反向代理侧 | |
|---|---|---|
| 工程师接触的 | 代理IP服务、代理池、代理客户端 | 目标站点的CDN、WAF、限流网关 |
| 配置位置 | 自己的程序、采集框架、HTTP库 | 对方运维，无法配置 |
| 软件代表 | Squid、3proxy、各类代理服务 | Nginx、HAProxy、Envoy、云厂商负载均衡 |
| 可见性 | 完全可见、可更换 | 只能靠响应头和响应行为推断 |
两侧组件的技术栈几乎不重叠，这也是"代理"一词容易混淆的原因：同一个词，指代的完全是链路两端的两种角色。
如何判断一次请求经过的是哪类代理？
看三个信号：配置权、方向、响应痕迹。
- 配置权：需要自己显式填地址、端口、账密的是正向代理；在对端架构里默默工作的是反向代理
- 方向：替"出去的请求"服务的是正向；替"进来的请求"服务的是反向
- 响应痕迹：响应头出现Via、X-Cache、X-Served-By或CDN特征字段，说明请求穿过了对方的反向代理层。Via字段是HTTP标准允许代理附加的，按规范记录途经的代理节点
再给一个实用习惯：在采集框架里把正向代理配置和响应诊断日志分开管理。前者是可随时更换的资源，后者是判断目标站点架构的线索来源。日志里保留完整响应头，遇到批量失败时，能快速定位是代理侧问题还是目标站网关策略。
FAQ
Q：代理IP属于正向代理还是反向代理？
属于正向代理。代理IP服务提供的出口，本质是部署在服务商侧的正向代理节点，客户端配置后由它代为访问目标服务器。采集场景里说的"换IP"，换的就是正向代理的出口。
Q：Nginx是正向代理还是反向代理？
两种能力都具备，但最常用的角色是反向代理。生产环境中Nginx绝大多数以反向代理身份承担负载均衡和静态缓存；它也能配置成正向代理，不过在采集场景里，使用现成代理服务远多于自建Nginx正向代理。
Q：CDN算反向代理吗？
算。CDN是分布在多个地理位置的反向代理集群，边缘节点代替源站接收请求、返回缓存内容，符合反向代理的全部特征：服务对象是源站、对客户端透明、客户端感知不到背后的真实服务器。
Q：透明代理属于哪一类？
透明代理通常指无需客户端配置就在链路上截流的代理，多见于企业网关和公共网络环境。判断标准依然是方向：它代理的是"出去的请求"，本质是正向代理，只是配置方式从显式填写变成了链路自动接管。
Q：采集请求返回403，和反向代理有什么关系？
403通常由目标站点的网关层发出，也就是反向代理这一层。判断方法是看响应头有无CDN或WAF特征字段，再对照自己的正向代理是否工作正常。两层都健康时，403多与出口IP和请求频率有关，调整轮换策略比重试更有效。
Q：SOCKS5代理和HTTP代理都是正向代理吗？
都是，区别在协议层。HTTP代理工作在应用层，理解并可检查HTTP请求；SOCKS5工作在会话层，只做通用数据转发，不解析具体协议。对采集而言，HTTP代理调试直观，SOCKS5对非HTTP协议的流量更通用。
方向感决定排查效率。配在客户端的是工具，长在对端的是环境，工具可以更换，环境只能适应。下次遇到批量失败，先问一句：问题出在自己的正向代理，还是对方的反向代理？
