How to Use the ping Command to Test Network Connectivity in Linux

The First Step in Network Troubleshooting

When a web server goes down, an API endpoint stops responding, or you suddenly cannot connect to the internet, you need a way to determine where the breakdown is occurring. Is your local router broken? Is your ISP experiencing an outage? Or is the remote server completely offline?

In the Linux terminal, the ping command is the universally accepted first step for diagnosing network issues. It works by sending small data packets (ICMP Echo Requests) to a specific IP address or domain name and waiting for those packets to bounce back (ICMP Echo Replies). By measuring if the packets return and how long they take to travel, you can instantly determine if a machine is alive and how stable the connection between you and that machine is.

Basic Usage: Pinging a Domain or IP

The syntax for the ping command is incredibly simple. You simply type ping followed by a domain name or an IP address.

ping google.com

When you run this command in a Linux terminal, it will begin outputting lines of text continuously. Each line represents a single packet of data successfully returning to your computer.

The output will look something like this:

64 bytes from maa03s35-in-f14.1e100.net (142.250.192.46): icmp_seq=1 ttl=117 time=14.2 ms
64 bytes from maa03s35-in-f14.1e100.net (142.250.192.46): icmp_seq=2 ttl=117 time=14.5 ms
64 bytes from maa03s35-in-f14.1e100.net (142.250.192.46): icmp_seq=3 ttl=117 time=14.1 ms

How to Stop the Ping Command

Unlike on Windows (where ping automatically stops after sending four packets), the Linux version of ping will run forever by default until you manually terminate it.

To stop the command and view the final summary, you must press:

Ctrl + C

Once stopped, Linux will print a statistical summary showing how many packets were transmitted, how many were received, the percentage of packet loss, and the minimum, average, and maximum response times.

Advanced Flags and Parameters

While the basic command is useful, system administrators rely on specific flags to modify how ping behaves for more advanced diagnostics.

1. Limit the Number of Pings (-c)

If you are writing a bash script or simply do not want to manually press Ctrl + C, you can tell the command to automatically stop after a specific “count” of packets.

ping -c 4 google.com

This will send exactly four packets and then terminate, mimicking the default behaviour of Windows.

2. Change the Time Interval (-i)

By default, ping sends one packet every 1 second. You can speed this up or slow it down using the interval flag. To send a packet every 5 seconds (useful for long-term background monitoring without flooding the network):

ping -i 5 google.com

Note: If you want to send packets faster than 0.2 seconds (a “flood ping”), you must run the command as the root user using sudo.

3. Only Show the Final Summary (-q)

If you are testing a connection and do not care about the individual line-by-line output of every single packet, you can use the “quiet” flag. It will run silently in the background until you press Ctrl + C (or until the -c count finishes), at which point it will only print the final statistics.

ping -c 10 -q google.com

How to Interpret the Results

When you look at the ping output, you are checking for three main things:

1. Is it resolving? If you type ping digitash.com and immediately receive a “Name or service not known” error, the target server isn’t necessarily down; your DNS resolver is broken and cannot convert the name into an IP address. Try pinging a raw IP address (like Google’s public DNS at 8.8.8.8). If that works, your internet is fine, but your DNS is broken.
2. Packet Loss: Look at the final summary. If 100 packets were transmitted but only 95 were received, you have a 5% packet loss. This indicates a highly unstable physical connection (like a bad Wi-Fi signal or a damaged ethernet cable).
3. Time (Latency): The time= value is measured in milliseconds. If you are pinging a server in your own city, it should be under 20ms. If the time wildly fluctuates from 20ms to 500ms to 100ms, you are experiencing “jitter,” which will cause severe lag in real-time applications like video calls or SSH sessions.