Ping vs TCP Check: What's the Difference?
Ping and TCP check are both reachability tests, but they measure different layers. Ping asks "is this host alive?"; a TCP check asks "is this specific service accepting connections?" — often the answer you actually need.
What ping tests
Ping uses ICMP echo requests. The host replies, and you learn round-trip latency and packet loss. It's the fastest way to confirm a machine is powered on and reachable at the network layer — but it says nothing about whether any service on it is working.
What a TCP check tests
A TCP check opens a real connection to a specific port — 443 for HTTPS, 22 for SSH, 3306 for MySQL. If the handshake completes, that service is up and accepting connections. This is a far stronger signal of "can users actually reach the service" than ping alone.
Why ping can mislead
- Many hosts block ICMP entirely — ping fails while the site works perfectly on port 443.
- Ping can succeed while the actual service is crashed — the box is up, the app is down.
- Firewalls often treat ICMP and TCP differently, so one passing tells you little about the other.
Which to use when
- Use ping to measure latency/packet loss and confirm basic reachability.
- Use a TCP check to confirm a specific service (web, mail, database, SSH) is truly reachable.
- When ping fails but you can browse the site, trust the TCP check — ICMP is probably just blocked.
Frequently asked questions
Why does ping fail but the website works?
The host is blocking ICMP (ping) at its firewall while still accepting TCP connections on the web port. The site is up; ping just isn't allowed. A TCP check on port 443 confirms reachability.
Is a TCP check better than ping?
For confirming a service is usable, yes — it tests the actual port a service listens on. Ping is still the right tool for measuring latency and packet loss. They complement each other.