How to Test Packet Loss: Ping-Based Detection and Network Troubleshooting Methods

A webpage that occasionally won't load, a game that suddenly stutters, a remote connection that keeps dropping, or a server that's reachable but never feels quite stable—all of these problems can be related to packet loss.

To determine whether packet loss is the culprit, you can't just check whether a single Ping timed out. It's more important to run a continuous test over a period of time, then combine results from different regions and different ISPs to gauge the scope of the problem. This article starts from practical troubleshooting and explains clearly how to test packet loss, how much packet loss counts as abnormal, and where to continue troubleshooting once packet loss is detected.

1. What Is Packet Loss Rate?

During network communication, data is split into individual packets and transmitted to the target server through routers, ISP networks, and internet backbone lines. Under normal circumstances, the packets sent out should reach the target and receive a response. If some packets fail to arrive during transmission, or the response times out, packet loss occurs.

The packet loss rate can usually be calculated as follows:

Packet loss rate = Number of lost packets ÷ Total number of packets sent × 100%

For example, sending 100 packets in a row:

• 97 successfully received;

• 3 lost;

• the packet loss rate is 3%.

A small amount of occasional packet loss doesn't necessarily cause obvious failures right away, but if packet loss persists, web resource loading, API requests, video calls, game connections, and remote desktop sessions can all be affected. This is especially true for services that require continuous connections, such as games, voice, WebSocket, and real-time trading interfaces—even if average latency isn't high, persistent packet loss can still cause noticeable stuttering.

2. How to Test Packet Loss Rate

For practical network packet loss troubleshooting, the simplest method is Ping.

However, don't just Ping a few times during testing. Sending too few packets makes it hard to determine whether it's an occasional timeout or genuine persistent packet loss on the network.

1. Testing with the Windows Ping Command

Windows users can open CMD and enter:

ping example.com -n 100

Replace example.com with the domain or server IP you need to test.

-n 100 means sending 100 Ping packets in a row.

After the test finishes, Windows will show statistics similar to the following:

Packets: Sent = 100, Received = 97, Lost = 3
(3% loss)

The 3% loss here is the packet loss rate obtained from this test.

If you simply use:

ping example.com

Windows defaults to a relatively small number of tests, which is only suitable for a quick check of whether the target is reachable—not for determining whether packet loss persists over time.

2. How to Test on Linux and macOS

On Linux or macOS, you can use:

ping -c 100 example.com

This also sends 100 packets in a row.

After the test finishes, you'll see something like:

100 packets transmitted, 97 received, 3% packet loss

Where:

3% packet loss

indicates a packet loss rate of 3% for this test.

If you suspect the network issue is intermittent, you can also increase the number of tests or extend the observation time.

For example, some lines are perfectly fine during the day but start showing packet loss every evening during peak hours—testing for just a dozen seconds or so usually won't reveal the problem.

3. Using Chahu to Test Packet Loss in Different Regions

Local Ping has one obvious limitation: it only reflects the network conditions between the current computer and the target server.

For example, if you test a server from Guangzhou using a China Telecom broadband connection and the result shows:

Packet loss rate: 0%

This only means that the path from Guangzhou Telecom to the target server shows no obvious packet loss—it doesn't prove that Beijing Unicom, Shanghai Mobile, or other regions can access it equally well.

If your website serves users nationwide, you can use Chahu Online Ping:

Enter the domain or server IP to run a test. Chahu's Ping page currently supports testing across China Telecom, China Unicom, China Mobile, as well as Hong Kong, Macau, Taiwan, and overseas regions, and lets you view response times and network quality from different test nodes.

The main value of this testing method isn't to replace local Ping, but to help determine:

Whether packet loss is only happening on your end or whether other regions are experiencing the same problem, such as: you're seeing packet loss but other regions are basically fine; Telecom is fine but some Unicom nodes are consistently abnormal; domestic nodes are fine but overseas nodes show obvious abnormalities; multiple regions and multiple ISPs are experiencing packet loss simultaneously. The troubleshooting direction behind each of these scenarios is completely different.

3. What Packet Loss Rate Is Considered Normal?

The ideal state is, of course: 0% packet loss.

But in real network environments, an occasional timeout doesn't necessarily mean the line has a serious fault. To judge whether packet loss is abnormal, you need to consider duration, frequency, and the type of service.

For practical troubleshooting, you can refer to the following ranges:

4. Why Does Ping Show Packet Loss When the Website Opens Fine?

During testing, there's another easily misjudged situation: the website is clearly accessible, but Ping keeps timing out, or even shows 100% packet loss. This doesn't necessarily mean the website's network is completely down.

1. The Server May Be Blocking ICMP

