Packet loss
When data packets fail to arrive and must be resent, a quiet cause of slow, unreliable proxy connections that latency alone does not reveal.
Updated 22 September 2026 · 5 primary sources
Packet loss is data that left and never arrived. Networks move information in packets. When some go missing, through congestion, a weak radio link or overloaded equipment, the reliable transport underneath has to notice and resend them. That recovery is invisible in the sense that your data still gets through, and expensive in the sense that everything waits while it happens.
Its effect is easy to miss because people watch the wrong number. A connection can show a perfectly good average latency and still be miserable to use if a few percent of packets are dropping. Each loss triggers a wait-and-resend cycle, and on TCP it makes the protocol slow itself down, because it assumes congestion. The symptom is a connection that is fast in bursts and then stalls, rather than one that is uniformly slow. That is why loss is the culprit behind proxies that feel erratic rather than merely distant.
It concentrates in exactly the supply where residential and mobile proxies live. A datacenter exit on wired backbone loses fewer packets and loses them more predictably. A residential connection over consumer broadband, and especially a mobile exit whose last hop is a congested radio link, loses more and with less warning. That variability is structural, part of what you accept for the trust those address types carry. It is why a mobile proxy's throughput wobbles in a way a rack's does not.
For diagnosis the useful move is to measure loss separately rather than folding it into a vague slow. A run of requests that mostly complete quickly but occasionally hang points at loss rather than latency or bandwidth. The fix is usually a better exit, or a more tolerant timeout-and-retry policy. More concurrency is the wrong answer, because on a lossy path it just multiplies the stalls. Distinguishing the three, loss, latency and bandwidth, is what turns it slow into a fixable finding.
Why one lost packet costs so much
TCP treats a missing packet as a message about the network, not as an accident. The standard says it plainly: "loss is an indication of congestion". So the sender does two things at once. It resends the data, and it halves the amount it is willing to have in flight. The specification writes that as ssthresh being set to half the outstanding data.
That is why a small loss rate does such large damage. The window that decides throughput is calculated from the path's loss rate. A connection carrying a steady one percent never gets to use the bandwidth it has. Nothing is broken and nothing reports an error. The transfer simply takes longer, and the cause is invisible to anyone watching an average.
| What you see | Likely cause | What changes it |
|---|---|---|
| Every request equally slow | Latency: the exit is far away | An exit nearer the target |
| Most fast, some stall | Loss: packets are being resent | A better exit, or a tolerant retry |
| Steady but capped | Bandwidth: the pipe is full | More bandwidth, or fewer bytes |
What we measured on our own list
The paragraph above makes a claim, so on 22 September 2026 we tested it. From our own server we pinged 150 datacenter and 150 non-datacenter addresses taken from our own free list, thirty probes each, and counted packets rather than impressions.
The direction held and the wording did not. Non-datacenter addresses lost 6.16 percent of all probes against 4.33 percent for datacenter ones, and they were slower, at a median round trip of 309.7 against 205.7 milliseconds. What the numbers refuse is the word rarely: 56.7 percent of the datacenter hosts that answered lost at least one probe. Cheap servers running open proxies are congested too.
The real difference is consistency rather than perfection. Datacenter addresses were clean, with no loss at all, in 43.3 percent of cases against 29.9 percent, and the worst case on the residential side was far worse, at 73.3 percent of probes lost against 56.7. That is the shape the first paragraphs describe: not a clean path against a dirty one, but a predictable one against a path that is usually fine and occasionally terrible.
| What we counted | Datacenter | Home lines |
|---|---|---|
| Answered at all | 120 of 150 | 144 of 150 |
| Packets lost | 4.33 percent | 6.16 percent |
| Hosts that lost nothing | 43.3 percent | 29.9 percent |
| Worst host | 56.7 percent lost | 73.3 percent lost |
| Median round trip | 205.7 ms | 309.7 ms |
Measuring loss without fooling yourself
Two things in that run would have produced a wrong answer, and both are ordinary mistakes. The first is silence. Thirty of the 150 datacenter addresses answered no ping at all, against six of the home ones, because ignoring pings is a firewall policy rather than a fault. Counting those as total loss would have made datacenter addresses look catastrophic.
The second is too few probes. An earlier run of the same script sent fifteen probes instead of thirty and compared the typical host rather than the packets. It reported the opposite result. With fifteen probes the smallest loss you can see is one packet in fifteen, so a single dropped probe becomes 6.7 percent and the comparison turns into noise. Loss is a rate, so it needs enough packets and it needs counting over the whole sample.
It also matters that this is ICMP. A ping measures what the path does to pings, and hosts under load answer them last. The same caution applies to the gaps in a traceroute, and for the number that decides your work, the honest measurement is the one taken over the connection you will actually use.
How HProxy handles it
Our checker reports the round trip for an address, and the free list carries its uptime record, which is the cheap way to spot an exit that stalls rather than one that is merely distant. For paid work the number worth having is the one measured from the exit you will use to the target you care about.
Frequently asked questions
How does packet loss affect a proxy connection?
Lost packets must be detected and resent, so everything waits during the recovery, and on TCP the protocol also slows itself down assuming congestion. The result is a connection that is quick in bursts and then stalls, rather than uniformly slow. A few percent loss can ruin a connection whose average latency looks perfectly healthy.
Why do residential and mobile proxies have more packet loss?
Because their last hop is a consumer connection rather than wired backbone. Residential broadband and especially mobile radio links drop more packets and do so unpredictably, depending on congestion and signal. That variability is part of what you accept in exchange for the network trust those address types carry, and it is why their throughput is less steady than a datacenter exit's.
How do I tell packet loss from high latency?
Watch the shape of the failures, not the average. High latency makes every request uniformly slow; packet loss makes most requests fast and a few hang or stall while data is resent. A run of requests that mostly complete quickly with occasional long pauses points at loss, which calls for a better exit or a tolerant retry policy rather than more concurrency.
How much packet loss is acceptable?
For anything interactive, under one percent. TCP sizes its window from the loss rate, so a steady one percent already costs throughput you have paid for, and five percent makes a connection feel broken while reporting no error.
Do datacenter proxies really have no packet loss?
No. In our own measurement 56.7 percent of the datacenter addresses that answered lost at least one probe of thirty. They lose less than home lines in total and far more often lose nothing at all, but cheap servers running open proxies are congested too.
Does a ping test measure the loss my traffic will see?
Only roughly. A ping measures what the path does to pings, and a loaded host answers them last, so the figure can look worse than your data's experience. Treat it as a hint and measure over the connection you will really use.
Why did my proxy work yesterday and stall today?
Loss is not a property of an address, it is a property of a path at a moment. Congestion anywhere along the route, or on the exit's own link, changes it within hours, which is why an exit that was clean last night can stall this morning.
Does more concurrency help on a lossy path?
It usually makes things worse. Every extra connection meets the same loss, and each one reacts by slowing itself down, so you multiply the stalls instead of routing around them.
Sources
- RFC 5681: TCP Congestion Control, IETF Draft Standard (M. Allman, V. Paxson, E. Blanton), 2009-09.
- RFC 9293: Transmission Control Protocol (TCP), IETF Internet Standard (W. Eddy, Ed.), 2022-08.
- RFC 6349: Framework for TCP Throughput Testing, IETF Informational (B. Constantine, G. Forget, R. Geib, R. Schrage), 2011-08.
- RFC 3819: Advice for Internet Subnetwork Designers, IETF Best Current Practice (P. Karn, Ed.), 2004-07.
- Thirty probes to each of 300 addresses on our own free list, HProxy measurement, 2026-09-22.
Back to the full glossary.