Как читать результаты traceroute и MTR
Введение
Если ваш сайт открывается медленно или теряются пакеты, стандартные инструменты диагностики — traceroute и MTR — помогут определить, где именно возникает задержка или потеря данных. В этой инструкции мы разберём на конкретных примерах, как выглядят различные проблемы и как не попасть в ловушку ложных срабатываний.
Зачем это нужно?
Представьте, что интернет — это многополосное шоссе. Ваш запрос к сайту — это автомобиль. Traceroute показывает все города (узлы или «хопы»), через которые проезжает машина, и сколько времени занимает каждый участок пути. MTR (My TraceRoute) делает то же самое, но показывает статистику за период времени (не теряются ли пакеты по дороге).
Запуск диагностики
Выбор команды зависит от вашей операционной системы:
- Windows (встроенная): tracert ya.ru (или IP-адрес вашего сервера)
- macOS / Linux (встроенная): traceroute -I ya.ru (флаг -I использует ICMP-пакеты, что удобнее для диагностики)
- Для углубленного анализа (кросс-платформенная): MTR. Если она не установлена:
- macOS: brew install mtr
- Linux (Ubuntu/Debian): sudo apt install mtr
- Windows: Скачайте WinMTR (бесплатная программа с графическим интерфейсом).
Запускать диагностику лучше в тот момент, когда проблема проявляется (например, сайт тормозит).
Структура вывода MTR
Для удобства будем использовать MTR, так как он даёт статистику потерь и времени. Вот как выглядит типичный отчёт (цель — сервер с IP 198.51.100.10):
Пример запуска с командой mtr -r -c 50 ваш_сервер.ру. Флаг -r выводит отчет, -c 50 отправляет 50 пакетов для статистики.
| Hop | Узел | Loss% | Snt | Last | Avg | Best | Wrst | StDev |
| 1 | 192.168.1.1 | 0.0% | 50 | 1.2 | 1.5 | 1.0 | 4.2 | 0.5 |
| 2 | 10.0.0.1 | 0.0% | 50 | 2.1 | 2.3 | 2.0 | 5.1 | 0.3 |
| 3 | 172.16.1.2 | 0.0% | 50 | 5.5 | 6.0 | 5.1 | 15.2 | 1.1 |
| 4 | 212.45.12.1 | 0.0% | 50 | 15.2 | 16.5 | 14.8 | 30.1 | 2.0 |
| 5 | 195.34.6.7 | 0.0% | 50 | 45.1 | 46.2 | 44.9 | 60.3 | 2.5 |
| 6 | 198.51.100.10 | 0.0% | 50 | 45.5 | 46.8 | 45.0 | 61.0 | 2.6 |
Разберем столбцы по порядку:
- Hop (Прыжок): Порядковый номер маршрутизатора на пути к цели.
- Узел: Адрес маршрутизатора (если у него есть DNS-имя, оно отобразится здесь).
- Loss%: Процент потерянных пакетов на этом узле. Самый важный столбец.
- Snt (Sent): Сколько пакетов было отправлено (в нашем примере — 50).
- Last: Время ответа последнего пакета (в миллисекундах).
- Avg (Average): Среднее время отклика.
- Best: Лучшее (минимальное) время.
- Wrst (Worst): Худшее (максимальное) время.
- StDev (Стандартное отклонение): Показывает, насколько стабилен пинг. Высокое значение (более 10-15) говорит о нестабильности канала (дрожании — jitter).
Комментарий: Все хопы отвечают, потерь нет, время нарастает плавно. Сеть работает идеально.
Примеры различных ситуаций с пояснениями
Главное правило при анализе трассировки: Потери пакетов имеют значение только на последнем узле (ваш сервер), если они не массовые на всей цепочке.
Потери на промежуточных узлах, но не на целевом сервере
| Hop | Узел | Loss% | Snt | Last | Avg | Best | Wrst | StDev |
| 1 | 192.168.1.1 | 0.0% | 50 | 1.1 | 1.4 | 1.0 | 3.9 | 0.4 |
| 2 | 10.0.0.1 | 0.0% | 50 | 2.3 | 2.5 | 2.1 | 5.5 | 0.4 |
| 3 | 172.16.1.2 | 0.0% | 50 | 5.8 | 6.2 | 5.3 | 16.0 | 1.2 |
| 4 | 212.45.12.1 | 45.0% | 50 | 15.5 | 17.0 | 15.0 | 35.2 | 3.1 |
| 5 | 195.34.6.7 | 0.0% | 50 | 46.2 | 47.5 | 45.8 | 62.0 | 2.7 |
| 6 | 198.51.100.10 | 0.0% | 50 | 46.5 | 47.9 | 46.0 | 63.0 | 2.8 |
Что мы видим?
На хопе 4 (212.45.12.1) потери 45%. Но на следующих хопах (5 и 6) потери отсутствуют, пакеты доходят до сервера без потерь.
Интерпретация: Маршрутизатор 212.45.12.1 настроен так, что не отвечает на ICMP-запросы (или отбрасывает их с низким приоритетом), но пользовательский трафик (TCP/UDP) через него проходит нормально. Это не является проблемой. Ориентируйтесь только на потери на последнем узле, если они не сопровождаются потерями на всём пути.
Потери на последнем узле (сервере) или перед ним
| Hop | Узел | Loss% | Snt | Last | Avg | Best | Wrst | StDev |
| 1 | 192.168.1.1 | 0.0% | 50 | 1.3 | 1.6 | 1.1 | 4.5 | 0.5 |
| 2 | 10.0.0.1 | 0.0% | 50 | 2.4 | 2.6 | 2.2 | 5.8 | 0.5 |
| 3 | 172.16.1.2 | 0.0% | 50 | 5.6 | 6.1 | 5.2 | 16.5 | 1.3 |
| 4 | 212.45.12.1 | 0.0% | 50 | 15.8 | 17.2 | 15.3 | 36.0 | 3.0 |
| 5 | 195.34.6.7 | 10.0% | 50 | 60.5 | 65.0 | 55.0 | 120.0 | 15.0 |
| 6 | 198.51.100.10 | 20.0% | 50 | 120.0 | 140.0 | 80.0 | 300.0 | 50.0 |
Что мы видим?
На хопе 5 начинаются потери (10%) и время резко возрастает (Avg 65 мс против 17 на предыдущем). На целевом сервере (хоп 6) потери достигают 20%, пинг очень высокий и нестабильный (StDev 50).
Интерпретация: Проблема на участке от хопа 5 до сервера. Это может быть перегрузка канала, DDoS-атака, проблемы с оборудованием провайдера или высокая нагрузка на сам сервер (он не успевает отвечать). Такой отчёт можно отправлять в поддержку, указав, что потери начинаются с хопа 5.
Высокий пинг (Latency) на одном из хопов
- Норма для Европы/Москвы: 1–40 мс.
- Норма для трансатлантики (Европа — США): 90–150 мс.
- Норма для Дальнего Востока / Австралии: 150–300 мс.
Если пинг внезапно подскочил на одном из хопов и держится высоким до конца маршрута — это место узкого горлышка.
| Hop | Узел | Loss% | Snt | Last | Avg | Best | Wrst | StDev |
| 1 | 192.168.1.1 | 0.0% | 50 | 1.2 | 1.5 | 1.0 | 4.0 | 0.4 |
| 2 | 10.0.0.1 | 0.0% | 50 | 2.2 | 2.4 | 2.0 | 5.2 | 0.4 |
| 3 | 172.16.1.2 | 0.0% | 50 | 5.4 | 5.9 | 5.0 | 15.5 | 1.1 |
| 4 | 212.45.12.1 | 0.0% | 50 | 150.0 | 152.0 | 148.0 | 170.0 | 5.0 |
| 5 | 195.34.6.7 | 0.0% | 50 | 151.0 | 153.0 | 149.0 | 172.0 | 5.2 |
| 6 | 198.51.100.10 | 0.0% | 50 | 152.0 | 154.0 | 150.0 | 173.0 | 5.3 |
Что мы видим?
До хопа 3, пинг был около 5-6 мс. На хопе 4 он резко подскакивает до 150 мс и держится таким до конца.
Интерпретация: Пакеты пошли по альтернативному (географически удалённому или перегруженному) маршруту. Это может быть связано с изменением таблиц маршрутизации у вышестоящего провайдера.
Звёздочки (* * *) вместо ответа
Часто маршрутизаторы просто не отвечают на запросы.
| Hop | Узел | Loss% | Snt | Last | Avg | Best | Wrst | StDev |
| 1 | 192.168.1.1 | 0.0% | 50 | 1.1 | 1.4 | 1.0 | 4.1 | 0.4 |
| 2 | 10.0.0.1 | 0.0% | 50 | 2.3 | 2.5 | 2.1 | 5.4 | 0.4 |
| 3 | *** | 100.0% | 50 | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 |
| 4 | *** | 100.0% | 50 | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 |
| 5 | 195.34.6.7 | 0.0% | 50 | 45.0 | 46.5 | 44.8 | 61.0 | 2.6 |
| 6 | 198.51.100.10 | 0.0% | 50 | 45.3 | 46.9 | 45.0 | 62.0 | 2.7 |
Что мы видим?
Хопы 3 и 4 не отвечают (100% потерь, время отсутствует), но на хопе 5 трафик снова появляется и идёт без потерь до цели.
Интерпретация: Это абсолютно нормально. Маршрутизаторы на хопах 3 и 4 просто не настроены отвечать на диагностические запросы. Ваш трафик идёт через них, но они «молчат». Беспокоиться стоит только в том случае, если звёздочки начинаются и продолжаются вплоть до последнего узла, и при этом сервер недоступен (например, сайт не открывается).
Что делать с результатами? (Краткий чек-лист)
- Запустите MTR в момент проблемы, зафиксируйте 50–100 пакетов.
- Посмотрите на последний хоп (IP вашего сервера).
- Потерь нет (<1%)? Сеть работает идеально. Ищите проблему в настройках сервера (веб-сервер, база данных, скрипты).
- Потери есть на последнем хопе? Проблема на самом сервере или на входном порту. Нужно проверять нагрузку сервера (CPU, I/O).
- Потери есть на предпоследнем хопе (шлюзе провайдера/дата-центра)? Проблема на сетевом оборудовании хостера. Сохраните лог и отправьте в поддержку.
- Проверьте стабильность (StDev). Если StDev высокий (>15-20) на последнем хопе, а Loss нет — канал нестабилен (джиттер). Это критично для VoIP и онлайн-игр, для обычного сайта — не очень.
- Сохраните лог. Если вы обращаетесь в поддержку, копируйте результат целиком, а не только последнюю строчку.
Обратная трассировка и асинхронные маршруты
До сих пор мы смотрели путь от вас к серверу. Но интернет — двустороннее движение. Ответы от сервера идут к вам по обратному маршруту, который может отличаться от прямого. Это называется асинхронной маршрутизацией.
Зачем проверять обратный путь?
Если пакеты к серверу идут хорошо, но ответы теряются или задерживаются, вы увидите потери на своей стороне, но прямой трассировкой их не обнаружить. Обратная трассировка помогает выявить проблемы на обратном пути.
Как сделать обратную трассировку?
Вам нужно выполнить команду с сервера по направлению к вашему локальному IP-адресу. Для этого:
- Узнайте свой внешний IP-адрес (например, через сайт 2ip.ru).
- Подключитесь к серверу по SSH (или через консоль хостинга).
- Выполните MTR или traceroute до своего IP:
- mtr -r -c 50 ваш_внешний_IP
- или traceroute -I ваш_внешний_IP
Если у вас нет доступа к серверу, попросите поддержку хостинга выполнить эту команду и прислать отчёт.
Пример сравнения прямого и обратного маршрутов
Прямой маршрут (клиент → сервер):
| Hop | Узел | Loss% | Avg |
| ... | ... | ... | ... |
| 5 | 195.34.6.7 | 0.0% | 46.2 |
| 6 | 198.51.100.10 | 0.0% | 46.8 |
Обратный маршрут (сервер → клиент):
| Hop | Узел | Loss% | Avg |
| ... | ... | ... | ... |
| 4 | 195.34.6.8 | 0.0% | 45.5 |
| 5 | 212.45.12.5 | 15.0% | 120.0 |
| 6 | ваш_IP | 15.0% | 125.0 |
Анализ:
Прямой маршрут идеален. На обратном маршруте на хопе 5 (212.45.12.5) начинаются потери и высокий пинг. Это означает, что проблема кроется в обратном пути — возможно, перегружен канал одного из транзитных провайдеров, через который идут ответы.
Как определить асинхронность?
Сравните списки узлов (их IP или имена) в прямом и обратном маршрутах. Если они сильно различаются (например, прямой идёт через один город или страну, а обратный через совершенно другой город или страну), то маршрут асинхронный. Сама по себе асинхронность не является проблемой, но если на обратном пути возникают потери, это объясняет, почему вы видите плохую работу при хорошем прямом пути.
Что делать?
Отправьте в поддержку оба лога (прямой и обратный) с пояснением: «Прямой маршрут чистый, но на обратном наблюдаются потери на узле X.
Заключение
Диагностика сети — это искусство исключения. Traceroute и MTR помогают локализовать проблему: ваше оборудование, местный провайдер, магистральный оператор или сам сервер. Добавив к этому анализ обратного пути, вы получаете полную картину движения трафика. Сохраняйте примеры из этой статьи и сравнивайте со своими результатами — так вы быстро научитесь отличать безобидные особенности сети от настоящих аварий.