Ping typically uses the ICMP protocol for detection.

For security policy or server configuration reasons, some servers, firewalls, and cloud platforms directly block or restrict ICMP requests.

In this case: Ping: 100% packet loss

But accessing the website via HTTP/HTTPS in a browser may still work perfectly fine.

Therefore, you can't directly equate "Ping fails" with "the website is down."

2. Network Devices May Deprioritize Ping Responses

Some routers or network devices prioritize normal business traffic when load is high, deprioritizing ICMP responses.

As a result, you might see:

Request timed out

But actual business traffic isn't experiencing the same level of packet loss.

This is especially relevant during subsequent traceroutes—if only one intermediate hop shows Ping packet loss while later nodes still respond normally, you can't conclude that the fault is at that hop.

3. Too Few Test Samples

Another common problem is too few test samples.

If you only send 4 packets and 1 doesn't respond, the statistics will directly show:

25% packet loss

Which looks very serious.

But if you continue testing 100 times and only that one occasional timeout occurs:

1% packet loss

The two results lead to completely different conclusions.

Therefore, when troubleshooting packet loss, it's best to test dozens or even hundreds of times in a row, rather than concluding there's a line problem the moment you see one Ping timeout.

5. After Detecting Packet Loss, How Do You Determine Where the Problem Is?

What really matters isn't measuring "3% packet loss"—it's continuing to find out: where exactly that 3% of packet loss is occurring. You can start from the network closest to you and work outward layer by layer.

1. Test the Local Gateway First

First, Ping your current router or default gateway.

A common LAN address might be:

192.168.1.1

If even the local gateway shows persistent packet loss, there's no need to suspect the server first.

The problem is more likely in: Wi-Fi signal; network cable; network card; router; switch; local LAN.

For example, if the wireless signal is very weak or interference is severe, packet loss may occur before data even leaves your home or office.

2. If Local Is Fine, Test Public Addresses

If the local gateway shows: 0% packet loss

But obvious packet loss starts appearing from public addresses, you can continue checking your local broadband exit or ISP line.

At this point, you can test several stable public addresses simultaneously for comparison.

If multiple public targets show similar problems while the local gateway is completely fine, the troubleshooting focus should shift from the LAN to the ISP network.

3. Only One Website or Server Shows Packet Loss

There's another common situation: all other websites are fine, but one particular server shows obvious packet loss.

For example:

Server A: 0%
Server B: 0%
Target server: 8%

In this case, there's no need to re-troubleshoot your entire local network.

What's more worth checking:

• The target server's network;

• Its data center;

• Upstream lines;

• Firewall policies;

• Server load;

• The specific route to the target server.

If the target server restricts ICMP, you should also combine actual HTTP and TCP connection results for further judgment, rather than relying solely on Ping.

4. Only Some Regions or ISPs Show Packet Loss

For website servers, this situation is especially common.

For example:

Beijing Telecom: Normal
Shanghai Telecom: Normal
Guangzhou Telecom: Normal

Beijing Unicom: Packet loss
Tianjin Unicom: Packet loss
Hebei Unicom: Packet loss

Mobile nodes: Basically normal

In this case, the problem doesn't look like an overall server failure—it's more worth focusing on the Unicom direction's lines or network interconnection.

This is where the value of multi-node Ping comes in.

Using a multi-node testing tool like Chahu, you can observe results from different regions and ISPs together, rather than judging the entire website's network status based on a single test from the webmaster's own region. Chahu's current online Ping page provides nationwide multi-node latency distribution and distinguishes test results by Telecom, Unicom, Mobile, and different regions.

6. Why Should You Also Look at Latency When Testing Packet Loss Rate?

Packet loss rate and latency are best not viewed separately.

For example, here are three sets of test results:

Line A:

Average latency: 35ms
Packet loss rate: 0%

This kind of network is usually fairly stable.

Line B:

Average latency: 38ms
Packet loss rate: 8%

Although the average latency is only 38ms, which doesn't look slow, 8% packet loss will already seriously affect network stability.

This is why simply seeing "Ping is only 38ms" isn't enough.

Now consider another situation:

Line C:

Average latency: 180ms
Packet loss rate: 0%

No packet loss, but latency is noticeably high.

In this case, the problem may not be line instability, but rather the server being far away, cross-border transmission, a long network path, or route detours.

So during actual testing, you should at least observe simultaneously:

• Whether packet loss occurs;

• Average latency;

• Maximum latency;

• Latency fluctuation;

• Differences in test results across regions.

If the average latency looks normal, but the results jump from 20ms to 300ms and back, with timeouts mixed in, that also shows the network quality is not stable.

7. The Correct Troubleshooting Order After Detecting Packet Loss

