How to Test Server Speed When Ping Is Blocked: From TCP Connections to HTTP Responses

After the server went live, the administrator disabled public Ping responses. Some called it a security policy; others argued that “if Ping fails, there is no way to test performance.” During an actual incident, the questions are usually more specific: the server does not answer ICMP Echo, but can the website still accept TCP connections? Port 443 is open, but is the HTTPS certificate correct? The page returns 200, but does its body contain the expected application content?

Blocking Ping does not make testing impossible or mean the server is unavailable.It only means that one probe method, ICMP Echo, received no response. For a website, a more realistic testing sequence is DNS resolution, TCP port connection, TLS handshake, HTTP status, and response body. Then use server-side listener checks and packet captures to identify exactly where the request stops.

CdnChart recommends treating “server speed testing” as “layer-by-layer validation of the access path.” To check whether users can open a website, test the production domain and URL. To investigate an origin port, pin the connection to the origin endpoint with proper authorization. To assess a particular network path, also record the region, carrier, IPv4 or IPv6, and actual responding IP. When Ping results are unavailable, defining exactly what you are testing becomes even more important.

First, establish exactly what “blocking Ping” means

“Ping is blocked on the server” often describes several different situations. Typically, the host or an upstream firewall drops ICMP Echo Request packets. It may filter only IPv4 Echo, while the IPv6 path behaves differently. A CDN edge may also ignore Ping while its HTTPS endpoint works normally. If the domain uses multiple proxy layers, the address being pinged may simply be an edge address, not the origin server the administrator has in mind.

ICMP Echo is a diagnostic signal, not a website application protocol. Even if the operations team chooses not to respond publicly to Echo Request packets, allowing all ICMP traffic just to turn a Ping tool green is not advisable. This is especially important for IPv6: ICMPv6 is not just for Ping; it also supports functions such as path and neighbor discovery. SeeICMPv6 Firewall Filtering Recommendationsto understand why blocking all ICMPv6 can introduce new connectivity problems.

The first step is therefore not to change the firewall, but to qualify the observation: which domain, IP, protocol, test location, and time window received no response? Without these details, “Ping fails” is only a clue, not a diagnosis.

Define the production target before testing an IP directly

For an HTTPS website, first establish the URL users actually visit, such ashttps://www.example.com/healthz, rather than starting with a machine’s public IP. A domain may have multiple A or AAAA records, and its CNAME chain may lead to a load balancer or CDN. Results from testing a fixed IP do not necessarily cover every endpoint used by the production domain.

On Windows, start by saving the following information:

Get-Date -Format "o"
Resolve-DnsName www.example.com -Type A
Resolve-DnsName www.example.com -Type AAAA
Resolve-DnsName www.example.com -Type CNAME
Test-NetConnection www.example.com -Port 443 -InformationLevel Detailed

On Linux or macOS, use:

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

Do not simply record “DNS is working.” Save the returned addresses, TTL, CNAME chain, resolver used, and execution time. When DNS returns multiple addresses, identify which one the subsequent connection actually selects. Different recursive DNS resolvers, carriers, and regions may receive different endpoints, especially with a CDN.

If both A and AAAA records exist, a Ping tool and a browser may select different addresses. Test application requests separately:

curl.exe -4 -q --silent --show-error --connect-timeout 5 --max-time 20 -o NUL -w "family=IPv4 remote=%{remote_ip} code=%{http_code} total=%{time_total}\n" "https://www.example.com/healthz"
curl.exe -6 -q --silent --show-error --connect-timeout 5 --max-time 20 -o NUL -w "family=IPv6 remote=%{remote_ip} code=%{http_code} total=%{time_total}\n" "https://www.example.com/healthz"

On Windows,NULis the device name used to discard the body; on Linux and macOS, replace it with/dev/null. The goal is not an impressive total time, but to verify whether IPv4 and IPv6 each complete DNS resolution, connection establishment, TLS, and the HTTP request. If the test environment has no working IPv6 egress, record “this test environment cannot validate IPv6,” not a website IPv6 failure.

TCP port testing: check whether new connections can be established

When a server does not respond to Ping, testing its TCP port is the most direct alternative. On Windows,Test-NetConnectioncan check whether a TCP connection can be established to a specified host and port:

Test-NetConnection www.example.com -Port 443 -InformationLevel Detailed
Test-NetConnection www.example.com -Port 80 -InformationLevel Detailed

