YouTube на домашнем Wi-Fi тормозит. На мобильном — летает. В другой квартире того же дома — тоже летает. Голосовые в Telegram рассыпаются каждые пять минут. Игровой сервер пингует 200 мс, хотя физически в том же городе. Где ломается? Провайдер говорит «у нас всё хорошо», Telegram говорит «у нас всё хорошо», все говорят «у нас всё хорошо». А у вас — не хорошо.
В этот момент на сцену выходят три скромных инструмента, о которых знает каждый сетевой инженер и не знает никто другой — `ping`, `traceroute` и `mtr`. С их помощью за десять минут можно ткнуть пальцем в конкретный участок маршрута, где теряются пакеты, и превратить «провайдер плохой» в «на 7-м хопе за границей Ростелекома потери 12%, вот скриншот».
Если коротко
- `ping` — проверяет, жив ли узел и какая задержка. Самое базовое.
- `traceroute` (Windows — `tracert`) — показывает цепочку роутеров между вами и целью. Даёт карту.
- `mtr` — гибрид первых двух, непрерывно считает потери и задержку на каждом шаге. Король диагностики.
Как вообще устроена маршрутизация
Интернет не один большой провод. Когда вы открываете сайт, ваш запрос проходит через десяток-другой промежуточных маршрутизаторов: домашний роутер → оборудование провайдера → городской узел → магистральный узел → межрегиональный стык → оборудование дата-центра сайта. Каждая такая точка — хоп (hop). На любом из них может возникнуть проблема: оборудование перегружено, канал забит, у оператора стыковка с соседом отвалилась.
Все три инструмента работают через пакеты ICMP (или UDP/TCP), у которых постепенно увеличивается поле TTL. Каждый роутер на пути уменьшает TTL на 1; когда TTL достигает нуля, роутер отбрасывает пакет и посылает вам жалобу «у меня тут пакет умер». Таким образом, отправляя пакет с TTL=1, 2, 3, 4… вы последовательно получаете ответы от каждого промежуточного узла.
Ping — самое базовое
Это ваша первая команда. Проверяет, достижим ли узел и сколько идёт ответ.
# macOS / Linux
ping -c 10 ya.ru
# Windows
ping -n 10 ya.ru
Что смотреть в выводе:
- Все пакеты дошли? Если 10/10 — связь стабильная. Если 8/10 — есть потери, ищем где.
- Какой time= в миллисекундах? Норма: соседний город ≤20 мс, другой континент 100-200 мс, через спутник 500+ мс.
- Разброс (jitter)? Если time скачет от 10 до 300 — у вас нестабильное соединение.
Ping говорит, что проблема есть. Он не говорит где.
Traceroute — карта маршрута
Отсюда начинается интересное. Traceroute показывает каждый роутер на пути.
# macOS / Linux
traceroute ya.ru
# Windows
tracert ya.ru
# Современная альтернатива (Linux)
tracepath ya.ru
Вывод похож на это:
1 192.168.1.1 1.0 ms — ваш домашний роутер
2 10.32.0.1 4.2 ms — первая точка провайдера
3 msk-agg-01.rt.ru 8.1 ms — агрегация в Москве
4 msk-core-02.rt.ru 9.0 ms — ядро в Москве
5 moscow-ix.net 12.3 ms — точка обмена трафиком
6 yandex-peer.net 13.0 ms — стык с Яндексом
7 ya.ru 14.1 ms — цель
Если на каком-то хопе время выросло с 10 мс до 150 мс — узкое место найдено. Если хоп вообще не отвечает («* * *») и следующие работают — это просто роутер, настроенный не отвечать на ICMP (часто так у магистралов). Не страшно. Если же «* * *» идёт до конца маршрута — связь обрубилась.
Один важный момент
Traceroute показывает только прямой маршрут (от вас к цели). Обратный путь может идти совершенно другим путём, и у многих проблем именно обратный путь — источник. Для этого есть `traceroute` в обратную сторону с цели, но у вас к ней обычно нет доступа.
MTR — король сетевой диагностики
Это то, что используют сами сетевые инженеры. Сочетает ping и traceroute, показывая непрерывно потери и задержку на каждом хопе в живом режиме.
# Linux
sudo apt install mtr && mtr ya.ru
# macOS (через Homebrew)
brew install mtr && sudo mtr ya.ru
# Windows — WinMTR или PingPlotter Free
Вывод выглядит как таблица, которая обновляется каждую секунду:
Host Loss% Snt Last Avg Best Wrst StDev
1. 192.168.1.1 0.0% 100 0.9 1.0 0.8 1.2 0.1
2. 10.32.0.1 0.0% 100 4.0 4.1 3.5 5.2 0.3
3. msk-agg-01.rt.ru 0.0% 100 8.5 8.7 7.9 10.1 0.4
4. msk-core-02.rt.ru 0.0% 100 9.1 9.3 8.7 11.5 0.5
5. moscow-ix.net 12.0% 100 125 130 85 210 32.1
6. yandex-peer.net 12.0% 100 128 135 90 220 34.0
7. ya.ru 12.0% 100 130 138 92 225 35.2
Читайте так: «потери появились на 5-м хопе и пошли дальше». Это значит проблема ИМЕННО на 5-м хопе — `moscow-ix.net`. Хопы до него — чистые. Именно это вы покажете провайдеру, и он больше не сможет отвечать «всё хорошо».
Почему MTR лучше обычного traceroute
- Traceroute делает 3 пакета на хоп — недостаточно для статистики. MTR делает сотни.
- Traceroute снимок — MTR показывает динамику во времени.
- В MTR видно StDev — разброс задержек, который говорит о загруженности канала.
- MTR умеет UDP / TCP / ICMP, что полезно когда ICMP фильтруется.
Типичные сценарии
«Только один сайт тормозит»
MTR до этого сайта и до нескольких других (ya.ru, google.com, ваш банк). Если потери видны только на маршруте к конкретному сайту — проблема у него или у его транзитного провайдера. Если потери появляются на одном и том же вашем хопе независимо от цели — проблема ближе, у вашего провайдера.
«Тормозит вечером»
Запустите MTR на 5 минут утром (чисто), потом на 5 минут вечером (проблема). Скриншоты. Потери, появляющиеся на конкретном хопе именно вечером — классика перегруженного канала у провайдера. Отличный аргумент в тикете.
«Связь рвётся случайно»
Оставьте MTR на час. Экспортируйте отчёт (`mtr --report-cycles 3600 ya.ru > report.txt`). Если потери приходят волнами — проблема в оборудовании, а не в канале.
«Игра показывает высокий пинг»
Узнайте IP игрового сервера и запустите MTR до него. Игровой трафик идёт по другому маршруту, чем веб-трафик, поэтому «сайты работают, игра лагает» — типичная ситуация.
Ограничения и подводные камни
- Многие роутеры отвечают на ICMP с более высоким приоритетом, чем реально обрабатывают трафик. Высокий ping не всегда значит реальную проблему.
- Некоторые маршрутизаторы вообще не отвечают на ICMP — вы увидите «* * *», но сам трафик проходит нормально.
- TCP/UDP-трассировка (`mtr -T`, `mtr -u`) часто даёт более точную картину, чем ICMP.
- В корпоративных сетях файрволы могут блокировать traceroute целиком — результат будет бесполезен.
- Traceroute показывает только прямой маршрут — обратный путь невидим без доступа к целевому серверу.
Как правильно обратиться с результатами в техподдержку
Плохой тикет: «Интернет плохой, YouTube тормозит, сделайте что-нибудь!». Хороший тикет:
Добрый день.
У меня с 20:00 МСК 17 апреля наблюдаются потери пакетов и повышенная задержка
при обращении к ya.ru и google.com. MTR показывает, что потери 12-15%
появляются на хопе 5 (moscow-ix.net, IP 193.0.2.10). До этого хопа
маршрут чист.
Мой IP: 1.2.3.4
Тариф: Оптимальный 200 Мбит
Логин: ivanov_a
Во вложении — MTR-отчёт за 5 минут утром (всё ок) и за 5 минут вечером (потери).
Пожалуйста, проверьте состояние вашего стыка с этим узлом.
С таким тикетом техподдержка не сможет отмахнуться. Провайдер либо признает проблему, либо переключит вас на нужного специалиста.
Частые вопросы
Зачем разница между `traceroute` и `tracert`?
Это одно и то же, просто на Windows команду переименовали. Работают одинаково, параметры местами отличаются.
MTR показывает высокие потери, а интернет работает — как так?
Вероятнее всего, промежуточный роутер отвечает на ICMP с низким приоритетом или вообще деприоритизирует трассировку. Реальный трафик через него идёт нормально. Проверяйте потери по TCP-варианту: `mtr -T -P 443 ya.ru`.
Можно ли сделать traceroute с мобильного телефона?
Да: для Android есть `Network Utilities` и `PingTools`, для iPhone — `Network Analyzer`. Они менее детальные, чем десктопный MTR, но для быстрой диагностики хватает.
Почему первый хоп — это мой роутер?
Потому что он первый на пути вашего пакета наружу. Дальше идёт оборудование провайдера, и так до цели.
Ping времени 5 мс — это хорошо или плохо?
Для соседнего города или узла провайдера — отлично. Для сайта в другой стране — нереально (может значить, что цель — CDN-нода рядом с вами, это нормально для Cloudflare/Google).
Что такое «tracepath» и чем отличается от traceroute?
Это современная и более простая альтернатива в Linux. Не требует root-прав, использует UDP, показывает MTU на пути. Функционально почти то же.