Skip to main content
← Network tools

Trace the route hop by hop, and find where it actually breaks

A real system traceroute on macOS and Windows, streamed line by line — plus the part nobody explains: how to read what comes back.

Download SSHive FreeAll network tools
A service is slow or unreachable and nothing on your side explains it. DNS resolves, the server answers locally, your link is clean. What you cannot see is the fifteen or twenty routers between your machine and that host, and that is usually where the answer is. Traceroute is the tool that makes those routers visible. It does not measure your connection to a server; it reconstructs the sequence of hops your packets take to reach it and how long each one takes to answer. Read properly, it tells you whether a problem is yours, your ISP's, a transit provider's or the destination's — the difference between fixing something and opening a ticket with the right party. Read carelessly, it produces more wrong conclusions than any other network tool. A hop full of asterisks looks like a dead router and almost never is. A 300 ms spike in the middle of the path looks alarming when it is usually a router deprioritising your probe while forwarding production traffic without a hiccup. Reading a traceroute is mostly about knowing which lines are measurements and which lines are noise. SSHive runs a real traceroute on macOS (direct-download build) and on Windows: it drives the operating system's own traceroute or tracert with a 30-hop limit and streams the output back verbatim, line by line, as each hop answers. Nothing is reformatted and nothing is invented. Two limits, stated up front. The Mac App Store build of SSHive cannot run traceroute — the App Sandbox does not grant the ICMP raw sockets it requires, so the card is shown disabled rather than faked. And SSHive does not offer traceroute measurement on iPhone or iPad, because iOS gives applications no way to send TTL-limited probes and receive the ICMP errors they trigger. Everything below explains why, what to run instead, and how to read the output you do get.

What SSHive does

The system traceroute, not a re-implementation

On the direct-download macOS build, SSHive runs the operating system's own traceroute binary with a 30-hop limit, launched with fixed arguments rather than an interpreted shell string. You read Apple's output exactly as it comes: hop number, resolved name, IP address and three round-trip times per line. Nothing is reformatted, nothing is synthesised, and no third-party service sits in the middle.

Live output, hop by hop

Hops appear as they answer, streamed line by line into a monospace pane that scrolls itself. A Running badge shows the trace is still in flight, and Stop cancels it immediately — useful when a path stalls on a filtered hop and you already got your answer at hop 6. You never have to sit through a full 30-hop run.

Windows tracert in the same panel

On Windows, SSHive drives tracert with the same 30-hop ceiling and the same streaming pane. Worth knowing when you compare the two: Windows probes with ICMP Echo while macOS probes with UDP datagrams to high ports, so the same destination can legitimately produce different asterisk hops on each system without either being wrong.

Disabled where it cannot work, never faked

The Mac App Store build cannot run traceroute: the App Sandbox does not grant the ICMP raw sockets it needs. SSHive greys the card out and says so, instead of returning an empty pane. SSHive does not measure a real traceroute on iPhone or iPad. The iOS app shows a Traceroute screen, but it is a placeholder that does not send TTL-limited probes and does not measure real hops — treat its output as illustrative only. For an actual path trace from a Mac, take the free direct-download build; from a phone, SSH into a host that has traceroute and run it there.

Trace, then connect

A traceroute usually ends with a question: what is that last responding router, and can I get onto the machine behind it? SSHive is an SSH, SFTP, RDP and VNC client first, so the answer is one tab away. Identify the last good hop, open a session to the jump host or the server, and keep working in the same window.

Free, with no account

The whole network-tools suite — traceroute, ping, DNS lookup, whois, MX lookup and DNSBL checks — sits in the free tier on every platform where it is available. No feature gate on any of them, no ads, no sign-up. SSHive Pro is a one-time purchase, Universal across Mac, iPhone and iPad, and it unlocks session features, not diagnostics.

How to do it, step by step

  1. 1

    Open the network tools

    In the macOS or Windows app, click the network icon in the sidebar, or use the Network tools button on the welcome screen. Either one opens a dedicated tools tab alongside your sessions, so you can trace a route without closing what you are working in.

  2. 2

    Find the Traceroute card

    The tools tab stacks its cards in a fixed order. Traceroute is the second full-width card, below the DNS, interfaces, reputation and MX grid, between Ping and Whois. On the Mac App Store build the card is present but greyed out, with a note explaining the sandbox restriction.

  3. 3

    Enter a destination and start the trace

    Type a hostname or IP address in the field (the placeholder shows e.g. google.com) and press Trace. SSHive hands the target to the system traceroute, which resolves it and starts probing with a TTL of 1, walking outward one hop at a time up to 30.

  4. 4

    Watch the hops arrive

    Lines stream in as each router answers, with a Running badge while the trace is active. A hop showing asterisks is simply not replying inside the timeout, and the trace moves on to the next TTL. Press Stop as soon as you have seen what you needed.

  5. 5

    Act on the last responding hop

    Note the last hop that answered and whether the destination replied at all. From there, open an SSH, RDP or VNC session to the relevant host in the same window, or cross-check the target with the Ping and DNS Lookup cards above.

