Nationwide Ping Tests Are All Green—So Why Are Users Still Reporting the Website Won’t Open?

After a site owner receives reports that “the website won’t open,” they immediately reach for a nationwide Ping testing tool. Dozens of regions all show green with low latency, so it is easy to conclude that the server is fine and the problem must be with the user’s own network.

This conclusion is not reliable.

All-green Ping results only show that the test node sent an ICMP Echo request to an IP address and received a response. When a user opens a website in a browser, the request still has to pass through DNS resolution, TCP connection, TLS handshake, HTTP request, CDN origin fetch, and page resource loading. If any of these stages fails, the user may see “This site can’t be reached,” “Connection reset,” a certificate error, “403,” or a blank page.

Therefore, all-green nationwide Ping results and a user being unable to open the website can coexist. Ping is useful for assessing basic network reachability and round-trip latency, but it cannot by itself prove that the website service is available.

What does an all-green Ping result actually prove?

Ping typically uses ICMP Echo Request and Echo Reply messages. According tothe ICMP definition in RFC 792ICMP is mainly used to carry network control and error messages. It is not an HTTP request, nor does it establish an HTTPS connection or load a web page on the user’s behalf.

A successful Ping test can usually prove only the following:

• The test node can send ICMP messages to the target IP;

• The target device or an intermediate network device is willing to respond to ICMP;

• No complete blocking occurred at the time of the test;

• A rough network round-trip time can be obtained.

It cannot prove the following:

• The domain name resolves to the correct IP address in the user’s location;

• A connection can be established normally on the server’s port 80 or 443;

• TLS certificates, SNI, and protocol negotiation are working properly;

• The CDN node can successfully fetch from the origin;

• The WAF has not blocked the current user;

• The HTTP request ultimately returns 200;

• Login, search, checkout, or API endpoints are usable;

• IPv4 and IPv6 access produce the same result.

There may even be a case where the Ping replies come from a CDN edge node, load balancer, or firewall, while the service that actually handles web requests is already failing. Ping continues to show green, but browser requests return 502, 503, or 504.

Why can some users still not open the website when nationwide Ping tests are normal?

1. The IP used by Ping differs from the IP the user actually accesses

After a CDN is enabled, the same domain name may return different IP addresses based on the user’s region, ISP, recursive DNS, and real-time scheduling policies. A nationwide Ping platform may test one of those IPs, while the user’s browser actually connects to a different edge node.

For example, the testing platform may resolve the domain to an East China node and get a normal Ping response, while a China Mobile user in Northwest China is scheduled to a different responding IP. If that latter node has a fault, routing anomaly, or origin fetch failure, the result is “all-green nationwide Ping, but some users cannot open the site.”

When troubleshooting, you must record both the domain resolution result and the actual responding IP; do not log only a Ping latency.

2. ICMP works, but the TCP port cannot be reached

Ping and HTTPS use different protocols. A server can respond normally to ICMP, yet connections to port 443 may fail because of security groups, firewalls, port listening, connection limits, or traffic scrubbing policies.

Common symptoms include:

• Ping latency is normal, but the browser reports a connection timeout;

• Port 443 is reachable in some regions but reset in others;

• Port 80 works, but connections to port 443 fail;

• The server still responds to Ping, but the web service process has stopped;

• The attack protection device allows ICMP but restricts new TCP connections.

Therefore, to determine whether a website can be opened, you need to send real HTTP or HTTPS requests rather than stopping at the ICMP layer.

3. TLS handshake failures occur after Ping

After an HTTPS website establishes a TCP connection, it must also complete a TLS handshake. An expired certificate, incomplete certificate chain, incorrect SNI configuration, domain-certificate mismatch, or protocol negotiation anomaly can all cause the browser to refuse further access.

Such failures do not affect Ping. The user sees a certificate warning, TLS error, or closed connection, while nationwide Ping results may still all appear normal.

If the same IP hosts multiple HTTPS websites, tests must also carry the correct domain name and SNI. Accessing HTTPS directly by IP may return a certificate and website content that do not correspond to the target domain.

4. The HTTP request reaches the node, but an error status code is returned

Even if DNS, TCP, and TLS all succeed, the HTTP layer may still return 403, 429, 500, 502, 503, or 504.

According toMDN’s documentation on HTTP status codesdifferent status codes represent different processing outcomes. For example, 403 usually means the server understood the request but refused access, 502 means the gateway received an invalid response from upstream, 503 means the service is temporarily unavailable, and 504 commonly indicates that the gateway timed out waiting for an upstream response.

When these errors occur, the node itself may still respond normally to Ping. The status code should be used to determine whether the problem lies in access control, the CDN node, the origin connection, or the origin application.

