传统协议

传统代理协议是指那些在现代代理技术兴起之前就已广泛使用的协议，包括 HTTP 代理、SOCKS 代理、SSH 隧道和 Tor 洋葱路由。尽管它们大多不具备专门针对深度包检测的防护设计，但在特定场景下仍然具有实用价值，并且是理解现代代理协议演进的重要基础。

HTTP 代理

概述

HTTP 代理是最古老也是最简单的代理形式，历史可以追溯到 1990 年代初期 Web 的早期发展阶段。它运行在应用层，通过拦截 HTTP 请求并代为转发来实现代理功能。

工作原理

HTTP 代理有两种主要的工作模式：

正向代理（HTTP CONNECT）：

用于代理 HTTPS 或任意 TCP 流量。客户端首先向代理服务器发送一个 CONNECT 请求，建立隧道后再传输实际数据：

客户端
  |
  | CONNECT target.com:443 HTTP/1.1
  v
HTTP 代理服务器
  |
  | 与 target.com:443 建立 TCP 连接
  | 返回 200 Connection Established
  v
目标服务器（通过隧道透明传输）

普通 HTTP 代理：

用于代理明文 HTTP 请求。客户端将完整的 URL 发送给代理服务器，代理代为请求并返回响应：

客户端 → GET http://target.com/page HTTP/1.1 → 代理 → 目标

认证机制

HTTP 代理支持基本认证（Basic Auth）：

Proxy-Authorization: Basic base64(username:password)

认证信息以 Base64 编码传输，注意 Base64 不是加密，只是编码——在明文 HTTP 中传输时凭证实际上是暴露的。如果需要安全认证，必须搭配 TLS（即 HTTPS 代理）。

优缺点

优点	缺点
配置极其简单，几乎所有软件都支持	明文 HTTP 流量完全暴露，无加密
系统级代理支持，无需额外软件	不适合在不受信任的网络中使用
调试方便，可以看到请求内容	没有流量混淆，流量特征极为明显
支持认证	Basic Auth 的凭证未加密（HTTP 时）
广泛用于企业内网环境	主动探测几乎没有任何防护

适用场景

企业内网或受信任网络中的流量转发
开发调试环境（如使用 Charles、Burp Suite 进行 HTTPS 抓包）
程序的代理设置（许多命令行工具通过 HTTP_PROXY / HTTPS_PROXY 环境变量使用 HTTP 代理）
作为其他代理工具链的中间层（如 Mihomo 提供的本地 HTTP 代理端口）

关于 HTTPS 代理

当 HTTP 代理搭配 TLS（即客户端到代理服务器的连接也使用 HTTPS）时，通常称为 HTTPS 代理或安全 HTTP 代理。NaiveProxy 的服务端就是这种形式——通过 HTTPS 方式暴露 HTTP CONNECT 代理接口。

环境变量配置

许多 Linux / macOS 命令行工具遵循以下环境变量：

export HTTP_PROXY=http://127.0.0.1:7890
export HTTPS_PROXY=http://127.0.0.1:7890
export NO_PROXY=localhost,127.0.0.1,::1

SOCKS 代理

概述

SOCKS（Socket Secure）是一种通用的代理协议，设计目标是在不同网络之间透明地转发任意 TCP 连接，后来也扩展支持了 UDP。与 HTTP 代理不同，SOCKS 工作在更低的会话层，对上层协议透明——无论是 HTTP、FTP、SMTP 还是自定义协议，SOCKS 都可以代理。

SOCKS 目前有两个主要版本：

版本	发布时间	主要特性
SOCKS4	1989	仅支持 TCP，仅支持 IPv4，认证机制简单
SOCKS4a	1990s	SOCKS4 的扩展，支持域名解析
SOCKS5	1996（RFC 1928）	支持 TCP 和 UDP，支持 IPv4、IPv6 和域名，支持多种认证方式

SOCKS5 工作原理

SOCKS5 连接建立分为三个阶段：

