Ping works but the application does not. Where do you look next?
Show the answer
Say this first
Ping only proves ICMP gets there and back. Next I test what the application really uses: does the name
resolve to the address I pinged, does TCP connect on the right port, and does the service answer. That
is nslookup, then nc -vz or Test-NetConnection -Port, then curl -v. The usual causes are DNS, an
ACL or firewall that permits ICMP but not the port, MTU, a proxy or load balancer, or the service itself.
Go deeper
Carry on up the stack
- Name. Does the client resolve the name to the IP you pinged? Split DNS and stale records are common.
- Port.
nc -vz 10.30.0.15 443on Linux orTest-NetConnection 10.30.0.15 -Port 443on Windows. - Large packets. If TCP connects but the page hangs, suspect MTU and test with
ping -M do -s 1472. - Application.
curl -v https://app.example.com/shows resolution, connect, TLS and the HTTP status. - Path. Policy-based routing, a proxy or a load balancer can send TCP 443 a different way from ICMP.
Read the TCP result
| What you see | Likely meaning |
|---|---|
| SYN, then nothing | dropped by a firewall or ACL, broken return route, or host down |
| SYN, then RST | host reached but nothing listens, or a firewall set to reject |
| Handshake completes, then a hang | MTU, a middlebox, or the application |
They will ask next
What does "connection refused" prove?
Something answered with a TCP RST, so routing works in both directions to that point. Either nothing listens on that port or a device in the path resets on the host's behalf. In a capture, the RST's TTL often shows whether it came from the host or from a firewall closer to you.
Traps
- Closing the ticket because "ping works".
How did you do?