If you have confirmed that the network has persistent packet loss, you can narrow down the scope step by step from near to far.

Step 1: Test the Local Gateway

First confirm whether there is packet loss inside the local network.

If it is already abnormal here, check the Wi-Fi, router, Ethernet cable, or switch first.

Step 2: Test Public IP Addresses

Once the local network is normal, test several different public IP addresses.

If multiple public IP addresses show packet loss at the same time, the broadband uplink or the ISP network is more likely to be the suspect.

Step 3: Test the Target Domain or Server IP

If only a specific target has problems, narrow the scope further to the server, data center, and target route.

Step 4: Run Multi-Region Ping Tests

If you find anomalies in your own region, you can continue testing from different regions and ISPs through Chahu.

If only your own location is abnormal, the problem is more likely close to your local network.

If a certain ISP is broadly abnormal, you need to check the corresponding route further.

If multiple regions across the country are abnormal at the same time, the priority for checking the server, data center, or upstream network should be raised.

Step 5: Continue Checking the Routing Path

After confirming persistent packet loss, you can further use Traceroute, MTR, and similar tools to check which routing nodes the network passes through.

The key here is not to see packet loss at a single hop and immediately conclude there is a fault, but to observe whether the packet loss starts at a certain point and continues to affect the nodes after it.

If an intermediate node shows:

50% packet loss

but all the nodes after it show:

0% packet loss

then that intermediate node is very likely just limiting ICMP responses, and it does not prove that half of the real business traffic is being lost there.

Testing for packet loss is not difficult; a single Ping command can give you a result. What really takes time to judge is whether the packet loss occurs in the local network, on the ISP route, or on the server and data center side. So after seeing a packet loss rate of 1%, 3%, or 5%, do not stop at the number itself.

Test the local gateway first, then gradually expand the scope to public networks and the target server; if the website serves users in different regions, compare the detection results of different ISPs using a multi-node tool like Chahu. Only then can you gradually narrow "the network is a bit laggy" down to a specific problem you can continue to handle. For intermittent faults, you should also try to repeat the test during the time period when the problem actually occurs. Only by looking at the test time, region, ISP, and target server together does the packet loss rate number truly have troubleshooting value.

Related Q&A

1. What exactly is the difference between packet loss and jitter? Why does a game still lag when the packet loss rate is 0%?

Packet loss means packets are simply gone, while jitter means latency keeps fluctuating. Many people only stare at the packet loss rate, see 0%, and assume the route is fine, yet the character in the game still stutters. In fact, jumping from 20ms to 200ms and back to 30ms is just as fatal for real-time services. When testing, do not only look at the average value; the maximum latency and latency variation should be checked as well.

2. What do you miss if you only look at the average packet loss rate when testing for packet loss?

You miss "consecutive packet loss." For example, if 3 out of 100 packets are lost, the average packet loss rate is 3%, which sounds tolerable; but if those 3 are lost consecutively, and that happens to coincide with a login request or a payment callback, the user side simply fails. When troubleshooting, besides the total packet loss rate, also pay attention to the maximum consecutive packet loss and the time when the packet loss occurs.

3. If packet loss occurs after using a VPN or proxy, how do you tell whose problem it is?

Ping a public IP address inside the VPN, then ping the same address directly from your local network. If there is no loss locally but loss inside the tunnel, the problem may be on the VPN server side, encryption overhead, MTU, or the tunnel route. If the local network itself already has loss, then the VPN is just taking the blame. In a proxy environment, also note that some nodes actively limit ICMP, so do not conclude the route is bad just because you see a timeout.

4. Testing packet loss on a cloud server with a different port gives completely different results. What is going on?

This is very common. Cloud platform security groups, system firewalls, and DDoS scrubbing policies may all allow only certain ports. ICMP being blocked does not mean the business port is also down; conversely, normal ICMP does not mean port 443 is stable. When troubleshooting, use TCPing or directly stress the business port, and do not judge whether a cloud server has packet loss based only on Ping results.

5: Why does TCP testing seem fine, but UDP protocol packet loss is especially severe?

 This is mainly because the two protocols handle things differently. TCP itself has a retransmission mechanism and sliding window control, so even if a packet is lost in transit, the protocol layer automatically requests a resend, and at the application layer (such as web browsing) you may only feel slight latency rather than noticing "packet loss"; but UDP is a connectionless protocol that only sends and does not receive, with no retransmission mechanism. Once the network link is congested, routers will preferentially drop UDP packets that have no congestion control. Services based on UDP, such as online games, real-time voice (VoIP), and live video, have extremely high requirements for network link quality, and even slight congestion will show very obvious stuttering or frame drops.