Hi Administrator,
近年来主要 CDN 提供商已经开始部署 ESNI0 了，在通过代理访问网络的时候，加密 SNI 的内容也逐渐变得可能了。随着 DoH 被 Surge 支持，以及 draft 版本已经相对稳定，我觉得提出 ESNI 需求的时机已经成熟。同时 Cloudflare 提供了一个 ESNI 测试页面1，并且在博客上2描述了为何支持这项技术。目前部署方案是使用 TXT _esni 记录来储存域名公钥，但对 RR 的支持也在进行中。我十分希望能在 Surge 中见到对这项技术的支持，谢谢！
Warm Regards,
Lug
--
支持一波，不用搭配Firefox Nightly不用关闭surge了
Surge 作为 HTTPS 代理工作时并不需要对 ESNI 进行额外支持，浏览器可以直接工作。
对于使用 TLS 协议的代理握手环节，暂时没有看到需要使用 ESNI 的必要性。
现在 Cloudflare SNI证书已经在部分地区被阻断，还请重视 ESNI 支持。
Vivooop 证书和 SNI/ESNI 没有关系
Administrator Cloudflare免费版网站不能上传自定义证书，证书统一由CF签发管理，sni暴露的域名为sni.cloudflaressl.com。在未加密SNI请求头的情况下，探测设备可以直接阻断使用CF证书的443连接，这就是目前部分地区的阻断原理，所有使用免费版CF并且只开放HTTPS的网站都不能访问。 相关的情况描述可以google
Vivooop Surge 支持自定义 TLS client hello 中 SNI 的内容，浏览器访问 URL 发送的 SNI 为 URL 中的主机名，服务端证书的 Common Name 和其他字段均为加密传输，你不主动访问 sni.cloudflaressl.com 数据流中根本不会出现 sni.cloudflaressl.com 的明文。这些和 ESNI 根本没有关系。
明白 HTTP Connect 模式下且配置了 DoH 确实流量是浏览器的事情。那么 Surge 自己的请求确实不太急迫了。
