几乎每隔几个月，就会出现一种新兴的代理协议，支持各种新兴代理协议从来不是 Surge 的开发目标，即使在开发资源允许的情况下，我们更倾向于实现被更为广泛接受和成为业界标准的协议（如 WireGuard），而非各种试验品。

部分用户执着于新兴的协议，主要是被一些花哨的宣传语所吸引，从各个角度来说：

代理延迟：shadowsocks/Snell 协议的延迟已经达到理论极限（0-RTT），不可能再更高。
CPU 占用 / 加密性能 / 带宽上限：AES 类型加密有硬件加速，单次加解密操作开销在 0.1ms 级别，iOS 设备上带宽已可达 Wi-Fi 吞吐量物理极限。现在基本所有协议都使用 AES 加密。
安全性：所有正确运用了现代加密算法的协议均不存在数据被强行破解的可能。TLS 类型协议提供有额外的（如前向安全）等更全面的保护。且投入使用时间越早的协议，则经受了更多的时间检验。而且由于上层承载流量通常也由 HTTPS/TLS 所保护，所以即使代理协议加密真的被突破（极其不可能），上层流量中也只有 SNI 会泄露。
multiplex 连接复用：由于大多数网站和程序均已使用 HTTP/2 协议，自带了 multiplex 支持，所以并不会产生很多的底层 TCP 连接，代理层再支持 multiplex 的优化意义不大。而且 multiplex 的支持会导致额外的问题，如单 TCP 连接被限速，更加复杂繁琐的连接错误检查和纠错等。
gRPC：gRPC 和其他一些类似的技术，只是方便开发者实现的一些技术框架和标准，对代理协议本身并不会提供什么改进和优化。
抗封锁：不同协议由于其特征不同，被封锁的可能性各不相同，但是如果你现在用的协议没有受到干扰，那就没有必要去追求其他协议。目前代理协议流量特征主要有以下几类：
- 明确特征：如 OpenVPN、SSH 等，这些协议并未为抗封锁所设计，所以存在明显的特征，极易被封锁。
- 完全无特征：如 shadowsocks、VMess 和其他衍生协议，目前已发现此类加密后完全不具备任何特征的流量，反而容易被当成一个特征进行封锁。
- 真实使用 TLS：如 Trojan，客户端不产生额外特征的情况下与标准 TLS 基本一致（如 Surge 的 Adaptive TLS Fingerprint 功能），但所使用的证书可能被用于判断。另外在使用该 TLS session 再去传输 TLS 流量时，可能产生一定的流量特征。但该特征不够准确，很难被实际用于封锁。
- 模拟为 TLS：如 ShadowTLS，使得连服务器证书信息等特征都可以被伪装。但是任何伪装都有可能在实现中露出蛛丝马迹，需要时间和用户量方可检验是否可靠。
- 随机特征：Snell 的设计方式，Snell 客户端会随机生成一些特征，且随机生成时依赖于当前 session（Surge 重载一次配置算一次新的 session）、PSK 哈希等输入，使得每个用户的流量特征都不尽相同。（请放心，特征很弱且算法不可逆，而且每次重启 Surge 后特征都会更新，绝不可能用于用户追踪）目前该方案表现良好。
  
  另外封锁通常会纳入多种因素综合判断，如机房 IP 段等等，排除故障时应考虑各种原因而仅协议问题。
  
  可阅读以下论文了解更多：
  The Parrot is Dead: Observing Unobservable Network Communications
  The use of TLS in Censorship Circumvention
  Detecting Probe-resistant Proxies
  How the Great Firewall of China Detects and Blocks Fully Encrypted Traffic

如果只是好奇尝鲜，可自行在 macOS 上配合 External Proxy 功能配置使用。