Traceroute (в Windows — tracert) показывает путь пакета от вашего компьютера до сервера, перечисляя все промежуточные маршрутизаторы (хопы) и время отклика каждого. Читают вывод сверху вниз: резкий рост задержки или подряд идущие звёздочки * * * указывают на хоп, где начались проблемы с сетью или маршрутом.
Эта статья объясняет, как работает traceroute на уровне TTL и ICMP, как запустить его в Windows, Linux и macOS, как читать колонки вывода (номер хопа, три значения RTT, звёздочки) и как по расположению проблемного хопа понять, кто виноват — ваша сеть, провайдер или целевой сервер. Разберём и типичную ловушку: почему промежуточные хопы «врут» о задержке.
Что такое traceroute и зачем он нужен
Traceroute — диагностическая утилита, которая строит список маршрутизаторов на пути к цели и измеряет задержку до каждого из них. В отличие от Ping, который отвечает лишь «доступен хост или нет», traceroute показывает где именно на маршруте теряется связь или растёт задержка. Это ключевой инструмент, когда сайт открывается медленно, а простой ping до него не выявляет очевидной проблемы.
Инструмент есть в каждой ОС: tracert в Windows, traceroute в Linux и macOS. Продвинутая версия — mtr — объединяет traceroute и ping, непрерывно опрашивая каждый хоп и показывая процент потерь пакетов в реальном времени.
Как traceroute работает: TTL и ICMP
В основе лежит поле TTL (Time To Live) в заголовке IP-пакета. Каждый маршрутизатор на пути уменьшает TTL на единицу; когда TTL достигает нуля, маршрутизатор отбрасывает пакет и отправляет обратно ICMP-сообщение «Time Exceeded» (Тип 11 по RFC 792).
Traceroute использует это хитро: он отправляет первый пакет с TTL=1 — тот «умирает» на первом маршрутизаторе, и тот раскрывает свой адрес. Затем TTL=2 — ответит второй хоп, и так далее. Наращивая TTL, утилита по очереди «вытаскивает» каждый маршрутизатор на пути. Windows использует ICMP Echo-запросы, классический Unix-traceroute — UDP-пакеты на высокие порты, но принцип истечения TTL одинаков.
Как запустить traceroute
Команда почти одинакова во всех системах — отличается только имя утилиты. Откройте терминал (в Windows — «Командную строку» или PowerShell) и введите одну из команд ниже, заменив example.com на нужный домен или IP.
# Windows
tracert example.com
# Linux / macOS
traceroute example.com
# mtr — traceroute + ping в реальном времени (Linux/macOS)
mtr example.comПолезные ключи: в Windows tracert -d отключает разрешение имён (быстрее, только IP), tracert -h 30 задаёт максимум хопов. В Linux traceroute -n — тоже без DNS, traceroute -I переключает на ICMP (как Windows), traceroute -T — на TCP, что полезно, когда фаервол режет UDP.
Как читать вывод: колонки и звёздочки
Каждая строка вывода — это один хоп. Слева номер хопа, затем имя и/или IP маршрутизатора, а справа три значения времени отклика (RTT) в миллисекундах — traceroute шлёт три пробы на каждый хоп для надёжности. Таблица ниже расшифровывает элементы строки.
| Элемент строки | Что означает |
|---|---|
| Номер хопа (1, 2, 3…) | Порядковый номер маршрутизатора от вас к цели; хоп 1 — обычно ваш роутер/шлюз |
| Имя хоста / IP | Адрес маршрутизатора, ответившего на этом хопе; имя раскрывается через обратный DNS |
| RTT ×3 (мс) | Три замера времени «туда-обратно»; разброс нормален, важна общая тенденция |
* (звёздочка) | Проба не получила ответа за таймаут: пакет потерян ИЛИ хоп не отвечает на traceroute |
* * * | Все три пробы без ответа на этом хопе |
Пример реального вывода с пояснением
traceroute to example.com (93.184.216.34), 30 hops max
1 192.168.1.1 1.2 ms 1.1 ms 1.3 ms
2 10.0.0.1 8.5 ms 9.1 ms 8.7 ms
3 91.200.15.1 12.4 ms 11.9 ms 13.0 ms
4 * * *
5 213.248.65.9 24.6 ms 25.1 ms 24.9 ms
6 152.195.44.1 88.2 ms 90.5 ms 87.9 ms
7 93.184.216.34 89.1 ms 88.7 ms 89.4 msРазбор: хоп 1 (192.168.1.1) — домашний роутер, задержка около 1 мс. Хоп 2 — шлюз провайдера. Хоп 4 показывает * * *, но хопы 5–7 отвечают нормально — значит, четвёртый маршрутизатор просто не отвечает на пробы (это не потеря связи). Скачок с 25 до 88 мс между хопами 5 и 6 — это дальний магистральный переход (вероятно, межконтинентальный канал), а не поломка: задержка остаётся стабильной до самой цели.
Что значат звёздочки и высокий RTT
Главная ошибка новичка — паниковать при виде * или большого RTT на промежуточном хопе. В большинстве случаев это нормально. Разберём два сценария.
Звёздочки * * * посередине маршрута
Если хоп не отвечает, но следующие за ним отвечают нормально, проблемы нет. Многие маршрутизаторы намеренно депориоритизируют или блокируют ICMP-ответы «Time Exceeded» ради безопасности и снижения нагрузки — они прекрасно пересылают ваш трафик, но не тратят ресурсы на ответ traceroute. Тревожный признак — только когда звёздочки идут от какого-то хопа и до самого конца: тогда пакеты реально дальше не проходят.
Почему промежуточные хопы «врут» о задержке
Высокий RTT на одном промежуточном хопе, если на последующих хопах задержка снова падает, — не проблема. RTT промежуточного хопа отражает не сквозную задержку, а то, насколько быстро именно этот маршрутизатор нашёл время ответить на служебный ICMP. Обработка транзитного трафика для него приоритетнее, поэтому ответ traceroute может задержаться. Смотрите на RTT последнего хопа (цели) и на общую тенденцию, а не на отдельный «горб» посередине.
Как найти виновника проблемы
Расположение проблемного хопа подсказывает, чья это зона ответственности. Ориентируйтесь по таблице.
| Где растёт задержка / потери | Вероятная причина | Что делать |
|---|---|---|
| Хоп 1–2 (ваш роутер, шлюз) | Ваша локальная сеть, Wi-Fi, кабель | Проверьте роутер, подключитесь по кабелю, перезагрузите |
| Первые хопы провайдера (3–5) | Сеть вашего интернет-провайдера | Зафиксируйте вывод и обратитесь в поддержку провайдера |
| Магистральные/транзитные хопы посередине | Промежуточный оператор связи (обычно вне вашего контроля) | Часто временно; редко решается на вашей стороне |
| Последний хоп (цель) или предпоследний | Целевой сервер или его хостинг/дата-центр | Проблема на стороне сайта; сообщите его владельцу/хостеру |
| Потери с середины и до конца | Обрыв маршрута на этом хопе | Проблема у оператора этого хопа |
Важное правило: потери должны сохраняться до конца маршрута, чтобы считаться реальными. Потеря только на одном хопе с восстановлением на следующем — это депориоритизация ICMP, а не сбой. Запустите traceroute несколько раз или используйте mtr, чтобы увидеть устойчивый процент потерь, а не случайный всплеск.
Как проверить свой маршрут
Не хотите разбираться с командной строкой — воспользуйтесь бесплатной трассировкой маршрута прямо в браузере: она покажет все хопы и RTT в удобной таблице. Чтобы отделить проблему задержки от потерь пакетов, дополнительно запустите проверку ping до целевого хоста. Если ping стабилен, но сайт медленный, ищите узкое место в traceroute; если ping «прыгает» и теряет пакеты — проблема в канале.
Полезно почитать по теме: как исправить высокий ping и потери пакетов, разница между задержкой и пропускной способностью и чем TCP отличается от UDP.
Частые вопросы
Чем tracert отличается от traceroute?
Это одна и та же утилита в разных ОС. tracert — команда в Windows, она использует ICMP Echo-запросы. traceroute — команда в Linux и macOS, по умолчанию она шлёт UDP-пакеты. Логика работы через истечение TTL идентична; отличаются лишь имя команды, протокол по умолчанию и набор ключей.
Почему traceroute показывает звёздочки, но интернет работает?
Звёздочки * * * означают, что конкретный маршрутизатор не ответил на служебную пробу traceroute. Многие роутеры намеренно игнорируют или депориоритизируют такие ответы ради безопасности и производительности, при этом исправно пересылая ваш реальный трафик. Если хопы после звёздочек отвечают нормально — беспокоиться не о чем.
Какой RTT считается нормальным?
Всё зависит от расстояния. До сайтов внутри вашей страны нормой считается 5–40 мс, до других континентов — 100–250 мс из-за физического расстояния и скорости света в оптоволокне. Важнее не абсолютное число, а стабильность: резкие скачки и рост потерь тревожнее, чем стабильно высокая, но ровная задержка.
Traceroute показал высокую задержку на среднем хопе — это проблема?
Скорее всего, нет. Если на последующих хопах задержка снова падает, высокий RTT посередине — это лишь медленный ответ конкретного маршрутизатора на служебный ICMP, а не реальная задержка вашего трафика. Ориентируйтесь на RTT последнего хопа (цели) и на общую тенденцию сверху вниз, а не на отдельный «горб».
Как определить, кто виноват — я, провайдер или сайт?
Смотрите, с какого хопа начинаются устойчивые проблемы. Первый-второй хоп — ваша локальная сеть. Ранние хопы с именами вашего провайдера — его сеть. Последний хоп или предпоследний — целевой сервер и его хостинг. Проблемы на магистральных хопах посередине обычно вне зоны вашего контроля.
Почему стоит использовать mtr вместо обычного traceroute?
mtr объединяет traceroute и ping: он непрерывно опрашивает каждый хоп и показывает процент потерь и среднюю задержку в реальном времени. Это надёжнее одиночного прогона traceroute, потому что единичный * может быть случайностью, а устойчивый процент потерь на протяжении десятков проб — уже реальный сигнал о проблеме.