Traceroute Command: Find Network Problems Fast

When a website feels slow, a game server suddenly develops high latency, or a remote system becomes difficult to reach, knowing that “the internet is slow” does not tell you where the problem actually is. The traceroute command gives you a clearer view by showing the network path traffic takes between your device and a destination.

Instead of testing only whether the destination responds, traceroute reveals the intermediate routing hops along the way. You can see your local router, internet service provider infrastructure, transit networks, and sometimes servers close to the destination, together with round-trip timing information for individual probes.

That makes traceroute one of the most useful basic network troubleshooting tools. It can help you investigate unexpected routing paths, determine roughly where connectivity stops, compare latency between network segments, and collect useful evidence before contacting an ISP, hosting provider, or network administrator.

Traceroute also has limitations that are easy to misunderstand. A slow-looking intermediate hop does not automatically mean that router is slowing your traffic, and a line filled with asterisks does not necessarily mean packets are being dropped. To use traceroute effectively, you need to understand both what it reveals and what it cannot prove.

What Is the Traceroute Command?

The traceroute command is a diagnostic networking utility that discovers the sequence of IP routing hops between your device and another host. That destination could be a website, server, public IP address, cloud service, router, or another reachable network device.

On Windows, the command is normally called tracert. On Linux and macOS systems, it is generally called traceroute. The underlying objective is similar even though the operating systems can use different types of probe packets and provide different command-line options.

A typical result displays numbered hops. Each hop usually represents a Layer 3 routing device that handled the probe on its journey toward the destination. Next to each hop, traceroute may display an IP address, hostname, and several round-trip measurements in milliseconds.

Instead of simply telling you whether a destination is reachable, traceroute helps answer a more useful question: What path is my traffic taking to get there? That additional visibility makes it valuable when a connection works but performs unexpectedly or fails somewhere beyond your local network.

How Does Traceroute Work?

Traceroute works by manipulating a field in IP packets called Time to Live, commonly abbreviated TTL. Despite the name, TTL effectively functions as a hop limit in this context rather than a clock measuring how many seconds a packet can survive.

The first probe is sent with a TTL of 1. When the first router receives that packet, it decreases the TTL. When the value reaches zero, the router discards the packet and normally returns an ICMP Time Exceeded response to the sender.

Traceroute then sends another probe with a TTL of 2. That probe can move through the first router before expiring at the second router. By repeating the process with increasingly larger TTL values, the tool gradually discovers routers farther along the path.

Eventually, a probe reaches the requested destination or the configured maximum hop limit is reached. By examining the response generated at each TTL value, traceroute maps the network route one hop at a time without needing advance knowledge of every router between the source and destination.

What Is TTL in Traceroute?

TTL, or Time to Live, is a field in an IP packet designed to prevent packets from circulating indefinitely when routing problems create loops. Routers decrease the value as packets move through routed network hops.

If a packet starts with TTL 64, for example, each routing hop normally reduces that value. If it eventually reaches zero before arriving at the destination, the packet is discarded instead of continuing forever through the network.

Traceroute deliberately uses very small TTL values to make this normal network behavior useful for diagnostics. TTL 1 reveals the first routing hop, TTL 2 can reveal the second, TTL 3 reaches farther, and the process continues toward the destination.

Without this mechanism, traceroute could not easily discover the network path between two hosts. The tool essentially asks each hop along the route to identify itself by intentionally allowing a probe’s TTL to expire there.

What Is a Hop in Traceroute?

A hop generally represents one Layer 3 routing step a packet takes while traveling toward its destination. Your home router may be the first visible hop, followed by routers belonging to your ISP and then other networks involved in carrying the traffic.

A hop does not necessarily correspond to one physical cable, building, or geographic location. Modern carrier networks can use complicated routing, tunneling, virtualization, and traffic-engineering technologies that make the visible path less straightforward than it appears.

You also should not assume every networking device appears. Layer 2 switches forwarding traffic inside a network segment generally do not become traceroute hops simply because the packet physically passes through them.

The number of hops therefore tells you something about the routed path, not every piece of infrastructure involved in delivering the connection. Two destinations with the same physical distance can have very different hop counts depending on network design and interconnection.

