请求添加shadowsocks客户端支持

[FanLuoh]

能不能增加shadowsocks客户端支持，主要是在服务端需要用到。 服务端根据域名分流，将流媒体分流到另一台vps上面进行访问，我觉得服务端之间的流量传输不需要过于复杂的加密（如tls），以轻量便捷为主。 具体使用场景： A小鸡 网络好 但不解锁流媒体 B小鸡 网络差 但解锁流媒体 在A小鸡上搭建verysimple服务端，指定流媒体域名分流到B小鸡进行访问，达到节点解锁流媒体的目的 这种情况下我更倾向于在A B之前用ss协议通讯，因为没有审查，而且ss足够轻量便携 感谢大大

[e1732a364fed]

嗯。可以考虑。

实现一下 ss/ssr 的过程，正好能为 vless v1 的 内层加密模式 积累经验。

[e1732a364fed]

要读shadowsocks协议标准。

http://shadowsocks.org/en/wiki/Protocol.html

https://github.com/shadowsocks/shadowsocks-org/wiki

博客参考

https://www.chinagfw.org/2020/01/shadowsocks_21.html

https://sulangsss.github.io/2018/12/18/Network/SS-SSR%20%E5%8E%9F%E7%90%86/

https://blog.rexskz.info/redirect-attack-weakness-of-ss-stream-cipher.html

[e1732a364fed]

网上搜索到的资料似乎 以 ss为主，而且发现 v2ray 也是只支持 ss的，不知道什么情况。而且 看很多评论有人说ssr是山寨的？？

不过我记得似乎最近说说 ss能精准识别了， 而ssr不能？？

不过我又听说 ssr停更了但是 ss没有？？

为啥事情如此复杂。。。

我还是先搞ss吧，似乎不难。

[FanLuoh]

我记得的是ssr已经被精准识别了 而且好久没有更新了 因为多用户管理做的好 所以现在基本上都是非个人项目在用 而ss是一直在更新的 https://github.com/shadowsocks/ 而且应该没有精准识别吧 主要得益于 aead 的实现 即 AES-128-GCM AES-192-GCM AES-256-GCM ChaCha20-IETF-Poly1305 XChaCha20-IETF-Poly1305 这五个加密

[e1732a364fed]

我记得的是ssr已经被精准识别了 而且好久没有更新了 因为多用户管理做的好 所以现在基本上都是非个人项目在用 而ss是一直在更新的 https://github.com/shadowsocks/ 而且应该没有精准识别吧 主要得益于 aead 的实现 即 AES-128-GCM AES-192-GCM AES-256-GCM ChaCha20-IETF-Poly1305 XChaCha20-IETF-Poly1305 这五个加密

原来如此。那就不管ssr了，只实现ss即可。

[e1732a364fed]

目前 因为 正好 ss推出了个 2022模式，那么我们似乎可以考虑先实现它？

[e1732a364fed]

参考阅读 http://overtalk.site/2020/02/25/network-shadowsocks/

似乎意识到，ss好似不像vmess等协议一样，只使用一种传输层协议来传输 tcp和udp数据；而是：用tcp传tcp，用udp传udp。 如此的话，特征必很明显。

还有一个重要的问题，就是，我们vs的架构，在设计之初，就是为vmess/vless/trojan等 只需要一种传输层协议 来获取 多种传输层协议的客户端等数据的；

而为了支持ss，以目前的vs架构来说，要同时写两个listen，一个监听tcp，一个监听udp，如此才能做到。

而且对于client来说也比较棘手，因为我们的架构只认为需要dial单一的传输层协议就可以与一个服务端完整通信，所以配置文件里需要配置network指明使用的是哪个传输层协议；而如果是ss的模式的话，则客户端对tcp和udp都要拨号，也十分麻烦。

总之，这种同时使用两个传输层协议的代理协议，特征明显、不符合vs的哲学以及架构，我不再计划进一步支持。 目前已经有了初步的支持，我也不愿继续完善，如有朋友有兴趣可以继续提PR。

[e1732a364fed]

还是要加ss

[e1732a364fed]

shadowtls

golang的quic没法自定义tls层

[e1732a364fed]

在 最新 commit 83ed64011792c163e9457267101bfb68bb396a37 中，已经支持了shadowsocks

不过目前只支持到aead，没支持 2022.

我简单看了一下，目前golang到 ss-2022的实现，一般用的是sing包的实现： https://github.com/SagerNet/sing-shadowsocks

它又引用sing

但是我暂时不想引用这么一个大的外部包。

这个包似乎不错 https://github.com/database64128/shadowsocks-go

这个 database64128 正是 ss-2022文档的编写者 https://github.com/Shadowsocks-NET/shadowsocks-specs/blob/main/2022-1-shadowsocks-2022-edition.md

[SakuraSakuraSakuraChan]

在 最新 commit 83ed640 中，已经支持了shadowsocks

不过目前只支持到aead，没支持 2022.

我简单看了一下，目前golang到 ss-2022的实现，一般用的是sing包的实现： https://github.com/SagerNet/sing-shadowsocks

它又引用sing

但是我暂时不想引用这么一个大的外部包。

这个包似乎不错 https://github.com/database64128/shadowsocks-go

这个 database64128 正是 ss-2022文档的编写者 https://github.com/Shadowsocks-NET/shadowsocks-specs/blob/main/2022-1-shadowsocks-2022-edition.md

根据TG上的反馈，SS2022被封的不少，而且是直接封IP，因此感觉不支持也没什么，基本的 vmess+ws 存活率都比这个高

[e1732a364fed]

根据TG上的反馈，SS2022被封的不少，而且是直接封IP，因此感觉不支持也没什么，基本的 vmess+ws 存活率都比这个高

嗯