A domain can resolve to an IP address while HTTPS still fails for users in mainland China. A reset, a handshake error and a browser certificate warning are different observations. Successful DNS resolution cannot settle what happened later in the connection.
Start with the URL that actually failed. The homepage, sign-in service and API may use different domains. The useful outcome is a reproducible account of the failing stage, not an immediate claim about who caused it.
1. Define what “DNS works” means
A successful ordinary DNS query means that a response was obtained. It is not the dedicated DNS Pollution assessment. Equally, a check that reports no pollution does not establish that HTTPS or the application works. Keep the hostname, observation time and network alongside the result.
For an initial single-domain question, use the free DNS Pollution check. If you already have an observation, retain it rather than restarting the investigation at DNS. The DNS checking introduction explains how to act on the available outcomes.
Replace “DNS works” in a ticket with the method, time and outcome. A query from another machine cannot exclude a DNS issue on the affected user's network. Keep those observations separate.
2. HTTP Host and TLS SNI identify names at different stages
One server address can host several sites. HTTP Host carries the target host and port so the server can distinguish resources, as described in RFC 9110, Section 7.2.
TLS SNI supplies a server name during the handshake and can influence server configuration or certificate selection; see RFC 6066, Section 3. In a normal HTTPS exchange, TLS negotiation precedes the HTTP request. Host and SNI are related names, but an HTTP observation and a TLS observation test different stages. An HTTP response does not establish a successful HTTPS handshake.
3. An IP-address URL is not the same virtual host
Changing https://example.com/ to https://198.51.100.10/ changes more than resolution. The request name changes too, and the server may select a default site or a different certificate. Neither success nor failure at the literal IP proves what happened to the named service. This reserved address is illustrative, not a test destination.
For an authorized fixed-address comparison, use a client that preserves the original URL hostname, port and TLS name while changing only the connection address. Record that adjustment. Do not ignore certificate errors to manufacture a successful result or treat a default-site response as evidence about the intended site.
4. Separate handshake, certificate and application results
| Observation | What it establishes | Still to investigate |
|---|---|---|
| TCP connection succeeds | A connection to that address and port | TLS, domain identity and HTTP |
| TLS handshake succeeds | This negotiation completed | Browser certificate checks and application requests |
| Valid HTTP response arrives | An HTTP response was received | Status meaning, content and required redirects |
| Homepage displays | This homepage visit completed | Sign-in, APIs, assets and dependency domains |
A certificate warning may concern expiry, hostname matching, trust or the client clock. WeaveBit handshake results are not a complete certificate audit. A valid HTTP response need not be 200 either: a redirect, authentication response or server error has its own application meaning.
Save the browser warning for the site owner to review against the deployed certificate. Do not ask users to weaken security, disclose passwords or make a real payment merely to test a connection.
5. A reset or timeout is not a root-cause label
A reset records an interrupted connection; it does not independently identify the sender or reason. Origin behavior, CDN or access-control policy, and network conditions need investigation. A timeout means the operation did not finish within its wait window. Preserve TLS alerts, EOF and other handshake errors as distinct observations rather than relabeling them all as blocking.
Locate the stage first: TCP connection, TLS negotiation or a subsequent HTTP request. Correlate origin, CDN and security logs with the incident time. An absent log entry is not conclusive without knowing the log coverage and retention.
Record intermittent and repeated failures, including affected users. Saving only a successful retry hides instability. Append new observations instead of overwriting the original incident evidence.
6. Inspect GFW Full dimensions, not just the summary
When the DNS result cannot explain HTTPS failure, GFW Full combines DNS Pollution, HTTP Host and TLS SNI dimensions with a per-node summary. It is neither all seven methods nor a full browser test. Choose nodes relevant to affected customers and keep the domain and ports consistent; follow the GFW Full guide.
Keep each dimension's status and assessment. TLS_HANDSHAKE_OK records success, while TLS_HANDSHAKE_RESET can meet the platform's abnormal classification. Timeouts and insufficient evidence can remain Indeterminate. The result interpretation documentation explains the categories; Indeterminate is not recovery evidence.
7. Collect evidence in a repeatable order
- Record the failed URL, time and timezone, browser error, user region and carrier. Remove tokens, personal information and sensitive query parameters before sharing.
- Identify the actual domain and port, including sign-in, API or asset dependencies. Separate ordinary resolution from a pollution assessment.
- Save node and protocol observations under the same configuration, including indeterminate and missing results.
- Compare the affected and reference networks at similar times. Review certificates, server logs and recent DNS, CDN or WAF changes.
- After a change, repeat the original configuration and ask affected users to verify their real workflow. Change few factors at once and record them.
8. Report a bounded finding and verify recovery
A useful report states the time, network, target and failing stage, then identifies what remains unconfirmed. “No DNS pollution reported; TLS reset observed on one carrier; sign-in still failing” is a reporting example, not a live measurement or attribution.
Normal protocol results still require browser certificate and business verification. Network and application recovery may occur at different times. Keep unresolved evidence open and consult the method definitions before letting one successful check stand for the whole service.
If your evidence is limited to Ping or an IP-port test, use the ICMP, TCP and domain-check guide to identify which HTTPS questions remain unanswered.