Traceroute – Complete Guide to Tracing Network Paths Hop by Hop

When a server is slow or unreachable from some places but fine from others, the question is no longer "is it up?" but "where does the traffic go?". Traceroute answers that by listing the routers between a source and a destination, one hop at a time, with the round-trip time to each. It is how you notice that traffic to a Frankfurt server is going via another continent, or that every trace dies at the same provider edge.

The NetTools.tech Traceroute runs the trace from our server to the host you enter. That gives you an outside view of the path into your network or to a third-party service, independent of your own connection.

What is traceroute?

In simple terms

Traceroute sends packets that are designed to expire after one router, then after two routers, then three, and so on. Each router where a packet expires sends back a short "time exceeded" message, which reveals its address. Put together, those answers form a list of the routers on the way to the destination.

Technical background

Every IP packet carries a Time To Live (TTL) field. Each router that forwards the packet decrements it, and when it reaches zero the router drops the packet and sends an ICMP Time Exceeded message (type 11, defined in RFC 792) back to the sender. Traceroute exploits this: it sends probes with TTL 1, 2, 3 and so on, records who sent the Time Exceeded message for each TTL, and measures the time until it arrived.

When a probe finally reaches the destination, the destination answers differently. With the classic Linux implementation, which sends UDP datagrams to unlikely high ports (starting at 33434), the destination replies with ICMP Port Unreachable, which tells traceroute that the end has been reached. Windows tracert uses ICMP echo requests instead and stops at the Echo Reply.

A few properties of this technique matter for interpretation:

• Only the forward path is discovered. Replies may return over a completely different route, and that return path is part of every RTT you see.
• The reply comes from the router's control plane, which is slower and more rate-limited than its forwarding hardware.
• Routers can answer from the address of the interface facing you, a loopback address or even a private address, so the listed IP does not always match the link you think of.
• With load balancing (ECMP), different probes at the same TTL can take different parallel links.

Why use traceroute?

• Locate where reachability ends. If every probe beyond a certain hop goes unanswered, the problem or the filtering starts around there.
• Spot routing detours. Latency that jumps at one hop and stays high often marks a long-distance link; an unexpected jump can mean traffic is taking a suboptimal path.
• Identify networks on the path. Hostnames from reverse DNS often reveal the provider and sometimes the city of each router.
• Gather evidence for a provider ticket. A trace from a neutral location is a standard attachment when reporting routing problems.

Who should use it?

• Network engineers investigating routing, peering and transit issues.
• System administrators checking how traffic reaches their servers from outside.
• Hosting and support teams who need a trace from a location other than the customer's.
• DevOps engineers verifying that a new CDN, load balancer or cloud region is reached via the expected path.

How traceroute works

On the NetTools.tech server, a trace follows these steps:

1. Validation. The host field accepts a hostname or a public IP address; a pasted URL is reduced to its host. Max hops must be between 1 and 30.
2. Resolution and address check. The hostname is resolved on the server. If any resolved address is private, loopback, link-local or reserved, the request is refused. When a name has IPv4 and IPv6 addresses, IPv4 is used; IPv6-only targets are refused because the probe server has no IPv6 connectivity yet.
3. Fixed command. The system traceroute binary runs by absolute path with a fixed argument list, equivalent to:

traceroute -n -q 3 -w 2 -N 8 -m 30 -- 203.0.113.10

That is: numeric output, 3 probes per hop, wait up to 2 seconds for each reply, up to 8 probes in flight at once, at most the chosen number of hops. Probes are UDP datagrams, the Linux default. The run is stopped after 50 seconds at most.

4. Masking. Any hop address that is not a public IP address is replaced with (private address). These are usually routers inside our own hosting network.
5. Reverse DNS. For each hop, the first public address that answered is looked up in reverse DNS to show a name.
6. Reached or not. The trace counts as having reached the target when any probe was answered from the target's own IP address.
7. Limits. At most 10 traces per target address per 10 minutes across all users, per-client request limits, and no more than 4 probe processes on the server at any time.

The trace starts in Latvia, so the first hops are always our provider's network.

How to use the NetTools.tech traceroute

1. Open Traceroute.
2. Enter a hostname or public IP address in Host, for example example.com.
3. Optionally set Max hops (1–30, default 30). A lower limit finishes faster when you only care about the first part of the path.
4. Select Run Traceroute. A trace usually takes a few seconds, longer when many hops do not reply.
5. Use Copy to take the table into a ticket.

In the web terminal, the same test is /traceroute example.com (alias /tracert), with --max-hops as an option.

Understanding the results

Read a trace from the end backwards. If the destination answers with reasonable times, intermediate hops with asterisks or high times are almost always cosmetic. Only patterns that continue to the destination affect real traffic.

