Ping fails, service works
“`ping api.example.com` times out, but `curl https://api.example.com/` returns 200 from the same machine. Explain how both can be true, and what `ping` actually proves in each direction.”
What this tests
- That ICMP and TCP are different protocols filtered by different rules
- What a ping result does and does not prove
- The right tool for testing a service rather than a host
- Awareness of the ICMP messages that must not be blocked
Answers by level
Read the beginner answer first and notice what is missing.
ping sends an ICMP Echo Request (protocol 1 on IPv4, ICMPv6 type 128 on IPv6) and waits for an Echo Reply; curl opens a TCP connection to port 443 (protocol 6). These are different IP protocols, and every filter on the path — host firewall, cloud security group, network ACL, the load balancer’s own stack — decides about them separately. An AWS security group that allows TCP 443 and says nothing about ICMP drops the echo silently; Windows blocks incoming echo by default; many load balancer VIPs and anycast addresses never answer ICMP at all because nothing behind the VIP is a "host". The name may also resolve to a CDN or LB address that is not the machine running the service. So the ping proves nothing about the service, and the 200 proves the entire path — DNS, routing, TCP, TLS, HTTP — works. See ping: What an Echo Actually Proves and Firewalls.
What ping *does* prove: a reply means IP-level reachability in both directions and gives an RTT and loss estimate *for ICMP*. A timeout means only that an echo did not come back — the host may be down, or the echo may be filtered outbound, at the destination, or on the return path, or rate-limited. Routers commonly process ICMP on a slow control-plane path and rate-limit it, so ping RTT and loss can look worse than the forwarding plane actually is. The reverse case is equally common: ping succeeds and the service is down — the host is up but nothing listens (connection refused), or the port is filtered (timed out), or TLS fails, or the process is hung and accepts connections it never answers. Each of those is a different layer (Why Can’t I Connect?).
The right tools test the layer you care about: nc -vz host 443 or curl -v --connect-timeout 3 for TCP reachability, openssl s_client for TLS, curl -sS -o /dev/null -w "%{http_code}" for HTTP, mtr -T -P 443 or tcptraceroute to trace the path *using TCP to the real port* so ICMP filters do not produce * * * at every hop, and nmap -Pn to skip the host-discovery ping that would otherwise report "host down". A monitoring check that pings hosts is measuring a different thing from the service it is meant to watch.
Green flags · Red flags
- States ICMP and TCP are different protocols with separate firewall rules
- Says a failed ping proves nothing about a TCP service and lists what a successful one does prove
- Names TCP-level tools:
nc,curl,mtr -T,nmap -Pn - Mentions VIPs, LBs or
ClusterIPaddresses that never answer ping - Knows that blocking all ICMP breaks PMTUD
- Treats ping as the definitive host-up check
- Believes ping tests a port
- Recommends blocking all ICMP for security
- Cannot name a tool that tests TCP reachability
Follow-up questions
curl hangs at "Connected to … Trying" then times out. Which layer?traceroute show * * * for several hops while the destination responds normally?