DeviceTriage
Troubleshooting guide

How to investigate packet loss

Use repeated HTTPS samples as an initial signal, then confirm the affected route with tools designed for the application or network layer.

Check network stability

Common symptoms

  • Voice or video calls briefly cut out
  • Games teleport, freeze, or disconnect
  • Downloads pause even when average speed looks acceptable

Possible causes

  • Weak or congested Wi-Fi
  • A saturated upload queue or unstable mobile connection
  • Router, cable, modem, or ISP line errors
  • Loss or filtering on one specific internet route

How to diagnose it

  1. Run several Network Tests and note failed HTTPS samples
  2. Compare Ethernet with Wi-Fi from the same device
  3. Pause uploads, backups, VPNs, and other active devices
  4. Use the affected application's own statistics or an OS network tool to confirm protocol-specific loss

Solutions to try

  1. Improve Wi-Fi signal or use Ethernet for a controlled comparison
  2. Replace suspect cables and update router firmware
  3. Limit background uploads that fill the upstream queue
  4. Give the ISP time-stamped wired results if loss continues beyond the local network

The first 10-minute diagnosis

  1. Repeat the network test under the conditions that normally trigger the interruption.
  2. Separate failed HTTPS samples from raw ICMP or application-protocol packet loss.
  3. Compare Ethernet and Wi-Fi on the same device while background uploads are paused.
  4. Use the affected game, call, or streaming application's diagnostics to confirm service-specific loss.

Decision path by result

Loss appears only on Wi-FiInvestigate signal, interference, roaming, power saving, channel use, and access-point placement.
Loss appears on wired and Wi-FiCheck modem/router status, cables, upstream saturation, ISP line evidence, and target route.
Only one application reports lossPrioritize its server, region, protocol, firewall, and route before replacing local hardware.
Short loss appears during heavy uploadReduce upstream load and inspect queue management or bufferbloat.

Platform-specific checks

Browser measurement

DeviceTriage counts an HTTP sample as failed when that request does not complete. It cannot create privileged raw network packets from a normal webpage.

Games and calls

Use in-app network graphs because UDP media or game traffic can behave differently from HTTPS and may include concealment or retransmission behavior.

Home network

Check whether the symptom follows one device, one room, one access point, or all wired clients. That boundary is more useful than repeatedly rebooting everything.

What not to do first

  • Do not label one timeout as a permanent packet-loss rate.
  • Do not assume zero HTTP request loss means every protocol and route is clean.
  • Do not factory-reset network equipment before recording which link and destination fail.

When to move beyond a browser test

  • Give the ISP wired results, modem/ONT status, timestamps, and multiple affected destinations.
  • Escalate to a device or router vendor when loss follows one adapter or port across known-good networks.

Last technical review: 2026-09-01

Frequently asked questions

Does request loss equal ICMP packet loss?

No. DeviceTriage counts failed HTTPS samples. It can reveal instability on this route, but it is not a raw ICMP or game-protocol packet-loss test.

Is zero loss in one run proof that the line is perfect?

No. Intermittent faults may not appear in a short sample. Repeat under the conditions that normally trigger the problem.