Example: finding where latency increases

A team in Europe reports that an API at api.example.com is slower than usual. The trace below is illustrative; it uses documentation addresses and example names.

Status: Reached 203.0.113.80 in 7 hops.

Reading it: hop 1 is masked because it is inside the NetTools network. Hop 4 never answers but later hops do, so traffic passes through it. Hop 5 has one slow reply, but the next hop is not affected by it, so that is the router replying slowly. The real change is between hop 5 and hop 6: about 85 ms is added and stays until the destination. That is consistent with a long-distance link, for example traffic leaving Europe. Checking the network of 203.0.113.33 with ASN Lookup or IP Lookup shows who operates that segment.

Common use cases

• Confirming that traffic to your server enters through the expected provider or peering point.
• Finding the last responding hop when a host is unreachable from outside.
• Checking whether a CDN or anycast address is served from a nearby location.
• Collecting a trace from a second location for comparison with a customer's tracert output.
• Preparing evidence before contacting an ISP or transit provider.

Troubleshooting

Only asterisks after a certain hop

If every hop after hop N is * up to the limit, the destination or a firewall near it probably drops UDP probes and ICMP replies. That is common for well-protected servers. Check the service with Port Check, and run MTR with the TCP protocol on port 443, which looks like normal web traffic to firewalls.

The trace reaches the hop limit without reaching the target

If every hop answered and the trace ends exactly at the maximum, the route might be longer than the limit you set. Run again with Max hops at 30. Paths longer than 30 hops are unusual and can indicate a routing loop, which shows up as the same addresses repeating.

A hop shows a very high time, the next ones are normal

The router answered slowly because generating ICMP messages is low priority. It is not delaying the traffic that passes through it. Ignore it unless the increase continues to the destination.

The same address appears at several consecutive hops

This can be a routing loop or a device that answers with the same address on multiple interfaces. If the pattern repeats until the hop limit and the destination is never reached, it is likely a loop; report it to the provider that owns the address.

"resolves to a private or reserved address"

The hostname has a DNS record in a non-public range. The tool will not trace towards internal addresses. Verify your public DNS records with DNS Lookup.

"This target has been tested many times"

The target's budget of 10 traces per 10 minutes is used up. Wait and try again.

Common mistakes

• Blaming the first hop with loss or high latency. Only patterns that persist to the destination matter.
• Expecting the trace to match your own path. It starts in Latvia, on our provider's network.
• Reading reverse DNS names as facts. Operators set them, and names with city codes are not always current.
• Assuming the return path is the same. Every RTT includes a return route traceroute cannot see.
• Using traceroute for intermittent problems. Three probes per hop are a snapshot; use MTR for loss over time.

Limitations

• One vantage point: the NetTools.tech server in Latvia. It cannot show the path from your network.
• IPv4 only for now; IPv6 targets are refused.
• UDP probes only. The online traceroute has no ICMP or TCP mode; MTR offers those.
• Three probes per hop and a 2-second wait per probe, so short bursts of loss can be missed or exaggerated.
• Only the first responding address of each hop is shown in the table, so load-balanced hops may hide alternative routers.
• Hops inside our hosting network are masked as (private address).
• Hostnames come from reverse DNS and are only as accurate as the operators keep them.

Security & privacy

• What is sent: only the host and the hop limit. The probes come from the NetTools server, so the routers and the target see our address, not yours.
• Scope: private, loopback, link-local and reserved addresses are refused, both as direct input and after DNS resolution.
• No shell: a fixed binary with a fixed argument list; your input is never interpreted as a command.
• Masking: internal hop addresses of our own network are hidden from the output.
• Rate limits: per-client, per-target and global limits keep the tool from being used to probe networks aggressively.
• What not to enter: nothing sensitive is needed. Avoid internal hostnames in public tools; they would be refused anyway if they resolve to private addresses.

Related tools

• MTR — traceroute plus repeated probing, with loss and latency per hop and ICMP/UDP/TCP modes. Guide: MTR guide.
• Ping — quick reachability and RTT to the destination. Guide: Ping guide.
• Reverse DNS Lookup — checks the PTR name of an individual hop address. Guide: reverse DNS guide.
• ASN Lookup — finds the organization behind an autonomous system seen on the path. Guide: ASN lookup guide.
• Port Check — tests the service when the trace cannot reach the host.
• All diagnostics tools: Network diagnostics guide.

Summary

Traceroute uses increasing TTL values to make each router on a path identify itself, and shows the round-trip time to each hop. The NetTools.tech version traces up to 30 hops from our server in Latvia with three UDP probes per hop, masks internal addresses and adds reverse DNS names. Read it from the destination backwards, and move to MTR when you need loss figures over time.