Русский
English
Українська
Deutsch
Español
Português
Türkçe
中文
隧道代理在客户端与目标服务器之间建立端到端连接，把所有流量封装在一条经过代理服务器的安全通道中，通常代理并不检查其中的内容。
理解流量隧道
通过代理进行流量隧道传输，意味着代理服务器充当原始数据流的中继，而不是应用层的中间人。传统正向代理会终结客户端连接、解析 HTTP 请求，然后再向源服务器发起新连接；隧道代理则不同，它在客户端与最终目标之间搭建一条直接的、逐字节转发的管道。该机制主要用于需要加密连接或非 HTTP 感知连接的协议，例如 HTTPS、SSH 或 VPN 流量。
CONNECT 方法
通过 HTTP 代理建立隧道最常见的方式是 CONNECT HTTP 方法。当客户端需要经由代理连接到非 HTTP 服务或加密的 HTTP 服务（HTTPS）时，它会向代理发送一个 CONNECT 请求。
客户端请求示例：
CONNECT www.example.com:443 HTTP/1.1
Host: www.example.com:443
Proxy-Connection: Keep-Alive
收到该请求后，代理服务器会尝试与指定的主机和端口（例如 www.example.com 的 443 端口）建立 TCP 连接。
代理响应示例：
HTTP/1.1 200 Connection established
Proxy-Agent: Squid/5.8
如果代理成功连接到目标，就会返回 200 Connection established 状态。从这一刻起，代理不再解读经过它的数据，而是作为一个简单的 TCP 中继，把客户端后续的所有字节转发给目标服务器，反之亦然。客户端与目标随后可以在这条隧道之上建立自己的协议（例如 HTTPS 的 TLS 握手）。
隧道代理的应用场景
隧道代理是多种网络运维和安全架构中不可或缺的一环。
- HTTPS（SSL/TLS）流量：主要用途。浏览器使用
CONNECT隧道传输 HTTPS 流量；由于代理不解密内容，客户端与 Web 服务器之间的端到端加密得以保持完整。 - 加密协议：任何基于 TCP 的加密协议，例如 SSH（Secure Shell）、SFTP 或 VPN 隧道（如 OpenVPN、WireGuard），都可以经隧道代理转发。
- 非 HTTP 协议：FTP、SMTP、IMAP 或自定义应用协议，只要配置为使用支持
CONNECT方法的代理或 SOCKS 代理，同样可以被隧道传输。 - 绕过网络限制：在某些环境中，基础防火墙可能阻止对特定端口或服务的直接连接。隧道代理可把这类流量经允许的端口（例如代理自身使用 80 或 443 端口）转发，从而有效绕过基于端口的限制。
- 保护隐私：由于代理不检查隧道内的内容，从代理的角度看，客户端与目标服务器之间通信的机密性得以保留。
隧道代理与其他代理类型的对比
厘清隧道代理与其他代理类型的差异，对正确部署和保障安全至关重要。
| 特性 | 隧道代理（例如 HTTP CONNECT） |
正向代理（非隧道 HTTP） | SOCKS 代理 | 反向代理 |
|---|---|---|---|---|
| 协议层 | 会话层/传输层（TCP） | 应用层（HTTP/HTTPS） | 会话层（TCP/UDP） | 应用层（HTTP/HTTPS） |
| 内容可见性 | 无（数据不可读） | 完全（解析 HTTP 头部/正文） | 无（数据不可读） | 完全（解析 HTTP 头部/正文） |
| 主要用途 | HTTPS、SSH、VPN、非 HTTP 的 TCP 连接 | 面向 HTTP 的缓存、过滤、日志记录、访问控制 | 通用 TCP/UDP 隧道、绕过防火墙 | 负载均衡、SSL 终结、为服务器提供防护 |
| 加密 | 保持客户端与目标之间的端到端加密 | 可对 HTTPS 解密并重新加密（中间人） | 保持端到端加密 | 可终结来自客户端的 SSL/TLS 并重新加密到后端 |
| 请求方法 | CONNECT |
GET、POST、PUT 等 |
CONNECT（SOCKS5） |
客户端直接请求后端服务 |
隧道代理的优势
- 安全性：隧道代理不解密也不检查隧道内的流量，因而保持了 TLS 等端到端加密协议的完整性，确保敏感数据在客户端与最终服务器之间保持机密。
- 协议无关：隧道一旦建立，代理便不关心所使用的应用层协议。这使得几乎任何基于 TCP 的服务都可以被隧道传输。
- 代理开销更低：由于代理不对隧道流量做深度包检测或应用层处理，其计算开销低于检查内容的代理。代理主要负责管理 TCP 连接状态。
- 灵活性：为原本可能被严格网络策略阻断的流量提供了一条通路，提升客户端连接各类服务的能力。
局限与注意事项
- 无法检查内容：无法检查隧道流量意味着代理不能实施基于内容的安全策略，不能进行病毒扫描、数据防泄漏（DLP），也无法基于应用层数据实现细粒度访问控制。若管理不当，这可能成为安全隐患。
- 规避安全管控：恶意行为者可以把非法流量封装进加密隧道，利用隧道代理绕过依赖内容检查的网络安全设备（例如入侵检测/防御系统、Web 应用防火墙）。
- 资源消耗：虽然不检查内容，但维持大量并发 TCP 隧道仍会占用系统资源（连接状态所需内存、打开的文件描述符、网络带宽）。
- 透明性：标准隧道代理是显式的，客户端必须配置后才能使用。透明代理通常不直接支持
CONNECT，但可能以拦截并重定向流量的方式，为特定协议模拟隧道行为。 - 策略执行：部署隧道代理的组织必须考虑其对网络安全与合规的影响。策略应规定哪些客户端可以建立隧道，以及可以连接哪些目标。
配置示例（Squid 代理）
把 Squid 这类代理服务器配置为允许通过 CONNECT 方法建立隧道很简单。下面的配置片段允许对标准 HTTPS 端口（443）、SSH 端口（22）以及一个特定的自定义端口（8443）发起 CONNECT 请求。
# 允许对标准 SSL/TLS 与 SSH 端口使用 CONNECT
acl SSL_ports port 443
acl SSL_ports port 22
acl SSL_ports port 8443 # 自定义安全端口示例
# 阻止对其他端口使用 CONNECT
http_access deny CONNECT !SSL_ports
# 允许其余所有流量使用 CONNECT
# 若有特定的拒绝规则，此规则应排在其后
http_access allow CONNECT
该配置在允许隧道的同时，将其限制在常用的安全端口或明确放行的自定义端口上，从而缓解了不受限隧道带来的部分风险。在生产环境中，通常还会实施更细粒度的访问控制列表（ACL），以限制客户端访问范围和目标地址。