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