孤家寡人协议

"孤家寡人序列"收录了那些设计独特、但生态极为有限的代理协议。这些协议或因开发者资源有限、或因设计过于小众、或因已停止主动维护，导致客户端支持极少、社区积累稀薄，在日常使用中基本只能依赖原版工具。

本页面的目的不是推荐这些协议用于日常使用，而是为有技术探索兴趣的用户提供基本的了解，以及记录代理协议生态的完整面貌。

使用提示

本页面收录的协议均属于客户端支持极为有限的小众方案。如果你正在寻找日常使用的代理协议，请优先参考主流序列中的推荐。本页面的协议不适合作为主力方案使用。

kcptun

概述

kcptun 是一种基于 KCP 协议的 UDP 隧道工具，于 2016 年由开发者 @xtaci 发布。它不是一个独立的代理协议，而是一个"加速隧道"——将任意 TCP 连接通过 KCP（基于 UDP 的可靠传输协议）重新封装，利用 KCP 激进的重传策略在高丢包线路上提供比 TCP 更高的吞吐量。

技术背景

KCP（K-CP）是由 @skywind3000 设计的一种可靠传输协议，运行在 UDP 之上。与 TCP 的拥塞控制设计不同，KCP 的策略更为激进：

不进行流量控制，不会主动降速
以额外的带宽消耗（重传冗余）换取更低的延迟
在丢包率 10% 的网络上，KCP 的实际吞吐量可以比 TCP 高出数倍

kcptun 在 KCP 的基础上添加了 FEC（前向纠错）、数据加密和混淆功能，将其包装成一个可以加速任意 TCP 连接的隧道工具。

工作原理

客户端应用（TCP）
    |
    v
kcptun 本地端（TCP 监听）
    |  [封装为 KCP/UDP + 加密 + FEC]
    v
kcptun 远端（UDP 服务端）
    |  [还原 TCP 流]
    v
代理服务端（如 Shadowsocks）
    |
    v
目标服务器

kcptun 本身不提供代理功能，通常与 Shadowsocks 等代理协议配合使用：Shadowsocks 的流量先经过 kcptun 加速隧道传输，到达远端后再由 Shadowsocks 服务端处理。

配置参数

kcptun 的性能与配置参数关系密切：

参数	说明
`mode`	预设模式（fast3 > fast2 > fast > normal），影响重传策略的激进程度
`mtu`	KCP 数据包的 MTU，默认 1350，需要根据链路调整
`sndwnd` / `rcvwnd`	发送/接收窗口大小，越大吞吐量越高，但占用内存也越多
`datashard` / `parityshard`	FEC 的数据分片和奇偶校验分片数，提高丢包恢复能力
`crypt`	加密方式，如 `aes`、`salsa20`、`none` 等
`key`	加密密钥
`nocomp`	是否禁用压缩，通常设置为 `true`（代理流量已加密，压缩无效）

一个高性能配置示例：

# 服务端启动
kcptun-server \
  -t "127.0.0.1:8388" \
  -l ":4000" \
  --key "your-key" \
  --crypt aes \
  --mode fast2 \
  --mtu 1350 \
  --sndwnd 2048 \
  --rcvwnd 2048 \
  --datashard 10 \
  --parityshard 3 \
  --nocomp

# 客户端启动
kcptun-client \
  -r "your.server.ip:4000" \
  -l ":8388" \
  --key "your-key" \
  --crypt aes \
  --mode fast2 \
  --mtu 1350 \
  --sndwnd 2048 \
  --rcvwnd 2048 \
  --datashard 10 \
  --parityshard 3 \
  --nocomp

当前状态

kcptun 在 2021 年前后仍有一定的使用群体，但随着 Hysteria 2、TUIC 等专为代理场景设计的 QUIC 系协议崛起，kcptun 的使用场景已基本被这些更现代的方案取代：

Hysteria 2 的 Brutal 算法在高丢包场景下的效果与 kcptun 相当甚至更优
主流代理软件的 QUIC 支持使得不再需要额外的 kcptun 层
kcptun 需要在代理软件之外额外运行一个独立进程，增加了运维复杂度

客户端支持

kcptun 主要依靠原版命令行工具使用，只有极少数代理软件提供原生支持（主要是部分版本的 Mihomo 和小火箭）。

平台	支持状态
Linux / macOS / Windows	原版命令行工具
iOS (Shadowrocket)	部分版本支持（作为插件）
Android	几乎不支持
Mihomo	历史版本支持，当前状态不稳定

Vlite

概述

Vlite 是一种于 2020 年发布的代理工具，由开发者 @nicowillis 创建。它基于 UDP 传输，设计目标是在不依赖 QUIC 协议栈的情况下，通过自定义的轻量级可靠传输层实现高效的 UDP 代理。

设计特点

Vlite 的核心设计理念是"极简"：

代码库远比 Hysteria 2 或 TUIC 小，实现简单
不依赖 quic-go 等重型 QUIC 库，减少外部依赖
自实现了一套轻量的 UDP 可靠传输机制
支持基本的流量混淆

