Authors: Mingshi Wu
Between approximately 00:34 and 01:48 (Beijing Time, UTC+8) on August 20, 2025, the Great Firewall of China (GFW) exhibited anomalous behavior by unconditionally injecting forged TCP RST+ACK packets to disrupt all connections on TCP port 443. This incident caused massive disruption of the Internet connections between China and the rest of the world (source1 and source2).
This report documents our measurements and analysis of this temporary, widespread blocking event. Our primary findings are:
RST+ACK injections was on TCP port 443, but not on other common ports like 22, 80, 8443.RST+ACK injection disrupted connections both to and from China, but the trigger mechanism was asymmetrical. For traffic originating from inside China, the SYN packet from the client and the SYN+ACK packet could each trigger three injected RST+ACK packets. For traffic to inside China, only the server’s SYN+ACK response, not the client’s SYN packet, could trigger the RST+ACK packets.It is important to note that our analysis was limited by the short duration of the incident (approximately 74 minutes). We encourage others in the community to share their observations to build a more complete picture of this event.
We first confirmed the blocking by sending probes from a vantage points inside of China (AS45090, Tencent Cloud, Beijing), and from multiple vantage points outside of China.
In particular, we used the following command to try to establish a TCP handshake with a $NON_CN_IP:
nc -vn $NON_CN_IP 443
nc: connect to $NON_CN_IP port 443 (tcp) failed: Connection refused
We simultaneously used tcpdump to capture traffic:
tcpdump -n host $NON_CN_IP
It appears that the SYN packet triggered three forged RST+ACK packets, each with a relative sequence number 0, as well as incremental TCP window sizes of 1980, 1981, and 1982.
And the SYN+ACK packet sent by the server also triggered three RST+ACK packets, each with a relative sequence number 1, as well as incremental TCP window sizes of 3293, 3294, and 3295.
sudo tcpdump -n host $NON_CN_IP
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
01:31:07.153262 IP $CN_IP.52596 > $NON_CN_IP.443: Flags [S], seq 3193349615, win 64240, options [mss 1460,sackOK,TS val 318868316 ecr 0,nop,wscale 7], length 0
01:31:07.159991 IP $NON_CN_IP.443 > $CN_IP.52596: Flags [R.], seq 0, ack 3193349616, win 1980, length 0
01:31:07.159991 IP $NON_CN_IP.443 > $CN_IP.52596: Flags [R.], seq 0, ack 1, win 1981, length 0
01:31:07.160021 IP $NON_CN_IP.443 > $CN_IP.52596: Flags [R.], seq 0, ack 1, win 1982, length 0
01:31:07.274422 IP $NON_CN_IP.443 > $CN_IP.52596: Flags [S.], seq 2837031664, ack 3193349616, win 65160, options [mss 1424,sackOK,TS val 80839422 ecr 318868316,nop,wscale 7], length 0
01:31:07.274442 IP $CN_IP.52596 > $NON_CN_IP.443: Flags [R], seq 3193349616, win 0, length 0
01:31:07.278233 IP $NON_CN_IP.443 > $CN_IP.52596: Flags [R.], seq 1, ack 1, win 3295, length 0
01:31:07.278233 IP $NON_CN_IP.443 > $CN_IP.52596: Flags [R.], seq 1, ack 1, win 3293, length 0
01:31:07.278233 IP $NON_CN_IP.443 > $CN_IP.52596: Flags [R.], seq 1, ack 1, win 3294, length 0
Similarly, the RST+ACK packets can be triggered from outside of China. The $CN_IP is an IP address of baidu.com:
11:44:41.194853 IP (tos 0x0, ttl 64, id 48747, offset 0, flags [DF], proto TCP (6), length 60)
192.168.0.162.34500 > $CN_IP.443: Flags [S], cksum 0x418a (incorrect -> 0x252a), seq 3455861170, win 64240, options [mss 1460,sackOK,TS val 134891089 ecr 0,nop,wscale 7], length 0
11:44:41.440817 IP (tos 0x0, ttl 46, id 48747, offset 0, flags [DF], proto TCP (6), length 60)
$CN_IP.443 > 192.168.0.162.34500: Flags [S.], cksum 0xd4a2 (correct), seq 1580408478, ack 3455861171, win 8192, options [mss 1452,sackOK,nop,nop,nop,nop,nop,nop,nop,nop,nop,nop,nop,wscale 5], length 0
11:44:41.440817 IP (tos 0x0, ttl 96, id 40305, offset 0, flags [DF], proto TCP (6), length 40)
$CN_IP.443 > 192.168.0.162.34500: Flags [R.], cksum 0x515b (correct), seq 1, ack 1, win 2072, length 0
11:44:41.440817 IP (tos 0x0, ttl 97, id 39808, offset 0, flags [DF], proto TCP (6), length 40)
$CN_IP.443 > 192.168.0.162.34500: Flags [R.], cksum 0x515a (correct), seq 1, ack 1, win 2073, length 0
11:44:41.440817 IP (tos 0x0, ttl 98, id 38891, offset 0, flags [DF], proto TCP (6), length 40)
$CN_IP.443 > 192.168.0.162.34500: Flags [R.], cksum 0x5159 (correct), seq 1, ack 1, win 2074, length 0
11:44:41.440901 IP (tos 0x0, ttl 64, id 48748, offset 0, flags [DF], proto TCP (6), length 40)
192.168.0.162.34500 > $CN_IP.443: Flags [.], cksum 0x4176 (incorrect -> 0x5781), seq 1, ack 1, win 502, length 0
The client outside of China received only three TCP RST+ACK packets, not six. The relative sequence number 1 suggests that the GFW was triggered by the SYN+ACK packet responded by the Chinese server, and the SYN packet didn’t trigger the blocking. Indeed, we couldn’t trigger the blocking when the sending SYN packets to a Chinese IP address within the same /24 subnet as $CN_IP which didn’t have an open port (and thus did not send any SYN+ACK packet back to the client.)
The RST+ACK injection was confirmed to be specific to TCP port 443. We conducted a partial port scan from a machine inside China (AS45090, Tencent Cloud, Beijing) to an external IP address. We confirmed that other common ports, including 1-72, 22, 80, 444, and 8443, were not affected and did not receive a TCP RST.
nping -4 -c 0 --tcp-connect $NON_CN_IP -p 1-65535
We also ran a scan to probe all ports from 1-65535, but by the time we ran it at 01:48 CST 2025-08-20, we could no longer trigger the blocking anymore:
sudo nmap -sS -p- $NON_CN_IP -oN scan_results.txt -T4 --min-rate 10000 -Pn
The Great Firewall of China (GFW) is not a single entity but a complex system composed of various network devices that perform censorship. Previous research has established that different components, such as those responsible for HTTP Host-based and TLS SNI-based filtering, exhibit unique packet-level fingerprints when injecting TCP RST packets. The goal of this analysis was to identify which specific GFW component was responsible for the anomalous behavior observed during the incident.
To fingerprint the responsible device, after the incident had concluded, we sent probes from the vantage point in China to the IP address that triggered the unconditional RSTs. We used the same destination IP address so that our probe packets would be more likely to traverse the same network path and interact with the same set of censorship middleboxes, allowing for a consistent fingerprint analysis.
Our analysis of the probe results revealed that no captured packet fingerprint exactly matched the characteristics observed during the incident—specifically.
Since the unconditionally injection contain three RST+ACK packets with the IP Flag DF (Don't Fragment) on, they are similar, but not identical, to MB-1 identified by Niere et al. (see Figure 4); and they are also similar to, but not identical to, GFW (II) identified by Wu et al. (see Table 4).
However, a key difference exists: the known middlebox injector sends three identical TCP RST+ACK packets. In contrast, the packets observed during this incident contained fields that were clearly incremental, not identical. This discrepancy suggests that the incident was caused by either a previously uncatalogued GFW device or a known device operating in a novel or misconfigured state.
The unconditional RST+ACK packets comes in three packets, with an incrementally increasing IP TTL and an incrementally increasing TCP window size. We limited data, we were not able to identify the IP ID of it.
| IP Flag | IP ID | IP TTL | TCP Relative Sequence Number | TCP Flags | TCP Window Size |
|---|---|---|---|---|---|
| Don’t Fragment | 40305 (0x9D71) | 96 | 1 | RST+ACK | 2072 |
| Don’t Fragment | 39808 (0x9B80) | 97 | 1 | RST+ACK | 2073 |
| Don’t Fragment | 38891 (0x97E3) | 98 | 1 | RST+ACK | 2074 |
Table 1: Characteristics of Unconditionally Injected TCP RST Packets
curl --resolve youtube.com:80:$NON_CN_IP http://youtube.com
sudo tcpdump -v port 80
tcpdump: listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
04:27:09.790274 IP (tos 0x0, ttl 64, id 12103, offset 0, flags [DF], proto TCP (6), length 60)
$CN_IP.51506 > $NON_CN_IP.deploy.static.akamaitechnologies.com.http: Flags [S], cksum 0x630f (correct), seq 3187873750, win 64240, options [mss 1460,sackOK,TS val 329430953 ecr 0,nop,wscale 7], length 0
04:27:09.919296 IP (tos 0x68, ttl 251, id 0, offset 0, flags [DF], proto TCP (6), length 60)
a$NON_CN_IP.deploy.static.akamaitechnologies.com.http > $CN_IP.51506: Flags [S.], cksum 0xaf88 (correct), seq 155578285, ack 3187873751, win 65160, options [mss 1424,sackOK,TS val 2237542832 ecr 329430953,nop,wscale 7], length 0
04:27:09.919331 IP (tos 0x0, ttl 64, id 12104, offset 0, flags [DF], proto TCP (6), length 52)
$CN_IP.51506 > a$NON_CN_IP.deploy.static.akamaitechnologies.com.http: Flags [.], cksum 0xda42 (correct), ack 1, win 502, options [nop,nop,TS val 329431082 ecr 2237542832], length 0
04:27:09.919414 IP (tos 0x0, ttl 64, id 12105, offset 0, flags [DF], proto TCP (6), length 127)
$CN_IP.51506 > a$NON_CN_IP.deploy.static.akamaitechnologies.com.http: Flags [P.], cksum 0x0926 (correct), seq 1:76, ack 1, win 502, options [nop,nop,TS val 329431082 ecr 2237542832], length 75: HTTP, length: 75
GET / HTTP/1.1
Host: youtube.com
User-Agent: curl/7.81.0
Accept: */*
04:27:09.923159 IP (tos 0x68, ttl 251, id 31725, offset 0, flags [none], proto TCP (6), length 40)
a$NON_CN_IP.deploy.static.akamaitechnologies.com.http > $CN_IP.51506: Flags [R], cksum 0xc7c6 (correct), seq 155578286, win 42571, length 0
04:27:09.924494 IP (tos 0x68, ttl 251, id 45284, offset 0, flags [DF], proto TCP (6), length 40)
a$NON_CN_IP.deploy.static.akamaitechnologies.com.http > $CN_IP.51506: Flags [R.], cksum 0x9162 (correct), seq 1, ack 76, win 1658, length 0
04:27:09.924494 IP (tos 0x68, ttl 251, id 45284, offset 0, flags [DF], proto TCP (6), length 40)
a$NON_CN_IP.deploy.static.akamaitechnologies.com.http > $CN_IP.51506: Flags [R.], cksum 0x9162 (correct), seq 1, ack 76, win 1658, length 0
04:27:09.924510 IP (tos 0x68, ttl 251, id 45284, offset 0, flags [DF], proto TCP (6), length 40)
a$NON_CN_IP.deploy.static.akamaitechnologies.com.http > $CN_IP.51506: Flags [R.], cksum 0x9162 (correct), seq 1, ack 76, win 1658, length 0
04:27:10.048400 IP (tos 0x68, ttl 251, id 34753, offset 0, flags [DF], proto TCP (6), length 52)
a$NON_CN_IP.deploy.static.akamaitechnologies.com.http > $CN_IP.51506: Flags [.], cksum 0xd96f (correct), ack 76, win 509, options [nop,nop,TS val 2237542961 ecr 329431082], length 0
04:27:10.048426 IP (tos 0x68, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40)
$CN_IP.51506 > a$NON_CN_IP.deploy.static.akamaitechnologies.com.http: Flags [R], cksum 0x90e0 (correct), seq 3187873826, win 0, length 0
curl --resolve youtube.com:443:$NON_CN_IP https://youtube.com
sudo tcpdump -v port 443
tcpdump: listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
04:25:15.234561 IP (tos 0x0, ttl 64, id 59308, offset 0, flags [DF], proto TCP (6), length 60) [0/966]
$CN_IP.35816 > a$NON_CN_IP.deploy.static.akamaitechnologies.com.https: Flags [S], cksum 0x579d (correct), seq 2971216783, win 64240, options [mss 1460,sackOK,TS val 329316397 ecr 0,nop,wscale 7], length 0
04:25:15.365226 IP (tos 0x68, ttl 251, id 0, offset 0, flags [DF], proto TCP (6), length 60)
a$NON_CN_IP.deploy.static.akamaitechnologies.com.https > $CN_IP.35816: Flags [S.], cksum 0x4c87 (correct), seq 2839767305, ack 2971216784, win 65160, options [mss 1424,sackOK,TS val 91287507 ecr 329316397,nop,wscale 7], length 0
04:25:15.365257 IP (tos 0x0, ttl 64, id 59309, offset 0, flags [DF], proto TCP (6), length 52)
$CN_IP.35816 > a$NON_CN_IP.deploy.static.akamaitechnologies.com.https: Flags [.], cksum 0x773f (correct), ack 1, win 502, options [nop,nop,TS val 329316528 ecr 91287507], length 0
04:25:15.428628 IP (tos 0x0, ttl 64, id 59310, offset 0, flags [DF], proto TCP (6), length 569)
$CN_IP.35816 > a$NON_CN_IP.deploy.static.akamaitechnologies.com.https: Flags [P.], cksum 0x9a41 (correct), seq 1:518, ack 1, win 502, options [nop,nop,TS val 329316591
ecr 91287507], length 517
04:25:15.433547 IP (tos 0x68, ttl 251, id 47980, offset 0, flags [none], proto TCP (6), length 40)
a$NON_CN_IP.deploy.static.akamaitechnologies.com.https > $CN_IP.35816: Flags [R], cksum 0x7ed4 (correct), seq 2839767306, win 4547, length 0
04:25:15.434682 IP (tos 0x68, ttl 251, id 11362, offset 0, flags [DF], proto TCP (6), length 40)
a$NON_CN_IP.deploy.static.akamaitechnologies.com.https > $CN_IP.35816: Flags [R.], cksum 0xa0ec (correct), seq 1, ack 518, win 4332, length 0
04:25:15.434682 IP (tos 0x68, ttl 251, id 11362, offset 0, flags [DF], proto TCP (6), length 40)
a$NON_CN_IP.deploy.static.akamaitechnologies.com.https > $CN_IP.35816: Flags [R.], cksum 0xa0ec (correct), seq 1, ack 518, win 4332, length 0
04:25:15.434709 IP (tos 0x68, ttl 251, id 11362, offset 0, flags [DF], proto TCP (6), length 40)
a$NON_CN_IP.deploy.static.akamaitechnologies.com.https > $CN_IP.35816: Flags [R.], cksum 0xa0ec (correct), seq 1, ack 518, win 4332, length 0
04:25:15.435139 IP (tos 0x68, ttl 251, id 42431, offset 0, flags [DF], proto TCP (6), length 40)
a$NON_CN_IP.deploy.static.akamaitechnologies.com.https > $CN_IP.35816: Flags [R.], cksum 0xaac5 (correct), seq 1, ack 518, win 1811, length 0
04:25:15.559257 IP (tos 0x68, ttl 251, id 29047, offset 0, flags [DF], proto TCP (6), length 52)
a$NON_CN_IP.deploy.static.akamaitechnologies.com.https > $CN_IP.35816: Flags [.], cksum 0x7435 (correct), ack 518, win 506, options [nop,nop,TS val 91287701 ecr 3293165
91], length 0
04:25:15.559269 IP (tos 0x68, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40)
$CN_IP.35816 > a$NON_CN_IP.deploy.static.akamaitechnologies.com.https: Flags [R], cksum 0xc436 (correct), seq 2971217301, win 0, length 0
The unconditional RST appeared to stop prior to 2025-08-20 01:48 UTC+8, making the entire incident last for around 74 minutes (between 00:34 and 01:48 UTC+8).
sudo nmap -sS -p- $NON_CN_IP -oN scan_results.txt -T4 --min-rate 10000 -Pn
Starting Nmap 7.80 ( https://nmap.org ) at 2025-08-20 01:48 CST
Nmap scan report for $NON_CN_IP.deploy.static.akamaitechnologies.com ($NON_CN_IP)
Host is up.
All 65535 scanned ports on $NON_CN_IP.deploy.static.akamaitechnologies.com ($NON_CN_IP) are filtered
We are grateful to the many users and readers who promptly reported censorship incidents to us. In particular, this censorship event was of a very short duration, and without their timely notifications, it would have been impossible for us to conduct measurements in such a short period. We also thank Eric Wustrow for providing some of the measurement data sent from abroad to within the country.
This report was first published on GFW Report. We have also synchronously updated this report on net4people.
We encourage you to share questions, comments, or evidence related to the findings and hypotheses in this report, either publicly or privately. Our private contact information can be found in the footer of the GFW Report website.