Featured image of post Xray的 XTLS 与Trojan 的工作原理与区别
代理

Xray的 XTLS 与Trojan 的工作原理与区别

详细解析XTLS与trojan的握手与传输机制

一、XTLS 的工作原理

1. XTLS 的背景与定位

  • XTLS 是在 Xray 中，为了在保证安全性的同时进一步降低 TLS 搭建和数据加解密开销而设计的一种“定制化 TLS”扩展方案。

  • 其核心思路是：

    1. 保留 TLS 握手对外表现与标准 TLS（如 HTTPS）几乎完全一致，以获得良好的伪装效果；

    2. 在加密层面利用分层、拆分的思路，把真正的加密/解密操作尽量下沉到应用层，跳过传统 TLS 中对每一个数据包都要进行的多次加密包/解密包检查，从而减少 CPU 开销、提高吞吐与并发性能(理论上)。

2. XTLS 的主要设计要点

  1. 握手阶段与数据阶段拆分

    • 在传统 TLS 中，握手（Handshake）和数据传输（Application Data）都通过同一个 TLS record 层来完成：客户端发送 ClientHello、服务端响应 ServerHello、双方交换密钥、然后再逐步进入基于对称密钥的加密数据传输。每个 TLS record 都要完整地走一遍“记录层（Record Layer）→分片（Fragmentation）→压缩（Compression）→MAC → 加密”等流程。

    • XTLS 的做法是把“握手所需的最小部分”留给标准 TLS 完成，以满足双方外部看到的是一个“合法的 HTTPS”握手，而在完成握手后，立即切换到一个极简加密层（也可看作“伪装过的原生应用层协议”），此时的数据段不再通过标准 TLS 的 Record Layer 做完整的加密，而是直接使用 V2Ray/Xray 中自行实现的 AEAD 算法（如 ChaCha20-Poly1305 / AES-GCM）进行封包/加密。

    • 这样，就避免了“每个数据包都要额外做一次 TLS record 分片、MAC 校验、加密”的开销；数据阶段只剩下本地 AEAD 算法的加解密，同时保持对外表现为一条“正常的 TLS 连接”。

  2. 伪装层与混淆设计

    • 在握手阶段，XTLS 使用一套和标准 TLS 客户端（如浏览器或 curl）极度相似的 TLS Hello/ServerHello、证书、Key Exchange、Finished 数据包，因此对外看起来就是一笔正常的 HTTPS 握手。

    • 完成握手之后，XTLS 会把真实的代理数据流（如 VLESS 数据、UDP 转发等）先按照预定义的“前缀”（Prefix）+“数据本体”进行封装，然后整体与一个固定的“Fake TLS Record Header”（伪造的TLS头部）拼合：

      • Fake TLS Record Header：长度 5 字节，格式与标准 TLS 的 RecordHeader 一致（第 1 字节为内容类型 Content Type，如 0x17 表示 Application Data；接下来的 2 个字节表示 TLS 版本号，如 0x0303；最后 2 个字节表示报文长度）。

      • 真正的应用负载：由 V2Ray/Xray 自己设计的加密算法（AEAD）加密后，整体作为“看似 TLS Application Data 的负载”发送。

    • 服务端在收到数据后，先通过标准 TLS 库完成握手及密钥协商，进入一个可解密的状态。但它并不会把接下来的 Application Data 交给标准 TLS 库处理，而是在 Record Layer 解密出“裸 AES/GCM 或 ChaCha20-Poly1305 数据”后，再由 Xray 的内置模块进一步提取、解密出真正的代理数据流。

    • 整个过程中，外部抓包工具（如 Wireshark）只会看到“标准 TLS 握手 + 伪装成 TLS Application Data 的密文”，并不能直接区分这究竟是 Web 浏览流量还是代理流量。

  3. 数据传输阶段的加解密流程（示例）

    XTLS 数据包从客户端到服务端的处理流程：

    1. 客户端准备一段原始代理数据（如一个 VLESS 帧或 UDP 数据包）；

    2. 客户端用预共享的 AEAD 密钥（与服务端在 TLS 握手阶段通过 X25519/DH 或 RSA 签名确认）对该数据进行一次 AEAD 加密，得到密文 payload_ciphertext；

    3. 客户端拼接一个 Fake TLS Record Header：

      • ContentType = 0x17（Application Data）

      • Version = 0x0303（TLS 1.2/1.3）

      • Length = len(payload_ciphertext)

    4. 整体向下交给标准 TLS 库，再由标准 TLS 做一次真正的 TLS record-layer 加密；

    5. 经过网络传输后，服务端的标准 TLS 接收该 Record，将外层 TLS record 解密，得到 Fake Record Header + payload_ciphertext；

    6. 服务端校验 Fake Record Header（丢掉这 5 字节），并从密文缓冲区提取出 payload_ciphertext；

    7. 服务端用自己在握手阶段已知的 AEAD 密钥，对 payload_ciphertext 进行二次解密，把原始的 VLESS/UDP 数据包还原出来；

    8. 后续便是 Xray 上层的正常协议解析、路由、转发、加密等流程。

    可以看到，真正的“多次加密”仅发生在“TLS 外层”与“AEAD 内层”两层；相比于传统 TLS 对每个小数据片段都做分片 & MAC & 加密的方式，XTLS 只是：

    • 外层单次握手 + 单次 TLS 1.3 Record Layer（只针对少量握手数据）；

    • 内层对应用层原始数据直接做 AEAD 加密，从第二个报文开始再也不会触发标准 TLS 的 Record Layer 复杂逻辑。

  4. 版本划分与协议兼容性

    • XTLS 依赖于底层的 VLESS 协议（而非旧的 VMess），并要求服务端与客户端都要支持该扩展。

    • 由于伪装层与标准 TLS 几乎完全保持一致，理论上能够在绝大多数需要“伪装成 HTTPS 流量”的场景下使用（例如学校/公司防火墙、流量 DPI、SNI 检测、JA3 指纹等）。

    • 目前主流的 Xray 实现中，XTLS 大致有如下几种模式：

      • XTLS-rprx-direct：直连、最基础的模式；

      • XTLS-rprx-origin：与 “origin” 模式兼容性更好，但性能稍逊；

      • XTLS-rprx-splice：可用于 UDP 转发等轻量化场景。

