A domain can have no reported DNS poisoning and still fail to connect over HTTP or HTTPS in mainland China. Users may see a reset, a failed TLS handshake, or a problem limited to certain networks. WeaveBit's GFW Full domain check brings DNS poisoning, HTTP Host and TLS SNI checks together so you can inspect the affected dimension and compare results across selected nodes.
“Full” means these three dimensions and a combined summary. It does not mean all seven API methods or a complete browser test. This guide explains how to prepare targets, select nodes, run batch checks and follow up on an abnormal result. For an initial check of one domain, start with the free DNS poisoning check.
Define the question before choosing nodes
Write down the business question first: for example, “Does our login domain show a connectivity problem on networks used by our mainland China customers?” A website may depend on separate domains for its homepage, authentication, API and static assets. Checking the homepage domain alone does not cover those dependencies.
Build a list of domains you are authorized to check, with their purpose and owner. Use a plain hostname such as www.example.com or api.example.com, not https://www.example.com/login. Remove schemes, paths, ports and duplicates. Internationalized names may be returned as lowercase ASCII Punycode, so keep the association between your original input and the normalized target.
If the problem concerns a login sequence, an API parameter or page scripts, keep using application logs and browser diagnostics. A GFW domain check does not sign in, execute JavaScript or inspect page content.
Read the dimensions, not just the summary
| Dimension | What to inspect | What it does not establish |
|---|---|---|
| DNS poisoning | The assessment and result status returned by the service | No reported poisoning does not establish HTTP, TLS or application availability |
| HTTP Host | The request status using the target Host | A valid response does not guarantee HTTP 200 or correct page content |
| TLS SNI | The handshake status using the target SNI | A successful handshake does not establish login or API success, or a complete certificate audit |
| Combined summary | A starting point for finding targets that need attention | It does not replace the dimensions, node selection or observation time |
Supply a domain and read the public result; use the result documentation for the meaning of each status. Do not turn a timeout, an unknown outcome or an inconclusive result into either “normal” or “confirmed blocked.”
Choose Console monitoring or an API batch
When you want the platform to schedule recurring checks and send notifications, use the Console monitoring entry point and create a GFW Full task. Console currently offers DNS Pollution and GFW Full monitoring tasks, with up to 200 domains per task. Group domains by operational purpose or importance, rather than putting every domain into one undifferentiated list.
For a one-off batch or integration into your own system, use API v2 with gfw_full_domain_check. Each estimate or creation request accepts 1–1000 targets. An API batch is not a scheduled Console task: creating a batch does not automatically enable recurring monitoring. See the DNS and GFW batch API guide for the implementation workflow.
Select networks relevant to your customers
Start with the regions and carriers your customers use, then review current node coverage. Choose available nodes relevant to those users. If the affected network is not yet known, begin with a representative selection and refine it using actual reports. One node's outcome is not a result for all of mainland China.
For useful comparisons, keep the target, ports and node selection consistent and the observation times reasonably close. After an abnormal result, repeat the same configuration before adding other relevant networks for comparison. More nodes broaden the observation scope and may change the cost; they do not guarantee coverage of every end-user environment.
In an API integration, get current codes from /task/get_nodes and use node_id, not the display name. Parent selections expand to currently available child nodes, and availability can change. Review the selection and estimate again before creation. A standalone DNS poisoning API request omits nodes.
The GFW Full API defaults to HTTP port 80 and TLS port 443. For a service on other ports, set http_port and tls_port in the target object, rather than appending a port to the domain. Repeat the same ports for a meaningful comparison.
Create a Console task you can investigate later
- Sign in, review the account balance and choose a GFW Full monitoring task.
- Enter the deduplicated domain list, checking for URLs, ports or other misplaced characters.
- Select relevant nodes and a frequency available in the current task editor, balancing detection speed with budget.
- If you need alerts, confirm contacts and notification settings before saving.
- After the task produces results, inspect the summary, then each affected target, node and dimension. Also confirm that scheduled execution continues.
Do not repeatedly change nodes simply to obtain a green result. Keep the original observation time and configuration so you can distinguish an outcome change from a change in where you checked. The Console monitoring guide covers recurring tasks and alert handling.
Turn the result into a next step
Find the targets with abnormal or inconclusive outcomes, then identify the affected dimensions and nodes. If DNS has no reported poisoning but TLS is abnormal, investigate TLS connectivity rather than treating the DNS result as proof that the whole website works. Different HTTP and TLS outcomes also should not be reduced to a blanket statement that the entire website is blocked.
Compare the observation time, target, node and dimension status with the user report. A problem on one network calls for checking the affected scope. Repeated similar results across multiple nodes warrant further investigation alongside server, CDN, certificate or access-control records. A timeout alone does not identify the responsible party, and server policies can also affect connections.
A normal result describes this observation, not permanent availability for every user in China. If users still cannot connect, check the actual dependency domains, their end-user network and the application workflow.
Keep the configuration and preserve follow-up evidence
Repeat an abnormal check with the same target, nodes and ports, recording the new time. If you broaden the scope, document the additional nodes separately. Preserve inconclusive outcomes as unresolved; do not force them into a normal or abnormal category for reporting convenience.
After results return to normal, review the latest observations and the affected users' application experience. Mark your incident record as recovered or awaiting confirmation, keeping the original and follow-up evidence. API results must be saved before the returned expires_at; temporary batches are not a long-term evidence store.
Review current pricing before starting and use the public API contract for automation. A check with a defined target, network scope, time and next action is more useful than an isolated “blocked or not” label.