SurgeTeam Junho 我们有我们的技术坚持，如果对已有用户的需求产生了影响，这一点我们确实抱歉，无法两全。从长期来看，这也是对所有 Surge 用户负责。 从「钱还是好赚」的角度说，明显是支持 VLESS 最好赚，不仅可以收费升级，还可以吸引更多的用户，不是吗？
Junho SurgeTeam 哈哈哈，看来您也相当清楚😄。那何乐而不为呢，你有钱赚，我们又有协议用。我对你们的软件真的是又爱又恨，vless是现在这个时代的产物，存在即合理，或许可以用另外的方式让ios surge的用户使用上也不是不行吧。不能一刀砍死，得让掏了钱的用户有选择，您说呢
SurgeTeam Junho 正是基于对现有用户的诉求，我们才一直纠结于这个事情，一直犹豫在考虑是否应该加入支持 VLESS。该文仅仅是回应 VLESS作者的荒谬攻击。 但是一旦支持，就不可能撤销，意味着关于 VLESS 的所有代码和修改，将永远存在于 Surge 代码库中，带来持续的影响。而就像当年的 SSR 一样，VLESS 也可能就仅是昙花一现，在一阵吹嘘的浪潮过后就从此无人问津。
Junho SurgeTeam 但vless确实存在几年了，也一直有人用，盛行在自建圈。以前直连机场hy2盛行时期不算太多，但这两年完全不一样了。还有您发文说如果确定此协议被广泛使用会支持，这个东西主观性太强了，真要说广泛使用的话，那现在直连机场不基本全是这个啊。也就去年年底出了个anytls，如果没有这个真不知道surge想用直连机场该怎么活。但anytls的基数完全比不上vless，目前这形式vless只会多不会少。 这个技术我不懂哈，但是在软件中这个底层代码是否可以让他可调节呢，比如更多设置里加一个vless开关，关闭他就不会底层生效，其他不需要的用户不开也不会有影响，但想用的只要打开就可以用。存在于代码库，但是对用户没影响
yhyh 因为我用的机场都转成vless了，甚至给surge订阅链接直接返回403，希望surge予以支持，作为一个已经活跃多年的协议，实在无法说是“因为使用用户不多”而不予以支持。如果真的有技术困难，我觉得也可以去与其他开发者联系讨论，毕竟诸多其他代理软件都支持了。
Amundsen 赞同对VLESS协议作者的回应，技术讨论应该基于平和的态度、只在技术范畴中去讨论，且具备专业知识和素养，那篇抨击的文章里面大部分都是抹黑、攻击，完全看不出来是github上应有的技术讨论氛围，同时作为Surge用户，我认为使用代理软件的用户也需要具备一定的专业素养，理解一个需长期使用的软件服务，需要具备足够的稳定性和安全性，而不是想做一个all in one的产品。克制地加入新特性，极具专业态度去考量每一个改动，才是用这款软件的初衷。
Junho 话说我查了一下，vless自20年底诞生到现在5年多了，而且目前的增长量，绝不是说昙花一现了。而且vless✈️很多都便宜，可以套cf，不像是hy2 它不会爆内存，可以嫖免费节点，对用户来说绝对是利大于弊
Junho Junho 而且就目前其它代理软件支持的情况来看，没有啥对用户有影响，或者说软件开发者都维护解决了？ 只能说作为一名中立的普通用户，喜欢surge的功能及ui，也喜欢vless带来的好处。目前两方不断的纷争不能给用户带来任何的有益，像老刘你说的话一样，用户也一样在做取舍。为了用surge我断舍离了很多便宜不错的vless✈️，不过目前这形式可能真断舍离不了了🥹 Junho
lifedever Junho 我目前勉强自己写了一个singbox脚本，先启动然后用surge连singbox的sock5服务。没法办，拼车高质量的代理基本都是vless。 如果这种情况一直持续下去，有可能后面会放弃surge了。现在ai写一个自用的脚本也方便