How to Run Traceroute on Windows

Windows uses the command tracert. Open Command Prompt or a compatible terminal and enter tracert followed by the hostname or IP address you want to investigate, such as tracert example.com.

Windows begins tracing the route and normally tests progressively higher TTL values until the destination responds or the maximum hop count is reached. The result displays each discovered hop along with several round-trip measurements.

You can also trace directly to an IP address. This can be useful when you want to remove DNS resolution of the destination name from the initial troubleshooting process or when you already know the exact server address you want to test.

For faster output, Windows supports tracert -d example.com, which prevents intermediate IP addresses from being resolved into hostnames. Avoiding those DNS lookups can make the Windows traceroute command finish faster, especially when reverse DNS responses are slow or unavailable.

How to Run Traceroute on Linux

On Linux, the command is commonly traceroute, followed by the destination hostname or IP address. A basic example is traceroute example.com, which begins displaying network hops between the Linux machine and the target.

Traditional Linux traceroute implementations commonly use UDP probes, which differs from the ICMP Echo behavior normally associated with Windows tracert. Other probe methods may also be available depending on the installed traceroute implementation and command options.

If hostname lookups make output slow or you prefer to see only numerical addresses, traceroute -n example.com commonly disables name resolution. The underlying IP addresses are often more useful than hostnames during detailed network troubleshooting anyway.

Some Linux installations do not include traceroute by default, particularly lightweight server images or containers. In that case, the appropriate package may need to be installed before you can use the Linux traceroute command from the terminal.

How to Run Traceroute on macOS

macOS also provides the traceroute command through Terminal. Open Terminal and enter a destination such as traceroute example.com to begin mapping the route toward that host.

The output looks broadly similar to traceroute on other Unix-like systems. Each numbered line represents another TTL value, followed by responding addresses and round-trip measurements when the intermediate device replies.

You can also use an IP address instead of a domain name when you want to target a specific destination directly. Numerical output can be requested when you want to avoid waiting for reverse DNS lookups associated with each discovered address.

The basic macOS traceroute command is usually enough for ordinary diagnosis. More advanced options can change probe behavior, packet size, wait times, and other settings, but beginners should first learn to interpret standard output accurately before adjusting advanced parameters.

How to Read Traceroute Results

A typical traceroute begins with hop 1 and proceeds numerically toward the destination. The first hop is often your local router or another gateway inside your network, while subsequent hops generally belong to your ISP and upstream networks.

Each hop commonly includes multiple time measurements shown in milliseconds, abbreviated ms. These measurements represent round-trip time for individual traceroute probes traveling to that hop and returning a response.

You may also see both a hostname and IP address. A hostname can sometimes provide clues about the network operator or location, but hostnames are created by network administrators and should not be treated as perfectly reliable descriptions of physical geography.

The most useful approach is to read traceroute as a a sequence rather than obsessing over one line. Look for where meaningful changes begin and whether those changes continue through later hops and the final destination before deciding you have found a network problem.

What Do the Three Time Values Mean?

Traceroute commonly sends multiple probes for each hop. The three values you often see represent the round-trip times of separate probes rather than minimum, average, and maximum latency.

If a hop displays 20 ms, 21 ms, and 19 ms, three probes received responses in roughly the same amount of time. That consistency suggests stable response timing for those particular measurements.

If the values are 20 ms, 85 ms, and 22 ms, one probe took significantly longer to receive a response. This may represent temporary congestion, processing differences, queueing, route variation, or simply the way that router prioritizes diagnostic traffic.

Never diagnose an entire network from one unusual number. Traceroute latency measurements are samples, and routers may treat responses generated for traceroute differently from ordinary traffic they are simply forwarding toward your real destination.

What Does * * * Mean in Traceroute?

One of the most misunderstood traceroute results is * * *. An asterisk means that the particular probe did not receive the expected response within the configured waiting period.

That does not automatically mean the router is down. Network devices can block, filter, deprioritize, or rate-limit the ICMP responses traceroute depends on while continuing to forward ordinary application traffic normally.

