VPS & Linux
VPS packet loss: how to test it and locate the failing path
Packet loss matters when traffic that should arrive does not, but diagnostic tools can overstate it. The useful investigation proves loss end to end, identifies whether it is inbound or outbound, and correlates it with interface errors, congestion, firewall behavior, or a specific route.
Prove loss at the destination
Run repeated probes long enough to avoid declaring a problem from two packets. If an intermediate hop appears to drop packets but the final destination does not, the hop may simply rate-limit diagnostic replies.
Test the protocol that users actually depend on when practical. ICMP, TCP, and UDP can encounter different policy and queueing.
Inspect guest and interface counters
Check RX/TX drops, errors, overruns, retransmissions, socket pressure, and firewall counters. A saturated application receive queue or host firewall can create local loss symptoms without a provider-network fault.
Look at CPU and softirq pressure during the same interval on busy systems. Network processing can suffer when the guest itself is starved.
Compare directions and networks
A path can be asymmetric. Test from the VPS to the client-side network or a nearby probe as well as toward the VPS. Compare another ISP or region to determine whether the problem follows one route.
Keep timestamps in UTC so provider and application logs can be aligned accurately.
Escalate with continuity evidence
A useful provider report includes source/destination, duration, packet count, final-hop loss, route continuity, interface counters, and whether application retransmissions increased. Avoid conclusions based solely on one MTR screenshot.
- Use final-hop loss as the primary signal.
- Check retransmissions and interface counters.
- Compare both directions where possible.
- Retain exact timestamps for escalation.