Артём Савельев 
MTR и WinMTR: как читать отчёт и отличить реальную потерю пакетов от ICMP-лимита
Хостер просит «пришлите MTR», в отчёте на третьем хопе горит Loss 47%, и кажется, что виноват провайдер. Чаще всего это не потеря, а роутер, который не хочет отвечать на ICMP. Разбираем установку, ключи, колонки и пять типовых картинок отчёта.
MTR — это traceroute и ping в одной утилите: она находит все узлы на пути до цели и непрерывно шлёт пакеты каждому из них, накапливая по каждому хопу процент потерь и статистику задержки. Однократная трассировка показывает маршрут в один момент; MTR показывает, как маршрут ведёт себя во времени. WinMTR — версия с графическим интерфейсом для Windows.
Чем mtr отличается от traceroute, ping и WinMTR
Ping измеряет одну конечную точку, traceroute показывает путь одним проходом, mtr делает и то и другое циклически. Как устроен сам механизм с TTL, разобрано в статье про трассировку маршрута — здесь только про инструмент.
| Инструмент | Что показывает | ОС | Протоколы | Непрерывность |
|---|---|---|---|---|
| mtr | Все хопы + потери и задержки по каждому | Linux, macOS, BSD | ICMP, UDP, TCP, SCTP | Да, цикл каждую секунду |
| WinMTR | То же, в окне с кнопками Start/Stop | Windows | Только ICMP | Да, пока не нажат Stop |
| traceroute / tracert | Список хопов, 3 замера на каждый | Все | UDP (Linux), ICMP (Windows), TCP по ключу | Нет, один проход |
| ping | Потери и RTT только до цели | Все | ICMP | Да, но без пути |
На сентябрь 2026 актуальная версия mtr — 0.96 (репозиторий traviscross/mtr, июль 2025). Проект ведёт историю с 1997 года («Matt's traceroute» Мэтта Кимбалла). Оригинальный WinMTR от Appnor остановился на версии 0.92 в 2011 году; форк WinMTR-Redux (White-Tiger) в 2014-м выпустил 1.00 с IPv6. Новых версий с тех пор нет ни у одного, оба работают на современных Windows; ставить стоит Redux.
Как установить и запустить
mtr есть в репозиториях всех дистрибутивов и в Homebrew; WinMTR ставить не нужно — это один exe-файл. mtr шлёт сырые пакеты, поэтому процессу mtr-packet нужны права: пакет из дистрибутива обычно ставит ему setuid или CAP_NET_RAW; если запуск падает с ошибкой сокета — добавьте sudo.
sudo apt install mtr-tiny # Debian/Ubuntu, без GTK — для серверов sudo dnf install mtr # RHEL / Fedora / Alma / Rocky brew install mtr # macOS; запуск через sudo, setuid не ставится # Windows: WinMTR-Redux — архив с GitHub (White-Tiger/WinMTR), # распаковать, запустить WinMTR.exe. Установщика нет.
Запуск для отчёта хостеру — одна команда. Интерактивный режим без -r удобен для наблюдения, но в тикет нужен именно report:
mtr -rwc 100 example.ru # отчёт, широкие имена, 100 циклов mtr -rwc 100 -n example.ru # без резолва имён: быстрее, однозначнее mtr -rwc 100 -T -P 443 example.ru # TCP SYN на 443 вместо ICMP mtr -s 1000 -r -c 200 example.ru # формат Hetzner: 200 циклов по 1000 байт
Какие ключи mtr нужны на практике
Из полусотни опций в man mtr на практике хватает десятка. Ключи ниже сверены с man-страницей mtr.
| Ключ | Что делает |
|---|---|
| -r / --report | Режим отчёта: отработать заданное число циклов, напечатать таблицу, выйти |
| -c N | Число циклов (пакетов на каждый хоп). По умолчанию 10, для тикета — 100–200 |
| -w / --report-wide | Не обрезать длинные имена хостов в отчёте |
| -n / --no-dns | Только IP-адреса, без обратного резолва; -b / --show-ips — и имя, и IP |
| -T / --tcp | TCP SYN вместо ICMP Echo. Размер пакета игнорируется |
| -u / --udp | UDP-датаграммы вместо ICMP, как у классического traceroute |
| -P порт | Целевой порт для -T, -u или -S. С ICMP не работает; без -P для TCP берётся порт 80 |
| -s байт | Размер пакета вместе с IP- и ICMP-заголовками. Ловит проблемы с MTU |
| -z / --aslookup | Номер автономной системы рядом с каждым хопом — видно, где кончается ваш провайдер |
| --json / --csv / --xml | Машиночитаемый вывод для скриптов. JSON есть с версии 0.87, переписан в 0.94 |
Ключ -T стоит запоминать первым: TCP SYN на порт 443 выглядит для файрволов как начало обычного HTTPS-соединения — вы измеряете тот же путь, которым идут пользователи.
Что означают колонки Loss%, Snt, Last, Avg, Best, Wrst, StDev
Loss% и Avg — две колонки, по которым принимают решение; остальные объясняют, можно ли этим двум верить (Last — RTT последнего пакета, в отчёте почти шум). Главное правило: Loss% на одном хопе сам по себе ничего не значит, смотреть нужно на то, что происходит с потерями после него.
| Колонка | Смысл | Как читать |
|---|---|---|
| Loss% | Доля пакетов, на которые хоп не ответил | Важна только если сохраняется на всех следующих хопах вплоть до цели |
| Snt | Сколько пакетов отправлено | Меньше 100 — статистика ненадёжна: при 10 пакетах один потерянный даёт 10% |
| Avg | Средний RTT | Основная оценка задержки; должна расти к цели монотонно или почти |
| Best | Минимальный RTT | Ближе всего к «физике» пути. Best нормальный, Avg высокий — очереди |
| Wrst | Максимальный RTT | Один выброс — не диагноз; смотрите вместе со StDev |
| StDev | Стандартное отклонение RTT | Джиттер. Большой StDev при нормальном Avg — нестабильный канал, плохо для звонков и игр |
«Нормальной» задержки в абсолютных числах не существует — она определяется расстоянием и числом узлов. Ориентиры ниже — не норматив, а разовый снимок матрицы межточечных задержек Пруфена со страницы /status на 22 сентября 2026 (ICMP между точками мониторинга, не пользовательский трафик):
| Направление из Москвы (MSK-1) | RTT в снимке |
|---|---|
| Санкт-Петербург (SPB-1) | 9,6 мс |
| Минск (MIN-1) | 15,3 мс |
| Новосибирск (NSK-1) | 44,7 мс |
| Испания (ESP-1) | 61,5 мс |
| Владивосток (VLD-1) | 106 мс |
Если ваш Avg до сервера в Москве из Москвы — 90 мс, это не «медленный интернет», это маршрут, который ушёл через другой регион; ключ -z покажет, через чьи автономные системы.
Паттерн 1: потеря на промежуточном хопе, которая не доходит до цели
Если на хопе 3 Loss 47%, а на хопах 4–6 ноль — это не потеря пакетов, а ограничение частоты ICMP-ответов на роутере. Транзитный трафик через этот узел проходит целиком: следующие хопы получили все 100 пакетов, а они физически прошли через третий.
$ mtr -rwc 100 -n 203.0.113.80 # пример отчёта HOST: workstation Loss% Snt Last Avg Best Wrst StDev 1.|-- 192.168.1.1 0.0% 100 0.4 0.5 0.3 2.1 0.2 2.|-- 100.64.12.1 0.0% 100 2.8 3.1 2.4 9.7 0.9 3.|-- 198.51.100.33 47.0% 100 3.5 3.6 3.0 6.2 0.5 4.|-- 198.51.100.65 0.0% 100 4.1 4.4 3.6 11.3 1.0 5.|-- 203.0.113.1 0.0% 100 5.0 5.2 4.4 12.0 1.1 6.|-- 203.0.113.80 0.0% 100 5.3 5.5 4.7 13.8 1.2
Причина описана в RFC 1812 (требования к IP-маршрутизаторам, раздел 4.3.2.8): роутеру следует уметь ограничивать частоту генерации ICMP-сообщений об ошибках, включая Time Exceeded — а именно на это сообщение опирается mtr, чтобы «увидеть» промежуточный хоп. Cloudflare называет то же явление control plane policing: ответы ICMP генерирует управляющий процессор роутера, и он защищён лимитом, тогда как транзит идёт через коммутационную плату и лимиту не подчиняется.
Паттерн 2: потеря начинается на хопе N и сохраняется до цели
Если с хопа 4 потери есть на всех последующих строках, включая последнюю, — это реальная проблема, и она на хопе 4 или на линке перед ним. Все узлы после него не могут одновременно решить не отвечать на одну и ту же долю пакетов; они просто не получили эти пакеты.
$ mtr -rwc 100 -n 203.0.113.80 # пример отчёта HOST: workstation Loss% Snt Last Avg Best Wrst StDev 1.|-- 192.168.1.1 0.0% 100 0.4 0.5 0.3 1.8 0.2 2.|-- 100.64.12.1 0.0% 100 2.9 3.0 2.5 8.4 0.8 3.|-- 198.51.100.33 0.0% 100 36.1 36.8 35.9 41.0 0.9 4.|-- 198.51.100.9 12.0% 100 38.2 41.7 36.9 95.4 10.3 5.|-- 203.0.113.17 11.0% 100 39.0 42.1 37.2 97.8 10.9 6.|-- 203.0.113.80 12.0% 100 39.6 42.9 37.8 99.1 11.4
Обратите внимание на StDev: вместе с потерями на хопе 4 подскочил разброс задержки, а Wrst вырос вдвое — типичная перегрузка линка, очередь на интерфейсе то переполняется, то нет. Величину реальной потери оценивайте по наименьшему проценту среди хвостовых хопов (здесь 11%): бо́льшие значения на отдельных строках — сложение реальной потери с ICMP-лимитом самого узла. Документация Linode (Akamai) формулирует то же правило: при расходящихся цифрах верить более поздним хопам.
Паттерн 3: высокая задержка на одном хопе, дальше нормально
Если Avg на хопе 3 — 200 мс, а на хопе 4 — 41 мс, третий хоп ничего не тормозит: пакеты через него доходят до четвёртого за 41 мс. Высокая цифра — время, за которое управляющий процессор роутера сгенерировал ICMP-ответ, а не задержка транзита.
2.|-- 100.64.12.1 0.0% 100 2.9 3.0 2.5 8.4 0.8 3.|-- 198.51.100.33 0.0% 100 212.4 198.7 40.1 480.3 71.2 4.|-- 198.51.100.9 0.0% 100 41.0 41.3 40.2 47.6 1.1 5.|-- 203.0.113.80 0.0% 100 42.2 42.5 41.0 49.3 1.3
Подсказка в колонке Best: 40,1 мс — когда роутер отвечал без очереди, RTT до него был нормальным. Задержка на транзитном узле становится проблемой, только когда её наследуют все следующие хопы.
Паттерн 4: строка ??? или звёздочки
Хоп с ??? в mtr (или с «No response from host» в WinMTR) не ответил ни разу, но трафик через него идёт — следующие строки заполнены. Это узел, где ICMP Time Exceeded отключён политикой, MPLS-туннель или файрвол на границе сети.
4.|-- 198.51.100.9 0.0% 100 38.0 38.4 37.1 44.2 1.0 5.|-- ??? 100.0 100 0.0 0.0 0.0 0.0 0.0 6.|-- 203.0.113.17 0.0% 100 40.9 41.3 39.8 48.7 1.2 7.|-- 203.0.113.80 0.0% 100 41.5 41.9 40.3 50.1 1.3
Тревожный вариант только один: ??? начинается с некоторого хопа и продолжается до конца отчёта, включая цель. Тогда путь физически обрывается перед первым ???, и это уже паттерн 2 со 100% потерь.
Паттерн 5: потеря 100% на последнем хопе
Если весь путь чист, а сама цель показывает Loss 100%, сервер почти наверняка жив — его файрвол не отвечает на ICMP Echo. Проверяется тем же mtr с -T и портом сервиса.
$ mtr -rwc 50 -n 203.0.113.80 # ICMP: цель молчит 6.|-- 203.0.113.1 0.0% 50 5.0 5.2 4.4 12.0 1.1 7.|-- 203.0.113.80 100.0 50 0.0 0.0 0.0 0.0 0.0 $ mtr -rwc 50 -n -T -P 443 203.0.113.80 # TCP SYN на 443: цель отвечает 6.|-- 203.0.113.1 0.0% 50 5.1 5.3 4.5 11.7 1.0 7.|-- 203.0.113.80 0.0% 50 5.4 5.6 4.8 13.2 1.1
Если и TCP даёт 100% на цели при чистом пути — сервер выключен или отбрасывает всё входящее. Почему хост молчит на ICMP при работающем сайте, разобрано в статье про ping и молчащие серверы.
Сводная таблица: паттерн → вывод → что делать
| Что в отчёте | Вывод | Что делать |
|---|---|---|
| Loss на хопе N, на N+1 и далее — 0% | ICMP-лимит, не проблема | Ничего. В тикет не писать |
| Loss с хопа N сохраняется до цели | Реальная потеря на N или линке перед ним | Отчёт в обе стороны, -z для владельца AS, тикет провайдеру или хостеру |
| Avg высокий на одном хопе, дальше низкий | Приоритет ICMP на роутере | Ничего |
| Avg растёт с хопа N и не падает | Перегрузка или длинный обход после N | Сравнить Best и Avg; -z — не сменился ли транзит |
| ??? в середине, дальше ответы есть | Узел скрыт, трафик идёт | Ничего |
| ??? с хопа N до конца, включая цель | Путь обрывается перед N | Повторить с -T; отчёт от хостера в обратную сторону |
| 100% только на последнем хопе | Файрвол цели режет ICMP | Повторить с -T -P 443; если 0% — всё в порядке |
| Loss 1–3% на всех хопах, включая первый | Проблема на вашей стороне: Wi-Fi, кабель, роутер | Прогнать mtr до 192.168.x.1, сменить кабель |
Зачем нужен обратный MTR
Отчёт из одной точки показывает только маршрут «туда», а пакеты «обратно» почти всегда идут другим путём — каждая сеть выбирает исходящий маршрут независимо. Поэтому потеря с хопа N физически может происходить на обратном пути, которого в вашем отчёте нет: Loss% на хопе — сумма потерь в обе стороны.
Linode (сейчас Akamai) прямо пишет, что поддержка «часто запрашивает MTR как до сервера, так и от него». Hetzner формулирует жёстче: 200 циклов пакетами по 1000 байт, каждая трассировка в обоих направлениях, результат приложить файлом TXT или HTML с сохранённым выравниванием колонок. Просьба хостеру звучит просто: «прошу выполнить mtr -rwc 200 до моего адреса X.X.X.X с сервера». Свой внешний IP укажите явно — за NAT его не видно.
MTR, снятый через час, когда всё уже прошло, покажет чистый путь и ничего не докажет. Если проблема плавающая, оставьте интерактивный mtr или WinMTR работать 20–30 минут во время «плохого» окна: Snt в несколько тысяч сглаживает ICMP-лимиты, и реальные потери в хвосте отчёта становятся очевидны.
WinMTR: как пользоваться и чего в нём нет
В WinMTR один экран: поле Host, кнопки Start/Stop и Options, четыре кнопки экспорта — Copy Text, Copy HTML, Export TEXT, Export HTML. Ввели адрес, нажали Start, дождались Sent хотя бы 100–200, нажали Stop и Export TEXT — этот файл и прикладывают в тикет.
|------------------------------------------------------------------| | WinMTR statistics | | Host - % | Sent | Recv | Best | Avrg | Wrst | Last | |------------------------|------|------|------|------|------|------| | 192.168.1.1 - 0 | 312 | 312 | 0 | 1 | 14 | 1 | | 100.64.12.1 - 0 | 312 | 312 | 2 | 3 | 21 | 3 | | 198.51.100.33 - 38 | 312 | 194 | 3 | 4 | 19 | 3 | | 198.51.100.9 - 0 | 312 | 312 | 36 | 38 | 61 | 37 | | 203.0.113.80 - 0 | 312 | 312 | 38 | 40 | 66 | 39 | |________________________|______|______|______|______|______|______| (пример экспорта)
Колонки те же, что в mtr, только Recv показан явно, а StDev нет. Читается отчёт по тем же пяти паттернам: здесь на третьем хопе 38% при нулевых потерях дальше — ICMP-лимит.
| Возможность | mtr 0.96 | WinMTR-Redux 1.00 |
|---|---|---|
| TCP / UDP / SCTP-зонды | Да, -T / -u / -S с -P | Нет, только ICMP |
| IPv6 | Да | Да (в оригинале 0.92 — нет) |
| StDev / джиттер | Да | Нет |
| Номер AS у хопа | Да, -z | Нет |
| JSON / CSV для скриптов | Да | Нет, только TEXT и HTML |
Отсутствие TCP-режима — главное ограничение: если целевой сервер режет ICMP (паттерн 5), WinMTR покажет 100% на последнем хопе и ничем не поможет. Обход — запустить mtr из WSL: wsl sudo mtr -rwc 100 -T -P 443 example.ru. Штатный tracert в Windows, как и WinMTR, использует только ICMP.
Как следить за потерями постоянно, а не по жалобе
MTR отвечает на вопрос «где теряется» из одной точки и в один момент. Он не скажет, что путь из Новосибирска сломался в три ночи, если вы сидите в Москве. Для этого нужен мониторинг из нескольких регионов: сравнение локаций показывает, что сервер жив, а сломан конкретный маршрут.
В Пруфене за это отвечают два типа проверок: ICMP-пинг отправляет Echo Request и фиксирует ответ и RTT, а проверка порта устанавливает TCP-соединение — аналог mtr -T для серверов, которые на ICMP не отвечают. Обе выполняются из 13 точек мониторинга: 11 в России, а также Минск и Испания. Инцидент открывается по кворуму — когда цель не отвечает из настроенной доли точек, — поэтому сбой маршрута до одной локации не становится ложной тревогой, а виден во вкладке «По локациям».
Пруфен проверяет ping и TCP-порт с интервалом от 2 минут из 13 точек мониторинга и присылает уведомление в Email, Telegram или Макс, когда хост перестал отвечать; если ресурс так и не поднялся, подключается голосовой звонок. История по каждой локации показывает, из какого региона путь потерялся, — с этим уже можно идти к хостеру и снимать MTR с нужной стороны. Бесплатный план — 5 проверок.
Частые вопросы
Почему хостер просит MTR, а не traceroute?
Traceroute даёт три пакета на хоп — по ним нельзя отличить лимит ICMP от потери и увидеть плавающую проблему. MTR за 100–200 циклов накапливает по каждому узлу статистику, в которой видно, где потери начинаются и сохраняются ли до цели.
Работает ли MTR через VPN?
Работает, но покажет маршрут от VPN-сервера: первым хопом будет туннельный шлюз, участок до него схлопнется в одну строку, и потери внутри туннеля припишутся ему. Для отчёта провайдеру VPN отключите; для диагностики самого VPN снимите два отчёта, с ним и без.
Сколько пакетов нужно для отчёта?
Не меньше 100, Hetzner требует 200. Отчёт с дефолтными 10 циклами бесполезен: один потерянный пакет — уже 10%, и отличить лимит от реальной потери невозможно.
Почему mtr показывает не тот маршрут, что traceroute?
Разные протоколы — разные пути: traceroute в Linux по умолчанию шлёт UDP, mtr — ICMP, а балансировка на роутерах раскидывает потоки по протоколу и портам. Чтобы сравнивать одинаковое, запустите mtr с -u или traceroute с -I; путь пользователей точнее покажет mtr -T -P 443. Как измерить задержку до цели без трассировки, описано в статье про ping-тест.