Sharing a modified Shadowsocks as well as our thoughts on the cat-and-mouse game

[gfw-report]

Authors: Anonymous, Anonymous Date: Saturday, October 15, 2022 中文版：分享一个修改版的Shadowsocks，兼谈我们对猫鼠游戏的一点想法

---

In this post, we release and open source a modified version of Shadowsocks that can bypass the current GFW's detection and blocking. We first introduce the reason why this modified Shadowsocks can bypass the detection and blocking. We then share a simple tutorial on how to setup the client and server. We will also cover two other ways that help Shadowsocks and VMess bypass the current GFW's blocking. At the end of the article, we share some of our thoughts on the cat-and-mouse game of censorship. In particular, we start with answering why censor always starts the massive blocking a few days or weeks before politically sensitive period of time in China; we then argue that, comparing to the anti-censorship community, a fundamental weakness of censor is its inflexibility. We further discuss how to exploit censor's weaknesses to achieve better anti-censorship effect with limited resources.

Motivations

We release this modified Shadowsocks tool today for three reasons:

1. First, we want to provide Chinese netizens with a (temporarily) viable solution to bypass censorship, mitigating the GFW's massive blocking of multiple censorship circumvention tools since October 3rd, 2022.

2. Second, we would like to take this opportunity to start a discussion among anti-censorship researchers and developers. Our empirical research shows that the current GFW can already accurately identify Shadowsocks, VMess, and Obfs4 and many other full-encrypted protocols. We estimate that the GFW's current traffic detection algorithm has 0.6% false positives, while the false negatives are almost negligible. This finding urgently requires us to brainstorm and discuss how to improve the current protocols collectively.

3. Finally, we would like to use this release as an experiment to observe both the censor and the anti-censorship community on how fast each side can react to a new (anti-)censorship event.

Why can this modified Shadowsocks circumvent the GFW's current detection and blocking?

We worked with other researchers to discover that the current GFW utilizes a number of different rules to identify fully encrypted protocols like Shadowsocks, VMesss, and Obfs4. One of these rules takes advantage of the fact that the ratio of 0 bit to 1 bit in these encrypted flows is close to 1:1. Therefore, if we add more 0s or 1s to the encrypted traffic and then rearrange the bit sequence, we can achieve the goal of changing the original ratio feature to bypass detection and blocking.

How do I use this modified Shadowsocks?

This modified version of Shadowsocks is based on Shadowsocks-rust, and we also make use of Shadowsocks-android to compile the apk files for Android users. All client and server side software can be found at this branch and this release.

Installing the server

The installation process is the same as installing any other Shadowsocks-rust server.

1. First you login to your remote server, and then get the server binary with:

wget https://github.com/gfw-report/shadowsocks-rust/releases/download/v0.0.1-beta/shadowsocks-v1.15.0-alpha.9.x86_64-unknown-linux-gnu.tar.xz
tar xvf shadowsocks-v1.15.0-alpha.9.x86_64-unknown-linux-gnu.tar.xz

2. Then you create a configuration file:

sudo nano server_config.json

Copy and past the following settings to the file. Note that you need to replace the password ExamplePassword with a much stronger one. A handy way to do this from your terminal is: openssl rand -base64 16. You may also want to change the server_port.

{
  "server": "0.0.0.0",
  "server_port": 8388,
  "password": "ExamplePassword",
  "method": "aes-256-gcm"
}

After finishing editing, you type Ctrl + x to exit. The text editor will ask "Save modified buffer?", and you can type y and then hit Enter.

3. Now you can start running the binary with the configuration file, but to make it work even after you ended your SSH session, you may want to create a tmux session by:

tmux

You then do:

./ssserver -c ./server_config.json

Finally, type Ctrl + b and then type d to detach from the tmux session.

Firewall configuration

We use ufw to open ports for the Shadowsocks server.

To install ufw on a Debian-based server:

sudo apt update && sudo apt install -y ufw