Suppose hop 7 shows * * *, but hops 8, 9, 10, and the final destination all respond successfully. Traffic clearly passed beyond hop 7, meaning that device was forwarding packets even though it did not answer your traceroute probes.

Asterisks become more interesting when responses stop at one point and every subsequent hop also disappears, particularly if the destination itself is unreachable. Even then, traceroute alone may not reveal whether filtering, routing, a firewall, or another issue caused the failure.

Does a Slow Hop Mean That Router Is Causing Latency?

Not necessarily. A router’s primary responsibility is forwarding traffic, not responding quickly to traceroute. It may deliberately give low priority to diagnostic ICMP processing while forwarding actual transit packets at full speed.

Imagine hop 6 responds in 180 ms while hop 7 returns to 30 ms. Hop 6 cannot realistically be adding 150 ms of permanent forwarding latency if packets reach hop 7 and return significantly faster.

A more meaningful pattern appears when latency increases at one hop and remains similarly elevated through every later hop, including the final destination. That can suggest that the network segment before or around that point contributed additional path latency.

Even this is not absolute proof. Different return paths, traffic engineering, load balancing, and response policies complicate interpretation. Use ping, repeated traceroutes, application measurements, and network context before concluding that a particular router is responsible.

Can Traceroute Detect Packet Loss?

Traceroute can show missing probe responses, but that is not the same thing as conclusively measuring end-to-end packet loss. Routers may intentionally ignore some diagnostic probes without dropping ordinary transit packets.

If an intermediate hop responds to only one of three probes but every following hop and the destination responds consistently, you should not claim that the intermediate router is dropping two-thirds of user traffic.

True packet loss becomes more plausible when loss begins at a particular part of the route and similar loss continues through all later hops, especially the destination. Repeated testing can help determine whether that pattern remains consistent.

Tools designed to send repeated measurements over time, including ping and path-analysis utilities such as MTR on supported systems, can provide better evidence when the real goal is identifying persistent packet loss or latency variation rather than simply discovering the route.

Traceroute vs Ping: What’s the Difference?

Ping primarily tests reachability and round-trip response time between your device and a destination. It is useful for answering questions such as whether a server responds and whether end-to-end latency is unusually high.

Traceroute focuses on the path between the two endpoints. It shows a sequence of routing hops so you can investigate where a connection travels and roughly where changes or failures begin.

If ping to a server works but latency is unexpectedly high, traceroute may show that traffic follows a longer-than-expected international route. If ping fails entirely, traceroute may help identify the last part of the path that returns diagnostic responses.

The two tools are therefore complementary. Ping tells you about the endpoint relationship, while traceroute tells you about the route toward that endpoint. Effective troubleshooting often uses both instead of choosing one as universally better.

Traceroute vs MTR: What’s the Difference?

Traceroute normally provides a snapshot of a network path by sending a limited number of probes toward each hop. That is excellent for quickly visualizing routing but less useful for observing performance continuously over a longer period.

MTR, often interpreted as My Traceroute, combines concepts from ping and traceroute. It repeatedly measures the route and can display statistics for individual hops over time.

This makes MTR useful when latency or packet loss is intermittent. A single traceroute might run during a good moment and show nothing unusual, while repeated measurements can reveal that problems appear periodically.

MTR still requires careful interpretation because intermediate devices can deprioritize or filter diagnostic traffic. Repeated statistics provide more evidence, but apparent loss at one hop is meaningful primarily when the effect continues toward later hops or the destination.

Traceroute vs Pathping on Windows

Windows also provides pathping, a diagnostic utility that combines elements of ping and traceroute. It first discovers the path and then collects measurements across the discovered route.

Because pathping observes the route for longer than a basic tracert command, it can provide additional information when you are investigating persistent latency or suspected packet loss.

The trade-off is time. A normal traceroute completes relatively quickly, while pathping deliberately spends longer gathering measurements so its statistics have more context.

For quick troubleshooting, begin with ping and tracert. If the results suggest an unstable route and you need more detailed measurement over time, pathping or another continuous path-monitoring tool can become a useful next step.

How Traceroute Helps Find High Latency

Suppose ping shows that a normally responsive server now has 180 ms latency. Traceroute can help determine whether that increase appears close to your home, inside the ISP, at an interconnection point, or much farther toward the destination.

