China’s Evolving Internet Censorship: Seven WeaveBit Checks for Accurate Domain Blocking Detection
When people discuss Internet censorship in China, they often imagine a single “super firewall” deployed at the country’s international gateways and applying the same rules to all traffic. That description is no longer complete.
As censorship technologies have continued to evolve, China’s Internet censorship has developed into a multi-layered and distributed system involving different organizations, network operators, and technology vendors. In addition to the national-level firewall covering major cross-border network routes, some provinces and network operators also use independently operated regional filtering systems.
This helps explain a common situation: the same domain may be accessible in one province but repeatedly time out in another. Even within the same city, users of China Mobile, China Unicom, and China Telecom may receive different results.
However, not every cross-border connectivity problem means that a domain has been blocked. China’s international Internet egress capacity is comparatively constrained, and the additional impact of traffic inspection and classification may further affect connection quality. Normal cross-border requests may therefore experience higher latency, packet loss, or connection timeouts because of congestion at international gateways or along cross-border routes.
For this reason, determining whether a domain has been blocked requires more than one node, one timeout, or one type of test. DNS, IP connectivity, ports, HTTP Host behavior, and TLS SNI behavior should be examined separately, with results compared across multiple regions and network operators.
1. The National-level GFW: China’s Primary Filtering Layer
China’s national Internet filtering system is commonly known as the Great Firewall of China (GFW). In this article, the broader and relatively coordinated part of this system is referred to as the National-level GFW.
The National-level GFW is primarily deployed around international gateways and backbone network boundaries, where it applies relatively consistent and coordinated filtering rules to cross-border traffic. Its main characteristics include broad coverage, relatively stable rules, long blocking durations, and more sophisticated detection methods. Once a domain has been persistently flagged, it is generally difficult for the restriction to be lifted within a short period. The same target may also be affected by several filtering mechanisms at once.
DNS pollution is one of the most common and wide-reaching domain-blocking methods used by the National-level GFW. When a user queries a polluted domain, filtering equipment may inject an incorrect IP address before the legitimate DNS response arrives. The browser or application is then unable to connect to the correct server. Because this interference may occur along cross-border DNS paths, it can appear as a widespread access failure across multiple regions and network operators in China.
In addition to DNS pollution, the National-level GFW may use IP address blocking, HTTP Host filtering, plaintext SNI filtering in the TLS ClientHello, TCP RST injection, active probing of proxy services such as Tor and Shadowsocks, and traffic analysis based on packet length, content characteristics, and connection behavior. ESNI and ECH connections may also be identified, restricted, or disrupted through DNS information, destination IP addresses, visible outer handshake characteristics, or direct interference with the relevant connections.
A traditional TLS connection sends a plaintext Server Name Indication (SNI) in the ClientHello to tell the server which domain the client wants to reach. Because the domain is visible, network equipment can identify and filter it directly.
Encrypted SNI (ESNI) was an early experimental attempt to protect SNI and has gradually been superseded by Encrypted Client Hello (ECH). ECH encrypts the real inner ClientHello and SNI, so filtering equipment cannot read the actual domain in the same way it can read traditional plaintext SNI. However, connections may still be disrupted using other network information or by blocking ECH-related connections.
2. Regional Firewalls: A “Firewall Behind the Firewall”
In addition to the National-level GFW, provincial and operator-level filtering systems can operate independently as an additional layer. This article refers to these systems as Regional Firewalls.
A Regional Firewall can be understood as a “firewall behind the firewall.” It mainly affects specific provinces, cities, network operators, or Internet egress routes. Its rules do not necessarily match those of the National-level GFW, and it may maintain separate domain lists and filtering policies.
Regional Firewalls have been observed using HTTP Host filtering, SNI filtering in the TLS ClientHello, TCP Reset, and silent connection dropping. They may also interfere with some encrypted ClientHello connections or apply additional restrictions to specific international routes.
Compared with the National-level GFW, a Regional Firewall generally has a smaller geographic scope, affecting only certain provinces, cities, or network operators. However, its rules may change more quickly, its implementation may be less precise, and it may block a larger number of domains or cause more collateral damage. Some regional restrictions may also be removed after a period of time.
Different forms of regional network filtering have now been observed and confirmed in multiple provinces. Regions with weaker network infrastructure or limited international egress capacity may also impose stricter controls on cross-border connections.
As a result, the same domain may work in one province but fail in another. Different network operators in the same city may also produce different results. HTTP may fail while HTTPS remains available, a TCP connection may succeed but be reset after an HTTP Host header is sent, or a connection may be interrupted during the TLS handshake after a ClientHello containing the target SNI is transmitted.
Cross-border congestion can produce similar symptoms. High latency, packet loss, and connection timeouts do not by themselves prove that filtering has occurred. More specific signals, such as DNS pollution, HTTP Host Reset, or TLS SNI Reset, should also be examined.
3. What Detection Capabilities Does WeaveBit Provide?
WeaveBit currently provides five basic checks and two GFW scenario checks. The basic checks examine individual stages of a network connection, while the scenario checks combine relevant capabilities to help users determine whether a domain is affected by common blocking mechanisms.
1. DNS_RESOLVE
DNS_RESOLVE checks which IP addresses a domain resolves to from a selected test node and reports successful resolution, timeouts, NXDOMAIN responses, and other DNS errors.
2. ICMP_PING_CHECK
ICMP_PING_CHECK checks whether a target IP address responds to ICMP Echo Requests and reports latency and packet loss.
3. TCP_CONNECT_CHECK
TCP_CONNECT_CHECK checks whether a TCP connection can be established to a specified IP address and port, distinguishing between successful connections, timeouts, refusals, resets, and network-unreachable errors.
4. HTTP_HOST_RESET_CHECK
HTTP_HOST_RESET_CHECK checks whether a plaintext HTTP connection is reset after a request containing the specified Host header is sent.
5. TLS_SNI_HANDSHAKE_CHECK
TLS_SNI_HANDSHAKE_CHECK checks whether a conventional TLS handshake succeeds, times out, closes, or is reset after a ClientHello containing the specified SNI is sent.
4. Two GFW Scenario Checks
1. DNS Pollution Check
The DNS Pollution Check determines whether a domain’s DNS resolution results show known characteristics of DNS pollution. It is the most fundamental test and should generally be the first step in checking a domain for GFW-related interference.
DNS pollution is a commonly used National-level GFW blocking method with a potentially wide scope. When a domain is affected by national-level DNS pollution, users relying on affected ordinary DNS paths are generally unable to obtain the correct IP address. The result may appear as widespread inaccessibility across multiple regions and network operators in China.
The DNS Pollution Check can be used before launching a new domain, when a domain suddenly becomes inaccessible across a wide area, when users in multiple provinces report problems, for continuous DNS monitoring, or for automated batch testing through the API.
If DNS pollution is detected for the first time, the domain should be tested again. Results should also be compared with DNS resolution from other regions and with the GFW Full Domain Check to determine the likely scope of the problem.
2. GFW Full Domain Check
The GFW Full Domain Check combines tests for DNS pollution, HTTP Host Reset, and TLS SNI Reset. It runs checks through nodes across multiple regions and network operators, helping users determine whether an issue is closer to nationwide blocking or a provincial, city-level, or operator-specific difference.
In addition to showing whether a domain presents common blocking characteristics, the GFW Full Domain Check helps identify the protocol stage at which the problem occurs and the regions and network operators affected. It is suitable for comprehensive testing, continuous monitoring, historical trend analysis, and domain availability troubleshooting.
5. Which Detection Method Should You Choose?
| Requirement | Recommended First Check | Follow-up Check |
|---|---|---|
| Quickly determine whether a domain shows common blocking characteristics | DNS Pollution Check | GFW Full Domain Check |
| Comprehensively determine whether a domain is blocked when the mainland China market matters | GFW Full Domain Check | Review DNS, HTTP Host, and TLS SNI results across multiple regions and network operators |
| Suspect widespread nationwide inaccessibility | DNS Pollution Check | Multi-node GFW Full Domain Check |
| Only certain provinces or network operators cannot access the domain | Multi-node GFW Full Domain Check | Compare HTTP Host Reset and TLS SNI Reset results |
| HTTPS works but HTTP fails | HTTP_HOST_RESET_CHECK |
Retest through multiple regions and network operators |
| HTTP works but HTTPS fails | TLS_SNI_HANDSHAKE_CHECK |
Retest through multiple regions and network operators |
| The domain resolves, but the website does not open | TCP_CONNECT_CHECK |
Run an HTTP Host or TLS SNI check |
| Suspect that a specific IP address or port is unreachable | TCP_CONNECT_CHECK |
ICMP_PING_CHECK |
| Suspect international egress or cross-border route congestion | ICMP_PING_CHECK and TCP_CONNECT_CHECK |
Retest across multiple regions, network operators, and time periods |
| Need continuous monitoring | DNS Pollution Check or GFW Full Domain Check | Configure alerts based on consecutive abnormal results |
| Need batch or automated testing | WeaveBit API | Store node, status, test time, and historical trend data |
For a typical domain check, users can follow this sequence:
- Check for DNS pollution.
- Run a multi-node GFW Full Domain Check.
- Review whether HTTP Host Reset or TLS SNI Reset was detected.
- Compare the provinces, cities, and network operators of abnormal nodes.
- Repeat the test to determine whether the abnormal result persists.
6. How to Interpret Multi-node Results
If most valid nodes across different regions and network operators detect DNS pollution, HTTP Host Reset, or TLS SNI Reset, the domain can be considered widely flagged by the corresponding filtering mechanism. If the abnormal results span multiple provinces and network operators, the evidence is more consistent with national-level or otherwise widespread blocking.
If only a small number of nodes detect HTTP Host Reset or TLS SNI Reset, the issue may be related to a Regional Firewall, city-level or operator-level filtering, local international egress restrictions, a specific network route, or a temporary network failure. In this situation, the result should not be treated as proof of nationwide blocking. The abnormal nodes should be tested again and compared with other operators in the same region or with nodes in neighboring regions.
If the only observed symptoms are increased latency, packet loss, or connection timeouts, international egress and cross-border route congestion should be considered. Congestion is more likely to produce unstable results that vary by time or affect several unrelated overseas destinations simultaneously. Domain filtering is more likely to produce repeatable, domain-specific abnormalities during the DNS, HTTP Host, or TLS SNI stage.
WeaveBit results should be interpreted using three distinct states:
- Normal: The check completed and no abnormality defined by that detection method was found.
- Confirmed abnormal: The check detected a specific signal such as DNS pollution, HTTP Host Reset, or TLS SNI Reset.
- Inconclusive: A conclusion could not be reached because of a timeout, offline node, failed connection, failed prerequisite step, or insufficient data.
A timeout, offline node, failed connection, or untested component must not automatically be classified as blocking. A reliable conclusion should consider the proportion of confirmed abnormal results among valid nodes, the provinces and network operators affected, the protocol stage where the problem occurs, repeated test results, the duration of the issue, and historical trends.
Conclusion
China’s evolving Internet censorship is no longer a simple, single-layer blocking system. The National-level GFW applies broader and more persistent filtering, while provincial and operator-level systems may introduce more regionalized, rapidly changing, and less precise rules. At the same time, constrained international egress capacity and cross-border route congestion can affect legitimate requests, causing latency, packet loss, and timeouts.
For domain operators, the DNS Pollution Check should be treated as an essential first step. HTTP Host Reset and TLS SNI Reset are also important signals for identifying domain-level blocking, especially provincial or regional filtering.
WeaveBit’s five basic checks help identify the specific network stage where a problem occurs, while the DNS Pollution Check and GFW Full Domain Check provide a more direct and comprehensive assessment of domain blocking. A reliable conclusion should never be based on one timeout or one node. It should come from multiple regions, multiple network operators, several detection methods, and repeated testing over time.
References
- How Great Is the Great Firewall? Measuring China’s DNS Censorship
- GFWeb: Measuring the Great Firewall’s Web Censorship at Scale
- A Wall Behind a Wall: Emerging Regional Censorship in China
- How the Great Firewall of China Detects and Blocks Fully Encrypted Traffic
- RFC 6066: Transport Layer Security Extensions — Server Name Indication
- RFC 9849: TLS Encrypted Client Hello