Sr Technical Writer and Team Lead Learning how to use traceroute and MTR to diagnose network issues is a practical step when you need to see which routers sit between your machine and a remote host, whether latency spikes on one hop, and whether loss is real or an artifact of how probes are handled. Traceroute gives a single snapshot of the forward path. MTR combines traceroute-style discovery with repeated probes so you can build loss and round-trip time statistics per hop. This tutorial walks through how TTL-based tracing works, how to install and run traceroute and mtr on common operating systems, how to read annotated output, when paths differ in each direction, and a short triage workflow you can use before you attach logs to a support ticket. For background on interfaces and protocols, see An Introduction to Networking Terminology, Interfaces, and Protocols. A hop is one router or layer-3 device along the path. Your packets cross many hops between a home or office network and a cloud instance. Each hop decrements the IP TTL. When TTL reaches zero, the device is supposed to return an ICMP time exceeded message, which is what classic traceroute uses to discover that hop. Traceroute answers: “Which routers did my packets visit on the way to this destination, and what round-trip time did I see to each?” On many Linux systems the default traceroute from iputils sends UDP probes to high ports and listens for ICMP responses. On macOS, the system traceroute also uses UDP by default. You can often request ICMP echo probes with a flag such as -I on Linux (where supported) when you want behavior closer to ping. The sender starts with a small TTL. The first router drops the packet, returns time exceeded, and reveals its identity. The sender increases TTL step by step until the packet reaches the destination (or the hop limit is hit). For a deeper read on interpreting traces, see the APNIC article How to properly interpret a traceroute or MTR. Most Ubuntu images include traceroute. If it is missing: Install MTR (CLI; includes mtr and an optional TUI). For a smaller CLI-only package you can use mtr-tiny: Use dnf on current releases (older systems may still use yum): traceroute is preinstalled. Install MTR with Homebrew: Homebrew may install mtr as mtr or advise a path; run mtr --version after install to confirm. tracert is built in. Open Command Prompt or PowerShell: pathping combines a route trace with sustained loss sampling: Native MTR is not bundled with Windows; many administrators use maintained third-party builds if they need MTR semantics on Windows clients. Replace example.com with a hostname or IP you are allowed to test. Your addresses and hostnames will differ. This sample shows the usual fields: Increase the maximum hop count (default is often 30; max is 255 on many builds): Change probe count per hop: Skip reverse DNS to run faster: On many Linux systems you can change the packet size (payload length) with a length argument after the host: An asterisk means that probe did not get a usable reply before the timeout. That often indicates an intermediate router that does not respond to traceroute probes, ICMP rate limiting, or a firewall policy. If later hops still appear, user traffic may still work. Treat * as a signal to corroborate with MTR, application tests, and possibly captures. Look for the first hop where latency jumps sharply compared with the previous stable hop, or where loss appears and the last hop also shows loss or the application fails. If only middle hops show loss but the destination is clean in MTR, the middle loss may be control-plane deprioritization rather than a broken forwarding path. MTR (Matt’s traceroute, often packaged as mtr) sends repeated probes and updates statistics per hop. That makes it far better for intermittent loss and jitter than a one-off traceroute. In report mode you typically see: Use MTR when the problem is sporadic, when you need evidence for a provider, or when you want to see whether “bad” middle hops still lead to a healthy final hop. The TUI refreshes until you quit (often q). Send 10 cycles by default (exact flags depend on version; --report is widely available): Increase cycles for a steadier sample: Example report (values are illustrative): In this pattern, latency rises at hop 4 and stays high through the destination, which points to that segment of the path (subject to asymmetric caveats below). If an intermediate hop shows loss but the final hop shows about 0% loss and the service works, the intermediate loss may be because that router deprioritizes or limits probe traffic. If the final hop shows sustained loss that matches application errors, treat it as end-to-end loss. You may see RFC 1918 addresses or terse labels on provider backbones. That is common with MPLS or carrier networks. Focus on where latency or loss changes relative to neighboring hops, not on whether a label is “pretty.” A sharp jump at a single hop suggests congestion, a long geographic segment, or a questionable peering point. Compare across time with MTR and from another network (for example tethered phone versus office Wi-Fi) to see if the jump is stable. If traces stop entirely, check local egress, VPNs, corporate proxies, and security groups or cloud firewalls. On Linux hosts, also confirm that local iptables or nftables rules are not blocking probes. For open listeners and connectivity checks beyond routing, you may use How To Use Netcat to Establish and Test TCP and UDP Connections and How To Use Nmap to Scan for Open Ports on Your VPS. Paths from A to B and B to A can differ. A forward trace that looks clean can coexist with a poor return path for some flows. When you have shell access on both ends (for example your laptop and a Droplet): If the client sits behind carrier-grade NAT and has no stable inbound IP, use a known reflector both sides can reach, or test from a small cloud VM you control with a public address on one leg of the path. Compare both reports side by side and note where latency or loss diverges. Use this sequence when users report “the server feels slow” or “SSH drops.” Plain text is easy to paste into tickets: Run the matching reverse test when possible and label files with direction, time zone, and source IP. The classic traceroute idea is associated with Van Jacobson’s work on Unix network tooling in the late 1980s. MTR appeared later to merge repeated measurements with path discovery, which matches how network operators actually isolate flaky paths. Both tools remain everyday utilities on Linux and BSD servers, including cloud hosts you manage yourself. Run traceroute <destination> (or tracert on Windows) and look for the first hop where latency jumps compared with earlier hops, or where asterisks cluster and your application also fails. Combine that with mtr --report so you are not fooled by a single lucky snapshot. Start with basic reachability (ping or a TCP connection test when ICMP is blocked). Then run mtr --report toward the service IP. If the service is bidirectional, run MTR from both ends or toward a stable public endpoint on each side to account for asymmetric routing. Use interactive mode for live monitoring during an incident. For tickets, use report mode with enough cycles, for example mtr --report --report-cycles 50 <host>. If UDP or ICMP is filtered, explore TCP mode with -T toward an open port when your build supports it. No. Traceroute discovers hops once per run (unless you script repeats). MTR repeatedly probes and summarizes loss and round-trip statistics per hop, which is closer to what you need for intermittent issues. They mean that probe did not receive a reply before the timeout. Common causes include ICMP filtering, rate limits, or a router that does not prioritize traceroute traffic. If the trace continues past the stars and MTR shows a healthy final hop, the path may still be fine for real application traffic. You can use traceroute and MTR to diagnose network issues by mapping hops, comparing round-trip times, and reading loss on the final hop versus middle hops. Add bidirectional tests when asymmetry is likely, then move to captures and socket inspection if routing looks healthy but applications still fail. Spin up a DigitalOcean Droplets and practice forward and reverse mtr between your home connection and the instance. Thanks for learning with the DigitalOcean Community. Check out our offerings for compute, storage, networking, and managed databases. Learn more about our products I help Businesses scale with AI x SEO x (authentic) Content that revives traffic and keeps leads flowing | 3,000,000+ Average monthly readers on Medium | Sr Technical Writer(Team Lead) @ DigitalOcean | Ex-Cloud Consultant @ AMEX | Ex-Site Reliability Engineer(DevOps)@Nutanix This textbox defaults to using Markdown to format your answer. You can type !ref in this text area to quickly search our full set of tutorials, documentation & marketplace offerings and insert the link! Hi, My backup dpn NIC, I mean eth1 is 1000mbps and I had to transfer the 3.5TB of data from the server to the storage. It took me almost 65 hours to do that which is technically wrong. It should be less than 10 hours. The NIC pings ok. Traceroute is ok. What might be the issue with that NIC? The article is awesome! Thank you guys a lot! I have a question. Sometimes, last hop (or last ping’able hop) gives lower ping than previous hops. For example: (from sgp1 node to bulgaria) HOST: **************** Loss% Snt Last Avg Best Wrst StDev As you can see, last hop is 250ms, while sofia pop of GTT.net is 320 ms. So which one is real? Good job on the article. Something to keep in mind is that if there are firewalls / routers dropping UDP or ICMP traceroutes you can often get a more complete result with tcptraceroute. Tracing to the open TCP port on a server or gateway. This comment has been deleted This comment has been deleted Nice article. I have a question. I ran traceroute, and found that there is an increase of latency with one server. I pasted the traceroute below. As you might see one the #9 hop, the latency increses and doesn’t go down. How might i solve this? is there a way i might connect to a vpn and then connect to the webpage in order to diminish this latency? Is there anything i can do from my computer or the clients computer (because the ISP isn’t going to move a finger)? traceroute remote.mate.com traceroute to remote.mate.com (67.139.16.201), 30 hops max, 60 byte packets 1 192.168.4.1 (192.168.4.1) 0.142 ms 0.153 ms 0.174 ms 2 1-245-195-190.cab.prima.net.ar (190.195.245.1) 35.735 ms 35.781 ms 35.783 ms 3 * * * 4 * * * 5 * * * 6 9-165-89-200.fibertel.com.ar (200.89.165.9) 26.189 ms 237-165-89-200.fibertel.com.ar (200.89.165.237) 13.866 ms 9-164-89-200.fibertel.com.ar (200.89.164.9) 14.872 ms 7 250-165-89-200.fibertel.com.ar (200.89.165.250) 22.305 ms 15.703 ms 15.691 ms 8 ge-0-1-2.ar3.eze1.gblx.net (159.63.23.5) 15.620 ms 15.597 ms 15.584 ms 9 po3-20G.ar3.MIA2.gblx.net (67.17.75.66) 139.890 ms po2.ar3.MIA2.gblx.net (67.17.68.234) 136.998 ms 181.555 ms 10 ae5.edge2.miami2.level3.net (4.68.111.121) 184.563 ms 183.950 ms 190.760 ms 11 ae-23-52.car3.Chicago1.Level3.net (4.69.138.37) 224.550 ms 193.841 ms 187.657 ms 12 ae-23-52.car3.Chicago1.Level3.net (4.69.138.37) 178.595 ms 179.081 ms 177.543 ms 13 INTEGRA-TEL.car3.Chicago1.Level3.net (4.71.100.122) 184.659 ms 189.074 ms 183.205 ms 14 tg9-1.ar10.mplsmncd.integra.net (209.63.97.30) 191.308 ms 188.868 ms 193.198 ms 15 * * * 16 * * * 17 * * * 18 * * * 19 * * * 20 * * * 21 * * * 22 * * * 23 * * * 24 * * * 25 * * * 26 * * * 27 * * * 28 * * * 29 * * * 30 * * * This comment has been deleted good very nice this site Please complete your information! Get paid to write technical tutorials and select a tech-focused charity to receive a matching donation. Full documentation for every DigitalOcean product. The Wave has everything you need to know about building a business, from raising funding to marketing your product. Stay up to date by signing up for DigitalOcean’s Infrastructure as a Newsletter. New accounts only. By submitting your email you agree to our Privacy Policy Scale up as you grow — whether you're running one virtual machine or ten thousand. Sign up and get $200 in credit for your first 60 days with DigitalOcean.* *This promotional offer applies to new accounts only.