阶段一：协商认证方式

客户端 → 服务端：支持的认证方式列表
服务端 → 客户端：选择的认证方式

阶段二：认证（如果需要）

客户端 → 服务端：用户名和密码
服务端 → 客户端：认证成功/失败

阶段三：发送代理请求

客户端 → 服务端：CONNECT/BIND/UDP ASSOCIATE 命令 + 目标地址
服务端 → 客户端：成功响应
→ 开始透明转发数据

SOCKS5 的 UDP 支持

SOCKS5 的 UDP ASSOCIATE 命令允许客户端通过代理服务器转发 UDP 数据包。这是 SOCKS5 相比 HTTP 代理的重要优势，适用于需要 UDP 的应用（如 DNS 查询、视频通话、游戏）。

客户端
  |
  | 1. TCP 控制连接：UDP ASSOCIATE 请求
  | 2. 服务端返回 UDP 绑定地址和端口
  | 3. 客户端向该地址发送 UDP 数据包（带 SOCKS5 UDP 头部）
  v
SOCKS5 服务端
  |
  | 4. 剥离 SOCKS5 UDP 头部，转发给目标
  v
目标（UDP）

SOCKS5h 变体

SOCKS5h（SOCKS5 with remote DNS）是 SOCKS5 的一个变体，表示 DNS 解析发生在代理服务器端而不是客户端。当客户端使用 SOCKS5h 时，域名不会在本地解析，而是作为字符串原样传给代理服务器，由代理服务器负责解析。这对于避免 DNS 泄露非常重要。curl、wget 等工具支持通过 socks5h:// 协议前缀使用此模式。

优缺点

优点	缺点
协议透明，支持几乎任意 TCP/UDP 应用	无加密（SOCKS5 本身不加密流量）
SOCKS5 支持 UDP，适用范围比 HTTP 代理更广	流量特征明显，无混淆能力
支持 IPv6	需要应用程序原生支持或使用 ProxyChains 等工具
客户端支持极广泛	不适合需要隐蔽性的场景
可用于代理链（Proxy Chain）	—

适用场景

作为本地代理软件（Mihomo、sing-box 等）的本地监听接口，供系统或应用程序使用
配合 ProxyChains 在 Linux 上将不支持代理的程序强制走代理
作为代理链中的一环（如 Mieru 客户端暴露 SOCKS5 端口供第三方工具使用）
在安全受信任的内网环境中提供通用代理服务

在代理软件中的作用

现代代理软件（如 Mihomo、sing-box）的本地监听接口通常同时暴露 HTTP 代理和 SOCKS5 代理两种接口，供系统或应用程序使用。这两者本身不经过任何加密——加密和伪装发生在出站（到远端服务器）的部分，本地监听只是提供一个标准化的接入点。

本地应用
  |  SOCKS5（127.0.0.1:7891）
  v
Mihomo / sing-box（本地监听）
  |
  | 分流规则处理
  |
  | VLESS + Reality（到远端服务器，经过完整加密和伪装）
  v
远端代理服务器
  |
  v
目标网站

SSH 隧道

概述

SSH（Secure Shell）是一种用于安全远程登录和命令执行的协议，于 2001 年由 IETF 标准化（RFC 4251）。它的隧道功能（Port Forwarding / SOCKS 代理）使其成为一种简便的临时代理手段，在没有专用代理服务器的情况下，只需一台可 SSH 访问的远程服务器即可实现代理。

三种隧道模式

本地端口转发（Local Port Forwarding）：

将本地端口的流量转发到远端服务器可访问的目标地址：

ssh -L 本地端口:目标主机:目标端口 user@ssh服务器

示例：将本地 8080 端口的流量通过 SSH 服务器转发到 内网web服务
ssh -L 8080:192.168.1.100:80 user@your.vps.com

远程端口转发（Remote Port Forwarding）：

将远端服务器的端口映射回本地，用于内网穿透：

ssh -R 远端端口:本地主机:本地端口 user@ssh服务器