Reading a traceroute without reaching the wrong conclusion

Each line is one TTL value, not a measurement of your connection. Three probes go out per hop, so you get three round-trip times, and the spread matters as much as the values: 10 / 11 / 10 ms is a stable router, while 10 / 400 / 11 ms is one probe that got queued behind something and rarely deserves investigation. Every RTT includes a return path you never see. Hop 8's reply comes back over whatever route that router has toward you, which is often not the reverse of the outbound path. That is why hop 8 can read 90 ms while hop 9 reads 40 ms. It is not an error and latency did not drop — hop 8's reply simply took a slower way home. Never subtract two adjacent hops and call the result the latency of that link. Asterisks are the most misread output in networking. Three of them mean no ICMP Time Exceeded came back before the timeout (five seconds by default on macOS). There are three ordinary causes: the router does not generate ICMP errors at all, which is normal in ISP and MPLS cores; it rate-limits ICMP error generation, so it drops your probe's reply while forwarding production traffic perfectly; or a firewall blocks the outbound probe (macOS uses UDP from port 33434 upward) or the returning ICMP. In all three cases the data plane is healthy. The test is simple: if any hop after the asterisks answers, the silent hop forwarded your packet correctly. Only asterisks running unbroken to the end of the trace tell you anything. The same discipline applies to spikes. One hop at 300 ms between neighbours at 40 ms is a control-plane artefact — that router deprioritised your probe. What matters is whether an increase persists through every later hop and into the destination. A step that carries to the end is real, though it may be geography rather than a fault: a transatlantic leg costs its 70 to 90 ms and always will. Where a route genuinely breaks is the last hop that answered — the last router with both a route toward your target and a route back to you. If nothing after it replies and the destination never does either, the failure sits at or just past that point. A repeating pattern of the same hops is a routing loop. And !H, !N, !P or !X are definitive where asterisks are not: a router explicitly reporting the host, network or protocol unreachable, or the path administratively filtered.

Frequently asked questions

Why is Traceroute greyed out in the Mac App Store version of SSHive?+
Because traceroute needs ICMP raw sockets and the macOS App Sandbox does not grant them to App Store applications. The network-client entitlement authorises outbound connections, not packet crafting. Rather than return an empty pane, SSHive shows the card disabled with that explanation. Everything else in the tools panel still works in the App Store build — ping (as a TCP-connect probe), DNS lookup, whois, MX lookup and DNSBL checks. For a real traceroute on a Mac, use the free direct-download build.
Can I run a traceroute from an iPhone or iPad?+
Not with SSHive, and the constraint is the platform rather than the app: iOS allows no subprocess spawning, has no setuid binaries and exposes no public API for TTL-limited probes with ICMP error reception. SSHive therefore does not offer traceroute measurement on iPhone or iPad. Its mobile diagnostics are ping (a TCP-connect probe), DNS lookup, whois over TCP port 43, MX lookup and DNSBL checks. When you need a real path trace from a phone, SSH into a machine that has traceroute and run it there.
What do three asterisks mean in a traceroute?+
That none of the three probes for that TTL got an ICMP Time Exceeded back before the timeout. It usually means the router is configured not to emit ICMP errors, is rate-limiting them, or that a firewall dropped the probe or the reply. It rarely means the router is broken. If any later hop answers, that silent router forwarded your packet perfectly. Only asterisks that continue unbroken to the end of the trace are a real signal.
Why does a middle hop show 300 ms when the destination shows 40 ms?+
Because answering your probe is not that router's job. Generating an ICMP Time Exceeded is control-plane work, handled by a CPU that deliberately gives it low priority, while the traffic it forwards stays on the fast path. A spike that does not propagate to the following hops is an artefact, not a fault. Only an increase that persists through every subsequent hop and into the destination reflects something the traffic actually experiences.
The trace stops at hop 12 and never reaches the host. Is the network down?+
Not necessarily. Plenty of destinations behind load balancers, anycast front-ends or cloud firewalls silently drop traceroute probes while serving TCP traffic normally, so a trace that dies near the end while the service works is expected. Confirm with a connectivity test to the real port before concluding anything. If the service is genuinely unreachable, hop 12 is your evidence: it is the last router that had a route to your target and a route back to you, so the break sits at or immediately after it.
Can I change the hop limit or force ICMP probes instead of UDP?+
Not from the SSHive card. The trace runs with a fixed 30-hop ceiling and the platform default probe type — UDP to high ports on macOS, ICMP Echo on Windows — with no protocol, port or probe-count options exposed. Output is raw text, with no parsed hop table and no ASN or geolocation enrichment. If you need those switches on macOS, the underlying binary accepts them directly in Terminal; the card is there for the common case of tracing a host fast without leaving your sessions.
Is traceroute part of SSHive Pro?+
No. Traceroute and the rest of the network-tools suite are free on every platform where they are available, with no feature gate, no ads and no account to create. SSHive Pro is a one-time purchase, Universal across Mac, iPhone and iPad, with no subscription; it unlocks session-side capabilities rather than diagnostics. The free direct-download macOS build is also the one that can run a real traceroute, so the most capable option here costs nothing.

