WinMTR объединяет traceroute и повторяющийся ping. Он помогает увидеть маршрут, задержку и ответы промежуточных узлов, но потеря на одной строке ещё не доказывает неисправность этого маршрутизатора. Ключевой признак реальной проблемы — потери или рост задержки продолжаются на следующих хопах и достигают цели.
1. Устройство измерения и формулировка проблемы
Что именно делает WinMTR
WinMTR объединяет поиск промежуточных переходов и повторные измерения ответов. Вместо трёх проб, как в обычной трассировке, он накапливает Sent, Recv, Loss% и задержки по наблюдаемым узлам. Но промежуточный ответ генерирует сам маршрутизатор, тогда как пользовательский пакет он обычно пересылает другим механизмом. Поэтому два процесса могут иметь разные приоритеты и ограничения.
Сформулируйте симптом до измерения: «видеоконференция замирает каждые пять минут», «SSH разрывается», «веб-страница иногда отвечает 504». У них разные вероятные причины. WinMTR даёт сетевые наблюдения, но не измеряет состояние базы приложения и не обнаруживает автоматически ошибку TLS.
Фиксируйте точный целевой IP. Имя может разрешаться в разные CDN-адреса, а приложение может ходить через proxy. В первом случае разные запуски нельзя смешивать в одну выборку; во втором прямой маршрут до сайта не обязательно является путём рабочего приложения.
Проверяйте адрес сервиса, где проявляется проблема: игровой сервер, VPN-шлюз, сайт или SIP-провайдер. Тест до публичного DNS не объяснит разрывы другого маршрута. Запишите время и тип подключения.
Выберите конкретный адрес, семейство IP и окно наблюдения
Возьмём пример: сотрудники жалуются на обрывы HTTPS к portal.example.com с офисного ПК. Сначала определите A/AAAA адреса и реальный адрес, который выбрал браузер. CDN может выдавать разные IP разным резолверам; тест до вчерашнего адреса другой площадки не воспроизводит сегодняшний сбой.
Resolve-DnsName portal.example.com -Type A
Resolve-DnsName portal.example.com -Type AAAA
Get-NetIPConfigurationЗапишите адрес цели, время с часовым поясом, интерфейс, наличие VPN и симптом: тайм-аут соединения, прерывание загрузки или задержка ответа приложения. WinMTR до IP измеряет ответы этого IP; ошибка HTTP500 без потерь сети требует анализа приложения. Для IPv6 выбирайте инструмент, который действительно поддерживает IPv6, а не автоматически повторяйте IPv4-результат.
2. Выбор проекта и доверенная загрузка
Старая оригинальная утилита и поддерживаемость альтернатив
У исходного проекта WinMTR есть исторический выпуск и ограничения сопровождения. Не называйте его автоматически «самой свежей современной диагностикой». Страница WinMTR-Official позволяет проверить происхождение проекта. Отдельный fork White-Tiger добавляет свои возможности, включая IPv6, но его следует обозначать другим проектом и проверять совместимость конкретного выпуска.
Откройте Releases выбранного проекта, изучите выпуск и наличие готового Windows-архива, соответствующего системе. Исходный код в ZIP — не обязательно готовая программа. Если бинарника нет, используйте согласованное средство диагностики, а не случайный repack из поисковой выдачи. Собственный вычисленный hash нужен для фиксации полученного файла, но подтверждает подлинность лишь при сравнении с доверенно опубликованным значением.
Для Linux есть mtr с другим набором ключей. Команды mtr нельзя выдавать за команды Windows WinMTR. Доступные поля и экспорт также сверяйте с выбранным клиентом.
Официальный проект опубликован в репозитории WinMTR-Official. Проверьте архив и разрядность, не используйте сборку с рекламного каталога. Приложение портативное и не требует установки.
Версия и происхождение инструмента имеют значение
Первичный репозиторий WinMTR-Official содержит историческую ветку и описывает ограниченное сопровождение. Форк WinMTR Redux отдельно добавляет IPv6. Это разные сборки; в отчёте укажите источник, версию и семейство адресов. Не называйте любой скачанный ZIP «последним официальным». Скачивайте по ссылке разработчика, проверяйте контрольную сумму, если она опубликована, и используйте процедуру разрешённого ПО организации.
Архив распакуйте в отдельный пользовательский каталог. Для штатной диагностики не требуется копировать бинарник в System32. Если запуск блокирует EDR, согласуйте разрешение конкретного приложения; отключение защиты всего ПК меняет условия теста и увеличивает риск. WinMTR Redux — первичный репозиторий.
3. Контрольные условия: кабель, Wi-Fi и VPN
Поставить контрольный опыт дома и в офисе
Первый опыт выполняйте по кабелю, если жалоба наблюдалась через Wi-Fi. Иначе задержки доступа к радиоканалу смешиваются с проблемой провайдера. Сохраните одинаковую цель, выключите только согласованную лишнюю нагрузку и запишите, включён ли VPN. Повторите в момент жалобы и в спокойный период.
| Опыт | Что остаётся одинаковым | Что он помогает разделить |
|---|---|---|
| Wi-Fi и кабель | Цель, время около симптома | Локальная радиосеть и путь дальше |
| VPN включён/выключен, если это разрешено | Сервис и семейство адресов | Разные маршруты доступа |
| Шлюз LAN и конечный сервис | Сеть клиента | Локальная доступность и end-to-end наблюдение |
| Два согласованных внешних источника | IP сервиса | Доступность зависит от источника или общей стороны |
Сам шлюз может ограничивать Echo, поэтому даже здесь показатель Loss% нуждается в сопоставлении. Отдельный ping до gateway не заменяет измерение работы Wi-Fi на уровне радиоканала.
По возможности подключитесь кабелем, отключите VPN и фоновые загрузки. Сначала проверьте шлюз, затем внешнюю цель. Отдельный тест по Wi-Fi нужен для сравнения, а не смешивания причин.
ipconfig
ping -n 50 192.168.1.1
ping -n 50 example.comЛокальный baseline и исключение Wi-Fi
Сначала сохраните текущие параметры; замените адрес шлюза из ipconfig, не копируйте 192.168.1.1, если он не ваш. Тест по проводу проводите с тем же ПК и целевым IP. Не отключайте корпоративный VPN, если сервис доступен только через него: вместо этого явно разделите разрешённые сценарии.
Если шлюз теряет ответы, повторите тест до другого доступного LAN-узла и проверьте ошибки интерфейса. Маршрутизатор может ограничивать собственный ICMP, поэтому потери к шлюзу без потерь к внешней цели ещё не доказывают дефект кабеля. На Wi-Fi сравните RSSI, канал, повторные передачи и момент смены точки; MTR сам не показывает радиоэфир. Когда только Wi-Fi ухудшает конечный результат, сначала исследуют локальную среду, затем магистраль провайдера.
4. Запуск, длительность и полный экспорт
Как запускать измерение и сохранять весь результат
В поле Host укажите выбранный IP либо имя; при имени запишите реально использованный адрес. В Options задайте умеренный интервал, например одну секунду, оставьте сопоставимые параметры и начните Start. Соберите несколько минут, захватывая симптом. Остановите тест и экспортируйте таблицу в доступном вашей версии текстовом или HTML-формате.
300 проб при интервале около секунды дают примерно пять минут для конечного ряда; фактическая длительность зависит от реализации, тайм-аутов и числа узлов. Значение Sent может различаться между строками. Не меняйте цель или сеть посередине теста: начните новый измерительный интервал и подпишите его отдельно.
Скриншот без последних строк часто скрывает важнейший факт — отвечает ли конечная цель. Экспорт с Host, Loss%, Sent, Recv, Best, Avg и Worst позволяет проверить интерпретацию. Сначала сохраните внутреннюю полную копию, затем подготовьте наружную с учётом адресов и имён вашей инфраструктуры.
Введите hostname без протокола и пути, нажмите Start и дождитесь минимум нескольких сотен пакетов или появления симптома. Короткий тест из десяти ответов плохо показывает периодические провалы.
Пошаговый запуск и экспорт
Откройте WinMTR, в Host введите только hostname или IP без https:// и пути. В Options оставьте умеренный интервал около секунды и стандартный размер пакета; запишите параметры. Нажмите Start. Дождитесь 300–600 проб либо согласованного интервала, охватывающего симптом. Не запускайте десятки окон с минимальными интервалами: вы можете сами вызвать ограничение ICMP.
Зафиксируйте минуту ошибки приложения. Нажмите Stop, экспортируйте текст и отдельно сохраните скриншот полного окна. Нажмите Clear History/очистку перед новым сравнительным прогоном, чтобы не смешивать предыдущие счётчики с новой сетью. Без конечной строки и количества Sent таблица не позволяет проверить вывод. Пять минут при одном пакете в секунду дают около 300 проб, но не гарантируют, что редкий ночной сбой был пойман.
5. Поля таблицы, арифметика и выборка
Поля таблицы, формула и ограничения короткой выборки
| Поле | Значение | Частая неверная трактовка |
|---|---|---|
| Host | Ответивший адрес/имя | Это обязательно физический маршрутизатор отдельного здания |
| Sent | Количество отправленных проб для ряда | Одинаковое число у всех строк гарантировано |
| Recv | Количество учтённых ответов | Все пользовательские TCP-пакеты были доставлены |
| Loss% | Доля неучтённых ответов в данной выборке | На линке потерян тот же процент полезного трафика |
| Best | Минимальный измеренный RTT | Точная задержка одного кабеля |
| Avg | Средний RTT полученных ответов | Средняя задержка всех пользовательских транзакций |
| Worst | Наибольший учтённый RTT | Постоянная скорость сети |
| Last, если есть | Последний учтённый RTT | Надёжнее всей предыдущей выборки |
Для завершённого сопоставимого интервала Loss% приблизительно равен 100 × (Sent − Recv) / Sent. Округление и незавершённые пробы могут влиять на отображение. При 300 отправленных и 294 полученных получается 2%. Для проверки арифметики это достаточно, для локализации причины — нет.
Ноль потерь не доказывает отсутствие редкого отказа. Если условно считать потери независимыми с вероятностью 1%, вероятность не увидеть ни одной за 300 проб равна 0.99^300, около 4,9%. Это учебная модель, а не гарантированный confidence interval для реального burst loss. Короткий интервал особенно плохо ловит событие, возникающее раз в час.
Loss% показывает долю неответивших проб, Sent/Recv — объём выборки, Best/Avrg/Wrst/Last — задержку. Среднее без Worst скрывает всплески, а Worst без повторяемости может быть единичным событием.
Числа на учебном примере
Host Loss% Sent Recv Best Avrg Wrst Last
LAN-gateway 0 300 300 1 2 11 1
ISP-control-plane 80 300 60 10 14 35 12
transit 0 300 300 21 24 44 22
service 0 300 300 27 31 58 29Это иллюстрация, а не измерение AVG IT. Доля отсутствующих ответов (Sent-Recv)/Sent×100: у второго узла 240/300=80%. Поскольку последующие узлы получают все пробы, нельзя говорить о 80% потерь транзита на нём. Best близок к задержке без очереди, Avrg показывает среднее ответивших проб, Wrst — самый высокий наблюдаемый RTT, Last — последнюю пробу. У неответивших проб нет измеренного RTT; среднее не включает их как «бесконечную задержку».
6. Высокие потери промежуточных ответов
Случай A: 80% на промежуточном узле и 0% на цели
Узел Sent Recv Loss Avg
192.168.10.1 300 300 0% 1 ms
198.51.100.1 300 60 80% 70 ms
203.0.113.10 300 300 0% 15 msЭто учебные адреса и числа. Дальняя цель ответила на все 300 проб. Следовательно, таблица не доказывает 80% потерь пересылаемого трафика на втором узле. Возможны ограничение ICMP-ответов, иной приоритет CPU или фильтрация ответного направления. Если бы 80% полезных пакетов стабильно терялось там для того же потока, наблюдение цели потребовало бы другого объяснения.
Название control plane описывает обработку собственных сообщений устройства. Forwarding plane — пересылку проходящих пакетов. Ограничение первой части может защищать маршрутизатор, не ухудшая обычную пересылку. Не требуйте от провайдера отключить защиту только ради красивого ряда WinMTR.
Маршрутизатор может ограничивать ICMP к собственному control plane и при этом нормально пересылать пользовательский трафик. Если хоп показывает 80% loss, а все следующие и цель — 0%, транзит не потерян. Смотрите, продолжается ли эффект дальше.
Почему control plane даёт ложное подозрение
На промежуточном маршрутизаторе обычный пакет может пересылаться аппаратно, а ответ ICMP Time Exceeded формируется процессором и ограничивается отдельной политикой. Устройство способно переслать тысячу пакетов и ответить лишь на часть диагностических обращений. Строка No response from host с отвечающими узлами ниже показывает невидимый хоп, не полный обрыв канала.
Обратная ситуация тоже возможна: ICMP идёт хорошо, но TCP к нужному порту блокируется ACL или UDP теряется в очереди другого класса. Поэтому корректный вывод формулируют как «в выбранном ICMP-тесте наблюдается такой результат», а не «сеть абсолютно исправна».
7. Потери конечной цели и границы локализации
Случай B: потери продолжаются до конца
Узел Sent Recv Loss Avg
192.168.10.1 500 500 0% 1 ms
198.51.100.1 500 485 3% 12 ms
198.51.100.2 500 480 4% 18 ms
203.0.113.10 500 480 4% 21 msТут конечная цель недодаёт ответы. Первый подозрительный участок — после локального gateway или его ответного пути. Но не следует назвать первый ряд с 3% «точно неисправным портом»: пробы разных рядов не являются одним и тем же пакетом, обратный путь неизвестен, ICMP может обрабатываться отдельно.
Повторите интервал, сравните кабель/Wi-Fi, другую цель в согласованной сети и реальное приложение. При доступе к оборудованию сопоставьте counters интерфейсов: ошибки, drops, загрузку, очереди. Без таких данных WinMTR даёт основание расследовать участок, но не доказательство конкретной аппаратной неисправности.
Реальный кандидат появляется там, где loss или задержка начинаются и сохраняются на последующих узлах до цели. Первый хоп указывает на LAN/Wi-Fi, следующий — на доступ провайдера, дальние — на транзит или сеть сервиса.
Сохраняющееся ухудшение — повод исследовать границу
Host Loss% Sent Recv Avrg
LAN 0 500 500 1
access 4 500 480 20
transit 4 500 480 35
service 5 500 475 42Здесь потери до цели подтверждены диагностическими пробами. Ухудшение начинается возле доступа, но конкретное устройство ещё не установлено: каждую строку измеряют независимыми пакетами, обратный маршрут неизвестен, а промежуточные ответы могут лимитироваться. Потребуются тест с другой стороны, показатели ошибок интерфейса, очередей и корреляция с приложением. Небольшая разница 4% и 5% на выборке 500 не позволяет точно присвоить «ещё 1%» следующему хопу.
Если на первом хопе 0%, а цель потеряла ответы, не исключайте офис полностью: пересылка трафика через WAN/NAT отличается от ping к самому шлюзу.
8. Всплески задержки и интерпретация Worst
Случай C: плохой Worst без постоянных потерь
Средний RTT 20 мс, Worst 400 мс и Loss=0 могут означать единичную очередь или задержку ответа. Для голоса, удалённого рабочего стола и интерактивной работы одиночные всплески важны, но из одного Worst нельзя восстановить частоту. Одинаковый максимум может получиться у одного всплеска за час и у каждого второго пакета.
Сохраните несколько коротких интервалов и время жалобы. Для оценки jitter используйте инструмент и определение, подходящие приложению: вариация RTT не равна автоматически jitter RTP. При bulk download очереди доступа могут увеличиваться без потерь; повторите тест с обычной рабочей нагрузкой, а затем без лишнего трафика, сохраняя условия.
Запустите тест в момент проблемы и вне пика, по кабелю и Wi-Fi, с VPN и без него, если это разрешено. Маршрут обратного трафика может отличаться, поэтому WinMTR показывает не всю картину.
Матрица сравнений вместо случайного переключения
Сделайте четыре отдельных отчёта, где меняется один фактор: провод утром, провод в час проблемы, Wi-Fi в то же окно, альтернативный разрешённый канал до того же IP. При VPN добавьте имя туннеля и точку выхода. Смена сервера или DNS вместе со сменой подключения разрушает сравнение.
Запросите встречный тест от администратора сервиса до разрешённого офисного адреса, если архитектура это допускает. Из-за NAT обратная трассировка может завершиться на шлюзе; это ограничение нужно отметить. Anycast и ECMP иногда меняют маршрут без изменения hostname, поэтому сохраняйте именно фактические IP и полный результат.
9. Сопоставление с TCP, TLS и приложением
Сетевой ответ и прикладной ответ проверяют отдельно
На Windows проверка TCP до своего сервиса:
Test-NetConnection service.example.com -Port 443 -InformationLevel DetailedTcpTestSucceeded=True означает установление TCP в условиях теста, но не успешный login или HTTP. Для HTTPS можно использовать установленный curl:
curl --connect-timeout 5 --max-time 15 -o /dev/null -sS -w 'connect=%{time_connect} tls=%{time_appconnect} first_byte=%{time_starttransfer} total=%{time_total}\n' https://service.example.com/Этот Bash-пример использует /dev/null и предназначен Linux/macOS. На Windows применяйте curl.exe с соответствующим путём вывода либо свой прикладной клиент. Времена curl накопительные от старта: для длительности отдельной стадии нужно вычесть предыдущую отметку. Ошибка HTTP 500/504 может исходить от приложения или его upstream; один маршрут без потерь не объясняет её причину.
Если цель фильтрует ICMP, WinMTR может не показать конечный ответ при работающем TCP/HTTPS. Не снимайте firewall-защиту production-сервиса ради измерения, если можно выбрать согласованную диагностическую цель.
ICMP может обрабатываться иначе, чем TCP/UDP приложения. Сопоставьте WinMTR со временем ошибок, логами VPN, звонка или игры, TCP-проверкой порта и загрузкой. Не делайте вывод по одной картинке.
Test-NetConnection example.com -Port 443 -InformationLevel Detailed
ping -n 200 example.comПодтверждение TCP и HTTPS
TcpTestSucceeded=True подтверждает TCP handshake, но не скорость передачи и не корректность HTTPS. Для приложения измерьте ограниченный по времени запрос без отключения проверки сертификата:
Test-NetConnection portal.example.com -Port 443 -InformationLevel Detailed
curl.exe --connect-timeout 5 --max-time 15 -o NUL -sS -w "code=%{http_code} ip=%{remote_ip} connect=%{time_connect} tls=%{time_appconnect} total=%{time_total}\n" https://portal.example.com/time_connect и time_appconnect отсчитываются от начала запроса, а не являются независимыми длительностями стадий. HTTP401 может означать нормальный ответ защищённого портала, HTTP500 — отказ приложения, code000 — отсутствие HTTP-ответа. Не помещайте токены/пароли в пример или отчёт. Совпадение потерь на конечной строке с тайм-аутами повышает уверенность в сетевой причине; одиночный успешный запрос не исключает периодический сбой.
10. Технический отчёт с проверяемым выводом
Какой отчёт помогает поддержке
Симптом: что именно не работает, начало и длительность.
Источник: кабель/Wi-Fi, сеть доступа, VPN, семейство IP.
Цель: hostname и фактический IP, приложение и порт.
Инструмент: проект/версия, параметры, интервал.
Измерение: начальное и конечное время, полный экспорт.
Контроль: второй опыт с одной изменённой переменной.
Приложение: результат TCP/TLS/HTTP в то же время.
Вывод: наблюдения отдельно от неподтверждённой причины.К отчёту не нужна фотография любой строки с красным процентом. Нужны сопоставимые условия и конечный результат. Если точная локализация не получена, следующий шаг — конкретный дополнительный опыт, а не обвинение первого устройства с высоким Loss%.
Экспортируйте текст без внутренних адресов и персональных данных, укажите дату, часовой пояс, целевой hostname, тип линии, длительность, проводной baseline и момент симптома. Не обрезайте последние строки: поведение цели критично для интерпретации.
Что передать провайдеру и как проверить исправление
Сохраните полную исходную таблицу во внутреннем обращении. Для публичной копии обезличьте внутренние имена, сохранив номера строк, счётчики и указание, что адрес скрыт. Укажите исходный/целевой IP в защищённом канале поддержки, длительность, протокол, время, версию клиента, симптом и сравнение с baseline. Вывод «хоп №4 виноват» замените доказательством: где начинается эффект, доходит ли он до цели и какой прикладной отказ совпал по времени.
После ремонта повторите исходный тест при сопоставимой нагрузке и проверьте приложение. Если конечная цель перестала терять ответы, но один промежуточный узел всё ещё даёт 80%, это не основание отклонить исправление. MTR — режимы и параметры первичного инструмента.
Источники: WinMTR-Official, Microsoft Learn — tracert, Microsoft Learn — pathping.