5. WAF, rate limiting, or risk controls block only specific users

Website security policies often do not uniformly allow or block all visitors. A WAF may handle requests differently based on source IP, ISP, region, request rate, User-Agent, Cookie, URL path, and behavioral characteristics.

Therefore, the fact that an IP from a speed-testing platform can access the site does not mean that home broadband, campus networks, corporate egress, or shared mobile networks can also access it. Users may be blocked because of egress IP reputation, an accidental rate-limit trigger, or browser characteristics, and Ping does not carry this HTTP-layer information.

If user reports are concentrated on login, search, payment, or a specific API, test the specific URL and request method instead of checking only the homepage.

6. IPv4 works, but IPv6 connectivity fails

Many nationwide Ping tests use IPv4 by default, but some mobile networks and home broadband connections try IPv6 first. If the domain publishes AAAA records while the IPv6 CDN nodes, certificates, routing, or origin fetch configuration are incomplete, IPv4 tests may be all green while some users still cannot access the site.

This type of issue can be confirmed by performing IPv4 and IPv6 requests separately. For a more completetroubleshooting method for IPv6 access failuresyou also need to verify AAAA records, dual-stack nodes, and the actual access path.

7. Small Ping packets are normal, but large HTTPS responses fail to transfer

Ping packets are usually small, while HTTPS pages may contain large response headers, images, scripts, and API data. When path MTU, fragmentation, packet loss, congestion, or intermediate device handling is abnormal, a few small packets may work normally while larger TLS or HTTP data stalls.

In this case, users may see a connection established, but the page remains blank for a long time, resources fail to load, or downloads are interrupted. Ping latency alone usually cannot reveal the problem.

8. Ping tests only the domain’s homepage, while the user accesses another subdomain

The actual website may use the following at the same time:

• www.example.comto serve web pages;

• api.example.comto provide APIs;

• static.example.comto deliver images and scripts;

• login.example.comto handle login;

• third-party domains to load CAPTCHA, payment, or analytics resources.

A normal Ping for the main domain does not mean that APIs, static resources, and login subdomains are all normal. If the browser is missing critical JavaScript, API, or CAPTCHA resources, users may perceive the website as “unable to open.”

Do not test only Ping; send real HTTP requests

When some users cannot open the site, you can first usethe nationwide multi-node HTTP website speed testenter the full URL that users actually access, and filter the results by region and ISP.

The CDNChart test results should focus on the following items:

Compared with Ping, an HTTP speed test is closer to the user’s actual access process. It not only checks whether the target responds, but also tells you what status code was returned, which IP was connected to, and at which stage the request slowed down.

If you are unsure whether to choose Ping, three-ISP speed testing, or web performance scoring, you can first followthe guide to choosing between China three-ISP speed testing and web performance toolsto divide the problem into layers. “Unable to open” is an availability issue; check DNS, connectivity, TLS, and HTTP first, then discuss first-screen rendering scores.

Reproduce the user’s access path from the command line

Step 1: Query A and AAAA records separately

dig www.example.com A
dig www.example.com AAAA
dig www.example.com CNAME

Focus on the returned IPv4, IPv6, and CNAME chain. Have the network where the affected user is located run the same query, then compare the results with those from a normal network. If the two sides return different responding IPs, test HTTP access for each of those IPs separately.

Also pay attention to TTL. When a configuration has just changed, different recursive DNS resolvers may still cache the old record, causing some users to continue accessing the old node.

Step 2: Send a real HTTPS request

curl -sS -L -o /dev/null \
  --connect-timeout 10 \
  --max-time 30 \
  -w 'status=%{http_code}\nremote_ip=%{remote_ip}\ndns=%{time_namelookup}\nconnect=%{time_connect}\ntls=%{time_appconnect}\nttfb=%{time_starttransfer}\ntotal=%{time_total}\nredirects=%{num_redirects}\nurl=%{url_effective}\n' \
  https://www.example.com/

According tocurl’s official documentation for command-line optionsthese fields can separately show the final status code, remote IP, DNS completion time, TCP connection time, TLS handshake time, time to first byte, total time, and number of redirects.

If Ping is normal but curl times out, check the port, routing, or firewall first; if the TLS stage fails, check the certificate and SNI; if 403 or 5xx is returned, continue checking the WAF, CDN origin fetch, and origin application.

Step 3: Force IPv4 and IPv6 separately

curl -4 -I https://www.example.com/
curl -6 -I https://www.example.com/

If IPv4 succeeds but IPv6 fails, the problem cannot be attributed to “an occasional local network issue for the user.” You need to check the nodes corresponding to the AAAA record, IPv6 routing, certificates, and the CDN’s dual-stack configuration.