二、Trojan 的工作原理

1. Trojan 的定位

  • Trojan（Trojan-GFW）是一种“伪装成 HTTPS”的代理协议，核心目标是：

    1. 利用完全标准的 TLS 握手与证书，以获得极高的流量伪装度；

    2. 在完成 TLS 握手后，客户端向服务端发送一个预先约定的密码口令（password）；

    3. 服务端验证密码合法后，把后续数据当作代理流量转发；

    4. 只用一层 TLS，整个数据交换都通过标准 TLS record 层封装。

2. 基本流程

  1. 建立 TLS 连接

    • Client 发起标准的 TLS ClientHello，其中 Server Name Indication (SNI) 常常被设置为一个“伪装域名”（例如合法的 www.amazon.com）。

    • Server 返回标准的 TLS ServerHello、证书链、Key Exchange 等。

    • 双方通过 TLS 1.2/1.3 完成握手，共享对称加密密钥。

  2. 验证密码（Password）

    • 一旦 TLS 握手完成，客户端会立即将一个事先约定的“接入密码”发送到服务端。此时的“密码”会被 AES-GCM/ChaCha20-Poly1305 在 TLS record 层加密。

    • 服务端在解出密码后检查是否与配置一致：

      • 若合法，则进入“转发阶段”；

      • 若不合法，则转发到伪装域名上。

  3. 转发与加密

    • 在密码验证通过之后，客户端或服务端直接将实际代理协议（如 SOCKS5 或自定义的帧格式）封装在 TLS 的 Application Data 里。此时所有流量都只是“再多一次”通过标准 TLS record-layer 做加解密。

    • 例如：客户端先发一个 “CONNECT target.host:443\r\n” 之类的字节流，然后服务器读出后去连接目标，后续数据双向转发，均由标准 TLS 保持加密。

  4. 断开与重连

    • 断开连接后，若要继续访问，则重走上述流程。没有类似 XTLS 那种“握手后内层再做 AEAD 解密”的额外层次，一切都走标准 TLS。