Then open ports for ssh and Shadowsocks-rust. Note that if you set the server_port to a value different than 8388 in server_config.json, you need to change the value 8388 below accordingly:

sudo ufw allow ssh
sudo ufw allow 8388

Now enable ufw:

sudo ufw enable

If it prompts Command may disrupt existing ssh connections. Proceed with operation (y|n)?, type y and hit Enter.

Finally, run sudo ufw status, and the output should look like this:

Status: active

To                         Action      From
--                         ------      ----
22/tcp                     ALLOW       Anywhere
8388                       ALLOW       Anywhere
22/tcp (v6)                ALLOW       Anywhere (v6)
8388 (v6)                  ALLOW       Anywhere (v6)

Client side configuration

Below is a configuration file for Client. Remember to change the server value from ExampleServerIP to your remote server's public IP address. If you used andorid and installed from the apk file we provided, the usage should be the same as usual.

{
    "server": "ExampleServerIP",
    "server_port": 8388,
    "password": "ExamplePassword",
    "method": "aes-256-gcm",
    "local_address": "127.0.0.1",
    "local_port": 1080
}

Limitation of the current implementation

• Since we made changes to the Shadowsocks protocol, it is not compatible with other Shadowsocks clients and servers for now. Users need to download the client and server we prepared.
• Currently, the clients only support Windows, Linux, macOS, Android phone, and Android TV. It doesn't not support iOS. We welcome iOS developers who have the ability to implement this modified protocol. We also encourage iOS developers to contact us and we will share other ways to bypass the censorship with you.
• In terms of encryption method, the modified version does not yet support Shadowsocks-2022. This is not because we intend not to support it, rather, it's just that we do not have enough time to do it yet. Our current recommended encryption method choices are: chacha20-ietf-poly1305 or aes-256-gcm.
• In terms of implementation, we have made changes directly on the core code. It's not because we want to start maintaining a separate folk of the Shadowsocks protocol, rather, we just have got enough time to make the modified algorithm a user-selectable option yet. We will actively communicate with the Shadowsocks developers and hope to eventually merge the new protocol into Shadowsocks as a user-selectable option.

Are you aware of any other ways to circumvent the current blocking?

We know of two other currently viable options, all of which utilize a different traffic detection rule by the GFW.

If you are a V2Ray user, you can turn on the ExperimentReducedIvHeadEntropy option to avoid the GFW's detection and blocking. The advantage of this option is that you do not need to make any changes to your servers.

@database64128 also implemented another way to bypass the censorship. Because the protocol is changed, it requires updating both client and server to use it.

Our thoughts on this cat-and-mouse game

We'd like to take this opportunity to share some of our thoughts on the cat-and-mouse game of censorship. Our views are based on our observations and reflections on both the censor and the anti-censorship community; we have also been deeply influenced by klzgrad, David Fifield, and many other anti-censorship developers and researchers.

Censor's timing choice of new blocking techniques

As many long-time Internet censorship observers have noticed, Chinese censors always start using their new censorship weapons on a large scale a few days or weeks before a politically sensitive event. In fact, such timing choices are no coincident. So what are the specific reasons? We suspect there are at least three reasons, and we encourage everyone to share their thoughts on them.

1. First, it is an important political task for censors to ensure that they have sufficient control over public opinion and information flow, at least during politically sensitive time periods. This task is often described in official parlance as "protecting the cybersecurity during such-and-such event".

2. Second, censors are willing to tolerate more collateral damage caused by false positives in detection during sensitive times. This nature provides new censorship weapons a more permissive trial-and-error environment when they are first put into use. Tschantz et al. analyze and summarize a large number of censorship incidents and find that "real censors tend to use vulnerabilities that produce underblocking but not overblocking" (see recommendation 5). And this tendency shifts slightly during politically sensitive times: censors become more tolerant of the collateral damage caused by false positives in detection in trade of a tighter social control. By deploying a new censorship weapon during such period of time, the censor's mistake will be more tolerated even if the tool caused any overblocking accident due to bugs that were not tested out in the prior phases. klzgrad shares a similar view in this comment.

