Traceroute can help you investigate the network path between your computer and a destination. It provides diagnostic evidence; running it does not repair a connection.

What is a traceroute?

A trace sends probes with increasing hop limits and records the replies. The output shows responding network devices and round-trip timings. Some devices do not reply, so the output does not necessarily show every router in the path.

Why use traceroute?

Use it to compare routes, investigate a connectivity problem or provide supporting information to your ISP or hosting support team. A trace cannot by itself establish where application traffic is being lost or delayed.

How to run traceroute on different operating systems

Replace example.com with the hostname or IP address you want to investigate. Do not include https:// or a page path.

Windows

Press Windows + R, enter cmd and press Enter. Run:

tracert example.com

Wait for the trace to complete. Use Ctrl + C if you need to stop it.

Linux and macOS

Open Terminal and run:

traceroute example.com

If the command is missing on Debian or Ubuntu, install the traceroute package using your package manager. Installation requires administrative permission:

sudo apt update
sudo apt install traceroute

These installation commands apply to Debian and Ubuntu, not macOS or every Linux distribution. Different traceroute implementations can use different probe protocols and defaults.

Understanding traceroute output

Each line normally shows the hop number, the responding address or hostname, and timings for the probes. Timings measure a round trip from your computer to that responding device; they are not the delay between adjacent routers.

An asterisk means that a probe did not receive a reply before its timeout. A router can forward traffic while declining or limiting diagnostic replies. A slow response at one hop does not establish a forwarding problem, particularly if later hops respond normally.

Common traceroute issues and fixes

ObservationWhat to check next
One or more intermediate hops time outCheck whether later hops and the destination respond. Missing intermediate replies alone do not prove a fault.
The trace does not reach the destinationCheck normal application connectivity and compare another trace. Filtering, routing or an unavailable destination are possibilities, not confirmed causes.
Slow replies continue through later hopsRepeat the test and compare with the actual service behaviour before attributing a fault to a particular network.

Record the destination, test time, source network and output when contacting support. Review applicable firewall rules with the administrator; disabling the firewall is not a routine diagnostic step.