Как читать traceroute и MTR и не обманываться

Вот короткая версия, потому что именно из-за этого люди приходят к неверному выводу: потеря пакетов, показанная на промежуточном узле трассы и не продолжающаяся до последнего узла, не означает ничего. Это самое частое неверное прочтение traceroute, оно порождает огромное число обращений в поддержку, а причина в том, что маршрутизаторы намеренно понижают приоритет ответов, от которых зависит traceroute. Важны только потери, которые доходят до пункта назначения. То же относится к скачку задержки на одном узле, который не переносится до конца.

Второе, что нужно знать: traceroute показывает одно направление, а пакеты ответа вернулись по маршруту, которого вы не видите. Поэтому полезный отчёт - это всегда две трассы, по одной с каждого конца, снятые одновременно. Ниже - как их получить, как прочитать и что делать с ответом, который порой звучит так: «ничего, и вот почему».

Как на самом деле работает traceroute#

Каждый IP-пакет несёт TTL - счётчик прыжков, в IPv6 он называется hop limit. Каждый маршрутизатор, пересылающий пакет, уменьшает его на единицу, а маршрутизатор, доведший его до нуля, выбрасывает пакет и отправляет отправителю сообщение ICMP Time Exceeded.

Traceroute намеренно этим пользуется. Он посылает пробу с TTL 1, и первый маршрутизатор отвечает «time exceeded» - теперь вы знаете узел 1. Затем посылает пробу с TTL 2, и отвечает второй маршрутизатор. Так он идёт наружу, по три пробы на узел по умолчанию, пока не ответит сам пункт назначения, а не сообщением time-exceeded.

Сами пробы различаются по инструментам, и это важнее, чем ожидают:

Следствие: файрвол, который отбрасывает UDP, но пропускает ICMP, даёт трассу, которая обрывается на полпути с одним инструментом и завершается с другим, и ни тот, ни другой результат не говорит, доходит ли ваш игровой трафик. Если вас интересует конкретная служба, зондируйте её тем протоколом и портом, которые она действительно использует.

mtr - это traceroute и ping вместе. Он гоняет обход снова и снова и ведёт статистику по каждому узлу, а это единственный способ увидеть потери и джиттер, а не единичный замер. Для диагностики используйте mtr и забудьте, что обычный traceroute существует.

Команды, которые стоит знать#

# The one to use. Report mode, 100 cycles, wide output, ASNs and IPs shown.$ mtr -rwzbc 100 203.0.113.10# Probe the port the game actually uses, so ECMP hashes the same flow.$ mtr -rwzbc 100 -T -P 25565 mc.example.com$ mtr -rwzbc 100 -u -P 27015 cs.example.com# Plain traceroute over TCP to a web port, when ICMP is filtered.$ traceroute -T -p 443 example.com# Fast, numeric, no reverse DNS delays.$ mtr -rwnc 100 203.0.113.10

В Windows установите WinMTR - это GUI, он делает ту же работу, и именно его чаще всего просят хосты. Встроенные инструменты слабее, но тоже полезны:

tracert -d 203.0.113.10pathping -q 100 203.0.113.10

tracert -d пропускает обратный DNS, что убирает паузы, из-за которых кажется, что он завис. pathping посылает большое число проб на узел и печатает потери по узлам, так что он ближе к mtr; на длинном пути он также занимает несколько минут, так что запустите его и займитесь чем-нибудь другим.

Гоняйте минимум 100 циклов. Десять проб не позволяют с какой-либо уверенностью отличить 0% потерь от 10%, а отчёт с -c 10 ничего не доказывает.

Читаем отчёт MTR по столбцам#

$ mtr -rwzbc 100 203.0.113.10Start: 2026-09-21T14:02:11+0200HOST: laptop                    Loss%  Snt  Last   Avg  Best  Wrst StDev 1. AS???     192.168.1.1        0.0%  100   0.6   0.8   0.5   3.1   0.3 2. AS64500   100.64.0.1         0.0%  100   8.9   9.4   8.1  21.0   1.6 3. AS64500   198.51.100.9      12.0%  100   9.8  10.2   8.9  30.4   2.1 4. AS64501   192.0.2.17         0.0%  100  24.1  24.6  23.8  40.2   1.9 5. AS64502   192.0.2.201        0.0%  100  25.0  25.3  24.6  33.1   1.1 6. AS64502   203.0.113.10       0.0%  100  25.2  25.5  24.8  35.0   1.2

