[Feature Request]browser dialer 功能

[e1732a364fed]

见 https://github.com/XTLS/Xray-core/pull/421

由于墙越来越高，而我们还没兼容naiveproxy，所以暂时用 浏览器拨号 可以直接利用 浏览器做盾牌挡一下

[HeXis-YS]

个人感觉这个功能没有实现的必要。 自Xray推出WSS Browser Dialer已经过去1年8个月。那时使用WS过CF还是一种相当常见的用法，开发者有充分的积极性为WS开发一些实验性功能。与Browser Dialer一同发布的功能中还有uTLS，但是当时也仅支持普通TCP，对WS gRPC还没有支持，这时Browser Dialer更多地是uTLS的一种替代品。本项目对各种协议都有良好的uTLS支持，Browser Dialer相比于uTLS的优势也就仅限于一些行为上的细微差异了。 而Browser Dialer又不可避免地需要网页浏览器，这直接导致了其应用范围被很大程度上限制在了桌面平台，对于移动设备和嵌入式设备使用难度都非常高。就算通过某种方式解决了平台的兼容性，浏览器自身的限制也会影响性能和使用体验。 我个人的看法是，服务器被墙的原因很大程度上（9成以上）其实来自于用户的不适当操作和配置（分流、伪装等）而非代理程序存在的未被证实的缺陷。发布1年8个月之后，WSS Browser Dialer仍未收到良好的反馈就是很好的佐证。 综上，我认为没有充分的理由开发这一功能。（看开发者的意思还想兼容naive，我认为也大可不必）

[e1732a364fed]

本项目对各种协议都有良好的uTLS支持，Browser Dialer相比于uTLS的优势也就仅限于一些行为上的细微差异了。

uTls是没法过cdn的，而browser dialer应该可以。因为uTls是假的tls，只实现指纹，却不实现所有加密套件。

聊胜于无，有时间就实现。不难。

[e1732a364fed]

观察到一个类似的？ https://github.com/HyokaChen/ChromeHeadlessProxy

[egg1234]

本项目对各种协议都有良好的uTLS支持，Browser Dialer相比于uTLS的优势也就仅限于一些行为上的细微差异了。

uTls是没法过cdn的，而browser dialer应该可以。因为uTls是假的tls，只实现指纹，却不实现所有加密套件。

聊胜于无，有时间就实现。不难。

@e1732a364fed 想请教一下“ uTls是没法过cdn”这个是怎么表现的呢？因为我这边使用nekoray的windows客户端，选择v2ray内核，然后在vmess+ws+tls情况下过CF，CF点亮proxy功能，代理选择utls为chrome及firefox都能正常连接代理使用，所以有上面的疑惑想了解

谢谢！

[e1732a364fed]

代理选择utls为chrome及firefox都能正常连接代理使用，所以有上面的疑惑想了解

不知道你的v2ray现象如何解释。我们测过用vs使用utls是没法过cdn的。