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.
Packet loss is data that left and never arrived. Networks move information in packets, and 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, because each loss triggers a wait-and-resend cycle and, on TCP, causes the protocol to slow itself down assuming congestion. The symptom is a connection that is fast in bursts and then stalls, rather than one that is uniformly slow, which 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 rarely loses packets; a residential connection over consumer broadband, and especially a mobile exit whose last hop is a congested radio link, loses them far more and less predictably. That variability is structural, part of what you accept for the trust those address types carry, and 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, and the fix is usually a better exit or a more tolerant timeout-and-retry policy rather than more concurrency, which on a lossy path just multiplies the stalls. Distinguishing the three, loss, latency and bandwidth, is what turns it slow into a fixable finding.
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.
Back to the full glossary.