tanaka.host  / блог
RSSЗаказать VPS
Введение/Сеть

mtr и WinMTR: ищем, где теряются пакеты до сервера

Как устроена трассировка, три замера для диагностики (скорость сервера, mtr до сервера, обратный mtr с сервера), режим TCP для VPN-портов и чтение Loss%/Avg/StDev без ложных тревог. Windows, macOS, Linux.

23 октября 2026 г.·6 мин чтения·mtr, traceroute, network

Сервер отвечает с задержкой, VPN подключается через раз, в игре скачет пинг по вечерам. Первое, что нужно понять — на каком участке пути теряются пакеты: у вашего провайдера, на магистрали между странами, в дата-центре или на самом сервере. От этого зависит, кто вообще может это починить.

Как устроена трассировка

Данные идут до сервера через цепочку маршрутизаторов — хопов. Трассировка отправляет пакеты с растущим TTL: пакет с TTL=1 «умирает» на первом маршрутизаторе, и тот сообщает об этом; с TTL=2 — на втором, и так далее. Из ответов собирается список узлов с задержкой до каждого.

traceroute и tracert делают это один раз. mtr (и WinMTR на Windows) — непрерывно: шлют пакеты к каждому хопу снова и снова и считают процент потерь и разброс задержки на каждом участке. Поэтому для диагностики нужен именно mtr: одна трассировка — срез в момент времени, mtr — поведение каждого участка за минуты.

Две особенности, из-за которых отчёты читают неправильно:

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

1. Скорость самого сервера

Сначала убедимся, что с каналом сервера всё в порядке. По SSH на сервере:

wget -qO- bench.sh | bash

Скрипт несколько минут показывает характеристики сервера, скорость диска и в конце таблицу со скоростью и задержкой до точек в разных странах. Альтернатива — Speedtest CLI.

Запускайте тесты по одному. Тест скорости забивает канал, и запущенная параллельно трассировка покажет задержки, которых нет.

2. Трассировка с компьютера до сервера

Перед замером отключите VPN и прокси — иначе вы проверите путь до VPN-сервера, а не до своего. Если проблема заметна в определённое время, замеряйте именно тогда.

Windows. Скачайте WinMTR, запустите, в поле Host введите IP сервера, нажмите Start. Дождитесь 200–300 пакетов в столбце Sent (3–5 минут), нажмите Stop и Export TEXT или сделайте скриншот окна.

macOS:

brew install mtr
sudo mtr -rwzc 200 IP_СЕРВЕРА

Без Homebrew подойдёт встроенный traceroute IP_СЕРВЕРА, но он проверяет маршрут только один раз.

Linux:

sudo apt update && sudo apt install -y mtr-tiny     # Debian, Ubuntu
sudo dnf install -y mtr                              # AlmaLinux, Rocky
sudo mtr -rwzc 200 IP_СЕРВЕРА

Ключи: -r — готовый отчёт вместо живого экрана, -w — не обрезать имена узлов, -z — показывать номер автономной системы (AS) каждого узла, -c 200 — число пакетов.

3. Обратная трассировка с сервера

Теперь путь от сервера к вам. Узнайте свой внешний IP с отключённым VPN (любой сервис «мой IP» или curl ifconfig.me на компьютере) и на сервере:

sudo apt update && sudo apt install -y mtr-tiny
mtr -rwzc 200 ВАШ_IP

Если до вашего IP трассировка не доходит и последние строки — ???, это нормально: домашние роутеры и провайдеры часто не отвечают. Сделайте замер до адреса, который точно отвечает и находится рядом с вами — например, DNS вашего провайдера или 77.88.8.8.

4. Если режут порт, а не ICMP

Обычный mtr проверяет путь ICMP-пакетами. Бывает, что их пропускают, а соединения на конкретный порт — скажем, VPN на 443 — режут. Режим TCP стучится прямо в порт:

sudo mtr -T -P 443 -rwzc 100 IP_СЕРВЕРА

Если ICMP-mtr доходит без потерь, а в TCP потери начинаются на каком-то узле — кто-то по пути ограничивает именно этот порт. Для IPv6 добавьте -6, для UDP (WireGuard) — -u -P 51820.

Как читать отчёт

