Перейти к основному содержанию
Клиенты часто сообщают о потерях пакетов, увидев после traceroute или MTR 80% или даже 100% потерь на промежуточных узлах. Но во многих случаях на конечном узле потерь нет вообще. Эта статья объясняет, как правильно читать MTR и отличать реальные проблемы соединения от безвредных особенностей обработки диагностического трафика маршрутизаторами.

​
Кратко

  • Потери на промежуточных узлах не означают проблему автоматически.
  • Важнее всего последний узел — ваш VPS или целевой хост.
  • Многие маршрутизаторы снижают приоритет ответов ICMP или ограничивают их частоту.
  • Виртуальные среды добавляют уровни, где диагностический ICMP может обрабатываться иначе, чем обычный трафик приложений.
Начните с конечного узла, затем проверьте приложение. Отсутствие потерь на конечном узле в одной выборке — хороший признак, но оно не исключает периодические проблемы или сбои других протоколов.

​
Как на самом деле измеряются потери

traceroute и MTR отправляют диагностические пакеты, обычно ICMP или UDP, и измеряют ответы маршрутизаторов. Представьте, что они спрашивают каждый маршрутизатор на пути:
«Можешь ответить мне прямо сейчас?»
Некоторые маршрутизаторы не отвечают, но продолжают нормально передавать реальный трафик приложений. Маршрутизаторы оптимизированы для пересылки трафика, а не ответов на диагностические запросы. Под нагрузкой они могут:
  • ограничивать частоту ответов ICMP;
  • отбрасывать диагностические пакеты;
  • отвечать непостоянно.
В MTR это выглядит как потери, даже когда пользовательский трафик проходит нормально.

​
Как правильно проводить тесты

Перед интерпретацией потерь убедитесь, что тест выполнен правильно.

​
Использование traceroute и MTR

Следуйте пошаговому руководству: 👉 Запускайте MTR минимум на 100 циклов для получения содержательной статистики.

​
Использование ping.pe

Для внешней проверки из нескольких локаций: 👉 Это помогает определить, является ли проблема локальной или глобальной.

​
Как читать вывод MTR

Примеры ниже иллюстративные и сокращены до важных столбцов. Каждая строка соответствует 100 запросам; задержка указана в миллисекундах. Сначала читайте строку назначения, затем сравнивайте предыдущие узлы.

​
Сценарий 1: потери только на промежуточных узлах

01 · Потерь на конечном узле не обнаружено

Конечный узел: 0% потерь. В этом тесте отсутствие ответов на предыдущих узлах не продолжается до назначения.
Что заметно: маршрутизатор 2 совсем не отвечает, но последующие узлы и назначение отвечают. Его молчание не доказывает, что он отбрасывает весь пересылаемый трафик.Что делать: если приложение тоже работает нормально, одних промежуточных потерь недостаточно для сообщения о сбое. Маршрутизаторы могут фильтровать или ограничивать диагностические ответы.

​
Сценарий 2: потери продолжаются до последнего узла

02 · Потери на конечном узле требуют проверки

Конечный узел: 10% потерь. Ответы теряются и от назначения. Повторите тест и сопоставьте результаты с работой приложения.
Что заметно: потери сохраняются до назначения, поэтому их нельзя объяснить только отсутствием ответа одного промежуточного маршрутизатора.Что делать: сохраните полный отчёт, по возможности повторите проверку из другого источника или в обратном направлении и проверьте протокол и порт приложения. Возможны перегрузка, неисправный канал, проблемы хоста или фильтрация и ограничение диагностических запросов. Одна эта картина не определяет точный неисправный канал и не доказывает такой же процент потерь трафика приложения.

​
Сценарий 3: скачки задержки без потерь на конечном узле

03 · Промежуточный скачок не равен общей задержке

Пик маршрутизатора 2 — 250 мс, назначения — 23 мс. В этой выборке скачок не наблюдается на конечном узле.
Что заметно: последующие узлы отвечают быстрее маршрутизатора со скачком. Каждая строка измеряет отдельные ответы; времена узлов не складываются.Что делать: оценивайте задержку на назначении и в приложении. Маршрутизаторы могут медленно отвечать на запросы, нормально пересылая трафик. Если назначение также замедляется, исследуйте это отдельно.
Подробнее об ответах на диагностические запросы и ограничениях маршрутизаторов — в проекте MTR и объяснении MTR от Cloudflare.

​
Потери пакетов в виртуальных средах

В виртуальных средах сетевой трафик проходит через:
  • виртуальные интерфейсы гостевой системы;
  • сетевые уровни гипервизора;
  • сетевые стеки хоста.
Эти уровни могут обрабатывать диагностический ICMP иначе, чем обычный трафик. Поэтому:
  • промежуточные потери могут выглядеть завышенными;
  • реальный трафик приложения может оставаться незатронутым.
Всегда оценивайте соединение по конечному узлу и работе приложения, а не только промежуточной статистике ICMP.

​
Когда обращаться в поддержку

Обратитесь к нашей команде, если наблюдаете:
  • потери на последнем узле;
  • постоянно высокую задержку до назначения;
  • проблемы соединения на уровне приложения.
Приложите:
  • полный вывод MTR;
  • время тестов (UTC);
  • исходный и целевой IP;
  • результаты ping.pe при наличии.
Это поможет быстрее диагностировать проблему.

​
Главное

MTR — мощный инструмент, но его часто понимают неправильно. 👉 Потери только на промежуточных узлах не являются надёжным признаком сетевой проблемы.
👉 Важнее всего статистика конечного узла. Если на назначении стабильная задержка и нет потерь, тест подтверждает отсутствие потерь назначения в этой выборке, даже если предыдущие узлы выглядят тревожно. Проверьте работу приложения перед более широкими выводами.
Последнее изменение 7 ноября 2026 г.