工作原理

Vlite 在 UDP 之上实现了一套简化的可靠传输机制，类似于早期 KCP 的设计思路，但实现更为精简。它直接将代理流量封装在自定义的 UDP 数据包中传输，不尝试与任何已知协议的流量特征对齐。

当前状态与局限

Vlite 的使用群体极为有限，主要原因是：

仅在 V2Fly（V2Ray 的社区分支）的部分版本中有集成
其他主流代理软件均不支持
相比 Hysteria 2 等更成熟的 QUIC 系协议，在性能和生态上均无明显优势
开发活跃度较低

客户端支持

平台	支持状态
V2Fly（桌面）	支持（内置）
其他主流代理软件	基本不支持
iOS / Android	基本不支持

如果你正在寻找 UDP 加速方案，Hysteria 2 或 TUIC 在功能、性能和生态支持上均大幅优于 Vlite，应优先考虑。

Brook

概述

Brook 是一个由开发者 @txthinking 创建的开源代理工具，初始版本于 2022 年 1 月前后稳定。它以"简单"为核心设计理念，提供了一套轻量的代理协议实现，支持多种运行模式（代理服务器、WebSocket 隧道、QUIC 隧道等）。

主要特性

Brook 的设计目标是在尽量简单的配置下提供可用的代理服务：

单一二进制文件，无外部依赖
同时支持客户端和服务端角色
支持多种传输方式（TCP、WebSocket over TLS、QUIC）
内置了简单的混淆机制
提供了 Web 管理界面

协议设计

Brook 的协议设计比较朴素：在 TCP 连接上使用自定义的轻量加密（基于 ChaCha20 或类似方案），或通过 WebSocket over TLS 进行封装。它没有像 VLESS + Reality 那样的高级伪装机制，抗检测能力较为有限。

运行模式

Brook 支持多种运行模式：

模式	说明
`server`	传统 Brook 服务端，TCP 传输
`wsserver`	WebSocket 服务端，可搭配 TLS
`wssserver`	WebSocket over TLS 服务端
`quicserver`	基于 QUIC 的服务端
`dnsserver`	DNS 代理服务器
`tproxy`	透明代理模式（Linux）

简单服务端示例：

# 启动 Brook WSS 服务端
brook wssserver --listen :443 \
  --password your-password \
  --cert /path/to/cert.pem \
  --certKey /path/to/key.pem

客户端连接示例：

# 连接 Brook WSS 服务端
brook wss \
  --server wss://your.domain.com:443 \
  --password your-password \
  --socks5 127.0.0.1:1080

当前状态

Brook 仍在活跃维护中，但其用户群体较为小众。主要原因是：

协议抗检测能力不突出，在国内网络审查严格的场景下竞争力有限
主流代理软件（Mihomo、sing-box）不支持 Brook 协议
客户端支持局限于官方工具和少数 Android 客户端

Brook 的相对优势在于其工具的全面性（同时提供客户端、服务端、DNS 代理等多种功能），以及部署的简便性（单一二进制文件）。

客户端支持

平台	客户端	支持状态
Linux / macOS / Windows	Brook 官方客户端	支持
iOS	Brook 官方 App（App Store）	支持
Android	Brook 官方 App	支持
Mihomo / sing-box	不支持	—
Shadowrocket / QX / Stash	不支持	—

Brook 是本页面中官方客户端支持相对最完整的协议，iOS 和 Android 均有官方 App 可用。

TrustTunnel

概述

TrustTunnel 是一种于 2022 年 3 月前后出现的代理方案，在技术细节的公开信息方面较为有限。根据社区的使用反馈，它基于 TLS 传输，定位与 Trojan 类似，同样依赖 TLS 伪装来实现流量隐匿。

由于相关文档和技术规范的公开程度极低，TrustTunnel 的设计细节难以详细描述。以下内容主要基于社区的有限信息。

已知信息

传输层使用 TLS，流量外观与 HTTPS 接近
主要在 Mihomo（Clash Meta）的部分版本中有实现
客户端支持极为有限，仅见于少数代理客户端的支持列表
活跃用户群体极小，相关的社区讨论非常稀少

适用性评估

考虑到以下因素，TrustTunnel 在实际使用中几乎没有选择它的理由：

技术文档缺乏，难以评估安全性和可靠性
客户端支持极少
在 TLS 伪装这一设计目标上，Trojan（成熟稳定）和 VLESS + Reality（更强的抗检测能力）均是更合理的选择
没有活跃的社区支持，出现问题难以获得帮助

如果你看到了 TrustTunnel 的节点，建议在确认其可信度之前谨慎使用。

客户端支持

平台	客户端	支持状态
Windows / macOS / Linux	Mihomo（部分版本）	部分支持
Android	NekoBox（部分版本）	部分支持
Android	Husi	部分支持
iOS / 其他	基本不支持	—

Masque

概述