3. Finally, and most importantly, a often overlooked reason is the fact that the GFW is actually trying to compensate for and cover up its fundamental weakness of inflexibility. In this cat-and-mouse game, the censors know that they are simply no match for the anti-censorship community in terms of responsiveness and flexibility. If they started deploying their new secret weapon long before the sensitive period begins, the anti-censorship community will have more time to study it and find new ways to bypass censorship. At that point, if they can't be flexible and fast enough to improve their censorship weapons, then their attempts to tighten their controls over the Internet during politically sensitive times will fall flat. David Fifield shared a similar point of view in this comment.

Censors have weaknesses

The censor's lack of flexibility is dictated by the nature of itself and the problems it faces. Specifically, it is itself part of a large bureaucracy, which inevitably leads to inefficient internal operations and rigid behaviors. And yet the problem it faces is as complex as monitoring and censoring network traffic on a national scale. It is not hard to imagine that a new censorship weapon always has to go through the procedures of early-phase research, grants application, more formal scientific research, product development, debugging, surveying on real-world traffic, experimental deployment, and then the final nationwide large-scale deployment and use. The length of the process can take quite a long time.

One may be wondering if it indeed takes such a long time for the censor to deploy a censorship weapon. Let's take this release as another experiment to observe how fast the censor and anti-censorship community can react. In particular, let's see how long it takes the censors to block our released tool that has many weaknesses.

How to exploit censor weaknesses?

Exploiting the censor's weakness, we came up with a few principles in hope they can make the anti-censorship efforts more effective.

1. Be more tolerant of imperfect circumvention solutions and do not give up on an imperfect circumvention solution too soon. As mentioned in the previous section, the fact that the GFW is less flexible than the anti-censorship community is often overlooked. And because of that, many circumvention solutions have been dismissed and killed prematurely simply because they "have weaknesses". This is often because when anti-censorship developers and researchers envisioning themselves as censors, they tend to focus on the first step for censor -- "pre-research" -- and thinking that a circumvention solution would be easily blocked; however, they actually underestimated the long process of funding applications, formal scientific research, product development, debugging, surveying real-world traffic, experimental deployments, and finally, nationwide deployment, that the real censors have to face. In fact, if an anti-censorship developer spends an afternoon rolling out a new anti-censorship tool, but it takes the censor a large amount of time, energy, human, material and financial resources to block it in six months, we have to say this "imperfect" tool served as a great leverage.

2. Increase the diversity of censorship circumvention solutions by letting a thousand flowers bloom. In many people's imagination, the GFW is a perfect censor because of its national-level resources; however, in reality, there are limited number of teams with the skills, ability, and resources to walk through all the procedures to make a censorship weapon from an idea to a real weapon deployed national-wide. Therefore, the more anti-censorship solutions the community can create, the less likely these limited resource censor teams will be able to block all tools in one go. And as long as there is one working circumvention solution left in one of these massive blocking event, the information is not disrupted completely.

3. Actively report new censorship events, promptly measure and understand new censorship techniques, and share the viable circumvention strategies with the community. Achieving this will require communication, effort, and cooperation between Chinese netizens, researchers, and developers. Encouragingly, we are now seeing more and more people joining this collaboration and working together as a collective.

4. Develop backup circumvention tools in advance. We have seen that the GFW makes up for its lack of flexibility by starting using its new secret weapons in large scale a few days before politically sensitive events. So can we use a similar strategy where we develop more backup plans in normal times, and then send them out just before sensitive times, like this release? This way, even if the technical staffs working for the GFW immediately spot any flaws in the new tool, and knew how to block the tool, it would still take them a long research and development cycle before actually being able to block it in real world.

Acknowledgment

We thank David Fifield for commenting on an earlier draft of this article.

Contact

We encourage you to share your thoughts, comments, user experiences publicly or privately. Our private contact information can be found at the footer of GFW Report.