Start by checking the early hops. If your first gateway already shows unusually high and consistently elevated timing that persists through the rest of the route, the problem may be close to your local network.

If the first several hops remain fast and latency jumps substantially farther away, the connection may be crossing a long-distance link or encountering another part of the provider path where delay increases.

Remember that physical geography creates legitimate latency. Traffic traveling internationally will naturally take longer than traffic traveling across a city. The purpose of traceroute is not achieving zero latency; it is understanding where latency changes and whether that behavior makes sense for the route.

How Traceroute Can Reveal Routing Problems

Internet routing is dynamic. Networks decide how to reach destinations according to routing protocols, policies, interconnection agreements, failures, and available paths. The shortest-looking geographic route is not always the route traffic actually follows.

Traceroute can reveal surprising paths. Traffic between two nearby locations may travel through another city or even another country before returning, creating additional latency because of how providers interconnect.

Comparing traceroutes from different connections can be especially informative. If one ISP reaches the same server in eight hops while another takes a dramatically longer path with much higher end-to-end latency, routing differences may contribute to the user experience.

Traceroute does not explain why a routing policy was chosen, and hop hostnames can be misleading. However, it gives network engineers evidence they can combine with routing tables, BGP information, provider data, and other diagnostics to investigate inefficient or broken paths.

Can Traceroute Find an ISP Problem?

Traceroute can provide clues that a problem may be occurring within your internet service provider’s network, but it does not automatically prove responsibility.

Suppose your local gateway responds normally and the next few ISP hops show stable latency, but all subsequent destinations repeatedly become unreachable after the same provider router. That pattern gives you useful information to investigate further.

Similarly, if latency becomes consistently high within the ISP network and remains elevated at every subsequent hop and final destination across repeated tests, the provider may have congestion, routing, or upstream connectivity worth investigating.

Save multiple traceroute results with dates and times before contacting support. One trace may represent a temporary network condition, while repeated evidence showing the same pattern gives technical support teams much more useful information than simply reporting that “Wi-Fi is slow.”

Can Traceroute Diagnose Wi-Fi Problems?

Traceroute can sometimes show symptoms that begin close to your device, but it is not primarily a Wi-Fi diagnostic tool. Wireless problems occur between your device and access point, often before internet routing becomes the main issue.

If your first-hop latency varies dramatically or packets frequently fail before reaching the gateway, local Wi-Fi interference, weak signal strength, congestion, or device problems may deserve investigation.

Compare results over Wi-Fi and Ethernet when possible. If Ethernet produces stable first-hop and destination latency while Wi-Fi shows large fluctuations, the wireless connection becomes a much stronger suspect.

However, traceroute cannot tell you which Wi-Fi channel is congested, how strong your signal is, or which neighboring access point creates interference. Wireless analyzers, router statistics, signal measurements, and direct wired comparison provide more targeted information.

Can Traceroute Locate a Network Outage?

Traceroute may reveal the last responsive part of a path before communication disappears. This can help narrow the location of an outage, particularly inside networks where you understand the routers and topology.

For example, if internal hops 1 through 5 respond but every trace toward several remote subnets stops after hop 5, engineers can investigate links and routing beyond that point instead of checking every device randomly.

Public internet troubleshooting is more complicated because intermediate networks can suppress traceroute responses. A hop that disappears from output does not necessarily represent the physical point where ordinary traffic stops.

Use traceroute as one piece of outage evidence. Combine it with routing information, monitoring systems, ping tests, application logs, interface statistics, DNS checks, and provider status information before determining the actual failure location.

Why Can Traceroute Show Different Routes Each Time?

Internet paths are not always fixed. Routers can use Equal-Cost Multi-Path routing, traffic engineering, redundancy, or other mechanisms that distribute packets across multiple valid routes.

As a result, separate traceroute probes can occasionally receive responses from different routers at the same hop position. Running the command again may also reveal a slightly different path.

Routes can change for broader reasons too. Network maintenance, outages, congestion, provider policy changes, and BGP updates may move traffic onto alternative paths without users doing anything.