示例：将 VPS 的 8080 端口映射到本机的 80 端口
ssh -R 8080:localhost:80 user@your.vps.com

动态端口转发（Dynamic Port Forwarding / SOCKS 代理）：

在本地创建一个 SOCKS5 代理，所有流量通过 SSH 服务器中转：

ssh -D 本地SOCKS5端口 user@ssh服务器

示例：在本地 1080 端口建立 SOCKS5 代理
ssh -D 1080 -N -f user@your.vps.com

-N 表示不执行远端命令，-f 表示后台运行。建立后，将系统或浏览器的代理设置为 SOCKS5: 127.0.0.1:1080 即可使用。

SSH 隧道的安全性

SSH 使用强加密保护所有传输数据，认证方式包括密码和公钥（推荐公钥），是一种安全可靠的隧道方案。其流量特征与正常的 SSH 访问相同，在审查较为宽松的环境中不易引起注意。

然而，SSH 本身的流量特征（特别是其特有的握手和版本字符串）在严格的 DPI 环境下仍然可以被识别和封锁。

SSH 隧道的限制

限制	说明
速度上限	SSH 的加密开销相对较高，大量并发连接时吞吐量不如专用代理协议
连接稳定性	SSH 连接在网络中断后不会自动重连，需要额外工具（如 autossh）保持稳定
缺乏流量混淆	SSH 的握手特征明显，在强力 DPI 下可以被识别
不适合机场使用	SSH 隧道是点对点的，不适合机场这种多用户服务模式

保持 SSH 隧道稳定：autossh

autossh 是一个用于自动重启 SSH 隧道的工具，在网络中断后会自动重新建立连接：

# 安装 autossh
apt install autossh

# 使用 autossh 建立稳定的 SOCKS5 代理隧道
autossh -M 0 -D 1080 -N -f \
  -o "ServerAliveInterval=30" \
  -o "ServerAliveCountMax=3" \
  -o "ExitOnForwardFailure=yes" \
  user@your.vps.com

-M 0 表示不使用 autossh 的内置监控端口，而是依赖 SSH 的 ServerAliveInterval 机制检测连接存活状态。

适用场景

临时代理需求，手边只有一台可 SSH 的服务器
内网穿透（远程端口转发），让外网访问内网服务
访问只允许从特定 IP 连接的内部服务（通过本地端口转发中转）
与 ProxyChains 配合，为不支持代理的命令行工具提供代理能力
开发环境中临时暴露本地服务到公网（结合内网穿透使用）

Tor

概述

Tor（The Onion Router，洋葱路由器）是一个注重匿名性的网络协议，于 2002 年由美国海军研究实验室开发，并于 2004 年开源。它通过在多个志愿者运营的中继节点（Relay）之间多层加密转发流量，使任何单一节点都无法同时知晓流量的来源和去向，从而实现强匿名性。

工作原理

Tor 的核心是"洋葱路由"（Onion Routing）——流量在到达目标之前经过至少三个随机选择的中继节点，每一层用该节点的密钥加密，形成"洋葱"结构：

用户
  |
  | 加密层 A（出口节点密钥）
  | 加密层 B（中间节点密钥）
  | 加密层 C（入口节点密钥）
  v
入口节点（Guard）
  |  剥掉加密层 C，只知道来自用户，不知道最终目标
  v
中间节点（Middle）
  |  剥掉加密层 B，只知道来自入口节点，不知道用户或目标
  v
出口节点（Exit）
  |  剥掉加密层 A，知道最终目标，但不知道用户是谁
  v
目标网站

任何单一节点只知道"上一跳"和"下一跳"，无法同时掌握流量的完整路径，这是 Tor 匿名性的基础。

特点与局限

