Packet loss is the networking problem that keeps masquerading as something else. Video calls freeze. SSH sessions disconnect without warning. File uploads stall and retry. You run a speed test and it reports 100 Mbit — because speed tests measure bandwidth, not whether individual packets are arriving reliably.
Meanwhile 3% of your packets are disappearing somewhere in the network.
What Packet Loss Actually Means
Every data transfer is broken into packets. TCP sends a packet and waits for acknowledgment. If the acknowledgment does not arrive, TCP retransmits. This means data still gets through — but the retransmissions add latency. At 1–2% loss, most applications are fine. At 5%, TCP performance degrades noticeably. At 10%, interactive applications become painful. Video calls and gaming, which use UDP, just lose frames — there is no retransmission.
Measuring It
The global ping check shows packet loss directly. Each timeout in the results is a dropped ICMP packet. If certain regions consistently show loss while others do not, the problem is on a specific network path, not your server.
The MTR tool goes further: it shows loss at each hop in the route, letting you isolate where packets are being dropped rather than just confirming that they are.
The Common Causes
ICMP filtering — the false positive
Firewalls configured to drop or rate-limit ICMP echo requests cause packet loss in ping tests even when the server is serving HTTP traffic perfectly. If the HTTP check succeeds from all regions but ping shows loss, this is probably the explanation. Not a real problem — just a misconfigured firewall.
Congested links
A network link at or near capacity starts dropping packets when the buffer fills. This is called bufferbloat on home routers. On transit networks, it shows up as loss on a specific hop in an MTR trace — usually during peak hours. The loss appears suddenly at that hop and persists through all subsequent hops.
Physical layer problems
Damaged cables, bad connectors, or WiFi interference cause consistent low-level loss. Wired connections with a worn cable drop 1–5% of packets. Dense WiFi environments (2.4 GHz in an apartment building) can drop significantly more during congested hours. If loss disappears when you switch from WiFi to ethernet, the issue is physical.
ISP or BGP routing issues
A link failure or BGP route withdrawal can cause packets to be routed through a much longer path or dropped entirely. Loss from specific regions with clean results from others is a strong signal. MTR from the affected region will show where the path diverges.
DDoS mitigation
Under a volumetric attack, upstream providers sometimes drop traffic at the network border. This affects legitimate traffic along with attack traffic. The HTTP check shows timeouts from most nodes while your server itself might still be responding to traffic that does get through.
How to Diagnose Your Case
- Run a global ping test. Note which regions show loss — is it everywhere or specific locations?
- Run an HTTP check for the same host. If HTTP succeeds where ping fails, the loss is ICMP-specific (firewall). Not a real problem.
- Run MTR from the affected region. Find the first hop where loss appears — everything downstream inherits that loss.
- Compare results at different times. Loss only at peak hours points to congestion. Constant loss points to hardware or configuration.
When to Escalate
Contact your hosting provider or network team when:
- Loss is consistently above 1% from multiple regions.
- MTR shows loss starting on a hop that resolves to your provider's network.
- The problem appeared suddenly with no changes on your end.
Bring the MTR report link from Check-Host when you contact them — it pinpoints exactly which hop is responsible and significantly speeds up diagnosis.