Столбец Значение
Loss% Доля пакетов, на которые узел не ответил
Snt Отправлено пакетов
Last / Avg / Best / Wrst Задержка, мс: последняя, средняя, лучшая, худшая
StDev Разброс задержки. Чем больше, тем нестабильнее участок

Фрагмент реального отчёта с сервера в Германии до DNS в России:

HOST: server                                Loss%   Snt   Last   Avg  Best  Wrst StDev
  1. AS???    100.64.0.1                     0.0%    30    0.1   0.1   0.1   0.3   0.0
  2. AS???    ???                           100.0    30    0.0   0.0   0.0   0.0   0.0
  3. AS???    ???                           100.0    30    0.0   0.0   0.0   0.0   0.0
  4. AS???    узел провайдера                0.0%    30    6.1   6.1   6.0   6.3   0.1
  5. AS???    узел провайдера                0.0%    30    6.0   6.1   6.0   6.3   0.1
  6. AS???    ???                           100.0    30    0.0   0.0   0.0   0.0   0.0
  7. AS174    be9515.rcr31.fra06.atlas.cogentco.com   0.0%    30    6.5   6.6   6.4   7.0   0.1
  8. AS174    be4517.rcr22.fra06.atlas.cogentco.com   0.0%    30    6.9   6.8   6.6   7.4   0.2
  9. AS174    149.11.21.114                  0.0%    30    6.4   6.4   6.2   6.7   0.1
 10. AS???    ???                           100.0    30    0.0   0.0   0.0   0.0   0.0
 11. AS???    ???                           100.0    30    0.0   0.0   0.0   0.0   0.0
 12. AS13238 dns.yandex.ru (77.88.8.8)       0.0%    30   44.8  44.7  44.6  44.9   0.1

Пять узлов со 100 % потерь — и всё в порядке: они просто не отвечают на служебные пакеты, а до конечной точки дошли все 30 из 30 со стабильной задержкой. Скачок с 6 до 44 мс между 9-м и 12-м хопом — расстояние: трафик ушёл из Франкфурта в Россию.

Что видно Что значит
Потери на одном промежуточном хопе, дальше 0 % Узел не отвечает на запросы, проблемы нет
Потери начинаются на хопе N и держатся до конца Реальная проблема с хопа N
Задержка резко выросла на одном хопе и осталась Граница стран или длинная магистраль, если рост постоянный
Большой разброс Best/Wrst на последних хопах Нестабильная связь, часто перегрузка в часы пик
Все пакеты теряются с какого-то хопа, до сервера ничего не доходит Сервер недоступен с вашей стороны, возможна блокировка IP по пути
Потери только с вашей стороны, обратный замер чистый Проблема у вашего провайдера или в домашней сети

Потери на первом хопе — это ваш роутер или Wi-Fi. Повторите по кабелю или с мобильного интернета.

Что прислать в поддержку

Если не уверены, как понимать отчёт — приложите замеры к тикету в кабинете tanaka.host:

  1. IP сервера, ваш город и провайдер.
  2. Дата и время проявления проблемы с часовым поясом.
  3. Скриншот теста скорости из шага 1.
  4. Трассировка с компьютера до сервера из шага 2.
  5. Обратная трассировка с сервера из шага 3.
  6. Симптом словами: «пинг в игре скачет вечером», «VPN рвётся на мобильном».

Если сетей несколько — домашняя и мобильная — замеры по каждой отдельно, с подписью. Это сразу показывает, привязана ли проблема к провайдеру.

Частые вопросы

100 % потерь на одном хопе — это плохо? Чаще всего нет. Если дальше и на последнем хопе потерь нет — узел просто молчит. Тревожно, когда потери начинаются где-то и держатся до конца.

Сколько пакетов слать? 100–200 для обычной проверки, это 2–4 минуты. Если проблема плавающая — 500–1000 и именно в то время, когда она заметна.

Тест скорости хороший, а сайт и VPN тормозят. Тест скорости проверяет только канал сервера. Если он в порядке — проблема на пути между вами, и её покажут шаги 2 и 3. Для VPN дополнительно замер в режиме TCP/UDP на порт VPN.

mtr не найден на сервере — apt install -y mtr-tiny или dnf install -y mtr.

Если маршрут чистый, а конкретное соединение не устанавливается — смотрите, доходят ли пакеты до сервера, через tcpdump, и открыт ли порт через nc.