> Полный список статей есть в [llms.txt](https://docs.f3cloud.com/llms.txt). Markdown-версия есть у каждой страницы, достаточно добавить .md к её адресу. Эта страница в Markdown: [https://docs.f3cloud.com/ru/vps/network-troubleshooting-traceroute.md](https://docs.f3cloud.com/ru/vps/network-troubleshooting-traceroute.md).
# Трассировка до сервера и проверка потерь пакетов – WinMTR, MTR и Speedtest
Как сделать трассировку до сервера и проверить потери пакетов. WinMTR в Windows, mtr и traceroute в macOS и Linux, обратная трассировка с VPS, режим TCP для VPN-портов, как читать результат и что отправить в поддержку.
Если сервер отвечает с задержкой, VPN подключается через раз, а игра или видеозвонок подтормаживают, первым делом нужно понять, **на каком участке пути** теряются пакеты. Проблема может быть у вашего провайдера, на магистрали между странами, в дата-центре или на самом сервере, и от этого зависит, кто может её исправить. В этой статье разберём, как устроена трассировка, сделаем три замера, которые нужны для диагностики, и научимся читать результат. Все команды мы проверили на тестовом сервере с Debian 12, а примеры вывода взяты из реальных замеров.
***
## Как устроена трассировка
Данные идут от вашего компьютера до сервера не напрямую, а через цепочку маршрутизаторов, и каждый из них называется **хопом**. Трассировка показывает эту цепочку. Она отправляет пакеты с постепенно растущим ограничением по числу хопов, которое называется TTL. Пакет с TTL, равным единице, «умирает» на первом маршрутизаторе, и тот сообщает об этом отправителю, пакет с TTL, равным двум, доходит до второго, и так далее. По этим ответам и собирается список узлов с задержкой до каждого из них.
Утилита **MTR** и её версия для Windows **WinMTR** делают то же самое, но не один раз, а непрерывно. Они отправляют пакеты к каждому хопу снова и снова и считают для каждого процент потерь и разброс задержки. Именно поэтому для диагностики нужен MTR, а не однократный `tracert`. Одна трассировка показывает маршрут в отдельный момент, а MTR показывает, как ведёт себя каждый участок за минуту или две.
У этого способа есть особенность, из-за которой результаты часто читают неправильно. Отвечать на служебные запросы трассировки для маршрутизатора второстепенная задача, и многие из них ограничивают такие ответы или не отвечают вовсе, хотя обычный трафик пропускают без потерь. Поэтому **потери на промежуточном хопе ещё не означают проблему**, важно, сохраняются ли они до самого конца маршрута. Кроме того, путь от вас до сервера и путь от сервера к вам часто проходят через разные узлы, поэтому полную картину дают только замеры в обе стороны.
***
## 1. Проверьте скорость самого сервера
Сначала убедимся, что с каналом сервера всё в порядке. Подключитесь к серверу по SSH, например через [Termius](https://docs.f3cloud.com/ru/vps/termius-connection.md), и запустите тест.
```bash
# Тест сервера, сети и скорости до нескольких точек мира
wget -qO- bench.sh | bash
```
Тест идёт несколько минут. Сначала скрипт покажет характеристики сервера и скорость диска, а в конце таблицу со скоростью загрузки, отдачи и задержкой до серверов в разных странах. Сделайте скриншот итоговой таблицы, текст вывода присылать не нужно.
> **Запускайте тесты по одному.**
>
> Speedtest и трассировка, запущенные одновременно, мешают друг другу. Тест скорости забивает канал, и трассировка показывает задержки, которых на самом деле нет.
***
## 2. Сделайте трассировку с компьютера до сервера
Перед замером **отключите VPN и прокси** на компьютере, иначе вы проверите маршрут до VPN-сервера, а не до своего. Если проблема заметна только в определённое время, например вечером, делайте замер именно тогда.
#### Windows
1. Скачайте **WinMTR** с [официального сайта](https://winmtr.net/) или из [репозитория на GitHub](https://github.com/White-Tiger/WinMTR/releases) и распакуйте архив.
2. Запустите WinMTR и в поле **Host** введите **IP-адрес сервера**.
3. Нажмите Start и подождите, пока в столбце **Sent** наберётся **200–300** пакетов. Это 3–5 минут.
4. Нажмите Stop и сохраните результат кнопкой Export TEXT или сделайте скриншот окна.
#### macOS
В macOS удобнее всего поставить **mtr** через [Homebrew](https://brew.sh).
```bash
# Устанавливаем mtr
brew install mtr
# Трассировка до сервера, 200 пакетов, с номерами сетей (AS)
sudo mtr -rwzc 200 IP_сервера
```
Если ставить Homebrew не хочется, подойдёт встроенная команда `traceroute IP_сервера`, но она проверяет маршрут только один раз.
#### Linux
```bash
# Устанавливаем mtr (Debian и Ubuntu)
sudo apt update && sudo apt install -y mtr-tiny
# Трассировка до сервера, 200 пакетов, с номерами сетей (AS)
sudo mtr -rwzc 200 IP_сервера
```
В AlmaLinux, Rocky Linux и CentOS Stream mtr ставится командой `sudo dnf install -y mtr`.
У mtr мы используем несколько ключей. `-r` выводит готовый отчёт вместо живого экрана, `-w` не обрезает имена узлов, `-z` показывает номер сети (AS), которой принадлежит узел, а `-c 200` задаёт число пакетов.
***
## 3. Сделайте обратную трассировку с сервера
Теперь проверим путь в обратную сторону, от сервера до вашего компьютера. Для этого нужен ваш внешний IP-адрес. Откройте с отключённым VPN сайт [2ip.ru](https://2ip.ru) и скопируйте адрес, который он покажет.
```bash
# Устанавливаем mtr на сервер (Debian и Ubuntu)
apt update && apt install -y mtr-tiny
# Трассировка от сервера до вашего компьютера
mtr -rwzc 200 ВАШ_IP
```
Сделайте скриншот или скопируйте отчёт целиком.
> **Если до вашего IP трассировка не доходит.**
>
> Многие домашние роутеры и провайдеры не отвечают на запросы трассировки, и последние строки отчёта будут со знаками `???`. Это нормально. В таком случае сделайте трассировку до адреса, который точно отвечает и находится рядом с вами, например до DNS-сервера Яндекса `77.88.8.8`.
***
## Если нужен VPN-порт, а не ping
Обычный mtr проверяет путь служебными пакетами ICMP. Бывает, что их пропускают, а соединение на конкретный порт, например VPN на порту `443`, режут. В этом случае включите режим **TCP**, и mtr будет стучаться прямо в нужный порт.
```bash
# Трассировка в режиме TCP на порт 443
sudo mtr -T -P 443 -rwzc 100 IP_сервера
```
Если обычный mtr доходит до сервера без потерь, а в режиме TCP потери начинаются на каком-то узле, значит, кто-то по пути ограничивает именно этот порт. Для IPv6-адреса добавьте ключ `-6`.
***
## Как читать результат
В отчёте mtr для каждого хопа есть несколько столбцов.
* **Loss%** показывает долю пакетов, на которые узел не ответил.
* **Snt** показывает, сколько пакетов отправлено.
* **Last, Avg, Best, Wrst** показывают задержку в миллисекундах, последнюю, среднюю, лучшую и худшую.
* **StDev** показывает разброс задержки. Чем он больше, тем нестабильнее связь.
Вот фрагмент реального отчёта с нашего тестового сервера в Германии до DNS-сервера Яндекса. Названия узлов провайдера мы скрыли.
```text
HOST: vm4096.hosted-by.f3cloud.com 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
```
На первый взгляд здесь пять узлов со стопроцентными потерями, но это как раз тот случай, когда **всё в порядке**. Эти маршрутизаторы просто не отвечают на служебные запросы, а до конечной точки дошли все 30 пакетов из 30, и задержка на ней стабильная. Рост задержки с 6 до 44 мс между 9-м и 12-м хопом объясняется расстоянием, ведь здесь трафик уходит из Франкфурта в Россию.
| Что видно в отчёте | Что это значит |
| --- | --- |
| Потери только на одном промежуточном хопе, дальше 0% | узел не отвечает на запросы, проблемы нет |
| Потери начинаются на хопе N и держатся до конца | реальная проблема на участке начиная с хопа N |
| Задержка резко выросла на одном хопе и так и осталась | обычно это граница стран или длинная магистраль, если рост постоянный |
| Большой разброс между Best и Wrst на последних хопах | нестабильная связь, часто перегрузка в часы пик |
| Все пакеты теряются на последних хопах, а до сервера ничего не доходит | сервер недоступен с вашей стороны, возможна блокировка IP-адреса на пути |
| Потери только с вашей стороны, а обратная трассировка чистая | ищите проблему у своего провайдера или в домашней сети |
> **Сравните Wi-Fi и кабель.**
>
> Если потери появляются уже на первом хопе, это ваш роутер или Wi-Fi. Повторите замер по кабелю или с другой сети, например с мобильного интернета.
***
## Что прислать в поддержку
Если вы не уверены, как понимать результат, просто пришлите замеры нам в тикет, мы разберёмся сами. В обращении укажите следующее.
1. IP-адрес сервера, ваш город и провайдера.
2. Дату и время, когда заметна проблема, с часовым поясом.
3. Скриншот теста скорости с сервера из шага 1.
4. Трассировку с компьютера до сервера из шага 2.
5. Обратную трассировку с сервера из шага 3.
6. Что именно не так, например «пинг в игре скачет вечером» или «VPN обрывается на мобильном интернете».
Если у вас несколько сетей, например домашний интернет и мобильный, пришлите замеры по каждой отдельно и подпишите, где какой. Это сразу показывает, связана ли проблема с конкретным провайдером.
***
## Частые вопросы
WinMTR показывает 100% потерь на одном из хопов, это плохо?
Чаще всего нет. Если на следующих хопах и на последнем потерь нет, этот узел просто не отвечает на служебные запросы, а трафик через него проходит нормально. Тревожный признак, когда потери начинаются на каком-то хопе и сохраняются до конца маршрута.
Команда mtr не найдена на сервере
Установите её командой для вашей системы. В Debian и Ubuntu это `apt install -y mtr-tiny`, в AlmaLinux, Rocky Linux и CentOS Stream это `dnf install -y mtr`.
Сколько пакетов отправлять?
Для обычной проверки хватит **100–200** пакетов, это 2–4 минуты. Если проблема появляется время от времени, увеличьте число до 500 или 1000 и запускайте замер в то время, когда она заметна.
Тест скорости показывает хорошую скорость, а сайты и VPN тормозят
Тест скорости на сервере проверяет только канал самого сервера. Если он в порядке, проблема где-то на пути между вами и сервером, и её покажут трассировки из шагов 2 и 3. Для VPN дополнительно сделайте трассировку в режиме TCP на порт вашего VPN.
***
## Наши ресурсы
**Telegram-канал:** [https://t.me/f3cloud_news](https://t.me/f3cloud_news)\
**Официальный сайт:** [https://f3cloud.com](https://f3cloud.com/ru)