TTL, ICMP errors, and why a sandboxed app cannot do this

An IPv4 header carries an 8-bit TTL field (IPv6 calls it Hop Limit) whose only purpose is to stop packets circulating forever. Every router that forwards a packet decrements it by one; when it reaches zero the router discards the packet and returns an ICMP Time Exceeded message, type 11 code 0, sourced from the interface the packet arrived on. Traceroute turns that failure mode into a measurement. It sends a probe with TTL 1, which dies at the first router and elicits an error naming it. Then TTL 2, then TTL 3, walking outward one hop at a time. Three probes per TTL produce the three timings on each line. How the target is recognised depends on the probe type: the BSD traceroute on macOS sends UDP datagrams to unlikely high ports starting at 33434 and treats an ICMP Port Unreachable (type 3, code 3) as the arrival signal, while Windows tracert sends ICMP Echo Requests and stops on an Echo Reply. That difference is not cosmetic. Firewalls treat UDP probes and ICMP Echo very differently, so the same destination legitimately produces different asterisk hops from a Mac and from a Windows machine — worth checking both before you blame a router. The implementation problem is privilege. Setting a per-packet TTL and, above all, receiving the ICMP errors that come back requires a socket the operating system does not hand to ordinary processes. That is exactly why /usr/sbin/traceroute on macOS is installed setuid root while /sbin/ping is not: ping can use an unprivileged ICMP datagram socket, traceroute cannot. A sandboxed application inherits none of that privilege. The network-client entitlement authorises outbound connections; it does not authorise crafting packets or reading raw ICMP, and the App Sandbox denies raw sockets outright. This is the entire reason traceroute is unavailable in SSHive's Mac App Store build. The card renders disabled with an explicit note rather than failing silently, because a diagnostic that quietly produces nothing is worse than one that tells you why it cannot run. On the direct-download macOS build there is no sandbox, so SSHive spawns the system binary with fixed array arguments — a 30-hop limit and the target, never an interpreted shell string — and pipes its output straight into the panel as it arrives. Windows follows the same path through tracert. iOS and iPadOS are stricter still: no subprocess spawning and no setuid binaries, so the system traceroute cannot be driven the way it is on macOS and Windows. Reimplementing the probe loop on raw BSD sockets is possible but is not something SSHive ships today, so there is no traceroute measurement on iPhone or iPad. The mobile diagnostics are the ones that can be done honestly — a TCP-connect ping, DNS lookup, whois queried directly over TCP port 43, MX lookup and DNSBL checks. When you need a real path trace from a phone, the practical answer is the one SSHive was built for: SSH into a host that has traceroute and run it there. Know the limits before you lean on it. The hop ceiling is fixed at 30, there are no protocol, port or probe-count switches, the output is raw text with no parsed table and no ASN or geolocation enrichment, and the feature depends on the operating system's traceroute binary being installed and on PATH.

Related tools

Ping any host from your Mac, iPhone or iPad

Ten real ICMP echo requests on the Mac DMG, TCP-connect probes everywhere else — with the latency, packet loss and jitter you can actually act on.

Resolve a domain name without opening a terminal

A, AAAA, MX, CNAME, NS and TXT in one query on macOS and Windows — A and AAAA on iPhone and iPad. Free on every platform, no ads, no account.

Look up who owns a domain, from your Mac or your iPhone

SSHive opens the TCP connection to the whois server on port 43 itself — no web API in the middle, no third party logging what you look up.