I think SS is detected by GFW

[xspeed1989]

Please answer these questions before submitting your issue. Thanks!

(Please mention that if the issue you filed is solved, you may wish to close it by yourself. Thanks again.)

(PS, you can remove 3 lines above, including this one, before post your issue.)

What version of shadowsocks-libev are you using?

3.3.4

What operating system are you using?

Windows 11

What did you do?

View google, Then my VPS IP will be unconnectable

What did you expect to see?

View google, Then my VPS IP can be connect

What did you see instead?

What is your config in detail (with all sensitive info masked)?

ports:

• "10086:1314"
• "10086:1314/udp" environment:
• METHOD=rc4-md5
• PASSWORD=xxxx
• SERVER_PORT=1234

[xspio]

原来不止我一个用不了了，切换了不同 METHOD 也没用，服务器正常的，就是ss不传数据了

[fuyang0811]

端口封的很快，但是v2ray我试了一下，也很快被封了，所以可能不是ss的问题，不过ipv6连接现在看来是没有问题的。

[xspeed1989]

v2ray 我稳定使用中

fuyang0811 @.***> 于2021年11月10日周三 下午9:25写道：

端口封的很快，但是v2ray我试了一下，也很快被封了，所以可能不是ss的问题，不过ipv6连接现在看来是没有问题的。

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/shadowsocks/shadowsocks-libev/issues/2860#issuecomment-965135518, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABHMPLTGKLLFF26YDHD3RDTULJXFDANCNFSM5HV54APA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

[OmiceyO]

同样的经历，ss好像又能被gfw测到。

[xspeed1989]

是的呀，我现在用v2ray, 我路由器的ss费了

OmiceyO @.***> 于2021年11月11日周四 上午12:59写道：

同样的经历，ss好像又能被gfw测到。

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/shadowsocks/shadowsocks-libev/issues/2860#issuecomment-965545767, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABHMPLT3IKER6OMGBBR3FO3ULKQGNANCNFSM5HV54APA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

[ongogo]

就是这周开始，换一个ip几分钟就费掉了

[rampageX]

阿里云香港，可以不停复现，换端口，测速，30 秒内 ss-server -v 开始不接收数据（就是根本不显示客户端的请求），试过 libev 和 rust 版本都一样，都是最新版本，复杂密码，chacha20-ietf-poly1305，tcp_only 。同服务器其它小众协议的暂时没事；

但是甲骨文上的 ss-server 暂时好像没事。

只能估计阿里云这种国内公司特定（特殊？）时间段有自己的一套检测机制。

[thebitdragon]

阿里云新加坡，服务器能正常访问“互联网”，服务器的其他服务也能正常被访问，ping检测一切正常。唯独接收不到shadowsocks客户端的请求。

[yjd]

最近加强了。直连ss容易就被封。原来用好几年好好的，换了密码和端口，跑一会就又会被封。 kcptun套里面就没啥问题。 Trojan还能用。

[majietank]

我也是，确定vps没问题，直连ss，刚连上没几秒，就不能使用，提示无法建立握手协议。

[extrionhk]

阿里云香港，可以不停复现，换端口，测速，30 秒内 ss-server -v 开始不接收数据（就是根本不显示客户端的请求），试过 libev 和 rust 版本都一样，都是最新版本，复杂密码，chacha20-ietf-poly1305，tcp_only 。同服务器其它小众协议的暂时没事；

但是甲骨文上的 ss-server 暂时好像没事。

只能估计阿里云这种国内公司特定（特殊？）时间段有自己的一套检测机制。

同样的情况，阿里云新加坡，握手成功后秒断（一般可读出Google首页，然后断连），大概3-5分钟后复现 已dd重装系统，也在同服务器架设了V2Ray、Brook测试，情况无差。 现购入杂牌vps应急，均没有异状。 请问有什么可用的小众协议？

[Liu-Raymond]

可以试试用kcptun套一层，会开完了。过阵子应该就好了。

阿里云香港，可以不停复现，换端口，测速，30 秒内 ss-server -v 开始不接收数据（就是根本不显示客户端的请求），试过 libev 和 rust 版本都一样，都是最新版本，复杂密码，chacha20-ietf-poly1305，tcp_only 。同服务器其它小众协议的暂时没事； 但是甲骨文上的 ss-server 暂时好像没事。 只能估计阿里云这种国内公司特定（特殊？）时间段有自己的一套检测机制。

同样的情况，阿里云新加坡，握手成功后秒断（一般可读出Google首页，然后断连），大概3-5分钟后复现 已dd重装系统，也在同服务器架设了V2Ray、Brook测试，情况无差。 现购入杂牌vps应急，均没有异状。 请问有什么可用的小众协议？

可以试试楼上的用kcptun套一层。会开完了，过阵子应该就好了。

[extrionhk]

可以试试用kcptun套一层，会开完了。过阵子应该就好了。

阿里云香港，可以不停复现，换端口，测速，30 秒内 ss-server -v 开始不接收数据（就是根本不显示客户端的请求），试过 libev 和 rust 版本都一样，都是最新版本，复杂密码，chacha20-ietf-poly1305，tcp_only 。同服务器其它小众协议的暂时没事； 但是甲骨文上的 ss-server 暂时好像没事。 只能估计阿里云这种国内公司特定（特殊？）时间段有自己的一套检测机制。