Focus onTcpTestSucceeded, the remote address, source address, and port.PingSucceededis not a substitute for the TCP result. Do not skipTcpTestSucceededjust because it is False. If 443 is True while Ping fails, at least the TCP connection from the current source to that endpoint is not blocked in the same way.

A successful port connection still proves only that a process or upstream device accepted a TCP connection. It does not mean that port 443 serves the correct HTTPS service or that a browser will receive the right certificate. A load balancer can accept TCP and then forward requests to the wrong backend; a default virtual host can return an unrelated site after TLS completes.

Also pay attention to what a tool means by “latency.”Test-NetConnectionis useful for checking connectivity and target details, but not all online TCPing tools measure time the same way. Some include DNS time; others stop when they receive SYN-ACK. Some use proxies, while others connect directly. Ranking the “TCP latency” shown by different tools can mistake differences in test conditions for differences in network paths.

To determine whether the server actually sees new connections, also inspect its listeners:

sudo ss -lntp '( sport = :443 )'
sudo ss -lntp '( sport = :80 )'

The ss socket inspection utilityprovides essential local address, port, and process details. A service listening only on127.0.0.1:443may work locally but cannot accept direct public connections. A service listening only on a private interface does not prove that the cloud platform’s public IP mapping is correct either. Containers, Ingress, load balancers, and hosts may expose listeners in different places, so inspect the correct network namespace.

Use curl to break TCP success down into TLS, first byte, and download

The useful answer to testing a server that blocks Ping is not another “universal Ping” tool, but a controlled HTTPS GET request. The following command works in Windows PowerShell and can be adapted to Linux shell syntax:

curl.exe -q --http1.1 --silent --show-error --connect-timeout 5 --max-time 20 --dump-header https-headers.txt --output https-body.html --write-out "remote_ip=%{remote_ip}\nhttp_code=%{http_code}\nhttp_version=%{http_version}\ndns=%{time_namelookup}\nconnect=%{time_connect}\ntls=%{time_appconnect}\npretransfer=%{time_pretransfer}\nfirst_byte=%{time_starttransfer}\ntotal=%{time_total}\nsize=%{size_download}\n" "https://www.example.com/healthz"

This request neither follows redirects automatically nor disables certificate verification.--http1.1establishes a reproducible TCP-based baseline; it does not mean the browser will ultimately use HTTP/1.1.--connect-timeoutlimits the connection phase, while--max-timelimits the entire request. The numbers are diagnostic examples, not universal pass thresholds for every application.

The official curldocumentation on verbose output and connection informationcan help explain these phases. In general, interpret them as follows:

If TCP connects quickly and TLS timing is normal, but the first byte is slow, first investigate origin fetching, application processing, databases, or third-party APIs. If the first byte arrives normally but downloading takes too long, focus on response size, compression, and sustained throughput. If evenhttp_codeis missing, the request has not fully reached the HTTP response phase. This breakdown reveals where time is spent more effectively than repeating Ping.

Save the exit code, response headers, and body during testing. curl can fully receive HTTP 403, 404, and 500 responses, so command completion alone is not enough. Conversely, HTTP 200 does not guarantee a complete file: also check the transfer result, body length, and application-specific validation.

Preserve Host and TLS SNI when retesting a fixed IP

If a domain resolves to multiple addresses, or you suspect a particular node is faulty, use--resolvefor a controlled comparison:

curl.exe -q --http1.1 --silent --show-error --resolve www.example.com:443:203.0.113.10 --connect-timeout 5 --max-time 20 --dump-header fixed-headers.txt --output fixed-body.html --write-out "remote_ip=%{remote_ip}\nhttp_code=%{http_code}\ntls=%{time_appconnect}\nfirst_byte=%{time_starttransfer}\ntotal=%{time_total}\n" "https://www.example.com/healthz"

203.0.113.10is reserved for documentation. In actual testing, replace it with an address you are authorized to test and have confirmed belongs to the application. Keep the production domain in the URL so the request normally retains the correct Host and TLS SNI while directing only this connection to the specified IP.

Do not simply change the URL tohttps://203.0.113.10/and add only a Host request header. HTTP Host is sent after the TLS handshake and cannot replace the server name required during TLS. Any certificate error produced this way may be caused by the test method rather than an issue real users experience.

Pinning an IP is intended to compare the normal DNS path with a specified endpoint, not to prove that the IP is permanently healthy. If the fixed address succeeds while the production domain fails intermittently, investigate traffic steering, cache TTL, carrier-specific DNS results, and failure times. If the fixed address also fails, check that endpoint’s listeners, certificate bindings, and security rules.