This behavior is not automatically a problem. Redundant paths are an important part of network resilience. Route changes become more interesting when they coincide with higher latency, connectivity failures, severe instability, or application problems that users can actually observe.

Why Do Some Hops Show Private IP Addresses?

Early traceroute hops may display addresses from private IP ranges used inside your local network or ISP infrastructure. These addresses are not directly routable across the public internet.

Your home router commonly uses a private address such as one from the 192.168.x.x range, which is why the first hop often looks different from later public internet addresses.

Providers can also use private or shared addressing inside their own networks. Technologies such as carrier-grade NAT allow ISPs to conserve public IPv4 addresses while serving large numbers of subscribers.

Seeing a private address in traceroute is therefore not automatically suspicious. The address tells you something about network architecture, but it does not by itself indicate a security problem or routing failure.

Why Doesn’t Every Router Appear in Traceroute?

Traceroute relies on routers returning particular responses when probes expire. A device that forwards traffic but chooses not to return those diagnostic messages may remain invisible.

Firewalls and security policies can filter ICMP responses. Routers may also rate-limit them to prevent diagnostic processing from consuming resources better reserved for forwarding production traffic.

Some network technologies can hide internal topology as well. Tunnels, MPLS networks, overlays, and other carrier technologies may cause traceroute to display a simplified path rather than every internal device involved.

Therefore, traceroute is better described as showing the observable Layer 3 path rather than a perfect physical map. Treat missing devices as normal possibilities instead of assuming the tool has discovered every router involved in delivery.

Can Firewalls Block Traceroute?

Yes. Firewalls can block the probe traffic traceroute sends, the ICMP responses required to reveal hops, or both. This is one reason traceroute can fail even while a website or application remains perfectly accessible.

Different traceroute implementations also use different probe types. Windows normally uses ICMP Echo requests, while traditional Unix-like implementations commonly use UDP, and other modes can use TCP.

A firewall may treat these protocols differently. ICMP probes might be blocked while HTTPS traffic on TCP port 443 works normally, creating a traceroute full of timeouts despite a functioning website.

Never assume “traceroute failed” means “the network failed.” First test the actual service you care about. Diagnostic traffic and production application traffic can follow similar paths while being treated differently by security controls.

Can Traceroute Show the Physical Location of a Router?

Not reliably. Router hostnames sometimes contain city abbreviations, airport codes, facility names, or network identifiers, which can provide useful hints about likely geography.

IP geolocation databases may also associate addresses with particular cities or countries. However, registration records, routing infrastructure, provider naming practices, and actual equipment location do not always align precisely.

A router that appears to be located in one city based on its hostname could be elsewhere, and the IP address might be registered at a provider’s headquarters rather than the physical data center.

Use location information as context rather than proof. When exact network geography matters, provider documentation, routing databases, facility information, and direct confirmation from network operators provide stronger evidence than traceroute hostnames alone.

How to Use Traceroute When a Website Is Slow

Begin by confirming that the problem is not limited to one browser or device. Test the website normally, check another site, and use ping where appropriate to understand whether the destination has unusually high end-to-end latency.

Next, run traceroute to the site’s hostname or known server IP. Look at where latency begins increasing and whether that increase continues through later hops all the way to the destination.

Run the test more than once. Internet paths and response timings naturally fluctuate, so repeated results are much more useful than one screenshot captured during an unusual moment.

Finally, remember that many slow website problems are not network-path problems. Slow server processing, overloaded databases, huge JavaScript bundles, third-party scripts, images, DNS, CDN configuration, and application errors can make a site slow even when traceroute looks perfectly healthy.

How to Use Traceroute When a Game Has High Ping

Online games are particularly sensitive to latency because player input needs to reach the game server quickly. Start by identifying the actual game-server address if the provider makes that information available.

Run ping and traceroute while the latency problem is occurring. Compare first-hop timing with later network hops to determine whether delay appears to originate locally or farther across the internet.

If Wi-Fi is being used, repeat the test over Ethernet whenever possible. Wireless interference can create latency spikes that have nothing to do with the route between your ISP and the game provider.

