SurgeTeam 相比之下，Trojan、TUIC、Hysteria、TrustTunnel 等协议均建立在标准 TLS 实现之上。标准化 TLS 经过长期实践验证，是目前应用最广泛且成熟度最高的加密隧道。
我觉得这里有一个重要的实际问题，不是关于 VLESS，而是关于你们提到的 TrustTunnel。
你们自己也写到，TrustTunnel 也属于建立在标准 TLS 实现之上的协议。也就是说，TrustTunnel 和 VLESS / REALITY 的争议不同，似乎很符合 Surge 的技术理念。
但目前 Surge 对 TrustTunnel 的支持并不完整，无论是在 macOS 和 iOS 的最新正式版，还是最新 beta 版中都是如此。在很多现代部署场景下，它还无法被完整使用。
至少有两个关键能力目前缺失：
客户端无法显式设置 custom SNI。
如果没有这个能力，就很难把 TrustTunnel 部署在普通的 TLS endpoint / HAProxy / SNI-based routing 后面，也很难让服务器在外部观察者看来像一个正常网站。
客户端无法设置 user random prefix / client auth prefix。
如果没有这个能力，服务端就无法通过预先设定的随机 prefix 来区分合法的 TrustTunnel 客户端和主动探测流量，也就无法实现这样的逻辑：合法客户端进入 TrustTunnel，其他所有未知连接则被当作普通 TLS 服务处理。
正是这些参数，才让 TrustTunnel 能够真正用于实际环境，而不仅仅是一个“形式上支持”的协议。
所以我想请问：Surge 是否计划在 iOS 和 macOS 两个平台上，为 TrustTunnel 增加 custom SNI 和 user random prefix 的支持？如果你们的立场是支持基于标准 TLS 的协议，而不是对 TLS 层边界进行有争议的修改，那么把 TrustTunnel 支持完善到可完整使用的程度，似乎是一个非常自然、也非常符合这一技术方向的选择。
