I think SS is detected by GFW #2860
Comments
|
原来不止我一个用不了了，切换了不同 METHOD 也没用，服务器正常的，就是ss不传数据了 |
|
端口封的很快，但是v2ray我试了一下，也很快被封了，所以可能不是ss的问题，不过ipv6连接现在看来是没有问题的。 |
|
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
<#2860 (comment)>,
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>.
|
|
同样的经历，ss好像又能被gfw测到。 |
|
是的呀，我现在用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
<#2860 (comment)>,
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>.
|
|
就是这周开始，换一个ip几分钟就费掉了 |
|
阿里云香港，可以不停复现，换端口，测速，30 秒内 但是甲骨文上的 只能估计阿里云这种国内公司特定（特殊？）时间段有自己的一套检测机制。 |
|
阿里云新加坡，服务器能正常访问“互联网”，服务器的其他服务也能正常被访问，ping检测一切正常。唯独接收不到shadowsocks客户端的请求。 |
|
最近加强了。直连ss容易就被封。原来用好几年好好的，换了密码和端口，跑一会就又会被封。 |
|
我也是，确定vps没问题，直连ss，刚连上没几秒，就不能使用，提示无法建立握手协议。 |
同样的情况，阿里云新加坡，握手成功后秒断（一般可读出Google首页，然后断连），大概3-5分钟后复现 |
|
可以试试用kcptun套一层，会开完了。过阵子应该就好了。
可以试试楼上的用kcptun套一层。会开完了，过阵子应该就好了。 |
谢谢回复，我尝试一下。 |
|
V2Ray的mKCP模式，阿里雲測試成功，特此告知 |
还是习惯SS， |
|
我的用的好好也被封了,请问一下什么原因?是因为在开六中全会吗 |
|
各位大佬们，你的ss能用了么？换个国外服务商的服务器搭建ss可用么？ |
|
不要用阿里云的线路
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>.
|
亚马逊云服务如何？或有其他云服务商推荐么？ |
|
我这边用的vultr，ping服务器是正常的，偶尔丢包。ss大约十几分钟能连上几秒钟，服务器也一切正常，换端口后情况没有任何改变，仍然ping正常ss断线。 |
我的跟你一样哦,最近才开始这种情况的,以前都是正常的 |
|
六中全会结束以后ss还是不太对劲。已经转战v2ray+TLS，目前一切正常。事实证明伪装https流量才是骗过GFW的正确方法，租域名的费用比起VPS也不算高。给过来人指条明路：https://tlanyan.pp.ua/tag/v2ray%E6%95%99%E7%A8%8B/ |
|
试了搭建v2ray，各种问题没有搭建成功（个人水平问题所致），现在改用ss+v2ray-plugin成功，目前来看正常。 |
|
我们于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. |
|
The shadowsocks-libev should be upgraded right now, Let us wait for the good results. |
|
@xspeed1989 the |
|
@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. |
|
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. |
|
我的azure能稳定半个月，就要换端口 |
|
没结果了吗？ |
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
The text was updated successfully, but these errors were encountered: