Traceroute / MTR

Traceroute / MTR shows the path packets take to a host so you can see where latency or filtering begins. Classic traceroute lists hops with numeric IPs and round-trip times; MTR (when available) adds per-hop loss and rolling averages so you get a live-style report without needing a terminal. Configure max hops and probe count to keep tests concise while still revealing routing changes.

Use traceroute to answer questions like: does traffic stay inside the ISP or break out through a VPN/peer? Where does a CDN edge hand off to a transit provider? Which hop starts dropping packets during an incident? Because results are numeric, you can quickly spot private hops, CGNAT, or data-center networks. When MTR isn’t installed, the tool falls back to traceroute automatically and marks the response.

Loss in MTR should be interpreted carefully: loss on early hops that disappears later often indicates ICMP deprioritization, not actual packet loss to the destination. Combine this view with ping/HTTP tests to confirm whether the final hop is healthy. Adjust max hops (up to 30) to avoid extremely long traces while still surfacing middle-mile issues.

Outputs are copyable JSON plus raw text so you can paste them into tickets, postmortems or routing requests. Everything runs server-side with SSRF protections—private/reserved targets are blocked up front. That keeps traces safe while still providing the visibility needed for SRE, NetOps and support teams.

Common workflows: triaging a slowdown by seeing which hop adds >100ms; proving that a regional outage stops before your infrastructure; checking whether a VPN exit really uses the expected ASN; or documenting ISP peering paths for procurement and capacity planning.