anytls - 控制您的代理流量行为模式，逃避 TLS in TLS 检测

[anytls]

大家好！ 如果您对新技术感兴趣，不妨试试我们的新协议！🚀

这是一款精心设计的 TLS 代理，具备更简单的配置，更优的性能，并且更强的抗审查能力，助您畅通无阻。

🔗 项目地址： https://github.com/anytls/anytls-go

我们期待您的体验与建议！💡

如果 Xray-core 开发者接受，我们也可将此协议通过 Pull Request 添加至 Xray-core。

[RPRX]

又简单看了下，为什么你设计一个全新的协议却使用“以地址确定 UoT”的方案、sing-box 的 UoT？你是世界的小号？

[anytls]

没必要纠结这种细枝末节。在 TLS 上使用哪种 UoT 方案并没有本质区别，我们只是使用了较为方便的一种。而且，现在代理承载的用户流量主要都是 TCP。

[RPRX]

你不觉得 XUDP 的 UoT Migration 与它们有本质区别吗？

[RPRX]

刚刚简单看了一下代码，看到你都是在使用 sing-box 的组件，觉得你对它的开发会比较熟悉，并且也认为 CDN 是滥用

Vision 也确实有准备了很久的 Seed #3260 ，它支持结合 Mux 和 CDN 使用，anytls 和 Seed 相比优势在哪？

[Fangliding]

udp我不关心 我的看法一样 细枝末节的东西 能用就行
但是这些东西感觉 vless+mux.cool也可也做到 这东西本身是一个vmess这个层级的代理协议 自带回落 多路复用 和padding功能
回落这个功能vless也已经有了 多路复用mux.cool也可以做到 包括填充mux其实也可以实现只是没做

[RPRX]

@CyanChanges #3272 (comment)

[RPRX]

@CyanChanges 你这言论就像说“v2fly 把 VLESS 弃用了”一样无脑，不要发表这种未经大脑思考、一点历史也没查过的言论

[RPRX]

@CyanChanges 你会看代码不会看 git history？

[RPRX]

@CyanChanges 这不是人尽皆知的吗

[RPRX]

@CyanChanges 只是这一个原因吗？想不通就别想了，这么无聊的问题就别问了，浪费时间

[MoRanYue]

anytls can you tell me, why do we need to use this single protocol rather than trying adding functions to available protocols that exists now? What a redundant protocol...

[MoRanYue]

what's one of the main reasons is that i think we have already a nice protocol and lots of good functions supported that, and anytls seems not to be more useful than vless with xhttp+tls/reality or visions+tls/reality, to name but a few. on the other hand, thinking about seed in the near future, or vmess with mux.cool, or vless with configuring xhttp's xmux? yeah, we can even completely avoid tls in tls.
i felt familiar with something when considering anytls, it seemed to make a big deal out of a small matter, just intending to have more configuration to tls packet padding and multiplexing mechanism so that created a new protocol.

[MoRanYue]

what's one of the main reasons is that i think we have already a nice protocol and lots of good functions supported that, and anytls seems not to be more useful than vless with xhttp+tls/reality or visions+tls/reality, to name but a few. on the other hand, thinking about seed in the near future, or vmess with mux.cool, or vless with configuring xhttp's xmux? yeah, we can even completely avoid tls in tls. i felt familiar with something when considering anytls, it seemed to make a big deal out of a small matter, just intending to have more configuration to tls packet padding and multiplexing mechanism so that created a new protocol.

Well, firstly, VLESS doesn't have a good design, and is kinda a heavy protocol, it needs to use multiple versions and sub protocols to patch its problem. Well VLESS claims they are the best and they does everything first. Well actually that doesn't seems to be true. They invented a protocol that includes the legacy of Vmess, and spent months to implementing sub protocols to fix their bad design. I don't think coupled everything is good for whatever reason, just Keep It Stupidly Simple.

maybe you are thinking differs to me, i prefer keep one factor simple and combine it with others, i consider scalability and compatibility as important features. you may prefer a big toolkit which has already many things included. afterwards, i dont think vless is heavy, developers originally purposed on using it with others bcuz vmess had already too many things.

[MoRanYue]

And probably these things will get RPRX unhappy and block me or lock/delete the disscussion lol, i don't care, well I stopped using xray/xtls/whatever these years.

okay, i thought that you cares xray-core, since you dont need it and care it, i dont have to explain anything else.

[RPRX]

@CyanChanges 基本的错误事实乱飞，连协议原理什么的都没区分清楚，懒得喷

[RPRX]

@CyanChanges 原来还是你啊？什么 VLESS 是 ShadowTLS 的 copy，什么 XTLS 在 ShadowTLS 后才出现都被你说出来了，你分得清这些协议哪个是哪个吗？又菜又爱玩又丢人现眼，blocked