Этот отчёт здоровый. Узел 3 показывает 12% потерь, а всё после него - ни одной, и это маршрутизатор, ограничивающий частоту собственных ответов, а не маршрутизатор, теряющий трафик. Если бы узел 3 действительно терял один пакет из восьми, узлы 4, 5 и 6 никак не могли бы показывать 0%: их пробы проходят через него.

Читайте в таком порядке: сначала последняя строка для потерь, затем Avg на последней строке для задержки, затем StDev и разброс от Best до Wrst на последней строке для джиттера. Только если последняя строка показывает проблему, промежуточные узлы становятся интересными, да и то лишь затем, чтобы найти, где проблема начинается.

Номера AS - вторая половина истории. Они говорят, какой сети принадлежит каждый узел, так что видно, где ваш провайдер передаёт трафик транзитному оператору и где тот передаёт его сети хостинга. Узел, на котором меняется AS, - это точка пиринга, а точки пиринга - место, где на самом деле живёт перегрузка.

Четыре вещи, которые выглядят неисправностью, но ею не являются#

Ограничение частоты ICMP. Формирование ответа Time Exceeded - это работа для управляющего процессора маршрутизатора, и загруженный магистральный маршрутизатор с удовольствием пересылает миллионы пакетов в секунду, отвечая лишь на горстку проб traceroute. Он настроен так, чтобы защищать себя. Симптом: потеря или дикое значение задержки на одном узле при чистых узлах после него.

Задержка плоскости управления. Та же причина, другой симптом. Узел показывает 200 мс, а пункт назначения двумя узлами дальше показывает 25 мс. Маршрутизатор медленно сформировал ответ о пакете, который переслал мгновенно. Задержка, не переносящаяся вперёд, - это не задержка, которую испытал ваш трафик.

*** * * на узле.** Маршрутизатор, настроенный вообще не отправлять сообщения Time Exceeded, или файрвол, их отбрасывающий. Крайне распространено внутри сетей операторов и вокруг облачных провайдеров. Если трасса идёт дальше и завершается, узел невидим, а не сломан. Если же трасса идёт * * * от узла до конца и так и не завершается, это другое: что-то блокирует ваш тип пробы, и TCP-трасса на порт, который пункт назначения действительно слушает, обычно проходит.

Приватные адреса и фантомные узлы. 10.x, 172.16-31.x, 192.168.x и диапазон 100.64.0.0/10 в трассе - это нормально: операторы используют приватное пространство для внутреннего транспорта, а 100.64 - именно carrier-grade NAT. Отдельно: классический traceroute меняет порт назначения на каждой пробе, а там, где сеть балансирует нагрузку по нескольким путям равной стоимости, каждая проба может пойти своим. Это порождает узлы, которые появляются и исчезают, и значения потерь, лишённые смысла. Фиксация порта через -P держит все пробы на одном пути и делает результат воспроизводимым.

Ещё два поменьше: туннели MPLS могут скрывать все маршрутизаторы внутри себя, так что трасса может перепрыгнуть из одного города в другой одним узлом с приростом задержки, который выглядит тревожно и является просто расстоянием; а трасса, снятая, пока сеть перестраивается после смены маршрута, покажет сначала одну половину маршрута, потом другую.

Как выглядит настоящая неисправность#

HOST: laptop                    Loss%  Snt  Last   Avg  Best  Wrst StDev 1. AS???     192.168.1.1        0.0%  100   0.7   0.9   0.5   4.2   0.4 2. AS64500   100.64.0.1         0.0%  100   9.1   9.6   8.2  19.7   1.4 3. AS64500   198.51.100.9       0.0%  100  10.0  10.4   9.1  24.0   1.8 4. AS64501   192.0.2.17         6.0%  100  24.3  38.9  23.9 210.4  31.7 5. AS64502   192.0.2.201        6.0%  100  25.4  40.1  24.7 214.8  32.9 6. AS64502   203.0.113.10       6.0%  100  25.6  40.6  24.9 219.1  33.4

Настоящей эту картину делают три вещи, и все три должны присутствовать, прежде чем вы скажете об этом вслух:

