tech/protocol · 集群 A · 主流协议原理 · 2/6

Trojan 协议原理：基于 TLS 的设计思路、密码认证与回落机制

Trojan 的核心思路

Trojan 的核心思路是「不发明新的加密，直接站在 TLS 上」。它假设一个提供 HTTPS 服务的普通网站是网络上最常见、最不需要解释的流量，于是让代理服务尽可能在外部表现上接近这样的网站。

这个思路决定了 Trojan 的全部结构：外层是一条完全标准的 TLS 连接，内层是一段非常简短的认证与目标地址信息，之后就是原样转发的应用数据。它不像 VMess 那样自带加密算法，也不像 Shadowsocks 那样依赖预共享密钥做对称加密。

┌─────────────────────────────────────────────┐
│ TLS 记录层（由证书与 TLS 1.2/1.3 保护）      │
│  ┌───────────────────────────────────────┐  │
│  │ 密码哈希（56 字节十六进制）+ CRLF       │  │
│  │ 指令 | 地址类型 | 目标地址 | 端口 + CRLF │  │
│  │ 应用数据 ……                            │  │
│  └───────────────────────────────────────┘  │
└─────────────────────────────────────────────┘

一次连接的完整过程

一次 Trojan 连接可以分为三个阶段：TLS 握手、认证与请求、数据转发。理解这三个阶段的先后顺序，就能看懂大部分 Trojan 相关的报错。

第一阶段与普通浏览器访问 HTTPS 网站完全相同，这也是 Trojan 设计的出发点。第二阶段中，密码不会以明文出现，而是先计算 SHA224 哈希，再编码为 56 个十六进制字符发送；即使如此，它也是在 TLS 加密之后才传输的，网络上的第三方看不到。第三阶段就是普通的转发，此时体验好坏主要取决于线路和节点负载，相关原理可参考 线路与专线 专题。

回落机制：认证失败时会发生什么

回落（fallback）是 Trojan 设计中最有特点的部分：当服务端收到的首段数据不是合法的 Trojan 请求时，它不会直接断开，而是把这条连接转交给一个预先配置好的普通 Web 服务。

这样设计的目的，是让未持有密码的访问者（比如一个普通浏览器，或者一次探测性的连接）看到的是正常的网页响应，而不是一个异常断开的端口。从协议设计角度讲，这是在降低「这个端口提供的是非常规服务」的可判断性。

需要强调两点。第一，回落机制是服务端的部署设计，用户侧无需配置，也无法从客户端控制；第二，回落只能降低一类特征，并不能让服务「无法被识别」。协议识别是一个综合了多种手段的领域，相关原理在 协议识别的原理 中有概述，本站不讨论针对任何系统的具体规避方法。

证书与 SNI：用户需要关心的部分

Trojan 的机密性完全建立在 TLS 之上，因此证书是否有效、客户端是否校验证书，直接决定了这条连接的安全前提。标准部署中，服务端持有某个域名的有效证书，客户端连接时在 SNI 中携带这个域名，并验证服务端返回的证书是否匹配、是否由可信机构签发。

用户在机场订阅里通常会看到 sni 和 skip-cert-verify（或 allowInsecure）之类的字段。后者如果被设为开启，意味着客户端不再校验证书，TLS 仍会加密，但无法确认对端身份，理论上留下了中间人风险。合理的态度是：完全按服务商下发的订阅使用；如果发现证书校验被关闭，可以询问服务商原因，而不是自行改动。证书与握手的原理细节见 代理协议中的 TLS。

时间不同步有时也会导致证书校验失败，因为证书有有效期，设备时间相差过大时会被判定为「证书尚未生效」或「已过期」。这类故障的排查可参考 故障排查 专题。

UDP 与多路复用

Trojan 支持 UDP 转发，但 UDP 数据是被封装在同一条 TLS（TCP）连接内传输的。协议中定义了 UDP 关联指令，客户端把每个 UDP 包加上地址与长度信息后写入 TLS 流，服务端解包后再以 UDP 发出。

这种方式的好处是不需要额外开放 UDP 端口，坏处是 UDP 数据会受到 TCP 队头阻塞与重传的影响：一旦底层 TCP 丢包重传，后面的 UDP 包也必须等待。对于网页浏览影响不大，对于语音、游戏这类对实时性敏感的场景，体感可能不如原生基于 UDP 的协议。这也是 Hysteria2 这类基于 QUIC 的协议出现的背景之一。

部分实现（例如 Trojan-Go）还支持在 TLS 之上叠加 WebSocket 或多路复用，用于经过 CDN 或减少握手次数。这些属于实现扩展，是否可用取决于服务端部署与客户端支持，以订阅内容为准。

客户端兼容与选择建议

Trojan 是客户端支持最广泛的协议之一，原版 Clash 内核、mihomo、sing-box、Xray、Shadowrocket 等主流客户端基本都支持标准 Trojan。如果你使用的客户端较老、或者只支持有限的几种协议，Trojan 节点通常比 VLESS 节点更容易导入成功。

不过，客户端兼容只是选择的一个维度。可以用下面的思路判断：

你的客户端是否支持 VLESS？
├─ 不支持 → Trojan、Shadowsocks、VMess 节点是可用选项
└─ 支持 → Trojan 与 VLESS 都可以使用
          └─ 两者在服务商正确配置时差异更多体现在部署方式，
             日常体验主要看线路与节点负载（本站未实测）

本站收录的品牌中，有 12 个品牌资料标注协议为 VLESS，资料中没有品牌标注 Trojan；另有五个品牌协议待核实，本站不推测其是否使用 Trojan。实际下发的节点协议，以订阅内容为准。

小结

Trojan 用「站在 TLS 上」的方式换来了简单与兼容：没有自研加密，认证信息只有一段哈希，认证失败交给真实网站处理。用户真正需要关心的只有两件事：证书校验是否正常，客户端是否支持。

想了解不同品牌的协议资料，可以浏览 机场品牌库 或在 对比工具 中并排查看；对协议整体差异的梳理，可回到 代理协议 专题总览。