很多人第一次搭中转或排查转发问题时，都会卡在同一个地方：代理到底装在哪一头？有人说代理是给客户端用的，有人说代理是放在服务端前面的，两边听着都对，结果图画错了、配置也就跟着错。这篇不讲协议细节，只把「谁代理谁」这件事拆成可判断的几条标准，再给一套落到排错和选型上的动作，让你看到一张架构图就能说出代理在哪一层。
很多人第一次搭中转、或者排查转发问题时，都会卡在同一个地方：代理到底装在哪一头。有人说代理是给客户端用的，有人说代理是放在服务端前面的，两边听着都对，结果图画错了，配置也就跟着错。这篇不讲协议细节，只把「谁代理谁」这件事拆成几条可判断的标准，再给一套落到排错和选型上的动作。
先把结论摆在前面：正向代理作用在客户端这一侧，它代表客户端出去；反向代理作用在服务端这一侧，它代表服务端收流量。同一句话里的「代理」两个字，指的是完全不同的部署位置和责任边界。搞混了，后面超时、证书、鉴权、日志归属全都会跟着错位。
先看谁主动发起连接
判断代理类型的第一步不是看软件叫什么名字，而是看这次连接是谁发起的。客户端主动去找代理，代理再去找目标，这是正向代理；外部访问者以为自己连的就是服务端，其实先落到代理上，代理再转给后面的真实服务，这是反向代理。发起方在哪边，代理就属于哪类。
- 正向代理
- 客户端知道有代理，并主动配置它，代表客户端去访问外部目标
- 反向代理
- 访问者不知道有代理，看到的就是目标地址，代理代表服务端接收流量
- 站在客户端角度：正向代理是「我知道有代理，并且我配置了它」，反向代理是「我不知道有代理，我访问的就是我要的地址」
- 同一条链路上可能两种都有，别急着二选一，先分段看每段连接的主动方是谁
- 拿不准就把请求路径画出来，标出发起方，谁主动谁被动一目了然
- 如果路径里还有隧道或网关，先把它们单独拎出来判断，别混在一起贴标签
再看它部署在哪一侧
光看发起方还不够，还要看它在物理和网络上的落点。正向代理的部署位置跟着客户端走，通常和客户端在同一内网或同一台机器上，是客户端为了出去而走的口子；反向代理跟着服务端走，通常和服务端在同一侧，作为对外的统一入口，替服务端接住流量。
| 对比项 | 正向代理 | 反向代理 |
|---|---|---|
| 服务对象 | 客户端 | 服务端 |
| 部署位置 | 靠近客户端一侧 | 靠近服务端一侧 |
| 访问者是否感知 | 知道并主动配置 | 通常无感知 |
| 解决什么问题 | 客户端怎么出去 | 外部怎么进来 |
| 责任边界 | 管「谁出去」 | 管「谁进来」 |
这条口诀只在两段链路都清晰时成立。如果是多层结构，比如中间还叠了网关、缓存层或隧道，就要按每一段单独判断，不能整体贴一个标签。否则你会得到一个听起来没错、实际不能指导配置的结论。
为什么这个问题值得较真
配错类型最典型的后果，是把转发目标写在了错误的一侧。客户端该配代理地址的地方配了服务端地址，或者服务端入口该收流量的地方被当成客户端出口用，表现出来就是连不上、来回打转、证书对不上。这时候去翻超时参数往往是白费力气，因为方向从一开始就错了。
- 影响证书和鉴权的落点：客户端侧代理管的是「谁出去」，服务端侧代理管的是「谁进来」，两者的信任链根本不同
- 影响日志归属：出问题的连接到底该找哪一侧的日志，取决于代理站在哪边
- 影响排错顺序：先确认代理在哪一侧，再去看那侧的超时、并发和连接池，能省掉一大半无效翻查
- 如果团队里说法不统一，先把对照表写进文档，比反复争论快得多
判断代理位置只是排查的第一步，它不判断好坏。代理放在哪一侧本身没有优劣，取决于你要解决的是出口问题还是入口问题。真正要对照数字的时候，比如某条链路是不是变慢了，到站内页面核对当时的数字，别凭印象下结论。
落到实操：三步确认代理位置
- 从客户端发起一次访问在客户端所在机器上发起请求，看请求先到了哪个地址：是配置里的代理地址，还是业务域名。这一步定方向，先别急着改配置。
- 在服务端看进来的连接来源到服务端机器上看连接来源，如果来源是同一侧的代理地址而不是外部客户端，说明这一跳是反向代理；如果来源直接就是外部地址，说明这一侧没有替你挡在前面。
- 和架构图对一遍把实测结果和团队现有架构图对照，不一致就以实测为准，顺手把图改掉，别让下一个人继续按错图配。
验证时优先用现成手段拿事实，别只靠读配置猜。想确认链路是否真的通、是否真的走到你以为的那一跳，可以用站内 中转站真假在线实测（/tools/verify） 这类工具；想看这条路径上哪一跳拖慢了整体，先到 接口测速（/tools/speed-test） 量一遍延迟基线，再判断代理这一跳是不是瓶颈。
如果团队里对「转发」「网关」「隧道」这几个词的理解都不一致，先别讨论架构，先去 基础设施术语速查（/ai-dict/category/infra） 把词对齐。很多时候争论的不是方案，而是双方嘴里的同一个词指的是两件事。
最后提醒一句适用范围：上面这套判断标准针对的是「代理在链路中的角色」。如果一条链路里代理只是被当成纯转发用，既不为客户端出口服务、也不为服务端入口服务，那它更接近中间件的定位，不该硬套正向或反向的标签。遇到这种情况，按每段连接的实际主动方去描述，比强行归类更准确。
下一步把手里这张拓扑图按上面三步过一遍，确认每段代理站在哪一侧；顺手到站内的工具与资料页核对当时的实测结果和术语口径，比在群里反复争论快得多。→常见问题
是不是所有代理都能按正向、反向二分？
不一定。二分是判断位置和方向的入门框架，实际链路里常见一段正向接一段反向，中间还有网关和隧道。遇到混合链路别硬套，按每段连接分别判断谁主动、代理为谁服务，再拼出整张图，比给整条链路贴一个标签可靠。
代理服务器是不是一定作用在客户端上？
这句话只对正向代理成立。正向代理确实站在客户端这一侧，替客户端出去访问；反向代理站在服务端这一侧，替服务端接收外部流量，访问者通常感知不到它的存在。所以不能笼统说代理作用在客户端，要先说清是哪一类代理。
判断错了会有什么实际麻烦？
最直接的是配置写错方向，表现为连不上或请求绕回本地；其次是排查时找错对象，去翻客户端配置其实问题在入口侧，或反过来。另外证书、鉴权和日志的归属也会跟着错位。先确认位置，再动配置，能少走很多弯路。