Remember that the address you trace may not always represent the exact gameplay traffic endpoint. Modern games can use multiple server clusters, cloud regions, DDoS protection systems, and different protocols, so traceroute should complement in-game statistics rather than replace them.

How to Troubleshoot With Traceroute Step by Step

Start with the symptom rather than traceroute itself. Determine whether the issue involves complete connectivity failure, slow response, intermittent disconnections, one specific destination, or every internet service.

Test your local gateway and destination with ping where appropriate. If local connectivity is already unstable, investigating hop 15 on the public internet is unlikely to be the best first move.

Run traceroute several times and compare results. Look for persistent patterns, especially changes that begin at one point and continue through later hops rather than isolated intermediate responses.

Then combine the evidence with other tools. DNS lookup, ping, MTR, pathping, application logs, interface statistics, router diagnostics, and direct Ethernet testing can help confirm whether the network path is genuinely responsible for the problem.

Common Traceroute Mistakes to Avoid

The first mistake is assuming every asterisk represents packet loss. Routers frequently suppress diagnostic replies while continuing to forward normal traffic, so intermediate timeouts must be interpreted in context.

The second mistake is blaming the first hop with high latency. If the following hops immediately return to normal timing, that router was likely slow to answer the diagnostic probe rather than slow to forward actual packets.

Another mistake is treating traceroute as an exact geographic map. IP addresses and router hostnames can provide clues, but network tunnels, traffic engineering, and inaccurate naming can make the apparent route misleading.

Finally, avoid treating one traceroute as definitive evidence. Network conditions change continuously, and one short diagnostic run provides only a snapshot. Repeat tests and compare end-to-end behavior before reaching a strong conclusion.

When Traceroute Is Not Enough

Traceroute is excellent for discovering observable network paths, but it cannot diagnose every networking problem. It does not directly explain why a website application returns errors, why a database is slow, or why a wireless channel is congested.

It also provides limited evidence about intermittent problems because a normal traceroute lasts only a short time. Issues that appear for five seconds every hour can easily escape a single diagnostic run.

Encrypted application traffic, load balancers, CDNs, Anycast routing, firewalls, tunnels, and distributed cloud infrastructure can also make the relationship between a traceroute destination and the actual application architecture more complicated.

When the problem remains unclear, combine traceroute with continuous monitoring and application-specific diagnostics. Network professionals rarely rely on one tool alone; they build conclusions from several independent measurements that point toward the same cause.

The Bottom Line: Use Traceroute as a Clue, Not a Verdict

The traceroute command helps you see the observable routing path between your device and a destination. Windows uses tracert, while Linux and macOS commonly use traceroute, with implementation differences in the probes they send.

The tool works by increasing packet TTL values so successive routers return responses as probes expire. The resulting hops and timing measurements can help you investigate routing, latency, connectivity, and possible outage locations.

The most important skill is interpretation. An asterisk does not automatically prove packet loss, a slow intermediate response does not automatically identify a bad router, and a missing hop does not mean traffic stopped there.

Use traceroute alongside ping, MTR, pathping, wired testing, monitoring tools, and application evidence. When several diagnostics tell the same story, you can move from saying “the network is slow” to identifying where the problem most likely begins—which is what makes traceroute such a valuable troubleshooting tool.

Frequently Asked Questions About the Traceroute Command

What does the traceroute command do?

Traceroute displays the observable routing hops between your device and a destination. It also shows round-trip timing for probes, helping you investigate network paths, latency, and connectivity problems.

What is the traceroute command on Windows?

Windows uses tracert rather than traceroute. For example, entering tracert example.com in Command Prompt traces the route toward that destination.

What does * * * mean in traceroute?

Asterisks mean the expected traceroute response timed out. They do not automatically mean the router is down or dropping user traffic because intermediate devices may filter or rate-limit diagnostic responses.

Is traceroute better than ping?

They answer different questions. Ping measures end-to-end reachability and latency, while traceroute reveals the observable route toward the destination. Using both usually provides better troubleshooting information.

Can traceroute find where packet loss occurs?

It can provide clues, but missing responses from an intermediate hop do not prove packet loss. Loss becomes more meaningful when a pattern begins at one point and continues through subsequent hops and the final destination.