How to Use Ping and Port Scanning for Basic Server Diagnostics

When a server isn't responding or a website is down, the first diagnostic step isn't to check application logs or restart services — it's to verify basic network connectivity. Can you reach the server at all? Are the right ports open? Is there packet loss or abnormal latency? Ping and port scanning are the foundational tools that answer these questions in seconds. This guide shows you how to use them effectively, interpret the results, and decide where to investigate next.

Ping: The Simplest Network Diagnostic

Ping sends ICMP Echo Request packets to a target host and measures the time for each Echo Reply. It tells you three things:

1. Is the host reachable? — If you get replies, the target is alive and the network path between you is functional.
2. What's the round-trip latency? — The time in milliseconds for a packet to travel to the target and back.
3. Is there packet loss? — If some packets get replies and others don't, you have an intermittent network problem.

Try it now with the GF.dev Ping Test, which pings from our servers so you can see latency from a different vantage point than your local machine.

Reading Ping Output

A typical ping session looks like this:

$ ping -c 4 example.com
PING example.com (93.184.216.34): 56 data bytes
64 bytes from 93.184.216.34: icmp_seq=0 ttl=56 time=11.632 ms
64 bytes from 93.184.216.34: icmp_seq=1 ttl=56 time=11.726 ms
64 bytes from 93.184.216.34: icmp_seq=2 ttl=56 time=12.152 ms
64 bytes from 93.184.216.34: icmp_seq=3 ttl=56 time=11.448 ms

--- example.com ping statistics ---
4 packets transmitted, 4 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 11.448/11.740/12.152/0.252 ms

Key values to examine:

• time — Round-trip time in milliseconds. Under 50 ms is excellent for same-continent connections. 100–200 ms is typical for intercontinental. Over 300 ms indicates either extreme distance or a routing problem.
• ttl (Time to Live) — Decrements at each network hop. A low TTL (e.g., 40–50) suggests many intermediate routers. A sudden change in TTL across consecutive pings can indicate route flapping.
• packet loss — Any packet loss above 0% in a controlled test indicates a problem. Even 1–2% loss causes noticeable degradation for TCP connections because each lost packet triggers retransmission and backoff.
• stddev (standard deviation) — Measures jitter, or variation in latency. High jitter (relative to the average) suggests congestion or an unstable network path.

When Ping Fails

If ping returns "Request timeout" or "Destination host unreachable," don't immediately panic. Consider these possibilities:

• ICMP is blocked — Many cloud providers (AWS, Azure, GCP) block ICMP by default in their security group rules. The server may be perfectly healthy but configured to ignore ping.
• Firewall filtering — Network firewalls or host-based firewalls (iptables, ufw, Windows Firewall) may drop ICMP packets while allowing TCP traffic on ports 80 and 443.
• DNS resolution failure — If ping can't resolve the hostname, the problem might be DNS rather than connectivity. Use our DNS Lookup tool to verify resolution independently.
• Routing issue — A problem at an intermediate network hop. Use traceroute (Linux/Mac) or tracert (Windows) to identify where packets stop being forwarded.

The takeaway: a failed ping doesn't necessarily mean the server is down. That's why you need port scanning as a complementary diagnostic.

Port Scanning: Verifying Service Availability

While ping tests basic network connectivity, port scanning verifies that specific services are accepting connections. A web server that responds to ping but has port 443 closed isn't going to serve any HTTPS traffic. Use the GF.dev Port Scanner to check which ports are open on your server.

Essential Ports for Web Servers

• Port 80 (HTTP) — Should be open, even if you redirect all traffic to HTTPS. The redirect itself requires port 80 to be accessible.
• Port 443 (HTTPS) — Must be open for any TLS-encrypted traffic. If this port is closed, browsers will display a connection error, not a certificate error.
• Port 22 (SSH) — For remote administration. Should be open to your management IPs only, not the entire internet. If you've locked yourself out, this is the first port to check.
• Port 3306 (MySQL) / 5432 (PostgreSQL) — Database ports should never be open to the public internet. If the Port Scanner shows these as open, you have an urgent security issue.

Port States Explained

When scanning, ports fall into three categories:

• Open — A service is listening and accepting connections. This is what you want for ports 80 and 443.
• Closed — The port is reachable (the host responds) but no service is listening. This means the web server process isn't running or isn't bound to that port.
• Filtered — No response at all. A firewall is dropping packets to this port silently. From a security perspective this is ideal for ports that shouldn't be public, but it can be confusing during troubleshooting because it's indistinguishable from the server being completely offline.

Command-Line Port Scanning

For quick checks from your own machine, you don't need a full port scanner. These commands test individual ports:

# Test if port 443 is open (Linux/Mac)
nc -zv example.com 443

# Using Bash built-in (no extra tools needed)
echo > /dev/tcp/example.com/443 && echo "Port open" || echo "Port closed"

# Scan common ports with nmap
nmap -p 22,80,443,3306,5432,8080 example.com

Combining Ping and Port Scanning: A Diagnostic Workflow

Here's a systematic approach when you suspect a server or site is having issues:

1. Ping the server — Use the GF.dev Ping Test. If it responds, the server is reachable at the network level and you can note the baseline latency.
2. Scan the HTTP/HTTPS ports — Use the Port Scanner on ports 80 and 443. If these are closed, the web server process has likely crashed or been stopped.
3. Check TTFB — If ports are open, run a TTFB test. High TTFB with open ports means the server is receiving connections but processing them slowly — an application-layer issue rather than a network issue.
4. Inspect response headers — Use the HTTP Headers Test to see if the server is responding with errors (5xx status codes) or misconfigured headers.
5. Verify your own connectivity — Use What Is My IP to confirm your public IP address, especially if you're troubleshooting access from behind a VPN or corporate NAT. Sometimes the problem is that your IP has been blocked by the server's firewall.

Common Scenarios and Diagnoses

• Ping works, ports 80/443 closed — Web server process (Nginx, Apache) has stopped. SSH in and restart it: sudo systemctl restart nginx.
• Ping fails, ports filtered — Server may be completely offline, or a network-level firewall is blocking all traffic. Check your cloud provider's console for instance status and security group rules.
• Ping works, ports open, site still down — The server accepts connections but the application is failing. Check application logs, database connectivity, and disk space (df -h).
• High ping latency, normal TTFB from nearby locations — Geographic distance issue. Consider deploying a CDN to serve content from edge locations closer to your users.
• Intermittent packet loss — Network congestion or faulty hardware along the route. Use mtr (a combination of ping and traceroute) to identify the problematic hop.

Security Considerations

Port scanning your own servers is essential maintenance. However, keep these points in mind:

• Only scan servers you own or have explicit permission to scan.
• If the scan reveals unexpected open ports, investigate immediately. An open port you didn't configure could indicate a compromised server.
• Ensure database ports (3306, 5432, 27017) and admin interfaces (8080, 8443, 9090) are never exposed publicly. Use the Port Scanner regularly to verify.
• Review and minimize your server signature exposure — open ports combined with version-leaking headers give attackers a complete picture of your stack.

For a comprehensive approach to server diagnostics beyond network-level checks, see our Web Server Performance Troubleshooting pillar guide, which covers TTFB analysis, header inspection, caching strategies, and monitoring.