1. Потери начинаются на одном узле и продолжаются примерно с той же частотой до конца. 6% на узле 4, 6% на каждом узле после. Пробы, дошедшие до узла 6, должны были пережить узел 4.
2. Ухудшение задержки сохраняется. Avg подскочил с 10 до 39 на узле 4 и там остался. Сравните Best с Avg: Best по-прежнему 24 мс, значит, путь способен на 24 мс, а что-то создаёт очередь.
3. `StDev` и `Wrst` растут вместе. Best 24 и Wrst 210 при стандартном отклонении 32 - это перегруженный канал, а не длинный. Чистое расстояние даёт высокий Avg при низком StDev.

Этот шаблон - низкий Best, высокий Wrst, высокий StDev, начинающийся на одном узле, - и есть перегрузка, почти всегда на точке пиринга в определённое время суток. Высокий Avg при узком разбросе и без потерь - это расстояние, а расстояние - физика. Короткая версия того, почему эти три величины путают, - в статье задержка, джиттер и потеря пакетов.

Оба направления, потому что обратный путь другой#

Интернет-маршрутизация по умолчанию асимметрична. Маршрут от вас до сервера выбирают ваш провайдер и его транзитные операторы; маршрут обратно независимо выбирают сеть хостинга и её операторы. Нередко это не один и тот же путь, и у них может быть совершенно разная перегрузка.

Каждое число в вашей трассе - это круговой проход, поэтому чистый на вид прямой путь с плохими числами в конце может оказаться проблемой обратного пути, из которой вы не видите ничего. Единственный способ её увидеть - трасса, запущенная с другого конца обратно к вам.

Чтобы запустить обратную трассу, нужна оболочка на сервере. На VDS она у вас есть, так что достаточно mtr -rwzbc 100 <your-address>. На контейнерном игровом тарифе или тарифе для приложений оболочки нет: консоль панели - это собственный вывод приложения и его командная строка, а не терминал, - так что эту половину картины придётся получать через тикет. Укажите свой публичный адрес, иначе трасса будет запущена в никуда.

Если дома вы за CGNAT, обратной трассировки просто некуда направлять, и проверку в обратном направлении надо делать с машины, у которой публичный адрес есть. Стоит знать это, прежде чем потратить вечер.

Сопоставляем трассу с тем, о чём сообщают игроки#

Трасса полезна, только если соответствует жалобе. Три проверки перед выводами:

• Зондируйте то, что нужно. Большинство игр работает по UDP - почему, объясняет TCP против UDP для игровых серверов, - и путь, чистый для ICMP, может по-прежнему иметь файрвол или ограничение частоты перед игровым портом. Трассируйте с -u -P на игровой порт или -T -P для TCP-игр вроде Minecraft и убедитесь, что порт именно тот, что вы думаете, по статье порты игровых серверов простыми словами.
• Проверяйте, пока плохо. Трасса, снятая в 11:00, ничего не говорит о перегрузке, которую все чувствуют в 21:00. Перегрузка пиринга - вечернее явление. Запускайте mtr в плохое окно, в течение нескольких минут.
• Сначала исключите сервер. Лаг, который затрагивает всех игроков одновременно, где бы они ни жили, обычно не сеть. Прежде чем трогать трассу, проверьте графики CPU и памяти в панели и tick rate - быстрее всего к этому ответу ведут чтение графика нагрузки сервера и что на самом деле значит tick rate, а для Minecraft в частности - почему падает TPS.

Лагает один игрок - это его подключение. Лагают все игроки - это сервер или его аплинк. Лагают игроки из одной страны - это маршрут.

Что делать при каждом ответе#

Плох узел 1 или 2. Это ваша собственная сеть: wifi, дешёвый роутер, забитая исходящая полоса или кто-то ещё дома, смотрящий стрим. Прежде всего проверьте по кабелю. Wifi-канал, показывающий 30 мс джиттера до вашего же роутера, - это вся проблема, и никакой хост её не исправит.

Плоха собственная сеть вашего провайдера. Его поддержка обычно не примет MTR, но примет «потеря пакетов между вашим оборудованием на узле 3 и моим подключением». Будьте конкретны, приводите временные метки с часовым поясом и повторяйте тест несколько дней, чтобы нельзя было списать всё на разовый случай.