3. 特点

  • 简单易用：只要有一张合法的 TLS 证书（可使用 Let’s Encrypt 免费签发），以及一个密码配置，几乎在任意支持 OpenSSL/mbedTLS 的环境都能快速部署。

  • 伪装度高：因为整个握手和后续数据都严格按标准 TLS 1.2/1.3 来做，抓包者只能看到流量走的是“HTTPS”，很难区分是浏览网页还是 Trojan。

  • 性能开销相对较高：每个数据片段都要经过 TLS record 层的分片/压缩/加密/MAC 校验，性能开销稍高。

  • 单层加密：与 XTLS“外层 TLS+内层 AEAD”双层加密不同，Trojan 只做一层标准 TLS。在性能与安全之间做了最简单的权衡：更注重伪装易部署，而非极致性能。

三、XTLS 与 Trojan 的主要区别

区别维度 XTLS Trojan
伪装原理 - 外层依旧是标准 TLS 1.3（握手、证书交换、Key Exchange 都与常规 HTTPS 一致）- 数据阶段只在外层做一次 TLS Record 加密，内层用自定义 AEAD。 - 完全依赖标准 TLS 1.2/1.3：握手和数据全部都走标准 TLS Record。
加密层次 - 双层： 1. 外层：真正的 TLS Record 层； 2. 内层：V2Ray/Xray 自己的 AEAD。 - 单层：所有流量都通过标准 TLS Record 做分片/加密/校验。
性能表现 - 更轻量：完成握手后，绝大部分数据都由内层 AEAD 直接加密/解密，绕过了一般 TLS 的 Record 分片和 MAC 校验，大幅降低 CPU、延迟。- 高并发和大带宽场景性能优势明显。 - 较重：TLS Record（分片→MAC→加密→合并）的开销持续存在。- 高并发/大带宽时 CPU 消耗较高。
部署复杂度 - 需要 Xray 的支持，客户端/服务端都要安装并正确配置 XTLS 模块。- 还要生成并配置相应的 TLS 证书、AEAD 密钥等。 - 部署简单：只需一个合法的 TLS 证书（比如 Let’s Encrypt），服务端运行 Trojan 服务，客户端部署 Trojan 即可。
握手时长 - 握手过程与标准 TLS 类似，但握手完成后不会进入常规 TLS Record 流水线。- XTLS-rprx-direct 等模式下，握手时序略有差异，但总体时延与 HTTPS 接近。 - 完全标准 TLS 握手，时长与浏览器访问 HTTPS 网站相当。
流量伪装度 - 几乎与标准 HTTPS 无异：被 DPI、SNI、JA3 Fingerprint 等检测的风险很小。- 但由于内层 XTLS 特定标记较难被检测，只要实现得好，伪装度仍然很高。 - 伪装度非常高：握手、证书、加密方式均与主流 HTTPS 完全一致。
协议兼容性 - 仅限于支持 XTLS 的 Xray 客户端和服务端；不能被常见的浏览器或其他 TLS 客户端直接使用。 - 只要支持 TLS 的客户端/服务端都能使用，兼容性极好；与 HTTPS 完全通用。
安全性 - 外层 TLS 保证握手安全、前向保密；内层 AEAD 进一步对流量进行加密。- 但“拆分握手”和“数据阶段直下 AEAD”如果配置不当，可能出现实现漏洞。 - 只使用标准 TLS，安全性由底层 TLS 库与证书链保证。

四、总结

  • Trojan：

    • 依赖标准 TLS 做一切加密，部署简单、伪装度高。
    • 外层TLS加上内层(应用层)TLS，形成了"TLS in TLS" 双层传输，在性能开销上稍高。但由于其完全基于成熟的TLS，安全性上非常优秀。

  • XTLS：

    • 仍然对外呈现标准 TLS 握手，但握手完成后，真正的数据阶段跳过传统 TLS Record，采用自定义 AEAD 做加解密，从而提升性能。
    • 部署相对复杂，对配置要求较高。

总之，总体逻辑上基本相似，但实现细节上差异不小。各有所长，需求决定选择。

欢迎关注我的 Youtube频道 观看视频。

END.

© 2025 格朗Blog building
Designed By Jimmycai https://jimmycai.com