-IThe request sent is a HEAD request, which is suitable for quickly checking response headers, but a small number of websites handle HEAD and GET differently. For a formal determination, you should still use a GET request to verify.

Step 4: Specify a responding IP to test a specific CDN node

curl --resolve www.example.com:443:203.0.113.10 \
  -sS -o /dev/null \
  -w 'status=%{http_code}\nremote_ip=%{remote_ip}\nttfb=%{time_starttransfer}\ntotal=%{time_total}\n' \
  https://www.example.com/

--resolveMake curl connect to a specified IP while retaining the correct Host and TLS SNI. This lets you verify an abnormal responding IP without modifying the local hosts file or disabling certificate verification.

If a normal node is reachable but an abnormal node returns 502 or times out, there is strong evidence that the problem is related to a specific node or that node’s origin fetch path.

Step 5: Check the TLS handshake separately

openssl s_client \
  -connect 203.0.113.10:443 \
  -servername www.example.com \
  -showcerts

Focus on the certificate domain name, validity period, certificate chain, and whether the handshake completes. Do not omit-servernameotherwise a multi-domain node may return the default certificate, leading to an incorrect conclusion.

Step 6: Compare routing and packet loss

traceroute 203.0.113.10
mtr -rwzc 50 203.0.113.10

An intermediate routing node not responding to probe packets does not necessarily indicate a fault. When judging, focus on whether the endpoint is reachable and whether packet loss starting at a certain hop continues to subsequent nodes. If only an intermediate hop shows packet loss while the endpoint is normal, the routing device may simply be limiting probe responses.

Quickly determine which layer the problem is in based on the symptoms

When users report that the site cannot be opened, collect this information first

“Cannot open” is not a sufficiently specific fault description. Before handling it, try to confirm with the user:

• The full URL being accessed, not just the website domain;

• The exact time the problem occurred;

• The user’s province and city;

• Whether they use China Telecom, China Unicom, China Mobile, or another network;

• Whether it is home broadband, mobile data, a corporate network, or a campus network;

• The error message or HTTP status code displayed by the browser;

• Whether the issue resolves after switching to mobile data or Wi-Fi;

• Whether IPv4 and IPv6 results differ;

• Whether the homepage cannot be opened, or only specific functions such as login, images, or APIs are abnormal.

Then retest in regions and on ISPs close to the user, rather than testing only in the city where the server is located. For intermittent problems, also keep results from multiple time periods. You can followthe multi-round testing method for intermittent website slownessRepeat the checks to prevent a single normal result from masking an intermittent fault.

FAQ

Does an all-green nationwide Ping test mean the server has no faults?

No. It only means that ICMP messages received a response at the time of the test. When the web service process has stopped, port 443 is blocked, the TLS handshake fails, CDN origin fetch is abnormal, or HTTP returns 5xx, the server may still respond normally to Ping.

Ping is normal but the browser reports a connection timeout. What should I check first?

First use curl to test a real HTTPS connection and determine whether the failure occurs at the DNS, TCP, TLS, or HTTP stage. If TCP cannot connect, check port 443, firewalls, security groups, node routing, and connection limits first.

Why can only China Mobile users not open the site?

This may be related to China Mobile routes, DNS scheduling, IPv6, specific CDN nodes, or WAF policies. Select China Mobile test nodes and compare responding IPs, connection times, status codes, and failed nodes. Do not use the success of China Telecom routes as a substitute for the China Mobile user experience.

Ping tests a domain name, so why can it still test the wrong IP?

CDN and DNS scheduling return different IPs based on recursive DNS, region, ISP, and cache state. The address resolved by a speed-testing platform is not necessarily the same as that of the affected user, so you need to record both sides’ A, AAAA, and CNAME records and the actual connected IP.

The website occasionally cannot be opened, but manual checks are always normal. What should I do?

Run repeated tests across multiple time periods and nodes, and record failed nodes, responding IPs, and status codes. If the fault lasts for only a short time, you also need to use CDN logs, origin logs, load balancer logs, and real user monitoring to locate it.

Can I confirm whether a security policy is the cause by disabling the WAF?

It is not advisable to disable the WAF broadly. A safer approach is to review hit logs, check the blocked IP, rule ID, URL, and request characteristics, and then perform temporary verification against a controlled test IP to avoid increasing security risk.

Can CDNChart directly prove which ISP the fault comes from?

CDNChart can help you see whether faults are concentrated in certain regions, ISPs, responding IPs, or request stages, thereby narrowing the scope. However, the final root cause may still need to be confirmed using CDN logs, DNS configuration, origin status, and network paths.