[free-the-internet]

@free-the-internet By the way, the server in that post is still there. I can leave it up until 23:59 UTC on 2022-10-20 in case you want to test its reachability from your client. The v2rayN client config is in the post.

@free-the-internet This is what worked for me: https://freejohn123.github.io/2022/10/19/xray-from-source.html I didn't use a CDN because I've had problems in the past with Cloudflare not accepting free domain names. I don't know if that has changed. Also, I manually keyed in my client config. Screenshot enclosed in the post.

This saved my day. I had 3 problems:

• I used CDN with according to https://guide.v2fly.org/en_US/advanced/h2.html it doesn't work with CDN. But, websocket is working with CDNs I guess.
• I used my domain name without www for the address field in client side. By the way, your screenshot is correct for the client config, but in the table, address field is missing.
• I didn't include SNI

Using CDNs, I guess, should be very effective as I read this way, the real IP is hidden from the [G]FW. Have you tried it in Iran?

Well, The reason why CDN is currently available to bypass the censorship is that there are many legal(official) websites running through CloudFlare, such as the Hong Kong government official website. Thus, there is no TLS or other complex censorship but only SNI censorship for the connection towards CloudFlare so that you can use CDN to completely bypass the censorship. Sure, your server's IP is hidden behind CDN, so unless GFW blocks your domain or CloudFlare itself, the real connection won't be affected. Besides, CloudFlare only accepts regular HTTP(S) or Websocket connections. So Shadowsocks and Trojan don't support it. And, CloudFlare only allow the connections passing through a few specific ports, such as 2032, 80, 443, so you can't connect through an abnormal port. Additionally, using CloudFlare as a proxy agent violates the terms of services of CloudFlare, so there is a risk that your account gets banned.

Thank you for your great explanation. I think in Iran the censorship is tougher than China. As you said, some parts of the Chinese government and maybe media companies are using external CDNs; but in Iran either there is not such a service at all, or they are using domestic CDNs. So basically for Iranian regime it's much less costly to cut the whole internet off. A part of this also comes from the fact that Iranian economy is destructed under the external sanctions and internal corruption. Anyway; Can we have a pool of a persons who can share their servers and use something to multiplex the traffic? This would be great for Iran where usually external CDNs are not accessible. This way the huge volume of traffic towards the same IP from an specific IP, for the whole day can't be detected easily.

[Hadi-1624]

@free-the-internet This is what worked for me:

https://freejohn123.github.io/2022/10/19/xray-from-source.html

I didn't use a CDN because I've had problems in the past with Cloudflare not accepting free domain names. I don't know if that has changed. Also, I manually keyed in my client config. Screenshot enclosed in the post.

Hello, If i follow this, will it achieve the same result that 0xLem0nade has made in Iran? I'm trying to build a proxy so that my friends and family can access the internet as well.

[Hadi-1624]

@free-the-internet This is what worked for me: https://freejohn123.github.io/2022/10/19/xray-from-source.html I didn't use a CDN because I've had problems in the past with Cloudflare not accepting free domain names. I don't know if that has changed. Also, I manually keyed in my client config. Screenshot enclosed in the post.

Hello, If i follow this, will it achieve the same result that 0xLem0nade has made in Iran? I'm trying to build a proxy so that my friends and family can access the internet as well.

Hi, first half of this tutorial is for compiling xray from source and you don't need to do that anymore, new official xray builds are up now. I'm actually working on a script to simplify setting up xray server with Docker and will soon create a repo for that.

Thanks so much, it means a lot to us. So far i've tested a setup, VLESS + TCP + xtls-rprx-direct from this tutorial: https://privacymelon.com/how-to-install-vless-xtls-xray-core/ IT works but there are some issues, and i have no idea how to resolve them.

1. IT does not work with the v2rayng client on android, but it works with a client named xray vpn. I do not know how safe it is!
2. On windows, i've used v2rayn-core and it connects, however, when i turn system proxy on, applications such as unigram, battle.net won't connect, and discord voice/video calling won't work either. The upload speed is also set to 30 kb/s

