A server can ignore Ping while its website works. It can also answer Ping while sign-in fails. These observations are compatible because ICMP, a TCP connection and a web transaction ask different questions.
For a customer reporting mainland China access problems, begin with the actual domain and symptom. Ping is supporting evidence about an address, not the first or final verdict on domain availability.
1. Ping looks for an ICMP reply
Common IPv4 Ping uses ICMP Echo requests and replies, whose format is defined in RFC 792. It does not make an HTTP request to port 80 or 443, negotiate TLS, inspect a page or sign in.
A reply establishes an ICMP observation. No reply means this probe received no usable reply, not that the application is down. If Ping is given a hostname, it also needs an address first. Record the actual IP tested rather than saving only a hostname and a “reachable” label.
2. Why a working website may ignore Ping
A server, firewall or network device may suppress or rate-limit ICMP while allowing website connections. A CDN edge can apply different policies to ICMP and web traffic. ICMP packet loss is therefore not a page failure rate, and Ping latency is not a full page-loading measurement.
The reverse is just as important: a reply does not establish that the HTTPS service is listening, its certificate is valid or its application works. If users can complete their workflow and only Ping fails, investigate ICMP policy before declaring an outage.
Name the actual action completed. Another service on the same address, or a cached page, cannot establish that a fresh request to the intended site works.
3. TCP observations belong to one address and port
A TCP connection check asks whether this network can connect to this IP and port. 198.51.100.10:443 and 198.51.100.10:80 are different targets. Success at one port says nothing definitive about the other. This reserved example address is illustrative.
A successful connection does not validate TLS or an HTTP exchange. For a failure, distinguish refusal, timeout and other errors, then check the listener, access control and network. Compare observations with the same address, port, network and nearby time. Combining different ports into one “server status” hides useful evidence.
Confirm the address still serves the target. After an origin or CDN migration, an old IP may be irrelevant. Record where each tested address came from rather than changing addresses until one succeeds.
4. IP connectivity does not validate a named service
One address can host multiple domains. HTTP Host identifies the target host, as described in RFC 9110, Section 7.2. TLS SNI supplies a server name during negotiation; see RFC 6066, Section 3. Connecting to an IP and port alone tests neither behavior.
Replacing the hostname in an HTTPS URL with an IP may select a default site or cause a certificate name mismatch. Preserve the intended hostname for domain-level checks, and do not disable certificate validation to claim success. A valid HTTP response need not be 200; a TLS handshake is not a complete browser trust or application test.
5. Match the method to the question
| Question | Relevant check | Boundary |
|---|---|---|
| Is DNS Pollution reported for this domain? | DNS Pollution | Does not establish HTTP, TLS or application health |
| Are the main domain dimensions abnormal? | GFW Full | DNS Pollution, HTTP Host, TLS SNI and summary |
| Does this IPv4 address answer ICMP? | ICMP Ping | No reply is not an application outage verdict |
| Can this IPv4 address and port accept a connection? | TCP Connect | Does not validate domain identity or a business response |
For an initial domain question, use the DNS Pollution check and its introductory guide. For batch observations across the main dimensions, go directly to GFW Full. There is no need to check each domain individually first. Full means those three dimensions, not all seven methods or a browser session.
6. Keep IPv4, port and network boundaries visible
The WeaveBit public API currently accepts IPv4-only IP targets. TCP checks use a specified port. An IPv4 observation cannot guarantee IPv6 behavior, and a default-port result cannot validate another application port. Review the target and parameters in the public API documentation before choosing a method.
A user may reach another address or take a different path. For CDN-served domains, save the observed address and time rather than comparing a historical IP with a new visit as though they were identical. A single node cannot represent every carrier and region; mark additional networks when expanding coverage.
Investigate IPv6 reports with separately labeled client evidence and appropriate tools. IPv4 support does not imply dual-stack coverage, and another node does not reproduce a customer's home or enterprise network.
7. Give operations a usable evidence checklist
- Record the failing action, error, time and timezone: homepage, sign-in, API or asset. Remove tokens and personal information before sharing.
- List the hostname, actual IP, address family and port. Note any changed resolution or test configuration.
- Retain DNS or GFW dimensions and nodes. Keep supporting ICMP and TCP results separate rather than combining them into one success rate.
- Compare affected and reference networks at similar times. Review ICMP policy, listeners, CDN and security logs.
- After a change, repeat the original configuration and verify the real workflow. Preserve normal, abnormal, indeterminate and missing observations.
8. Resolve the symptom, not a “reachable” label
If ICMP alone fails while TCP and the site work, document the ICMP limitation and confirm policy. If TCP also fails, review the address, port and listener. If TCP succeeds but HTTPS fails, investigate TLS, certificates and domain requests. If only sign-in fails, include its dependency domains.
When the port connects but HTTPS still fails, continue with the TLS, SNI and reset troubleshooting guide to identify the next layer of evidence.
Close network and business findings separately: a port can recover while sign-in still needs verification. One successful new network is not recovery evidence for every affected user.
A reset or timeout does not independently identify a responsible party. Keep raw statuses and platform assessments as explained in result interpretation; Indeterminate is neither normal nor proof of blocking. Use the method definitions to combine network evidence with the customer's actual experience.