TLS can still fail after TCP connects

After connecting to the port, the client must verify the server’s identity and complete TLS negotiation. A hostname mismatch, incomplete certificate chain, expired certificate, incorrect client clock, wrong SNI binding, or incompatible protocol version can all cause HTTPS to fail. More Ping tests will not help: the fault is now in a security protocol above the transport layer.

Start with curl’s verbose output to identify the failing phase:

curl.exe -q --http1.1 --verbose --connect-timeout 5 --max-time 20 -o NUL "https://www.example.com/healthz"

If OpenSSL is available, you can also explicitly specify SNI with proper authorization:

openssl s_client -connect 203.0.113.10:443 -servername www.example.com -verify_return_error -brief

This command provides handshake and certificate clues; it is not a complete browser acceptance test. Check whether the certificate’s Subject or SAN includes the requested domain, whether a valid verification chain can be built, whether the server aborts the handshake, and whether the test reaches the expected IP. Do not disable certificate verification to turn a failure into a success. That changes the test conditions without fixing visitors’ trust problem.

For a CDN, separate two connections: the certificate and connection between users and the CDN edge, and TLS between the CDN and the origin. A correct edge certificate does not prove that the origin certificate, origin SNI, or origin Host is correct. Conversely, direct origin access may fail because the origin intentionally accepts only CDN requests. Evidence from one connection cannot replace evidence from the other.

Even HTTP 200 requires body and application-result checks

Once TLS completes, the HTTP status is only the next checkpoint. A 200 response may contain the correct homepage, but it could also contain a login page, WAF challenge, default virtual host, maintenance notice, or custom error page. Performance tests that record only status codes can count a reachable error page as a successful visit.

Define the expected result for each target in advance. A public health page might require 200 and a fixed field; an article page, a title or version identifier; a static file, a Content-Type and trusted checksum. An unauthenticated API request may legitimately require 401. Different application paths have different expectations: “every request must return 200” is not a universal rule.

For APIs, parse JSON fields wherever possible instead of merely searching for “success.” For pages, check a title, version number, or stable identifier. For downloads, check size, Range responses, and checksums. Do not repeatedly call production APIs that create orders, charge payments, or send SMS messages just to test performance. Prefer read-only paths or dedicated health checks.

If the website has dynamic APIs, a page cache hit does not prove that the origin application is healthy. Refer toDynamic APIs, CDN Caching, and Dynamic Acceleration: Key Differencesto validate publicly cacheable APIs, user-private APIs, and APIs that always fetch from the origin separately. A cache hit shows that the edge can deliver an object, but does not necessarily confirm database, login, or real-time application health.

Identify where the three-way handshake stops on the server

If the client reports only a timeout and Ping is unavailable, a limited server-side packet capture can be valuable. Before capturing, confirm authorization for the server and network devices. Set a short capture window, an explicit source filter, and a packet-count limit. Do not run continuous captures in production.

sudo timeout 15s tcpdump -i any -nn -tttt -s 128 -c 40 'host 198.51.100.20 and tcp port 443'

198.51.100.20is only a documentation address. Replace it with the authorized test source as actually seen by the server.-nnavoids interference from reverse DNS lookups,-ttttretains timestamps including the date,-s 128limits the capture length for each packet, and-c 40exits after reaching the packet-count limit. Capture files and output may still contain real addresses and protocol metadata; sanitize them before sharing.

The capture location must match the architecture. A load balancer may terminate the user’s TCP connection and open a separate connection to the backend. CDN origin fetching also creates a second, distinct handshake. A SYN visible at the frontend is not necessarily the same SYN seen by the application container. With proxies, NAT, or container networks, correlate ingress and backend activity separately; do not force two connections into one based on addresses and ports.

If the server sees SYN and sends SYN-ACK normally, but the client still times out, investigate the return path first. If the server sees no SYN, check the target, ingress, and upstream forwarding. If the handshake completes, move on to TLS and HTTP. This approach narrows the fault domain more effectively than finding more Ping locations.

Test IPv4 and IPv6 performance separately

Address-family differences are easy to overlook when Ping is blocked. A domain may have both A and AAAA records while its IPv6 listener, cloud security policies, CDN endpoint, or origin path is not ready, causing failures for users who prefer IPv6. Conversely, filtered IPv6 Ping with working IPv6 HTTPS does not mean the IPv6 service is unavailable.

Check DNS and HTTPS separately as follows:

curl.exe -4 -q --http1.1 --silent --show-error -o NUL -w "ipv4 code=%{http_code} ip=%{remote_ip} connect=%{time_connect} total=%{time_total}\n" "https://www.example.com/"
curl.exe -6 -q --http1.1 --silent --show-error -o NUL -w "ipv6 code=%{http_code} ip=%{remote_ip} connect=%{time_connect} total=%{time_total}\n" "https://www.example.com/"

If IPv4 works but IPv6 fails, check the AAAA target, IPv6 listeners, firewall rules, certificates, and CDN dual-stack configuration. If HTTPS works on both and only Ping fails, the issue may still be limited to ICMP policy. IPv6 defines packet handling and address behavior that differ from IPv4; successful IPv4 Ping cannot replace IPv6 application validation. For the fundamentals, see theIPv6 Protocol Specification.

If AAAA records or address-family policies must change, first assess the actual user share and rollback options. Removing AAAA may temporarily bypass an IPv6 fault, but it also forces working IPv6 users back to IPv4. Allowing all ICMPv6 may create unnecessary exposure. Identify the failing phase before deciding whether to repair dual-stack support or temporarily change traffic steering.

With a CDN, Ping may not target the origin

Once a CDN is deployed, there are at least two paths: user to edge and edge to origin. Ping to the domain may fail simply because the edge does not answer ICMP. TCP and HTTPS to the domain may work even when the CDN can no longer reach the origin. Direct access to the origin IP also does not prove that the user-facing CDN endpoint works.

That is why a Ping screenshot is not enough for CDN troubleshooting. For the public path, record the final responding IP, region, carrier, status code, connection time, and total time. For the origin path, examine origin-fetch logs, origin listeners, origin Host, SNI, and allowed sources. These are different test targets; do not mix their results in one column.

To determine whether deploying a CDN has actually changed the user experience, seeHow to Verify That CDN Acceleration Is Workingand compare the production domain’s DNS results, responding IPs, HTTP status, and actual request results across regions. Do not describe a successful TCP connection to an origin IP as proof that the CDN works, or an edge-cached 200 response as proof that every origin service is healthy.

The multi-region observations on the CdnChart homepage are better suited to identifying which user-facing endpoints are affected. They do not replace arbitrary TCP port scans, server listener checks, or origin packet captures. They can, however, expand a single customer’s experience into a breakdown by region, carrier, address family, and responding IP. Origin-fetch details unavailable to public probes still require administrative access, CDN logs, and origin-side evidence.

CdnChart’s approach: four tables are more useful than one Ping screenshot

For servers that block Ping, we recommend four linked records rather than pursuing a single supposed “server latency” value. The first is thetarget table, covering the production domain, path, port, A and AAAA records, CNAME, test resolver, and time. The second is theconnection table, covering region, carrier, address family, responding IP, TCP result, and failure type. The third is theprotocol table, recording TLS, HTTP status, redirects, body identifiers, and cache indicators. The fourth is theserver-side table, correlating listeners, load balancing, SYN observations, origin fetches, and application logs.

The benefit is that every conclusion has a defined scope. For example, “new TCP 443 connections from China Mobile in Guangzhou over IPv6 to 203.0.113.10 failed during the observation window” is reproducible; “the server is unreachable nationwide” requires more sources. If a column is missing, narrow the conclusion rather than filling unknowns with assumptions based on experience.

Retain failed samples in multi-region tests. Counting only successful locations removes users who cannot connect from the denominator; looking only at averages hides a carrier’s long-tail delays.

For before-and-after deployment comparisons, use the same application URL, the same primary regions, similar test times, and identical address-family conditions. Also document whether the initial test used a cold or warm cache, a proxy, or automatic retries. Pre- and post-migration results are comparable only when the measurement conditions are similar.

Define acceptance criteria for servers that block Ping

After a fix or configuration change, do not simply report “Ping restored” or “port opened.” Useful acceptance criteria should cover at least four layers:

1. Target layer: the production domain resolves to the expected address range, with no stale addresses or unexpected address-family results in key regions.

2. Connection layer: new TCP 443 connections from target user networks meet the application’s requirements for success rates and timeout ratios.

3. Protocol layer: TLS certificates, SNI, certificate chains, HTTP status, and redirects match expectations.

4. Content layer: response bodies, JSON fields, static files, or key read-only application results are correct.

