正常协议连接先经过TLS再发送认证内容
Trojan 协议先进行真实 TLS 握手，成功后发送密码摘要、请求与载荷。服务器核对的是密码的 SHA224 十六进制摘要，不能把这个认证条件改成另一协议的 UUID。
| 项目 | 协议或核心记录 |
|---|---|
| 传输通道 | TCP上的TLS |
| 认证对象 | 密码对应的摘要 |
| 请求类型 | CONNECT与UDP ASSOCIATE |
| UDP封装 | 长度前缀格式放入同一连接 |
| 协议版本栏 | 协议结构没有版本字段 |
连接地址与端口决定先连哪里，密码用于认证，TLS 是通道条件。这些位置分别核对，不能只记录客户端展示的节点名称就省去实际字段。
TCP通道和UDP请求并排看时不要互换概念
CONNECT 和 UDP ASSOCIATE 是协议中的命令，后者的 UDP 包封装在同一 TLS 连接里。因此转发对象包含 UDP，与底层 TCP 上的 TLS 是两项能够同时成立的描述。
- 连接目标按服务器与端口保留，不用标签代填。
- 密码条件按提供内容核对，不改写为用户ID字段。
- 协议命令与外层传输分开，避免只留下一个UDP字样。
请求内容可以是UDP，外层仍按Trojan协议说明建立TCP上的TLS连接。
格式或密码不符合时，协议说明会转给预设端点。这个行为描述服务端的协议安排，不代表你从网页外观就能确认节点身份，也不能反推每次访问的认证状态。
核心支持和使用条件分别保存
Xray、sing-box、mihomo 与 v2fly 的公开列表都有 Trojan 类型。类型存在只说明核心支持，客户端实际暴露的选项和服务交付内容还需各自核对。
Xray 文档强调必须配 TLS，并对公网环境列出 Mux 条件。引用这些要求时保留它属于 Xray 的范围，不扩成每个客户端都显示同样的开关或采用相同菜单。
- 先写正在使用的核心与客户端，不只写协议名。
- 对照该核心的TLS及附加条件，保留来源。
- 记录实际返回，不把支持列表当作服务已经可用。
参考实现版本与协议结构不要合成一项
参考实现的发布记录列有 Trojan 1.16.0，日期为 2020-06-10。协议结构没有版本字段，是另一事实，不能把实现版本填成节点协议头中的数值。
参考实现是否停止维护，没查到公开说明，不能从发布日期补出确定判断。现有服务采用什么实现也要另看，旧记录不能代替当前部署信息。
Trojan 分享前缀虽然被作为识别线索列出，但已读官方文档没有完整 URL 方案。具体查询参数保留为客户端与来源核对项目，不拼一条真实分享或下载地址。
服务另选时继续查看收录入口
如需了解别的机场，可从下面的入口读取各自服务信息。
常见问题解答
Trojan密码可以按VMess的UUID解释吗？
认证模型不同，Trojan 协议使用密码摘要，不能直接替换成 VMess 的用户标识。服务器位置、端口、密码与 TLS 条件分别核对，保留实际来源。
节点支持UDP就代表连接服务器走UDP吗？
Trojan 的 UDP 请求封装在 TCP 上的 TLS 连接里，内层请求与外层传输不同。记录时两项并列，不用一个 UDP 标签替代整个协议描述。
实现版本1.16.0要填进协议版本字段吗？
协议结构没有版本字段，实现发布号是软件记录。不能把参考实现版本填进不存在的协议栏，也不能由旧发布日期断定当前服务使用何种实现。