“It works on China Telecom but not China Mobile” is a useful clue, not a diagnosis. The city, access connection, time, hostname and affected feature may all differ. The aim is to identify where and at which stage access fails, then give the right provider actionable evidence.
This guide focuses on regional and carrier comparisons. For a broader incident, see website access troubleshooting for China. If you already need checks across several networks, you can go straight to GFW Full.
1. Turn a complaint into a reproducible problem
Establish what “not working” means: a name-resolution error, a connection timeout, a secure-connection error, or a working homepage with broken login, images or API requests. Keep the full failed URL in the incident record; use its bare hostname for domain checks. example.com and www.example.com are separate targets.
Ask for the city, carrier, mobile-data or fixed-broadband connection, time and error message. Where practical, reproduce on the same device using the original network and one alternative. Changing device, browser and network together obscures the comparison. Redact personal information and tokens; passwords are not needed.
2. Keep a comparable baseline
Choose one failed hostname, fix the protocols and ports, and compare networks within a short time window. A morning China Mobile result and an evening China Telecom result may reflect different service conditions. An HTTP check and a browser visit over HTTPS are not equivalent tests.
Record the target, ports, time zone, location, carrier and source of each observation. Preserve the failure before changing DNS settings, clearing caches or switching CDN configurations. Change one variable at a time. For an intermittent problem, successful and failed timestamps are more useful than “it works now.”
3. Move from a DNS first check to the networks that matter
For one domain, the free DNS poisoning check is a convenient starting point. A normal result does not exclude HTTP, TLS or application problems. Preserve an abnormal result; for an indeterminate result, verify the input and result time before rechecking. See the DNS poisoning introduction for next steps.
For a regional or carrier incident, use GFW Full with relevant available nodes. It combines DNS poisoning, HTTP Host and TLS SNI checks, not a complete browser test. You do not have to run a separate DNS check first for every domain. Follow the GFW Full guide.
The public node page describes coverage; Console or API availability at task creation is authoritative for selection. API clients should use current node_id values, not guess from old reports. See the public API documentation.
4. Build a small, useful comparison matrix
Start with the affected city and carrier, plus a same-city comparison where available. Add another region important to your customers. Mark unavailable coverage as missing; a different city is not a substitute for the requested one.
The following is a hypothetical example, not a real report or a coverage promise. Every row uses www.example.com, HTTP port 80 and TLS port 443, on the same day in UTC+8. Only HTTP/TLS observations are shown; keep DNS and overall results separately.
| Location and network | Time | HTTP observation | TLS observation |
|---|---|---|---|
| City A · China Mobile | 10:00 | Valid response | Handshake timeout; indeterminate |
| City A · China Telecom | 10:02 | Valid response | Handshake succeeded |
| City B · China Mobile | 10:04 | Valid response | Handshake succeeded |
This warrants investigating TLS access on the observed China Mobile connection in City A. It does not establish a nationwide China Mobile block. Recheck the original target and ports rather than replacing the matrix and losing the baseline.
5. Read the failure stage, not just the headline
Read each node’s dimensions and raw statuses before its overall result. A later step that was not tested after a prerequisite failed is not a confirmed failure of that step. Keep normal, abnormal, indeterminate and missing observations separate.
A valid HTTP response does not guarantee a 200 response or correct content. A successful TLS handshake is not a full certificate or browser audit. A reset requires context; a timeout alone does not identify who caused it. Use the result interpretation documentation rather than turning every failure into “blocked.”
6. When nodes and users disagree, add device evidence
A node observes its own network at a particular time. It cannot guarantee every household, mobile-data connection or corporate Internet connection, even in the same city and carrier. A normal node result is not a reason to close an unresolved user report.
Return to the affected device: record the error, actual failed request hostname and failure stage. A working homepage with failed login calls for checking login or API dependencies. Missing resources need their own hostnames recorded and investigated.
7. Align observations with service-side logs
Use the same time window to review CDN, reverse-proxy, origin and security logs. Did the request arrive, which service handled it, and what status was returned? Check recent changes to regional restrictions, rate limits, WAF rules or origin configuration. Absence from an application log alone does not prove a particular network device intercepted the request.
For escalation, provide redacted targets, ports, cities, carriers, timestamps, repeated symptoms and relevant statuses. Separate observations from hypotheses and state coverage gaps. That is more useful than a blanket accusation against a carrier.
8. Verify recovery under the original conditions
After an evidence-based change or provider action, repeat the original checks and ask affected users to retry the failed feature. Keep before-and-after records. An indeterminate result after an abnormal one is not recovery; note any changed node availability or network exit.
For recurring incidents, configure Console GFW Full monitoring around customer networks, or use API batches when you need your own archive. In short: preserve comparable evidence, check relevant networks, then correlate user experience with service logs. Carrier differences start the investigation; they do not finish it.