Traceroute and MTR

Traceroute shows each hop between you and a host in a single pass. MTR repeats that path over time and reports loss and latency per hop, which makes it the tool you usually paste into a support ticket when something feels slow or unreachable.

What traceroute and MTR actually measure

Each hop is a router that may or may not answer the probe you send. Stars in the middle often mean that network drops or rate-limits ICMP replies. They do not mean the path is broken if later hops still answer cleanly. Real trouble shows up when loss continues all the way to the destination row, or when latency climbs and stays high on the final hops.

UDP, ICMP, and TCP probes are not the same test. If ICMP is filtered along the path, a TCP probe aimed at the port your site uses is often more honest than a classic ICMP traceroute.

How to run a useful MTR

1. Aim the test at the hostname or IP that is actually failing for you.
2. Prefer MTR over a one-shot traceroute so you can see loss over time, not a single snapshot.
3. Read the destination row first. Loss that appears mid-path and then recovers is often ICMP rate limiting, not a dead link.
4. If you can, run the same test from the other direction as well. Paths are often asymmetric, and one side alone can mislead you.
5. Paste the full text output. Include the hostname you tested, your source address if you know it, and whether you used ICMP or TCP.

mtr -wz example.com

The -w flag waits for reverse DNS so hop names are easier to read. The -z flag adds AS numbers so you can see which network owns each hop. Watch the last row that belongs to your target. If that row shows zero loss while an earlier hop shows high loss, that earlier hop is usually not your outage. If the destination shows sustained loss and the hops stay clean until one specific network, that stretch is where the conversation should start.

What to send us before you open a ticket

Run MTR from your side toward the server, and we can run the matching test from ours. A ping screenshot from café or hotel Wi-Fi is not a path report. Congestion on a last mile and a problem closer to the server can look alike from one noisy network, but two clear MTR pastes usually separate them.

Do this before you reboot a guest or open a DDoS ticket. If only some sources fail while others work, think about filtering, routing policy, or a firewall rule before you reinstall anything. Looking only from inside the server shows what arrived. Looking from both ends shows where the path changed.

Quick reading checklist

• Stars in the middle with a healthy final hop usually mean ignored ICMP, not downtime.
• Loss that recovers on the next hop is often rate limiting on that router.
• Loss that sticks through to the destination is the signal worth investigating.
• TCP on port 443 is a fair next step when ICMP traceroute is all stars and the site still loads for some users.

Nameservers for our services are ns1.logicweb.com and ns2.logicweb.com if you need to confirm you are testing the right host after a DNS change. When you paste MTR output, we will match it from the edge and tell you what we see on our side.