同样的情况，阿里云新加坡，握手成功后秒断（一般可读出Google首页，然后断连），大概3-5分钟后复现 已dd重装系统，也在同服务器架设了V2Ray、Brook测试，情况无差。 现购入杂牌vps应急，均没有异状。 请问有什么可用的小众协议？

可以试试楼上的用kcptun套一层。会开完了，过阵子应该就好了。

谢谢回复，我尝试一下。

[extrionhk]

V2Ray的mKCP模式，阿里雲測試成功，特此告知

[xspeed1989]

V2Ray的mKCP模式，阿里雲測試成功，特此告知

还是习惯SS， SS + KCPTUN + UDPSpeeder

[wangjie33589]

我的用的好好也被封了,请问一下什么原因?是因为在开六中全会吗

[OPENCZ]

各位大佬们，你的ss能用了么？换个国外服务商的服务器搭建ss可用么？

[xspeed1989]

不要用阿里云的线路

YW @.***> 于2021年11月15日周一 下午12:00写道：

各位大佬们，你的ss能用了么？换个国外服务商的服务器搭建ss可用么？

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/shadowsocks/shadowsocks-libev/issues/2860#issuecomment-968514657, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABHMPLQYZIAXEAMTTDDATJLUMCAVHANCNFSM5HV54APA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

[OPENCZ]

不要用阿里云的线路 YW @.***> 于2021年11月15日周一 下午12:00写道： … 各位大佬们，你的ss能用了么？换个国外服务商的服务器搭建ss可用么？ — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#2860 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABHMPLQYZIAXEAMTTDDATJLUMCAVHANCNFSM5HV54APA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

亚马逊云服务如何？或有其他云服务商推荐么？

[Xackurai]

我这边用的vultr，ping服务器是正常的，偶尔丢包。ss大约十几分钟能连上几秒钟，服务器也一切正常，换端口后情况没有任何改变，仍然ping正常ss断线。 换了数个服务器都是这样，ping延迟200~350ms，ss连不上

[wangjie33589]

我这边用的vultr，ping服务器是正常的，偶尔丢包。ss大约十几分钟能连上几秒钟，服务器也一切正常，换端口后情况没有任何改变，仍然ping正常ss断线。 换了数个服务器都是这样，ping延迟200~350ms，ss连不上

我的跟你一样哦,最近才开始这种情况的,以前都是正常的

[xiashj96]

六中全会结束以后ss还是不太对劲。已经转战v2ray+TLS，目前一切正常。事实证明伪装https流量才是骗过GFW的正确方法，租域名的费用比起VPS也不算高。给过来人指条明路：https://tlanyan.pp.ua/tag/v2ray%E6%95%99%E7%A8%8B/

[majietank]

试了搭建v2ray，各种问题没有搭建成功（个人水平问题所致），现在改用ss+v2ray-plugin成功，目前来看正常。 ps：我也是vultr，试过改端口，改加密模式，重装vps，换机房，但都没有用。

[gfw-report]

我们于2021年11月14日确认中国的防火长城现在已经可以对任何看似随机的流量进行实时动态的封锁。这样的封锁能力会影响到众多的翻墙协议，包括但不限于Shadowsocks和VMess。据用户的汇报和我们的测量，目前GFW的封锁仅针对从中国发往某些流行的国外机房的连接（比如上面提到的阿里云的香港和新加坡机房，DigitalOcean的旧金山机房，Vultr等）。我们将尽快发布一篇详细的报告。

---

On November 14, 2021, we confirm that the Great Firewall of China has now been able to suspect and dynamically block any seemingly random traffic in real time. Such capability potentially affects a large set of censorship circumvention protocols, including but not limited to Shadowsocks and VMess. A detailed report on how the blocking details will be released very soon.

[fasthorse]

The shadowsocks-libev should be upgraded right now, Let us wait for the good results.

[fortuna]

@xspeed1989 the rc4-md5 method is deprecated. It's unsafe and very easy to detect. You must use an AEAD cipher. See https://gfw.report/blog/ss_tutorial/en/#q-should-i-use-any-stream-cipher-in-shadowsocks

[fortuna]

@gfw-report Thanks for the information.

I can confirm that we saw a drop in the opt-in Outline usage metrics in China starting on November 8. It was not a complete block, so there are definitely some configurations working. One guess is that it might be related to the choice of cloud provider, region or port, but we don't have data to validate that.

[fortuna]

Here is a fun thing to try:

It's possible to give up some of the 32 bytes of the initial salt to make the traffic look more like TLS, while still being backwards-compatible with the Shadowsocks protocol.

A TLS record header takes 5 bytes, and looks like this: https://tls.ulfheim.net/. Perhaps you just need to fake the first 3 bytes. Or you may need to include the handshake header and client version as well (giving up 11 bytes total). It may be worth playing with different record types too.

This could be done either from the server or client side, depending on how exactly censorship works.

While this may bypass immediate censorship, it may also make the connections more fingerprintable. It will raise the cost of censorship, as it would require parsing the TLS record and possibly reassambly of the TCP connection.

[yanke1311]

我的azure能稳定半个月，就要换端口

[hVenus]

没结果了吗？