评估网络质量与代理工具性能有多项指标，最重要的有带宽和延迟，带宽已经有非常多的工具可以测试，而大部分工具的延迟测试对于工作于 L4 的代理工具是无效的。

另一方面，由于 Surge 内部的延迟信息是由内部视角取得的测试数据，并不一定能反映真实的使用感受，为此我们制作了一个开源的小工具用于测试延迟。

工具完全开源，代码非常简单，可自行编译使用：https://github.com/Blankwonder/SGNetworkTest
该工具使用 NSURLSession 模拟一般应用，并发执行 5 个 HTTP/HTTPS 请求，使用 HEAD 方法。NSURLSession 是系统提供的 HTTP Client，几乎所有 iOS App 均使用该类库进行网络请求。
测试程序内含两组测试服务器：中国（如 taobao.com）和全球（如 twitter.com），具体测试目标会在日志中输出。
每次测试会进行 11 轮，第一轮作为预热不计入结果，用于去除 DNS 查询延迟等不确定因素。最终结果将选择后 10 轮中最优的 5 轮数据取平均值。（因为网络肯定会存在波动导致延迟不断变化，而由代理工具所引入的额外开销通常是固定的，所以以这样的方式去处理数据以减少网络波动的影响）
每轮测试结束后使用 [NSURLSession invalidateAndCancel] 保证下一轮测试重新进行连接。

Surge 在延迟方面做了非常多的架构和细节优化，确保在由 Surge 进行请求转发时尽量降低延迟损耗。通常来说，开启 Surge 使用 Direct Outbound 模式，测试结果应与不开启 Surge 直接测试相差在 5ms 以内。若使用规则模式进行测试，可能再额外产生个位数 ms 的开销。

该工具可用于评估 Surge 是否按预期正常工作，也可使用该工具与协议的官方客户端进行对比，确认 Surge 对代理协议的实现是否达到最优。

以下为我们在工作室中的测试结果：

测试环境：iPhone 12 Mini，iOS 16.1 Beta，Ethernet Adapter，北京电信，Surge iOS 为 5.1.2 正式版，Surge Mac 为 4.9.0 正式版。

从上述结果中可看出，Surge 在直连模式下，对延迟几乎没有影响。

WireGuard：同一子网下 WireGuard 服务端

Shadowsocks & Trojan：服务端为 Surge 内 RTT 测试结果约为 50ms 的香港服务器

注意事项：

应建立一个空配置来进行测试，避免各种高级功能产生干扰。
若要与其他工具进行对比，直连模式下应确保 DNS 设置一致，避免应 CDN 分配不同导致结果不一致，以及 IPv6 的一致性。代理模式下应确保各种配置一致，TFO、是否使用 TLS、是否使用 WebSocket 均会产生比较大的影响。
短时间内反复多次测试，可能导致被目标服务器当做恶意请求屏蔽，等待几分钟后再重新测试即可。
由于不同的测试环境下结果差异会相当大，该测试的结果仅在相同网络环境下具有可对比性。

一些常见问题：

Q：为什么开启 Surge 后测试 HTTP 或者 HTTPS by MITM，测试结果比不开启 Surge 反而更低？

由于 Surge 是完整的全功能 HTTP Proxy，即使在客户端完全断开连接后，Surge 仍会与服务端保存连接约 30s。这使得在下次进行连接时不再需要重新握手响应很快。

但是由于这个设计的存在，这两项测试的结果只具备参考意义，不太具有对比意义。

Q：为什么开启 TFO 后测试结果的变化很小？

首先应确认 TFO 是否真的生效，具体可参考：https://community.nssurge.com/d/866-tcp-fast-open。
另外，部分代理服务商采用了多重服务器转发的设计，使得与入口服务器间的 RTT 非常小，这种情况下开启 TFO 的提升非常有限。

Q：这个测试的结果对应的实际意义是什么？

这个测试的结果和在开启 Surge 或其他代理工具后，App 打开后首次加载数据的延迟相吻合。