Is this how a proxy behave and does it mean that i and my family wouldn't be able to use voice calls and such using proxies?

[free-the-internet]

@Hadi-1624 Use this config, thanks to @0xLem0nade . It's vmess+h2+tls.

Also use the latest android client from https://github.com/2dust/v2rayNG/releases which currently is 1.7.23

Note that CDN is not supported by h2. Use port 443 in Iran. In Firefox fill both http and socks5 proxy fields. To tunnel the whole system by opening a TUN interface see this.

@freejohn123 Could you please update your tutorial with these changes by @0xLem0nade ? Your config was not working on android (even by latest utls chrome/firefox fingerprint). Yesterday I followed the config by 0xLem0nade and android client could connect.

[ghost]

Is this how a proxy behave and does it mean that i and my family wouldn't be able to use voice calls and such using proxies?

Voice calls typically use UDP.

UDP is available as an option for SOCKS inbound.

However, Windows system proxy assumes HTTP inbound. There is no option for UDP on HTTP inbound.

Does your voice calling app have an option to use a SOCKS proxy? If so, you might be able to get it working with a config file with a SOCKS inbound with UDP enabled. For example:

    "inbounds": [
        {
            "listen": "127.0.0.1",
            "port": "10808",
            "protocol": "socks",
            "settings": {
                "auth": "noauth",
                "udp": true,
                "ip": "127.0.0.1"
            }
        },
        {
            "listen": "127.0.0.1",
            "port": "10809",
            "protocol": "http"
        }
    ],

If your voice calling app does NOT have an option to use a SOCKS5 proxy, you might have to consider "sophisticated" protocols such as OpenVPN+Shadowsocks or OpenVPN+Cloak.

Of course, Shadowsocks by itself can also transmit UDP as UDP, but that again is assuming your voice calling app can be configured to use a SOCKS proxy.

[patchescamerababy]

Can you add support for udp, including uot 能否增加对udp的支持，包括uot

[Hadi-1624]

Thank you guys for your help

When using proxies such as shadowsocks or v2ray, my upload speed is very very bad. example my download speed is at 1 mb/s, my upload speed goes down to 30 kb/s Are there ways to solve this issue?

[ghost]

When using proxies such as shadowsocks or v2ray, my upload speed is very very bad. example my download speed is at 1 mb/s, my upload speed goes down to 30 kb/s Are there ways to solve this issue?

There's nothing in the protocol itself that would make it that slow. You would have to do A/B testing to narrow down the cause of the problem, e.g. overloaded server, congested route, deliberate throttling by ISP, or whatever.

[opmaaadi]

Is there a specific reason that you use "pure" ShadowSocks (without plugins such as V2Ray, Xray, etc)? @gfw-report

[Kimberlysz]

If you are a V2Ray user, you can turn on the ExperimentReducedIvHeadEntropy option to avoid the GFW's detection and blocking. The advantage of this option is that you do not need to make any changes to your servers.

Hello there, currently I am using wss (vmess + tls + nginx), I use LEMP, then I use certbot to issue ssl, finally I add wordpress. I am wondering how to add this ExperimentReducedIvHeadEntropy option?

for clients I use, windows: Clash for Windows; android: v2rayNG, Clash for Android; macOS: clashX; iOS: shadowrocket.

