代理原理：五种代理类型全解析

说实话，代理（Proxy）这个概念，很多搞了几年开发的人也未必说得清。

我记得刚入行时，以为代理就是“翻墙用的”。后来在甲方做渗透测试，自己搭 MITM 解密代理，才彻底搞明白——代理的本质是一个中间人。你想想看，客户端和服务器之间插一个中间节点，不就是中间人攻击吗？只不过我们把它用在安全审查上罢了。

什么是代理？

代理就是一个中间服务进程。它接收客户端的请求，转发给目标服务器，再把响应返回给客户端。就这么简单。

• 客户端 知道 代理的存在（显式代理）
• 客户端 不知道 代理的存在（透明代理）
• 代理代表 客户端（正向代理）
• 代理代表 服务器（反向代理）

一张图理清所有关系

我先把这五种代理的核心关系画出来。后面的讲解都围绕这张图展开。

正向代理 vs 反向代理

这是最核心的分类。方向决定了代理的用途和配置方式。

我个人习惯把正向代理叫“客户端代理”，反向代理叫“服务器代理”。理解了这个方向，剩下的全是技术细节。

HTTP代理

最早的代理方式。客户端发送 HTTP 请求，代理直接透传。

注意：HTTP代理只能代理 HTTP 流量。HTTPS 流量会直接失败，因为浏览器在 CONNECT 之前会先尝试 TLS 握手…… 嗯，这里要划重点——HTTPS 必须用 HTTPS代理或透明代理模式。

HTTPS代理

本质上是 CONNECT 隧道。客户端发送一个 CONNECT 请求，代理只负责建立隧道，不解析内容。

梯子原理说白了就是这样：客户端告诉代理“我要跟 google.com 建立 TLS”，代理就搭一条 TCP 隧道，后面所有字节原封不动转发。但我们的 MITM 代理不一样——它会拆开隧道，自己充当服务器端 TLS 终点。

CONNECT 请求示例：

CONNECT api.example.com:443 HTTP/1.1
Host: api.example.com:443
Proxy-Connection: Keep-Alive

代理返回 200 Connection Established 后，双方便进入裸 TCP 隧道。

透明代理

透明代理就是 客户端没配置代理，但流量被网络设备拦截并导向代理。最常见的场景：公司网关把所有 80 端口流量强制转发到内部代理服务器。

• 优点：客户端零配置，部署方便
• 缺点：无法处理 HTTPS 隧道（CONNECT 需要客户端主动发送）
• 实现方式：iptables 或策略路由做重定向

我记得刚学透明代理时，被“透明”两个字骗了——以为数据经过代理时是明文的。其实透明指的是客户端透明，不代表数据不加密。HTTPS 走透明代理依然是加密的，除非你像 MITM 一样拆包。

# 将出口 80 流量重定向到本机 3128
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 3128

# 如果是透明 HTTPS 代理还需要 443
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 443 -j REDIRECT --to-port 3129

四种代理的 MITM 适用性对比

咱们做 MITM 解密代理部署，最关心的是哪种代理能让我们看到明文。

几句话总结

别再被一堆名词搞晕了。你只要记住三点：

• 正向反向看方向。 正向代理帮客户端，反向代理帮服务器。
• HTTP 代理只能看明文。 HTTPS 想解密必须中间人证书。
• 透明代理是“不小心”被劫持的。 适合大规模部署但不适合精细控制。

我在做《MITM解密代理部署实践指南》课程测试时，实际上只用到了一个基础的正向 HTTPS 代理 + MITM 补丁的模式。下一节我们就会动手搭建这样一个环境。但在此之前，请确保你理解了上面几种代理的本质差异——尤其是 CONNECT 隧道和透明重定向。