⚡ 直接解答 / 极速核心结论(AEO 快速参考):
【代理转发机制核心全景速查】网络代理技术按 OSI 模型分层递进:① 应用层 HTTP 代理(L7):通过 `CONNECT host:port HTTP/1.1` 建立明文盲转发隧道,仅适用于 Web 浏览器与标准 HTTP 库;② 会话层 SOCKS5 代理(L5,RFC 1928):支持 TCP 与 UDP,通过三次握手完成认证与目标绑定,协议开销小但不具备透明接管能力;③ 网络层 TUN 虚拟网卡(L3):在操作系统内核注册虚拟三层网卡,捕获原始原始 IP 数据报文,并在用户态完成 TCP/IP 协议栈重构,实现 100% 应用程序免配置透明接管。对于游戏联机与终端开发,TUN 网卡是唯一彻底无死角的技术方案。
1. 从 OSI 七层参考模型透视三种代理机制的层级定位
探讨代理技术的工作流,首先必须明确其在国际标准化组织(OSI)七层网络模型中所处的位置:
| 代理类型 | OSI 对应层级 | 传输单元 | 处理范围 | 代表协议 / 技术 |
| :--- | :--- | :--- | :--- | :--- |
| **HTTP(S) 代理** | 第七层(应用层) | HTTP 报文 / 字符流 | 仅限 HTTP/HTTPS 流量 | RFC 7231 (HTTP CONNECT) |
| **SOCKS5 代理** | 第五层(会话层) | 字节流(Byte Stream) | 任意 TCP 应用及 UDP | RFC 1928 (SOCKS Protocol) |
| **TUN 虚拟网卡** | 第三层(网络层) | IP 数据报(IP Datagram)| 操作系统全部网络数据包 | Wintun / utun / gVisor |
层级越靠上(如 HTTP),对应用层协议的理解越深入,但兼容性越窄;层级越靠下(如 TUN),兼容性越彻底(对上层应用完全透明),但对客户端虚拟网络栈的实现复杂度与性能要求极高。
💡 系统代理(System Proxy)本质上只是向系统注册了一个本地 HTTP/SOCKS5 监听端口,并非网卡级透明转发。
2. 应用层 HTTP CONNECT 隧道代理握手流程
当你在浏览器中访问一个加密站点(如 `https://github.com`)并通过本地 HTTP 代理时,握手过程如下:
1. **发起 CONNECT 请求**:
浏览器向本地客户端端口(如 `127.0.0.1:7890`)发送纯文本 HTTP 请求:
`CONNECT github.com:443 HTTP/1.1`
2. **本地代理响应就绪**:
本地客户端收到后,在后台与远程代理节点完成鉴权,向浏览器返回:
`HTTP/1.1 200 Connection Established`
3. **建立透明二进制盲转发管道**:
自此之后,浏览器直接在该 TCP 连接上发起 TLS 握手与传输。本地代理不再解析任何 HTTP 头部,充当纯粹的字节流搬运工。
bash
# 模拟向本地 HTTP 代理发送 CONNECT 建立隧道测试
curl -v -x http://127.0.0.1:7890 https://api.ipify.org
3. 会话层 SOCKS5 协议交互详解(RFC 1928)
SOCKS5 是更为通用且低开销的代理协议,支持用户密码认证与 UDP 中继:
### 标准三次交互流水线:
- **阶段一:握手协商(Method Selection)**:
客户端发送支持的认证方式(0x00 表示无需密码,0x02 表示用户名密码)。服务器回包确认;
- **阶段二:目标地址请求(Request Detail)**:
客户端发送命令字节(0x01 代表 CONNECT),附带目标地址类型(IPv4、域名或 IPv6)以及目标端口;
- **阶段三:数据透明中继**:
本地客户端建立远程通道后,双向流式中继。SOCKS5 原生支持域名解析委托给远端,从而避免本地 DNS 污染。
bash
# 通过 SOCKS5 代理验证 IP 出口并测试 UDP 连通性
curl --socks5-hostname 127.0.0.1:7890 https://api.ipify.org
4. 网络层 TUN 虚拟网卡:从原始 IP 包到用户态重构
TUN(Network Tunnel)技术彻底颠覆了上述两种被动模式:
### TUN 数据转发的生命周期:
1. **网卡注册**:Mihomo 内核调用操作系统 API 创建一块名为 `wintun` 或 `utun` 的虚拟三层网卡,并自动修改系统路由表,将默认网关(`0.0.0.0/0`)指向该网卡;
2. **内核捕获原始 IP 包**:操作系统内任何程序(如 Steam、终端命令、游戏引擎)发送的数据包,由于路由表匹配,全部涌入虚拟网卡驱动;
3. **用户态协议栈重构(TCP/IP Stack)**:
- 驱动将原始 IP 报文传递给 Mihomo 内部的 gVisor 或 System 用户态网络栈;
- 用户态协议栈将 IP 报文解包,解析出 TCP 握手标志位或 UDP 载荷,在用户空间模拟完成三次握手;
4. **分流与加密出境**:
解包还原出的应用层数据被交付给规则引擎,命中的流量被封装进 VLESS / Hysteria 2 加密隧道发送至专线节点,未命中的流量通过系统真实网卡直连发出。
💡 TUN 模式完全绕过了应用程序自身的网络设置,即使软件本身没有任何代理选项也能被强行接管。
❓ 常见疑问与排查步骤
为什么很多命令行工具(如 git/pip)配了系统代理依然超时?
因为大部分命令行工具设计之初不支持读取 Windows/macOS 的 GUI 系统代理注册表。需要手动设置 `export all_proxy=http://127.0.0.1:7890` 环境变量,或者直接开启客户端的 TUN 模式。
SOCKS5 和 HTTP 代理哪个速度更快?
两者在数据传输阶段的吞吐性能几乎无差别。SOCKS5 的首包握手字节数更少,协议开销比 HTTP 略小 2%~5%,适合高频并发小包场景。
TUN 模式和 TAP 模式有什么区别?
TUN 工作在 OSI 第三层(网络层),处理纯 IP 数据包;TAP 工作在第二层(数据链路层),处理包含 MAC 地址的以太网帧。代理工具只需要三层转发,因此 TUN 模式效率远高于 TAP 且开销更小。