How to Detect a Blocked Domain? Common Symptoms, Block Types, and a 4-Step Troubleshooting Guide

During website operations or overseas business expansion, you may encounter a situation where domestic users suddenly report that the website is inaccessible, yet the server backend shows normal system load and network traffic. This phenomenon—where overseas access works fine but domestic access is largely paralyzed—likely means the domain has triggered the blocking rules of the national firewall (GFW), commonly known as a "blocked domain."

A blocked domain not only causes a cliff-like drop in traffic but also deals a devastating blow to the site's indexing and ranking in search engines. This article will break down the underlying technical mechanisms of domain blocking, common symptoms, and provide a command-line troubleshooting process that requires no complex tools, along with subsequent remediation plans.

1. What Does "Domain Blocked" Mean? 3 Common Blocking Mechanisms

Many site operators, upon discovering access issues, often initially mistake it for server downtime or a firewall misconfiguration. In reality, GFW's domain blocking occurs at different network layers, primarily through the following three mechanisms:

To avoid going down the wrong path, first look at the table below to distinguish between a "blocked domain," server downtime, and DDoS attacks:

2. Common Symptoms of a Blocked Domain

Before diving into command-line diagnostics, you can identify potential issues through the following typical abnormal signs:

• Overseas access is completely normal, but multiple domestic locations fail to load

  Accessing the website via an overseas VPN or a server in Hong Kong, Singapore, the US, etc., loads instantly with no issues. However, when using domestic networks like China Telecom, China Unicom, or China Mobile, the page times out or cannot connect.

• Occasionally opens only after changing local DNS

  If the domain fails to resolve using the ISP's default DNS (e.g., local telecom DNS), but manually changing the local DNS to 8.8.8.8 or 1.1.1.1 restores access in some regions, this is typically an early sign of DNS poisoning.

• HTTP works, but HTTPS cannot establish a connection

  Accessing http://yourdomain.com over unencrypted HTTP loads normally or shows response headers, but entering https://yourdomain.com in the browser results in an ERR_CONNECTION_RESET or TLS Handshake Timeout error.

3. 4-Step Complete Troubleshooting Process

When you suspect a blocked domain, it's recommended to troubleshoot in order from the DNS layer to the network transport layer. The first three steps can be run directly in a Linux terminal or Windows Command Prompt (CMD), and the fourth step uses third-party node tools for comprehensive verification.

Step 1: Verify DNS Resolution Status

DNS poisoning is the most common blocking method. We need to compare the resolution results of the same domain using domestic public DNS and overseas public DNS.

Open a terminal and run the following commands:

# Resolve using domestic Alibaba DNS 
nslookup yourdomain.com 223.5.5.5 
# Resolve using overseas Google DNS 
nslookup yourdomain.com 8.8.8.8

Diagnosis Analysis:

If 8.8.8.8 returns your real server IP, while 223.5.5.5 returns a completely unrelated overseas random IP (such as certain fixed reserved addresses or nodes not under your name), or the returned IP changes each time you run the command, your domain has been subjected to DNS poisoning.

Step 2: Test TLS Handshake and SNI Blocking

Sometimes DNS resolution is not poisoned, but you still cannot open the webpage over HTTPS. This requires checking for SNI (Server Name Indication) blocking.

Use the curl command to bypass DNS resolution by directly specifying the server IP and carrying the target domain in the TLS request:

curl -Iv https://yourdomain.com --resolve yourdomain.com:443:YOUR_SERVER_IP

Diagnosis Analysis:

In the output log, observe the TLS handshake process:

• If the log shows that immediately after sending Client Hello, you receive "Recv failure: Connection reset by peer" or "OpenSSL SSL_connect: Connection reset by peer," it indicates that the ISP routing node recognized the domain string in the packet and triggered SNI blocking.

Step 3: Trace Routing Nodes

To determine whether the domain itself is blocked or the server's IP is blacklisted, use a route tracing tool to see where packets are dropped.

Use mtr on Linux or macOS, and tracert on Windows:

# Linux / macOS mtr -rw yourdomain.com # Windows tracert yourdomain.com

Diagnosis Analysis:

Review the route trace list. If packets suddenly show 100% loss after passing through the local ISP network and reaching the egress backbone node (e.g., an IP containing 202.97.*.* or 219.158.*.* for Telecom/Unicom egress), and all subsequent nodes time out, it indicates that the IP or port has been blocked at the egress routing level.

Step 4: Use chahu for Nationwide Multi-Node Testing

Single-point local testing can be affected by local network conditions or specific ISP failures. After completing the local diagnostics, use a multi-node testing tool like chahu to quickly identify the scope of impact across the entire network.

Steps:

1. Open chahu.com and enter your target domain in the speed test box.

2. Run Ping Test and Website Speed Test/HTTP Response Test.

3. Observe the response status and resolved IPs of nodes across provinces (Telecom, Unicom, Mobile):

   • If overseas and Hong Kong/Macau/Taiwan nodes all show green (normal response, correct IP resolution), while domestic provincial nodes show widespread red (connection timeout, resolution to wrong IP, or connection reset), you can 100% confirm that the domain has been targeted by the national firewall.

