Reverse Traceroute: How to Test the Return Path

Your traceroute only measures one direction. When the outbound path is clean but the connection still breaks, the evidence usually points at the return path — and here is how to actually measure it.

There is a category of network fault that is close to invisible with ordinary tools, and it is far more common than most people realise.

You run a traceroute. Every hop is clean. Latency is reasonable, no packet loss anywhere. Your ISP runs their own test and finds nothing. And yet calls still drop and downloads still stall.

The reason is that you have only measured half the connection.

What is reverse traceroute?

Reverse traceroute measures the network path from a remote server back toward your device, rather than from your device outward. It is the tool to reach for when your outbound path looks healthy but applications still suffer packet loss, latency spikes or stalled transfers — because those symptoms can be caused entirely by a path your own traceroute never touches.

You can run one from our MTR tool, which supports tracing from our servers back toward your address.

Internet routing is asymmetric by default

People tend to picture a network path as a road: you drive out, you drive back, same road. That is not how the internet works.

The route your packets take to a server is chosen by the routers between you and that server, based on their own routing tables and their operators' commercial arrangements — who peers with whom, who pays whom for transit, and which links each network prefers to fill. The route the replies take back is chosen independently, by a different set of routers, applying their own version of the same logic.

Nothing requires those two paths to match, and very often they do not:

  OUTBOUND — this is what your traceroute measures

    You  ──▶  ISP A  ──▶  Transit X  ──▶  Server


  RETURN — this is measured by nothing you normally run

    You  ◀──  ISP B  ◀──  Transit Y  ◀──  Server

Different networks. Different routers. Different congestion, at different times of day.

This has an immediate practical consequence: a traceroute measures the outbound path only. Every hop it shows you is a router on the way out. The return path is not measured, not displayed, and not implied by anything in the output.

Why the return path is invisible to ordinary tools

Traceroute works by sending packets with a deliberately small time-to-live value. Each router decrements the TTL; when it hits zero, that router discards the packet and sends back an ICMP time-exceeded message. That reply is what reveals the router's address.

Notice what is being identified: the router that received your packet. Increasing the TTL walks you outward hop by hop, mapping the outbound path.

The reply comes back over the return path — but it arrives as a single message. You learn nothing about which routers it crossed on the way. If one of those routers is dropping 5% of traffic, all you see is a slightly lower response rate, indistinguishable from a router that simply rate-limits its own ICMP replies.

That is the blind spot, and it is well understood in network measurement research — the foundational work on reverse traceroute (Katz-Bassett et al., NSDI 2010) exists precisely because a client-side traceroute cannot observe the reverse direction. It is also why an ISP can test in good faith and report no fault: their tests run outbound from their network too.

Reverse traceroute vs traceroute

Neither replaces the other. For a difficult problem you want both, because the comparison is what carries the diagnostic information — not either result on its own.

What a reverse trace shows

Running the measurement from the far end lets you compare directions:

The third row is the whole point of this article. It is the case where everyone's tests look fine and the problem persists, and where a support conversation goes in circles for weeks.

When should you use reverse traceroute?

Reach for it when:

• Your normal traceroute is clean but the application still misbehaves.
• Packet loss appears in one direction only — downloads suffer while uploads are fine, or the reverse.
• Your ISP reports that their outbound tests show no problem.
• Throughput is poor in one direction despite adequate line capacity.
• You suspect a peering or transit issue rather than a local fault.
• You need evidence that the forward and return paths differ.

If none of those describe your situation, start with a normal connection test and an outbound MTR first — the return path is worth checking when the obvious measurements come back clean, not before.

Reading a reverse trace

The output looks like a normal MTR, but the direction of travel is inverted, and that changes how you read it.

Hop 1 is near the server, not near you. The trace begins at our end and works toward your address, so the last hops are your ISP's network and your own connection — the reverse of what you are used to.

Your own address may not appear. Many home routers and firewalls silently drop inbound probes. The trace stopping one or two hops short of you is normal and does not indicate a fault. What matters is whether loss appears before that point.