特点	说明
强匿名性	多层路由使流量溯源极为困难
.onion 域名	支持访问只在 Tor 网络内存在的 .onion 暗网地址
志愿者节点	依赖全球志愿者运营中继节点，无中心化控制
速度慢	三跳路由和加密开销使延迟极高（通常在 300–1000ms 以上）
出口节点限制	访问明文 HTTP 时，出口节点可以看到流量内容
封锁问题	Tor 的节点 IP 是公开的，容易被封锁，需要使用网桥（Bridge）绕过

Tor 浏览器

访问 Tor 网络最简单的方式是使用 Tor 浏览器（Tor Browser），它是基于 Firefox 的定制版浏览器，内置了 Tor 客户端，并针对匿名性进行了系统性的隐私加固：

禁用所有可能暴露身份的浏览器特性（如 WebRTC、Canvas 指纹等）
默认启用 NoScript
统一化的窗口大小，防止通过屏幕尺寸指纹识别

下载地址：https://www.torproject.org/download/

在被封锁的网络中使用 Tor

在中国大陆等封锁 Tor 节点的网络中，可以使用网桥（Bridge）或可插拔传输（Pluggable Transport）：

网桥（Bridge）：未公开列出的 Tor 节点，不在公开节点列表中，更难被封锁
obfs4：将 Tor 流量伪装为随机字节，对抗基于协议特征的封锁
Snowflake：将 Tor 流量伪装为 WebRTC 流量，通过大量志愿者的浏览器中继

关于 Tor 的主流代理软件支持

从协议总览表可以看到，大多数主流代理软件（Mihomo、Xray、V2Fly、Shadowrocket 等）都将 Tor 标注为 na（不适用）。这意味着这些代理软件不支持将 Tor 作为出站协议，也不支持作为 Tor 节点使用。如果需要使用 Tor，应使用官方的 Tor 浏览器或 Tor 客户端（tor 守护进程），而不是通过代理软件的 Tor 支持。

sing-box 是少数几个在一定程度上支持与 Tor 网络交互的代理框架，但通常是以将流量转发到本地运行的 tor 守护进程的方式实现，而非直接实现 Tor 协议。

适用场景

Tor 的核心价值是匿名性，而不是速度或抗封锁能力：

需要高度匿名的网络访问（如举报人、活动人士）
访问 .onion 暗网服务
对流量溯源有强烈防护需求的场景
新闻机构和维权组织的安全通信

不适合 Tor 的场景：

日常代理使用（速度太慢）
流媒体或大文件下载
需要稳定低延迟连接的应用（如视频通话、游戏）

关于 Tor 的误解

使用 Tor 不等于完全匿名。你的身份仍然可能通过以下方式暴露：

目标网站的登录账号（登录 Google 后，即使通过 Tor，Google 仍然知道是你）
浏览器指纹（如果不使用 Tor 浏览器，而是仅配置了 Tor 代理的普通浏览器）
出口节点的流量监控（对于明文 HTTP 流量）
时序关联攻击（流量时序分析）

Tor 提供的是"对流量路径的混淆"，而非对所有身份识别手段的完全防护。

传统协议对比总结

协议	加密	匿名性	速度	UDP 支持	主要用途
HTTP 代理	无（HTTP）/ 有（HTTPS）	无	高	否	企业内网、调试、环境变量代理
SOCKS4	无	无	高	否	通用 TCP 代理（旧）
SOCKS5	无	无	高	是	通用 TCP/UDP 代理、本地接口
SSH 隧道	有（SSH 加密）	低	中	否（原生）	临时代理、内网穿透
Tor	有（多层加密）	极高	极低	否	匿名访问、暗网
WireGuard	有（ChaCha20）	低	极高	是（VPN）	VPN 组网、内网穿透

在现代代理软件中的角色

传统协议在现代代理生态中通常扮演以下角色：

HTTP / SOCKS5：作为代理软件的本地监听接口，供系统和应用程序接入
SSH：在没有专用代理服务器的情况下作为临时隧道方案
Tor：作为匿名化工具，在特定安全需求下使用，不用于日常高速代理
WireGuard：作为VPN 底层协议，在 Mihomo、sing-box 等工具中用作出站隧道