Masque 是由 IETF（互联网工程任务组）正在推进标准化的代理协议，于 2024 年 4 月前后进入被关注的视野。与本页面其他协议不同，Masque 不是某个开发者的个人项目，而是 IETF 的正式工作成果。

Masque 的全称是 Multiplexed Application Substrate over QUIC Encryption，基于 HTTP/3（QUIC）设计，旨在通过标准化的 HTTP/3 请求在 QUIC 连接上建立代理隧道。

技术背景

Masque 的设计灵感来自于将代理隐藏在普通 HTTP/3 流量中的思路。与 NaiveProxy 的 HTTP/2 CONNECT 类似，Masque 使用 HTTP/3 的 CONNECT 方法（以及扩展的 CONNECT-UDP 和 CONNECT-IP）在 QUIC 连接上建立代理隧道：

CONNECT-UDP（RFC 9298）：通过 HTTP/3 代理封装 UDP 数据包
CONNECT-IP（RFC 9484）：通过 HTTP/3 代理封装整个 IP 数据包（L3 代理）

Masque 的核心价值在于它是 IETF 标准，而非私有协议。这意味着：

基于 Masque 的代理流量与标准 HTTP/3 应用流量无法区分（因为它就是标准的 HTTP/3 流量）
主流浏览器和网络栈未来可能原生支持 Masque
苹果公司已在 iCloud 私有中继（Private Relay）和其他产品中使用了 Masque 相关技术

Masque 与 iCloud 私有中继

苹果的 iCloud 私有中继使用了基于 Masque 的技术，将用户的 Safari 浏览器流量通过两个独立的服务器中继，以实现类似 Tor 的双跳匿名化：

Safari 用户
    |
    v
苹果的第一跳中继（知道用户 IP，不知道目标）
    |  [基于 Masque 的 HTTP/3 隧道]
    v
内容提供商的第二跳中继（知道目标，不知道用户 IP）
    |
    v
目标网站

这表明 Masque 具备成为主流隐私保护基础设施的潜力。

在代理软件中的现状

截至目前，Masque 在代理软件中的支持极为有限：

主要仅见于 Xray-core 的实验性实现（通过其 XHTTP/SplitHTTP 的 HTTP/3 模式间接相关）
没有成熟的开源 Masque 代理工具可供一般用户直接使用
Cloudflare 在其部分产品中使用了 Masque 的底层技术

Masque 目前更多是一个"值得关注的技术方向"，而非"可供日常使用的协议"。它的实际可用性依赖于 IETF 标准的最终定稿和主流实现的跟进。

技术特点

特点	说明
标准化	IETF RFC，而非私有协议
基于 HTTP/3	流量特征与标准 HTTP/3 完全一致
UDP 代理	CONNECT-UDP 原生支持 UDP 数据的代理转发
IP 层代理	CONNECT-IP 支持 L3 级别的完整 IP 代理
加密	依赖 QUIC 内置的 TLS 1.3，无需额外加密层
需要域名和证书	是，与所有 HTTPS 服务一样

展望

Masque 是目前所有代理协议中理论上"最难被区分"的一种——因为它就是标准的 HTTP/3 流量，而 HTTP/3 是下一代互联网基础设施的重要组成部分。封锁 Masque 流量，在技术上等同于封锁所有 HTTP/3 流量，这会带来极高的附带损伤。

然而，在开源代理工具生态中，Masque 的成熟度尚不足以支撑日常使用，需要持续关注其发展动态。

客户端支持

平台	客户端	支持状态
Linux / macOS / Windows	Xray-core（实验性）	部分相关功能
iOS / Android	Surge（部分）	商业实现，非完整 Masque
浏览器原生	未来可能支持	尚无公开时间表

孤家寡人协议对比

协议	发布年份	传输层	主要特点	当前状态	实用性
kcptun	2016	UDP（KCP）	KCP 加速隧道，高丢包场景	可用但已过时	低（被 Hysteria 2 取代）
Vlite	2020	UDP（自定义）	轻量 UDP 传输	开发停滞	极低
Brook	2022	TCP / WS / QUIC	简单全功能代理工具	活跃维护	低（生态有限）
TrustTunnel	2022	TCP（TLS）	TLS 伪装，类 Trojan	文档匮乏	极低
Masque	2024	QUIC（HTTP/3）	IETF 标准，最佳 HTTP/3 伪装	尚未成熟	低（待成熟）

总结

本页面收录的协议，代表了代理生态中的"长尾"部分——它们或许有独特的设计思路，或许有值得关注的技术特点，但在实际可用性上均无法与主流协议竞争。

对于绝大多数用户，以下建议仍然成立：

如果你需要最强的抗检测能力，选择 VLESS + Reality 或 AnyTLS
如果你的线路丢包率高，选择 Hysteria 2 或 TUIC
如果你需要最广泛的客户端兼容性，选择 Shadowsocks 2022 或 Trojan
如果你对技术有探索兴趣，本页面的协议可以作为了解对象，但不建议作为主力方案