How to Read MTR Results Without Mistaking ICMP Loss for an Outage

Loss reported at one intermediate MTR hop does not by itself prove that the router is dropping your game traffic. Routers can limit or deprioritize replies to diagnostic probes while continuing to forward packets. Examine the final destination, the following hops and the application symptoms during the same time window.

Collect a bounded report during the problem

MTR combines repeated path probing with per-hop response statistics. On a Linux machine with MTR installed, replace the example hostname with the affected service’s hostname or IP. Run it from an affected connection; a test from your server measures a different direction.

mtr --report --report-cycles 100 --no-dns your-server.example

This makes a finite report rather than an indefinitely running capture. Depending on the installation, probe permissions may need to be configured by the administrator. Preserve the report as text with the test’s start time, timezone, source network and target. Share detailed addresses privately with support if they reveal your home or infrastructure addresses.

Interpret the pattern across hops

Illustrative patterns, not measurements of the EnderHost network
Pattern	What it may mean	Next step
One intermediate hop loses replies; later hops respond normally	That hop may limit diagnostic responses	Do not assign forwarding loss to it from this pattern alone
Loss appears at the destination during disconnections	End-to-end impairment or destination probe handling needs investigation	Compare application evidence and another source/measurement
A hop never replies but subsequent hops do	A router may not answer those probes	Continue examining downstream and destination behavior
Latency spikes at one hop but not later ones	Reply handling differs from forwarded traffic	Avoid treating that isolated value as application delay

What can an MTR report not establish?

A single trace does not identify the owner or cause of every delay. Paths can be asymmetric or change over time, and the reply path contributes to a round-trip measurement. Your game’s transport, port and treatment can also differ from the diagnostic probe. A destination that does not answer ICMP is not necessarily an offline application.

Comparing reports is more useful when each includes a clear source, target and observation window. A healthy report taken after the incident ended does not refute the earlier symptom. Keep the original evidence rather than repeatedly replacing it with the latest test.

Compare network evidence with application health

Record whether the symptom is a timeout, disconnect, delayed action or low client FPS.
Check whether nearby and distant users are affected at the same moment.
Check server processing metrics and logs for the same timestamps.
Capture during the problem and during a healthy interval from the same source if possible.
Use a second source to determine whether the problem is specific to one connection or more widely observed.

For Minecraft, healthy TPS and MSPT help separate simulation delay from delivery delay. The existing latency diagnostic guide provides the broader starting checklist.

What should you send to hosting support?

Include service identifier, source/target, exact UTC interval, the application symptom, text reports and whether the issue persists. Say which tests were possible and which were blocked. Do not label a particular transit router as faulty solely from one nonresponding hop.

Use EnderHost’s network and location page when considering regional options. A browser HTTPS latency sample is useful context but is not an ICMP trace or a guarantee of in-game ping. Measure the routes relevant to your players before making a relocation decision.