How to Check a Server: Ping, HTTP, and Port Tests Explained

To check whether a server is reachable and responsive, run three tests in order: a ping to confirm the host answers and measure latency, an HTTP check to confirm the web service responds, and a TCP or UDP port check to confirm the specific service you care about is open. Running each test from several locations separates a real server problem from a problem on your own network. Check-Host.net provides all of these as online tools, so you can run them from a browser without installing anything.

Start with a ping to test reachability

Ping sends small packets to the host and measures whether they come back, how long they take, and how many are lost. On Check-Host.net, the ping tool tests reachability and measures network latency and packet loss from different servers in the world.

What to look at:

• Packet loss — 0% means every packet returned. Partial loss points to an unstable path or an overloaded link. Total loss usually means the host is down, blocking ICMP, or unreachable from that location.
• Latency (round-trip time) — the delay in milliseconds. Compare values across locations: a server that answers in 20 ms from one region and 300 ms from another is reachable everywhere, but the far location is simply distant.
• Consistency — wildly varying times between packets suggest congestion rather than a dead server.

If ping fails from every location, the host is likely down or filtering ICMP. If it fails from one location only, suspect that network path, not the server.

Confirm the web service with an HTTP check

Ping only proves the machine answers — it says nothing about whether the website works. The HTTP tool checks a website's response performance and availability from many countries and datacenters.

Use it to answer:

• Does the site return a successful response, or an error status?
• How long does the response take from each location?
• Is the slowness global (server-side) or limited to certain regions (network or CDN routing)?

A server that passes ping but fails HTTP has a working network stack but a broken or stopped web service. A server that passes HTTP but is slow from everywhere points to server load or application performance, not connectivity.

Test the exact port your service uses

A server can be reachable while the specific service you need is closed. Port checks verify this directly:

• TCP port check — tests whether a TCP connection can be established to a specified port. Use it for web (80/443), SSH (22), mail, databases, and most services.
• UDP port check — tests whether communication works over UDP on a specified port. Use it for DNS (53), VPNs, game servers, and other UDP-based services.

Interpretation:

This distinction matters: "refused" and "timeout" point to different fixes. Refused usually means the service is stopped or bound to a different port. Timeout usually means a firewall or security group is blocking access.

Compare results from multiple locations

A single test from your own machine can't tell you whether a problem is the server or your connection. Running the same check from several locations is what makes the diagnosis reliable:

• Fails everywhere → the server or service is genuinely down.
• Fails only from your location → your network, ISP, or local firewall is the cause.
• Succeeds everywhere but slow from one region → routing or distance, not an outage.
• Inconsistent across locations → intermittent server load or an unstable network path.

This is the core reason to use a multi-location tool rather than a single ping from your laptop.

Check DNS when the name doesn't resolve

If a check fails before it even reaches the server, the problem may be DNS rather than the host. The DNS tool retrieves A, AAAA, and PTR records with TTL from nameservers around the world, which lets you confirm that a domain resolves correctly and that DNS updates have propagated.

Symptoms that point to DNS:

• The server responds when you test its IP address directly, but not by hostname.
• Different locations resolve the name to different or outdated addresses.
• A recent DNS change hasn't taken effect everywhere yet.

You can also look up IP location data — country, region, city, time zone, ISP, and organization — to confirm an address belongs where you expect.

Diagnose common failures

Putting it together

Run the tests in order — ping, then HTTP, then the specific port — and repeat from more than one location. Each result narrows the cause: reachability, web service, port access, or DNS. Check-Host.net bundles these tools (ping, HTTP, TCP port, UDP port, DNS, IP info, and a subnet calculator) in one place, and it also offers an API if you want to build your own monitoring on top of the same checks. For ongoing availability rather than one-off diagnosis, see [Website Monitoring: What It Checks and How to Test a Site's Availability].