Apply the same pattern rules as always. Loss that begins at a hop and continues through every subsequent hop is strong evidence of packet loss at or before that point. Loss confined to a single hop that clears at the next one is that router deprioritising replies to its own address while forwarding transit traffic normally — it is not a fault. This distinction holds in both directions, and misreading it is the most common way to send a support ticket down a dead end. The guide to reading MTR results covers it in detail.

Compare the ASNs. If the outbound path crosses one transit provider and the return path crosses another, and the loss is on the return, you now know which network to name. The AS lookup tool will tell you who owns each hop.

What causes one-directional faults

Return-path problems have a handful of common causes.

A congested peering link. Two networks exchange traffic at an interconnect running at capacity during peak hours. Because traffic volumes are usually asymmetric — you download far more than you upload — the congested direction is very often inbound. This is the classic evening-only slowdown.

ISP access or aggregation congestion. Oversubscription within your provider's own network, between the last-mile equipment and its core, can affect one direction disproportionately during peak periods. This tends to show up as loss that appears only in the evenings and only on download.

A routing change at one provider. A transit provider adjusts its announcements and inbound traffic starts taking a longer or more congested route, while your outbound path is untouched.

Asymmetric capacity. Cable, DSL and most fixed-wireless connections have far less upstream than downstream capacity, and the two directions can fail independently.

Middleboxes on one side. A corporate firewall, SASE gateway or DDoS-scrubbing service that only processes traffic in one direction can introduce loss or delay that outbound tests never touch.

Can reverse traceroute prove ISP packet loss?

It can provide strong evidence, but on its own it does not prove which organisation is responsible — and it is worth being precise about that, because overstating the result is how a ticket gets dismissed.

A reverse trace tells you that loss occurs somewhere along the return path, and roughly where it begins. What it does not establish by itself:

• Which network owns the fault. The hop where loss starts may be the boundary between two networks, and the responsible equipment can be one hop further along.
• Whether the loss affects real traffic. ICMP rate limiting can produce loss in a trace that transit traffic never experiences.
• Whether the problem is persistent. A single trace captures one moment.

To turn evidence into something conclusive, do three things: compare the forward and reverse paths so the asymmetry itself is documented, repeat the measurement at different times of day to establish a pattern, and use AS lookup to identify which network operates the affected hops. Three consistent traces across three days naming the same hop is a strong case; one trace is a starting point.

How to use this in a support ticket

This is where a reverse trace earns its keep, because it pre-empts the most common reason a ticket gets closed.

Do not simply paste the raw output. Explain the direction you tested and why it differs from the test the ISP will run by default — that framing is what stops the ticket bouncing back as "no fault found."

Outbound path from my connection is clean through all hops — no loss, stable latency. A reverse trace from an external server back to my address shows loss beginning at hop [N] ([IP], AS[number]) and continuing to my connection. This has been reproduced [N] times across [N] days. Because the evidence points to the inbound path, testing outbound from your equipment will not reproduce it. Please test toward my address specifically, or check inbound capacity at [the interconnect identified above].

That last paragraph saves an enormous amount of time. Without it, the near-certain outcome is that they test outbound, find nothing, and close the ticket. Naming the direction — and explaining why their standard test will come back clean — is what gets it looked at properly.

If you also need to document the loss rate itself, the guide to proving packet loss to your ISP covers what to measure and how to present it.

When both directions are clean

If a full connection test shows loss but both the outbound and reverse traces look healthy, the fault is almost certainly at one of the two ends rather than on the path:

• Wi-Fi, which produces loss that no path trace will ever show because it happens before the first hop.
• Your router, particularly under load, and especially with hardware NAT or QoS features enabled.
• A saturated uplink. A large upload competing with latency-sensitive traffic causes queueing delay and, once buffers fill, packet loss. This is commonly associated with bufferbloat, and it is fixable at your end with proper queue management.
• The device itself — a failing network adapter, a bad cable, an overloaded machine.

The slow internet troubleshooting guide walks through isolating each of those in order, and why a fast speed test can coexist with broken calls explains the measurement gap behind most of these cases.

The general principle is worth internalising even beyond this one tool: when you measure a network, always ask which direction you measured. Half the possible faults live in the half you did not test, and they are disproportionately the ones that go unfixed for months — precisely because everyone keeps testing the same direction and finding nothing.