Если один промежуточный узел в MTR показывает высокий Loss%, а следующие узлы и конечный адрес отвечают без потерь, это ещё не доказывает неисправность маршрутизатора. Сначала проверьте, продолжается ли ухудшение на всех последующих hop и достигает ли оно адресата.
MTR измеряет ответы на диагностические пакеты. Маршрутизатор может исправно пересылать пользовательский трафик, но ограничивать собственные ICMP-ответы, поэтому отчёт нужно сопоставлять с работой сайта и повторять из той сети, где возникла проблема.
Что именно показывает MTR
MTR объединяет логику ping и traceroute: отправляет пакеты с последовательно растущим TTL и собирает ответы промежуточных устройств. В отчёте важны не отдельные числа, а их изменение вдоль маршрута.
- Loss% — доля проб, на которые конкретный hop не ответил. Это не всегда доля пакетов, потерянных при пересылке к сайту.
- Snt — число отправленных проб. На коротком запуске случайный пропуск слишком заметно меняет процент.
- Last, Avg, Best, Wrst — последняя, средняя, минимальная и максимальная задержка ответа.
Строка со звёздочками или 100% потерь на промежуточном hop тоже не означает обрыв, если следующие узлы и адрес назначения отвечают. Устройство могло не посылать диагностические ответы, продолжая маршрутизацию.
Главный принцип: ищите продолжение симптома
Начните чтение с конечного адреса, затем двигайтесь вверх по отчёту. Промежуточный узел становится подозрительным, когда появившиеся на нём потери или задержка сохраняются на следующих hop и у адресата.
| Картина в отчёте | Что она означает | |---|---| | Потери есть на одном hop, ниже по маршруту их нет | Нет доказательства потери транзитного трафика; вероятно, ограничены ответы самого узла | | Задержка выросла на одном hop, затем вернулась к прежнему уровню | Медленно сформирован диагностический ответ, но пересылка могла не пострадать | | Потери начинаются на одном участке и доходят до адресата | Есть основание проверять участок, но виновника нужно подтверждать другими измерениями | | Потери видны только у адресата | Возможны ограничение ответов на сервере, перегрузка, фильтрация или реальная потеря у цели | | Маршрут и адреса hop меняются между запусками | Возможна балансировка; сравнивать строки как один неизменный путь нельзя |
Даже устойчивый рисунок не доказывает поломку конкретного устройства: ответ MTR может возвращаться другим маршрутом.
Как снять отчёт, который можно анализировать
1. Запускайте проверку там, где виден сбой
Проверка с сервера в дата-центре не объяснит, почему сайт плохо открывается из домашней или офисной сети. Запускайте MTR с затронутого подключения и в момент, когда пользователи замечают задержку или обрыв.
Для сохранённого отчёта в Linux можно использовать пример:
mtr -rw -c 100 example.comСто проб — пример для устойчивой выборки, а не универсальная норма. Не направляйте длительные или частые проверки на чужие системы без необходимости.
2. Проверяйте тот протокол, с которым возникла проблема
Обычный режим и HTTPS-соединение могут фильтроваться по-разному. Если установленная версия MTR поддерживает TCP-пробы, для сайта полезен дополнительный запуск к порту 443:
mtr --tcp --port 443 -rw -c 100 example.comIPv4 и IPv6 проверяйте отдельно с -4 и -6. Если один вариант работает, а другой нет, отчёт без указания семейства адресов скроет границу проблемы.
3. Сопоставьте MTR с проверкой сайта
MTR не проверяет HTML, авторизацию, базу данных и корректность ответа приложения. Одновременно зафиксируйте, открывается ли точный публичный URL, какой HTTP-код возвращается и на каком этапе возникает ошибка: DNS, соединение, TLS или ожидание ответа.
Для выбора между сетевой и прикладной проверкой полезен материал «Ping или HTTP-мониторинг: что действительно проверяет сайт».
4. Повторите измерение
Снимите отчёт во время проблемы и после её исчезновения. Если возможно, сравните результат из другой сети. Совпадающий симптом у адресата из нескольких точек весомее одной строки с потерями у промежуточного маршрутизатора.
Почему промежуточный hop может «терять» пакеты
Маршрутизатор прежде всего пересылает трафик. Формирование ICMP Time Exceeded для диагностического пакета относится к управляющей работе устройства и может иметь меньший приоритет или ограничиваться по частоте.
Ответа также может не быть из-за межсетевого экрана. При балансировке разные пробы проходят через разные узлы, а обратный путь ответа может отличаться от прямого. Поэтому по одному MTR нельзя определить загрузку канала или состояние интерфейса.
Отдельно проверьте, на какой IP разрешился домен. При нескольких A- или AAAA-записях два запуска могут тестировать разные серверы.
Какие данные передать провайдеру или администратору
Полезный диагностический пакет содержит:
- точный домен или публичный URL без токенов и персональных данных;
- дату, время и часовой пояс наблюдения;
- сеть и регион, откуда выполнялась проверка;
- полный текст MTR с параметрами запуска и указанием IPv4 или IPv6;
- описание пользовательского симптома и результат HTTP-проверки;
- отчёты во время сбоя и в нормальный период.
Не обрезайте верхние или нижние строки: без начала маршрута и конечного адреса невозможно понять, продолжается ли потеря. Не пишите, что «сломался узел N», если последующие hop отвечают нормально; опишите рисунок и попросите проверить участок.
Где заканчиваются возможности MTR
MTR помогает локализовать сетевой симптом, но не показывает обратный маршрут, правила балансировки, загрузку интерфейсов и внутренние журналы провайдера. Он также не заменяет проверку самого сайта.
Для постоянного контроля Web-Puls может фиксировать моменты, когда публичный URL перестаёт отвечать, а MTR полезно запускать во время инцидента. Если потеря доходит до конечного адреса, повторяется из разных сетей и причина остаётся неясной, отправьте заявку на профессиональную диагностику и приложите отчёты.
Вывод
Оценивайте не самый «красный» промежуточный hop, а сохранение потерь и задержки до конечного адреса вместе с реальным симптомом сайта. Такой порядок отделяет ограничение диагностических ответов от вероятной проблемы на маршруте.