# Provide a traceroute with MTR
Source: https://docs.webgee.com/en/servers/how-to-provide-a-traceroute-using-mtr-a-comprehensive-guide



Produce a network diagnostic report for a support ticket. Applies to any
connection problem between you and a WebGee server.

**MTR** combines `traceroute` and `ping`: it maps the route to a destination and
then keeps testing every hop, so it shows *sustained* packet loss and latency
rather than a single snapshot. That is what makes it useful — a plain traceroute
cannot distinguish a momentary blip from a persistent fault.

## Install it [#install-it]

```bash
# Debian / Ubuntu
sudo apt install mtr

# RHEL / AlmaLinux / Rocky
sudo dnf install mtr

# macOS
brew install mtr
```

On Windows, use [WinMTR](https://sourceforge.net/projects/winmtr/).

## Run it [#run-it]

```bash
mtr --report --report-cycles 100 example.com
```

That runs 100 cycles — around a minute and a half — and prints a text report.
Fewer cycles produce noise that is easy to misread.

Replace `example.com` with your server's hostname or IP address.

## Run it in both directions [#run-it-in-both-directions]

<Callout type="warn">
  **This is the part usually missing, and it is often the part that matters.**
  Routing on the internet is asymmetric: the path from you to the server can be
  fine while the path back is broken. A report in one direction only frequently
  shows nothing wrong.

  Run MTR **from your machine to the server**, and **from the server back to your
  own IP address**. Send both.
</Callout>

From the server, find your own address first:

```bash
curl -s https://ifconfig.me
```

Then run MTR from the server toward it.

## Send it as text [#send-it-as-text]

Copy the report as **text**, not a screenshot. Support needs to search it and
compare hop addresses against routing data, neither of which is possible with an
image.

Include:

* Both reports, each labelled with its direction
* Your public IP address
* When the problem started, and whether it is constant or intermittent

## Reading it yourself [#reading-it-yourself]

* **Loss at one middle hop but not at the final one** is usually harmless. Many
  routers deprioritise replying to ping while forwarding traffic normally.
* **Loss that starts at a hop and continues to the end** is real, and the first
  affected hop is where it begins.
* **Loss only at the final hop** is a problem at the destination.

## Related [#related]

* [Network issue troubleshooting guide](/en/servers/network-issue-troubleshooting-guide)
* [Find your support PIN](/en/account-billing/support-pin)