Trexmi
Network Ready

Traceroute

Trace the network path to a public hostname or IP address and review each responding hop and latency.

Visual route overview Public destination validation IPv4 and IPv6 support Hop-by-hop diagnostics
Traceroute depends on server-side network utilities and intermediate routers may choose not to reply to diagnostic probes.
INPUT Public hostname or IP *
0 chars0 words0 lines

Tool settings

Ctrl / ⌘ + Enter
Traceroute results Hop-by-hop route, destination state, timing, warnings, and raw JSON.
About the tool

What Traceroute does

Traceroute maps the network path toward a public hostname or IP address by sending probes with increasing hop limits. Each router that returns a response can appear as a hop, giving you a practical view of how traffic travels from the Trexmi server toward the destination.

Traceroute is useful for investigating route length, identifying where responses stop, and comparing latency across different parts of a path. Missing hops are normal because routers may forward packets without answering diagnostic probes, so the route should be read as observed evidence rather than a guaranteed map of every device.

Traceroute world route map with numbered network hops
Traceroute shows a hop-by-hop route map with responding nodes and measured latency.

How to use

  1. Enter a public hostname or IP address. The destination must resolve to a public address.
  2. Choose the maximum hop count. This limits how far the route discovery can continue.
  3. Set the timeout per hop. Routers that do not answer within the timeout can appear as missing or timed-out hops.
  4. Select Run Traceroute.
  5. Review the ordered hops, responding addresses, hostnames when available, latency, completion state, and raw JSON.
Built for the task

Why use Traceroute?

Focused controls, predictable output, and a workflow designed around this exact transformation.

01

Hop-by-hop route

Review responding routers in the order observed from the Trexmi server.

02

Public targets only

Private, reserved, loopback, and internal destinations are rejected.

03

Path diagnostics

See where responses appear, disappear, or become slower along the route.

04

Raw data included

Use structured output for deeper troubleshooting and comparison.

Useful answers

Questions about Traceroute

Practical details about input, output, privacy, limits, and the best way to use this tool.

01 Why are some Traceroute hops missing?

Routers can forward traffic without replying to traceroute probes, or they can rate-limit diagnostic responses. A missing hop does not automatically mean that traffic stops there.

02 Why can Traceroute show different routes at different times?

Internet routing can change because of load balancing, provider policy, peering changes, outages, or normal routing updates. A trace is a snapshot from the Trexmi server at one moment.

03 Are private destinations supported?

No. Trexmi restricts the tool to public Internet destinations.

04 Does a slow hop prove that router is the problem?

No. Some routers prioritize forwarding traffic over answering diagnostic probes. Compare later hops and repeated traces before attributing a performance issue to one device.

05 Can Traceroute prove the physical location of a router?

No. Hostnames and IP ownership can provide clues, but traceroute itself does not prove the physical location or owner of a device.

How Traceroute works

Traceroute discovers a path by sending network probes with gradually increasing hop limits. In IPv4, the relevant field is commonly called TTL, while IPv6 uses a Hop Limit. When a packet reaches zero before the destination, an intermediate router can return a diagnostic response. Repeating this process with a larger limit reveals additional responding hops.

For protocol background, the ICMP specification at the RFC Editor describes IPv4 diagnostic messages, while RFC 4443 defines ICMPv6 behavior. The IPv6 specification documents the Hop Limit field used as packets cross routers.

What Traceroute can reveal

A route can show how many responding hops are visible between Trexmi and the target, which addresses or reverse-DNS names answer, and how response timing changes along the path. This makes the tool useful when a remote service is reachable but appears unusually slow or when you want to understand where the observed route changes.

If the route reaches the destination, the trace provides evidence that packets can traverse the observed path. If the route stops early, the cause can be filtering, a non-responsive router, a routing problem, or simply a device that does not send diagnostic responses. The last visible hop is therefore not always the exact point of failure.

How to read hop latency

Latency shown beside a hop is the response time for that diagnostic probe, not necessarily the exact forwarding delay through that router. Network devices often prioritize real traffic over ICMP responses. A single hop can therefore answer slowly while subsequent hops return normal times.

Look for patterns instead of isolated numbers. If latency rises at one hop and remains elevated for every later hop, that can be more meaningful than one slow intermediate response followed by fast downstream responses. Repeating the trace can also help distinguish a persistent pattern from a temporary fluctuation.

Why Traceroute routes change

The Internet is dynamic. Providers can change routing policy, traffic can follow different peers, equal-cost paths can be load balanced, and failures can cause automatic rerouting. For this reason, two traces to the same hostname may not be identical. The route from Trexmi can also differ substantially from the route from your home, office, or mobile network.

When troubleshooting a user-specific problem, compare Traceroute from multiple vantage points if possible. Trexmi gives you the server-side path from its own environment, which is useful as an independent reference rather than a replacement for every local test.

Traceroute and DNS names

Intermediate IP addresses may have PTR records that provide readable hostnames. These names can offer operational clues, such as a provider naming convention or router role, but they are not guaranteed to exist and should not be treated as proof of physical location. Use Reverse DNS Lookup when you want to inspect PTR behavior for a specific address.

Combine Traceroute with other checks

Traceroute is strongest when used with other diagnostics. If a host resolves incorrectly, inspect it with DNS Lookup. If the route looks normal but a service is unavailable, use Port Checker for TCP connectivity or HTTP Status Checker for a web endpoint. Use Ping Test when you want a simpler packet-loss and round-trip latency sample.

Public network safety

Trexmi resolves and validates the destination before tracing. Private, reserved, loopback, and internal addresses are rejected. This restriction keeps the browser-facing tool focused on public Internet diagnostics and prevents it from being used to inspect private infrastructure from the server environment.

When to use Traceroute

Use Traceroute when a public endpoint is reachable but slow, when connectivity differs across networks, when you want to compare the number of visible hops, or when another diagnostic suggests a possible routing issue. It is also useful for documenting a route before and after infrastructure or provider changes.

Traceroute summary

Traceroute provides a visual, hop-by-hop snapshot of the network path from Trexmi to a public destination. Read it together with Ping Test, DNS Lookup, Port Checker, and HTTP Status Checker to separate routing clues from application-level failures.