what I learnt and found out mostly close tothe description are located here in v2fly.org (https://www.v2fly.org/config/protocols/vmess.html#userobject), then search "experiments: string".

So I took clash for windows as an example, and I add this in clash for windows yaml file:

  # 仅适用于设置 allow-lan 为 true 时
  # 192.168.122.11: 绑定单个 IPv4 地址
  # "[aaaa::a8aa:ff:fe09:57d8]": 绑定单个 IPv6 地址
  # bind-address: "*", "*": 绑定所有 IP 地址
  experimental:
    ignore-resolve-fail: true # 忽略 DNS 解析失败，默认值为true
    Experiment-Reduced-Iv-Head-Entropy: true # reduce entropy
    experiment-reduced-iv-head-entropy: true # reduce entropy
    ExperimentReducedIvHeadEntropy: true # reduce entropy
    experimentreducedivheadentropy: true # reduce entropy

and then at the server side I add this in ClientObject (https://www.v2fly.org/config/protocols/vmess.html#clientobject) under InboundConfigurationObject:

  {
    "email": "abc@yahoo.com",
    "id": "random uuid",
    "level": 0,
    "alterId": 0,
    "experiments": "ExperimentReducedIvHeadEntropy"
  },

Finally I also add maxEarlyData (https://www.v2fly.org/config/transport/websocket.html#websocketobject) in WebSocketObject.

  "wsSettings": {
    "path": "/x",
    "headers": {
      "Host": "example.com"
    },
    "maxEarlyData": 1024,
    "earlyDataHeaderName": "Sec-WebSocket-Protocol"
  },

I know these are probably wrong but all these echos back to the question, how to add 'ExperimentReducedIvHeadEntropy'. Although my servers get blocked daily but I think wss is still a very good method. Thank you in advance.

[fortuna]

The Outline Client now supports a prefix parameter that gets used as the first bytes of the connection salt to disguise it as an allowed protocol. The prefix is specified on the Access Key. Usage details and examples can be found at https://www.reddit.com/r/outlinevpn/wiki/index/prefixing/

Combined with Dynamic Access Keys, you can use different prefixes for different sessions.

One advantage of our approach is that downloading the client or inspecting its code doesn't give the censor knowledge to know what to block. Furthermore, it enables service providers to change prefixes easily and move faster than the censor.

[free-the-internet]

The Outline Client now supports a prefix parameter that gets used as the first bytes of the connection salt to disguise it as an allowed protocol. The prefix is specified on the Access Key. Usage details and examples can be found at https://www.reddit.com/r/outlinevpn/wiki/index/prefixing/

Combined with Dynamic Access Keys, you can use different prefixes for different sessions.

One advantage of our approach is that downloading the client or inspecting its code doesn't give the censor knowledge to know what to block. Furthermore, it enables service providers to change prefixes easily and move faster than the censor.

FYI: Tests have been done, users report that it does not working in Iran even with these modifications. However, it might be used in China.

[rezarms]

@gfw-report unfortunately doesn't work for Iran.

[KaraRyougi]

I just read the paper How the Great Firewall of China Detects and Blocks Fully Encrypted Traffic, which seems to be the research related to this modification. However, I also noticed that this research in 2021 has a contradictory conclusion regarding entropy. Did the blocking strategy change during the 1 year period?

[yoshyv]

@gfw-report How do you know if a certain IP address is under dynamic blocking? Try sending some random payload from China to an open port of that IP address:

head -c 100 /dev/urandom | nc -vn $ip $port

If after executing the command several times, your connections got timeout for 120 or 180 seconds, then you can confirm that the IP you tested is within the GFW's dynamic blocking IP subnets.

Sorry for necro but I did the test yesterday on a proxy server that I set up for my friend (only one user) and there was no timeout after reruning the command 200 time while the proxy server was blocked last year and unblocked few months later. It's an AWS Tokyo EC2 instance so I assume both the IP and ASN are red flags according to the latest research.

On the server end, I ran nc -l -p 10000 -k -v and my friend ran your command with for loop for 200 times.

Does it mean the block last year was just a false positive ? or did the GFW upgrade the algorithm?

BTW, do you have any insight of IPv6 traffic? According to some, IPv6 traffic is affected by neither active probing and passive analysis.

[gfw-report]

Hi @KaraRyougi,

I just read the paper How the Great Firewall of China Detects and Blocks Fully Encrypted Traffic, which seems to be the research related to this modification.

Thank you very much for your interest in the paper. And yes, you are right that this is the "modified Shadowsocks" we mentioned in the paper: https://gfw.report/publications/usenixsecurity23/en/#sec:responsible-disclosure

However, I also noticed that this research in 2021 has a contradictory conclusion regarding entropy. Did the blocking strategy change during the 1 year period?

Great question! Thank you for giving us the opportunity to clarify on that.

We did not observe any changes of the blocking strategy from November 2021 to the ceased blocking in March 2023. The contradicting statement was simply due to our lack of understanding of the system in 2021.

In particular, at that time in 2021, we did not fully understand the GFW's new censorship system and thus made the false/inaccurate statement in the preliminary report that "[b]locking is not based on entropy.... we find that entropy does not tell the whole story. Some payloads with very high entropy never trigger blocking, whereas other payloads with very low entropy can trigger blocking immediately".

We confirm that the GFW was indeed using the monobit testing as a measurement of randomness/entropy.

[gfw-report]

Hi @yoshyv,

We really appreciate your spirit of measuring the censorship system yourselves.

I did the test yesterday on a proxy server that I set up for my friend (only one user) and there was no timeout after reruning the command 200 time while the proxy server was blocked last year and unblocked few months later. It's an AWS Tokyo EC2 instance so I assume both the IP and ASN are red flags according to the latest research. ... Does it mean the block last year was just a false positive ? or did the GFW upgrade the algorithm?

The reason why you couldn't observe the blocking anymore is likely because the GFW has stopped dynamically blocking fully encrypted traffic since sometime between Tuesday March 7, 2023 and Wednesday March 15, 2023.

It may be because the politically sensitive time has passed and the censor is thus less willing to tolerate the collateral damage. Specifically, there were two politically sensitive conferences in China ended on Monday March 13, 2023:

• https://en.wikipedia.org/wiki/2023_National_People's_Congress
• https://zh.wikipedia.org/wiki/中国人民政治协商会议第十四届全国委员会#第一次会议

We documented this observation in this directory and README in the repo: https://github.com/gfw-report/usenixsecurity23-artifact/tree/master/artifacts/ceased-dynamic-blocking

---

BTW, do you have any insight of IPv6 traffic? According to some, IPv6 traffic is affected by neither active probing and passive analysis.

Great question. We do not have an answer to this question because we haven't done any testing over IPv6 yet.

[KaraRyougi]

So from my understanding, the current investigation is only focusing on "real-time TCP block", which seems to be only part of how GFW works now. I suspect there are also offline detections. Evidence includes the reports of blocking in this thread, and other reports of UDP-based protocols such as Hysteria being blocked.

[yoshyv]

@gfw-report We documented this observation in this directory and README in the repo: https://github.com/gfw-report/usenixsecurity23-artifact/tree/master/artifacts/ceased-dynamic-blocking

Thanks again for the heads up.

Are the affected AS and IP prefix the same for static blocking and dynamic blocking? Have you collected the data in this regard? Since there's no way to find out the affected IPs in a short period of time via dynamic blocking test now, is there any other method to find out which IPs are more likely to be blocked?

Is the original shadowsocks (2017) still considered a viable protocol to bypass GFW now? How to take proactive approach to prevent proxy server being IP address blocked? In fear of IP blocking, I haven't used my residential network to set up shadowsocks proxy as my IP address is not dynamic and doesn't change over years.

[robot-dot-win]

每年花50-200美元租【亚马逊/微软/Oracle/阿里/百度/腾讯】在【新加坡/北美】的VPS作为代理，随便用个什么加密协议只要数据不被破解，即可堂堂正正访问外网资源，速度极好，还不会被封。实在太担心，再加点洋葱佐料。简单、安全。

Spend $50-200 per year to rent [Amazon / Microsoft / Oracle / Ali / Baidu / Tencent] in [Singapore / North America] VPS as a proxy, casually use what encryption protocols as long as the data is not cracked, you can squarely access to the outside resources, the speed is excellent, but also will not be blocked. If you're too worried, add some onion spices. Simple and safe.