> For the complete documentation index, see [llms.txt](https://docs.ipcheck.ing/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.ipcheck.ing/knowledge-base/network-tests/mtr-test.md). # MTR Test ## What it does **MTR Test** is one of the Advanced Tools. MTR stands for *My Traceroute*: it combines a traceroute (which lists every router along a path) with a ping (which measures each of those routers repeatedly). MyIP runs MTR from **Globalping** probes in the countries you select, all aimed at the IP address you choose. So you see the route *into* your address from several parts of the world at once, with latency and loss at every step. Use it when a connection is slow or unreliable and you want to know **where** along the path the trouble starts. ## How to run it {% stepper %} {% step %} ### Choose the target Turn **Use a stored IP** on to pick an IP MyIP already found for you, or turn it off and type any IP address (for example `1.1.1.1`). {% endstep %} {% step %} ### Choose the regions The left panel is the same region picker used by the [Global Latency Test](/knowledge-base/network-tests/global-latency-test.md). **Suggested regions** is ticked by default; below it every continent lists the countries that currently have an online probe. The limit is **30** countries per run. {% endstep %} {% step %} ### Run it and open a probe Press the play button. Results appear on the right as a list of probes, each showing its country, city, network name and AS number. Click one to open its hop table. The first result opens by itself. {% endstep %} {% endstepper %} ## Reading your results Each row in the table is one **hop** — one router the packets passed through. Row 1 is closest to the probe; the last row is your target. MTR builds differ, so a probe only shows the columns it actually reported. | Column | Meaning | | -------- | ------------------------------------------------------ | | # | Hop number, counting out from the probe | | Host | Hostname of the router, when it has one | | IP | The router's IP address | | ASN | The network (autonomous system) that router belongs to | | Loss | Share of probe packets that router did not answer | | Sent | Packets sent to that hop | | Dropped | Packets with no reply | | Received | Packets answered | | Last | Round-trip time of the most recent packet, in ms | | Avg | Average round-trip time, in ms | | Best | Fastest round-trip time seen | | Worst | Slowest round-trip time seen | | StDev | How much the times varied — high means unstable | | Jitter | Average variation between consecutive packets | A hop marked **No response** answered nothing. That is common and usually harmless: plenty of routers are configured to stay silent. If the raw output could not be parsed into a table, the tool shows the original MTR text instead. ### The classic misreading {% hint style="warning" %} **Loss at a middle hop that disappears further down is not a problem.** Routers treat "reply to this measurement packet" as the lowest-priority job they have. A busy router will ignore some of them while forwarding your real traffic perfectly. That shows up as loss on that one line only. What matters is loss that **continues to the last hop**. If hop 6 shows 40% loss but hops 7, 8 and the final hop show 0%, nothing is wrong at hop 6. {% endhint %} Two more habits worth having: * **Read latency as a growing curve, not as thresholds.** Times rise with distance from the probe. A big jump between two hops usually means a long undersea or intercontinental link — expected, not broken. * **Latency that rises and never comes down** at every later hop points to a congested link right at that jump. Latency that spikes at one hop and returns to normal afterwards is just that router being slow to answer. ### Reading across probes Because the same target is traced from several countries, compare them: * Bad on **one** probe only → the problem is on that probe's regional path. * Bad on **every** probe, at the same last few hops → the problem is close to your target: your ISP, your line, or your router. ### If the test fails *"Test failed, it looks like your IP is not allowed to perform MTR test"* usually means the target blocks this kind of measurement traffic. Many firewalls and cloud servers do so on purpose. ## What to do next * Turn the findings into action → [Why Is My Internet Slow?](/knowledge-base/diagnose/why-is-my-internet-slow.md) * Compare plain round-trip times first → [Global Latency Test](/knowledge-base/network-tests/global-latency-test.md) * Understand loss and jitter → [Latency, Jitter & Packet Loss](/knowledge-base/concepts/latency-jitter-packet-loss.md) * Look up a network you saw in the ASN column → [ASN Info & Upstream Topology](/knowledge-base/lookup-privacy/asn-info.md) --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.ipcheck.ing/knowledge-base/network-tests/mtr-test.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.