4. 4 Response and Recovery Strategies After Domain Blocking

Once you've confirmed DNS poisoning or SNI blocking, many people's first reaction is to change the server IP, which is a waste of effort because the firewall blocks the domain, not the IP. To minimize losses, you can adjust based on your current business priorities, considering the following directions:

1. Change Domain + 301 Traffic Redirect

   If most of your traffic comes from overseas or relies on Google search, the fastest solution is to register a new domain immediately, host the service there, and set up a 301 redirect on the old domain. However, when domestic users access the old domain, the 301 redirect request is reset before it reaches their browser. So this only preserves overseas users and Google crawler traffic; domestic users still cannot access.

2. Integrate with a High-Protection CDN or Proxy Nodes with Concealment Capabilities

   If you don't want to change the domain, you can integrate with a high-protection CDN like Yewsafe that supports SNI concealment and intelligent routing, where the CDN's edge nodes handle domestic requests and mask sensitive response headers and characteristic packets. Combined with multi-node tools like chahu to continuously monitor the domestic reachability of CDN nodes, this can effectively mitigate business interruptions caused by specific node blocks.

3. Deploy Domestic Compliance Filing

   If your core customer base is still in China, trying various workarounds will likely be futile. The most reliable solution is to migrate the server back to China (or use a compliant dedicated line) and properly complete ICP filing and public security filing. Once you're on the compliance whitelist, GFW's false positives and dynamic blocking won't affect you.

4. Enable ECH Technology

   For those familiar with TLS protocols, you can try enabling the ECH extension of TLS 1.3 (the upgraded version of ESNI) if the server and client environments allow. This encrypts the domain name transmitted in plaintext during the handshake, so intermediate devices on the path cannot see which domain you're accessing, thus avoiding SNI blocking based on domain keywords. However, client support is not yet fully widespread, so this can be used as a supplementary measure.

The core of diagnosing a blocked domain lies in layered troubleshooting: first, use command-line tools locally to confirm DNS and TLS handshake status, then use a multi-node speed test platform like chahu to see the full impact. Once you identify whether it's DNS poisoning, SNI blocking, or IP blocking, you can choose to change the domain, integrate a CDN, or pursue compliance filing to recover traffic losses as quickly as possible.

Related Q&A

Q: After a domain is blocked, can changing DNS servers solve the problem?

No. DNS poisoning is one of GFW's blocking methods, but changing DNS servers (e.g., from the ISP's default DNS to 8.8.8.8) can only be used as a temporary test to verify if DNS poisoning exists. If the domain is already blocked, GFW intercepts the request at the backbone level regardless of which DNS provider you use. Changing DNS servers is a temporary fix; what you really need to do is review for prohibited content, consider changing the domain, or pursue compliance filing.

Q: If HTTP works but HTTPS doesn't, is the domain definitely blocked?

This is indeed a typical symptom of SNI blocking. But it's not absolute; you also need to check if the SSL certificate has expired or if there are issues with the server's TLS configuration. If the certificate is valid and the configuration is correct, but HTTP works and HTTPS reports connection reset, it's basically SNI-level blocking. You can use the curl command with the --resolve parameter to directly specify the IP and initiate a TLS request to verify.

Q: Are a blocked domain and DNS poisoning the same thing?

No, many people confuse these two concepts. DNS poisoning is one of GFW's blocking methods: it manipulates the domain resolution process, replacing the correct IP with an incorrect one, so users can't find the real server. "Blocked domain" is a broader concept that includes DNS poisoning, SNI blocking, IP blocking, and other technical methods. DNS poisoning is just one form of being blocked.

Q: If a website is blocked by WeChat, does that count as a blocked domain?

No. Platforms like WeChat and QQ have independent URL security detection mechanisms. If the domain opens normally in a browser but shows "This webpage has been stopped from accessing" when shared in WeChat, it's a platform-level content control block. It doesn't involve DNS resolution or GFW network-layer blocking; it's purely a unilateral "blacklist" by Tencent products. The handling method is also completely different; WeChat blocking requires submitting materials through the corresponding appeal channel.

Q: After a domain is blocked, will email services be affected?

Yes, but it depends on the situation. If the domain suffers from DNS poisoning, the mail server may have issues resolving the recipient's MX records, causing emails to fail to send. Additionally, GFW itself filters emails containing sensitive information, which may cause delivery failures or blank emails. However, another common reason for email rejection is that the domain or IP is blacklisted by international anti-spam organizations like Spamhaus, which is different from GFW blocking and needs to be treated separately.

Q: After a domain is blocked, how long does it take to recover?

It depends on the type of block and the response. For technical issues like DNS poisoning, changing resolution or switching CDN nodes usually restores access within 1 to 2 hours. For compliance issues, you need to go through filing or appeal processes, typically taking 5 to 20 business days. For severe violations leading to permanent bans, there's basically no hope of recovery. The appeal route is the longest, sometimes taking one to two months or even longer. Many site owners ultimately choose to change the domain rather than wait for unblocking.