Плоха транзитная сеть посередине. Это честный и неутешительный случай: ни у вас, ни у вашего хоста нет договора с этой сетью, и ни один из вас не может обойти её напрямую. Хост иногда может повлиять на то, какого из собственных транзитных операторов использует обратный трафик, и именно поэтому ему нужна трасса с вашей стороны. Отправьте её и наберитесь терпения.

Плоха сеть пункта назначения. Потери, начинающиеся на последнем-предпоследнем узле, затрагивающие всех и сохраняющиеся днями. Это стоит тикета с доказательствами. На RE:NODE тикет из панели доходит до всех сотрудников и принимает приватные вложения, что подходит для трасс и скриншотов.

Учтите, чего трасса не покажет. Она не отличит перегрузку от идущей атаки; крупные объёмные потоки отбрасываются выше по маршруту, а трафик, замаскированный под настоящих игроков, не фильтруется вовсе, - где проходит эта граница, объясняет DDoS-атаки на игровые серверы. И обычный совет «выберите локацию поближе» здесь неприменим: RE:NODE работает в одной локации, в Германии, на оборудовании, которое мы сами эксплуатируем. Если ваши игроки в Бразилии, никакая конфигурация не изменит скорость света через Атлантику, и правильный ответ - знать это до покупки, а не после. Честная версия этого компромисса - выбор места для вашего сервера.

Отчёт, по которому действуют#

Тот, кто читает ваш тикет, хочет воспроизвести ваш вывод, а не ваше ощущение. Приложите:

1. Оба направления, если можете получить, снятые с разницей в несколько минут.
2. Минимум 100 циклов, текстом, а не скриншотом, чтобы можно было искать и цитировать.
3. Временные метки с часовым поясом. Режим отчёта mtr печатает время начала. Укажите, когда проблема возникает и когда нет.
4. Адрес и порт, и каким протоколом вы зондировали.
5. Кого затрагивает: одного игрока, регион или всех, и с какого времени.
6. Сравнение. Чистая трасса до другого сервера в том же городе превращает анекдот в доказательство.

Чего не прикладывать: единственный tracert с четырьмя пробами на узел и красным кругом вокруг узла в середине. Именно такой отчёт эта статья и призвана предотвратить.

FAQ#

Почему один узел показывает 50% потерь, а остальные ни одной?

Маршрутизатор на этом узле ограничивает частоту ICMP-ответов, которые нужны traceroute, - это нормально и сделано намеренно. Ваш настоящий трафик он пересылает без проблем, что доказывают узлы после него без потерь. Реальны только потери, продолжающиеся до последнего узла.

Что использовать, traceroute или MTR?

MTR - для всего, на основании чего вы собираетесь действовать. Traceroute берёт три замера на узел, чего недостаточно для измерения потерь или джиттера. MTR непрерывно повторяет обход и выдаёт потери, среднее, лучшее, худшее и стандартное отклонение по каждому узлу. WinMTR - версия для Windows.

Сколько пакетов отправлять?

Минимум 100, с -c 100. Ниже этого процент потерь - шум. Если вы ловите перемежающуюся проблему, гоняйте несколько минут в плохой период, а не один раз.

Почему задержка выше, чем у ping до того же адреса?

На последнем узле её быть не должно: эта строка по сути и есть ping. Если промежуточные узлы показывают числа выше, чем пункт назначения, это задержки плоскости управления при формировании ответов, а не задержки, которые испытал ваш трафик. Читайте последнюю строку.

Показывает ли трасса путь, по которому идёт мой игровой трафик?

Только если вы зондируете тем же протоколом и портом, и даже тогда лишь приблизительно. Сети балансируют нагрузку по путям равной стоимости с помощью хеша адресов и портов, поэтому другой порт - потенциально другой путь. Используйте -T или -u с -P, равным настоящему порту.

Трасса обрывается на полпути и не доходит до сервера. Сервер лежит?

Обычно нет. Где-то файрвол отбрасывает ваш тип пробы или отказывается отвечать, продолжая пересылать настоящий трафик. Попробуйте TCP-трассу на порт, который сервер действительно слушает. Если игра подключается, путь в порядке, что бы ни говорила трасса.