For websites using a CDN, add a fifth layer: edge-to-origin results must correlate with origin logs. One homepage cannot represent cache hits, cache misses, and dynamic APIs. For login, search, checkout, and similar operations, use dedicated test accounts and approved read-only or reversible scenarios. Do not repeat production write operations just to obtain a successful screenshot.

Configure monitoring by layer too. ICMP can provide supporting clues, but should not be the sole basis for website availability alerts. TCP monitoring detects endpoint connection issues; TLS monitoring detects certificate and handshake issues; HTTPS monitoring checks status and body; critical transaction monitoring checks the login, query, or ordering flows users actually need. This allows monitoring to determine service availability accurately even when the server does not answer Ping.

Troubleshooting approaches that can make matters worse

Allowing all ICMP just to make Ping succeed

This may only change the monitoring display without fixing TCP, TLS, or HTTP failures, and may increase exposure. If ICMP monitoring is genuinely required, restrict sources, frequency, and necessary message types, and report it separately from HTTPS monitoring.

Declaring the website healthy after a port check passes

TCP success only confirms that a connection endpoint exists. Certificate errors, incorrect virtual hosts, WAF denials, origin-fetch 502 errors, and wrong body versions can all occur afterward. At minimum, add an HTTPS GET with certificate verification enabled and confirm that the body meets application expectations.

Accessing HTTPS directly through the origin IP

This often returns the wrong certificate or default site because Host and SNI are missing. For an authorized comparison, usecurl --resolveor an equivalent method that preserves the production domain context. Do not let the test method create false failures.

Masking connection failures with longer timeouts

Longer waits may make occasional successes appear more reliable without showing whether users can access the service within an acceptable time. Record the first failure, retry results, and actual wait time together, rather than retaining only the final success.

Relaxing the origin allowlist so public test probes can connect

If the origin intentionally accepts only CDN requests, failed direct access from public probes may be expected. Monitor the production user-facing endpoint. Run origin health checks within the permitted network and identity constraints; do not weaken origin protection just to obtain a green result.

Frequently asked questions

Can actual access speed still be measured when a server blocks Ping?

Yes. For websites, TCP connections, TLS handshakes, and HTTPS responses reflect real access more closely than ICMP. By using the production domain and URL and recording DNS, connection, TLS, first-byte, download, and body results separately, you can build more complete evidence than Ping provides.

Does a successful TCP 443 connection mean the server has no problems?

No. It only means the current test source can establish a TCP connection to a particular address. Certificates, SNI, HTTP status, caching, origin fetching, the application, and critical workflows still require separate checks.

Why does Ping fail while HTTPS works?

The most common explanation is that ICMP is filtered or rate-limited while TCP 443 is allowed. Also verify whether Ping and the browser use the same IP, address family, and endpoint. If the targets differ, the results cannot be compared directly.

Does blocking Ping affect CDN performance testing?

Not necessarily. Website performance tools such as CdnChart focus on actual HTTP access results, primarily observing DNS resolution, connections, status, and timing across regions. This is neither ICMP Ping nor arbitrary TCP port scanning. A server’s refusal to answer Ping does not automatically prevent HTTPS-layer testing.

Should I delete the AAAA record if IPv6 Ping fails but IPv4 works?

Do not delete it first. Test IPv6 TCP, TLS, and HTTP separately to determine whether only ICMP fails or the IPv6 application endpoint also fails. If the service behind AAAA is genuinely incomplete, decide on changes using actual user share, the repair plan, and rollback options, not Ping results alone.

Does the absence of server HTTP logs prove that requests never reached the server?

No. Requests may stop at upstream ingress, the TCP handshake, TLS, or a proxy before reaching application logging. An upstream load balancer may also have terminated the connection. Compare listeners, limited packet captures, load balancer logs, and application logs within the same time window.

Should I switch CDNs immediately if only one location fails in a multi-region test?

No. First identify the failing location’s carrier, address family, actual responding IP, DNS results, and failure phase, then repeat the test under the same conditions. ICMP failure alone with stable HTTPS does not justify switching CDNs. Persistent TCP or HTTP failures in the same region warrant further evaluation of traffic steering, network paths, nodes, or providers.

Blocking Ping removes one observation method, not the ability to troubleshoot.Start with the production domain: confirm the target, test TCP, then check TLS, HTTP, and the response body. For connection timeouts, return to server listeners, SYN flow, and the return path. Finally, use multi-region HTTPS results to assess impact and origin and CDN logs to identify the responsible layer. These findings can guide firewall, routing, origin-fetch configuration, or CDN migration decisions instead of letting a Ping screenshot dictate the response.