看站在谁一侧
| 类型 | 代表谁 | 典型用途 |
|---|---|---|
| 正向代理 | 客户端 | 翻墙、内网出网、缓存加速 |
| 反向代理 | 服务端 | 负载均衡、TLS 终止、隐藏后端 |
正向代理
客户端配置它，所有出站请求先到代理，再由代理去取资源。用户知道自己在用代理，常用于访问受限资源或统一出口。
反向代理
部署在服务端前面，对外是一个地址，内部把请求分发给多台后端。用户感知不到后端存在。Nginx、网关、CDN 边缘节点都是反向代理。
它顺手做的事
- TLS 终止：在代理层解密，后端走内网明文更省 CPU；
- 负载均衡：把流量摊到多实例；
- 统一安全头与限流：在边界集中处理。
实战案例：三个代理引发的诡异问题
- 拿不到真实客户端 IP：经反向代理后服务端看到的都是代理 IP，日志与限流失效。需要透传
X-Forwarded-For，并只在可信代理层解析。 - 重定向到内网地址：应用按内部 Host 生成跳转地址，用户被跳去
http://10.x.x.x。应透传X-Forwarded-Host与X-Forwarded-Proto，让应用生成外部地址。 - 正向代理变成开放代理：内网代理未做鉴权与出网白名单，被外部扫描后用于发起攻击。正向代理务必限制来源与目标。
常见问题（FAQ）
正向与反向代理怎么区分？正向代理代表客户端访问外部；反向代理代表服务器对外提供服务。X-Forwarded-For 能直接信任吗？不能，它可被伪造；只在请求确实来自可信代理时才可信，并应取最右侧的可信值。反向代理能替代负载均衡吗？常配合使用：反向代理做 TLS 终止与路由，负载均衡负责分发与健康检查。要不要在代理层限流？可以在边缘拦下大部分异常流量，但业务级限流仍应在应用或网关按用户维度实现。
代理配置的排查与验证
代理位于链路中间，一旦配置有误，问题往往表现得与代理本身无关。以下步骤可以在上线前后快速确认配置是否正确。
- 逐跳打印请求头：在代理与应用两侧分别记录进入与离开时的关键头（来源地址、主机名、协议、请求标识）。多数“找不到真实来源”的问题，靠对比两侧的头就能立刻定位是代理没加，还是应用没读。
- 统一可信代理范围：应用只应信任来自已知代理网段的转发头，其它来源的同名头一律忽略。否则任何人都能伪造来源地址与协议，绕过基于地址的限流与审计。
- 注意重定向与静态资源：应用生成的重定向地址、静态资源链接与邮件里的链接都依赖外部主机名与协议。若只透传了来源地址而漏了主机名与协议，用户会被跳到内网地址或 http 链接。
- 超时链路要一致：代理的超时必须大于应用的正常处理时间，但小于上游等待时间。逐层放大是级联超时的典型成因，应统一规划每一层的超时预算。
- 连接复用与空闲回收：代理到后端的连接池过大或空闲回收过慢，会在后端重启后继续使用失效连接，表现为零散的 502。应缩短空闲回收时间并启用健康检查。
安全边界
反向代理常被用来终止 TLS 与做统一鉴权，因此它是安全边界的一部分：证书管理、访问日志与限流策略都应在此层落实；而正向代理必须做身份识别与出网白名单，绝不允许成为任何人都能使用的公开出口。