What this traceroute shows
Traceroute lists the routers your traffic passes through on the way to a host. It works by sending small probe packets with a hop limit (the TTL) that starts at 1 and goes up by one each time. Every router that handles a packet lowers the limit by one, and the router that brings it to zero drops the packet and sends back a short “time exceeded” message that says who it is. Each of those replies is one hop on the map. When a probe finally reaches the destination, the destination answers differently and the trace is complete. HostChecker sends three probes per hop, waits up to 2 seconds for each, and stops after 30 hops or 20 seconds, whichever comes first. What happens first depends on whether you enter a domain name or an IP address.
For a domain name
Enter a domain and HostChecker looks the name up first, then traces the route to the first IPv4 address it finds. If the name has several addresses, only that one is traced, and it can be a different one next time. The tiles say whether the destination answered, how many hops it took, and how many hops stayed silent. The table lists the hops in order. Here is an example, with what each part tells you:
Route
| Hop | Host | IP | Times (ms) |
|---|---|---|---|
| 1 | 10.0.0.1 | 10.0.0.1 | 0.3, 0.2, 0.2 |
| 2 | gw.example-dc.net | 192.0.2.1 | 0.6, 0.7, 0.6 |
| 3 | core1.example-isp.net | 198.51.100.1 | 1.1, 1.2, 1.1 |
| 4 | * | — | * |
| 5 | ae1.chi.example-transit.net | 198.51.100.77 | 12.4, 12.3, 12.5 |
| 6 | edge.example-cdn.net | 203.0.113.1 | 12.9, 13.0, 12.8 |
| 7 | server10.example-hosting.net | 203.0.113.10 | 13.6, 13.5, 13.7 |
Reading the table, column by column:
- Hop is the step number, counted from HostChecker’s server. The last row is the destination.
- Host is the router’s name, found by a reverse DNS lookup of its address. When the router has no name, the address is shown instead, as in hop 1. A name is the network’s own label, so it often hints at the owner and sometimes a city (
chi,nyc,ams), but it is a hint, not proof of where the router is. - IP is the router’s address.
- Times (ms) are the three probes’ round-trip times to that router and back, in milliseconds. Lower is faster.
The first hops are on HostChecker’s own side. Hop 1 here is a private address (the kind that starts 10., 172.16 to 172.31, or 192.168), which is normal. The route starts inside the data center where HostChecker runs, not at your device. A grey row of asterisks, like hop 4, is a router that did not answer, which is explained below.
For an IP address
Enter an IP address and it is traced directly, with no name lookup. The tiles and table are the same. The complete, unedited output is always under “Show complete raw command output”, and it shows two things the table leaves out. Here is an example, with what to look for:
Raw output (under “Show complete raw command output”)
- Several routers on one hop. Hop 3 lists two routers. Big networks spread traffic across several paths, so the three probes for one hop can be answered by different routers. The raw output shows all of them. The route table shows only the first, with all three times, so check the raw output when a hop looks odd.
- The first line shows the address being traced and the limits: 30 hops, 60-byte probes. After a time, you may also see a mark such as
!H(host unreachable),!N(network unreachable), or!X(administratively prohibited, usually a firewall rule). They mean a router answered with that error instead of passing the probe on.
An address can also answer from somewhere you do not expect. Public services such as 8.8.8.8 and 1.1.1.1 use one address for servers in many places (called anycast), so the trace ends at whichever is nearest to HostChecker’s server.
Either way, four things are worth knowing. The trace runs from HostChecker’s server, so it shows that path, not the one from your device. It follows the way there only. The way back can take a different route, which traceroute cannot see. A single run is a snapshot, so run it again before drawing conclusions. And it measures whether probes get through, not whether a site works, which is what Host Check tells you. The trace uses UDP probes over IPv4 only, so IPv6 addresses are not supported, and addresses on private networks, such as 192.168.x.x or 10.x.x.x, are refused.
How to read the result
- Destination: Reached. The destination’s own address answered, so there is a working path from HostChecker to it. It does not say the website on that address works. Run Host Check for that.
- Destination: Not reached. The destination’s address never answered. Amber when some hops did, red when every hop stayed silent. This is often a firewall dropping the probes, not an outage, and many working sites look like this. The tile says where the replies stopped, for example “silent after hop 9”.
- Hops. The number of steps. Paths vary a lot, from a handful of hops to 20 or more, and a longer path is not a worse one. For a trace that did not reach the host, the tile says “traced”, since the count is how far the trace got.
- No reply. Hops that did not answer at all. These are usually harmless: many routers are set not to answer probes, or to answer only some of them, and still pass traffic normally.
- Times. Each time is a round trip to that router and back, not the time for that one link. Look at the pattern. Times that rise gradually along the route are normal, and distance sets a floor, so a crossing of an ocean adds tens of milliseconds at once. A rise that stays high for every hop after it points at that link. A spike at one hop that is gone by the next is almost always a router that was slow to answer the probe while forwarding traffic quickly. Routers often treat answering these probes as low priority, and they are allowed to limit how many replies they send.
The failure you will see most often is a trace that is answered for the first stretch and then goes silent to the end:
Route
| Hop | Host | IP | Times (ms) |
|---|---|---|---|
| 7 | nyc-bb1.example-transit.net | 198.51.100.40 | 17.9, 17.8, 17.7 |
| 8 | ash-bb1.example-transit.net | 198.51.100.52 | 17.7, 17.6, 17.5 |
| 9 | ash-b2.example-transit.net | 198.51.100.61 | 17.4, *, * |
| 10–30 | * (no reply from 21 hops in a row) | — | * |
Three or more silent hops in a row are folded into one grey row, as hops 10 to 30 are here, so a long silence does not push the useful hops off the screen. The raw output keeps every line. Every hop after 9 is silent, all the way to the 30-hop limit. That does not say the host is down. It says nothing past hop 9 answered these probes. Check the host another way, with Ping or Host Check, before deciding it is unreachable.
Common traceroute results and what they mean
The destination is reached and the times rise steadily
The path is healthy from HostChecker’s side. A last hop of a few milliseconds means the host is nearby, and tens or hundreds mean it is far away or on a slow route.
The last hops are asterisks, but the website works
This is the usual case for large sites, cloud providers, and anything behind a firewall or CDN. Linux and macOS send UDP probes by default, and the destination or a firewall in front of it often drops them while it serves web traffic normally. A different probe type can get a different answer, so a host that does not answer here can still reply to the ICMP echo requests that Windows tracert and Ping use. If the website loads, the trace has not found a problem.
The time jumps at one hop and stays high
The delay is added at or just before that hop. A jump of tens or hundreds of milliseconds is often just distance, such as a link under an ocean, and cannot be fixed. If it is not explained by distance, the link may be congested, and the router names at that hop show whose network it is. That is the detail to give the provider when you report it.
One hop is slow, and the hops after it are fast
Ignore it. The router was slow to answer the probe, which has little to do with how fast it passes real traffic. Only a slowdown that carries on through the later hops is a sign of a slow path.
Asterisks in the middle, then the trace carries on
Normal. Those routers do not answer the probes, but they forward them, as the hops after them prove.
The route goes somewhere unexpected
Not necessarily a problem. Internet routes follow agreements between networks, not the shortest line on a map, so a path can go a long way round. It can also change between runs, and the three probes of one hop can take different paths when a network balances traffic across several links.
The name does not resolve
If the result says no IPv4 address was found for the name, the raw output reads Name or service not known and nothing was traced. The name may be misspelled, not registered, or without an IPv4 address record. Check it with DNS Lookup, or with WHOIS if you suspect it has expired.
The trace stopped at the time limit
A trace is cut off after 20 seconds, and the result says so. That is rare, because silent hops are given up on after 2 seconds, but it can happen on a very slow path. Run it again, or trace a nearer address on the route to see where it slows.
Frequently asked questions
What is a traceroute?
A traceroute shows the path that traffic takes from one computer to another across the internet, one router at a time, with the time it takes to reach each. It is the usual next step when a site is slow or unreachable and you want to know where along the way the trouble starts. It works by sending probes with a hop limit that goes up by one each time, so that each router in turn reports back.
How do I run a traceroute?
Type a domain or IP address into the box above and run the check. To trace from your own computer, open Command Prompt or PowerShell and type tracert example.com on Windows, or open Terminal and type traceroute example.com on macOS and Linux. On some Linux systems you need to install it first. Windows sends ICMP echo requests, and macOS and Linux send UDP packets by default, so the two can disagree about the same host.
What does * * * mean in a traceroute?
It means none of the three probes for that hop got an answer within the wait time. The router may be set not to answer, or to answer only a few probes, or a firewall may drop the probes or the replies. A few of these in the middle of a trace are normal. A trace that goes silent and stays silent through to the end usually means a firewall is blocking the probes, not that the host is down.
Why does the traceroute say the destination was not reached?
Because the destination’s own address never answered. The most common reason is a firewall that drops the probes, which many working servers use. The path can also really end there, with a failed link or a host that is off. To tell the cases apart, run Ping and Host Check. If they work, the trace was only blocked.
What is a hop?
A hop is one step between two network devices, usually a router. Each time a packet is passed from one router to the next, that is one hop. The hop count in the result is the number of steps between HostChecker’s server and the host.
What is a good traceroute time?
It depends on distance more than anything. A host in the same city is a few milliseconds away, one on the same continent tens, and one across an ocean often 70 to 300. What to look for is not a number but a pattern: times that rise gradually are normal, and a jump that stays high for every later hop marks where a slow link is. The last hop’s time is roughly what a ping to the same address would show.
Why is the first hop a private address like 10.x.x.x?
Because the trace starts inside HostChecker’s own data center, and the first routers there use private addresses. The same thing happens at the start of a trace from your own computer, where hop 1 is your home router. Private addresses are not routed on the public internet, so they only show up at the start.
Why do my results differ from tracing on my own computer?
Because the starting point is different. This trace runs from HostChecker’s server, so it shows the route from there. Your computer sits behind a different provider and can take a different route, and Windows sends a different kind of probe from the one used here. If you are diagnosing your own connection, run the trace from your device.
Can a traceroute show where a server is located?
Not reliably. Router names often include a city or airport code, and that is a good hint, but it is only the network’s naming habit. An IP address does not carry a location, and a route through one city does not show where the destination sits. Anycast services also answer from the nearest of many sites.
Why is the route different every time?
Networks balance traffic across several links and change routes as links become busy or fail, so two traces a minute apart can differ. When different routers answer the probes of one hop, the raw output lists each of them.
Does the traceroute support IPv6?
No. It accepts domain names and IPv4 addresses only. For a domain it traces the first IPv4 address, so a name that has only an IPv6 address will not resolve here.
What is the difference between ping and traceroute?
Ping asks one question: does this address answer, and how fast? Traceroute asks about every router on the way. Use Ping to see whether a host is up and traceroute to find out where a slow or broken path goes wrong.
Is the traceroute tool free?
Yes. There is no signup, no account, and no limit on how many hosts you trace, apart from a per-visitor rate limit that keeps the service fast for everyone.