Трассировка — это проверка маршрута, по которому пакеты идут от вашего компьютера до сервера: утилита tracert в Windows или traceroute в Linux и macOS перечисляет все промежуточные маршрутизаторы (хопы) и время отклика каждого. Вывод читают сверху вниз: резкий рост задержки или звёздочки * * * до самого конца указывают на хоп, где начались проблемы с сетью или маршрутом.
Ниже — как работает трассировка на уровне TTL и ICMP, как сделать её в командной строке Windows, в Linux и macOS, как читать колонки вывода (номер хопа, три значения RTT, звёздочки), как пользоваться MTR и WinMTR, чтобы видеть процент потерь, и как по расположению проблемного хопа понять, кто виноват — ваша сеть, провайдер или целевой сервер. Разберём и типичную ловушку: почему промежуточные хопы «врут» о задержке. Трассировка лучей в видеокартах и графике — другое понятие, здесь речь только о сетевой трассировке.
Что такое трассировка маршрута и зачем она нужна
Traceroute — диагностическая утилита, которая строит список маршрутизаторов на пути к цели и измеряет задержку до каждого из них. В отличие от ping, который отвечает лишь «доступен хост или нет», трассировка пути показывает где именно на маршруте теряется связь или растёт задержка. Это ключевой инструмент, когда сайт открывается медленно, а простой ping до него не выявляет очевидной проблемы.
Инструмент есть в каждой ОС: tracert в Windows, traceroute в Linux и macOS. Продвинутая версия — mtr (и WinMTR для Windows) — объединяет traceroute и ping, непрерывно опрашивая каждый хоп и показывая процент потерь пакетов в реальном времени.
Типичные ситуации, когда без трассировки не обойтись:
- сайт или сервер открывается медленно только у части пользователей или только из одного региона;
- хостер пишет «у нас всё работает», а у вас соединение обрывается;
- после смены провайдера, VPS или дата-центра выросла задержка;
- нужно понять, в какой сети — своей, провайдерской или транзитной — пропадают пакеты, и приложить доказательство к обращению в поддержку.
Как traceroute работает: TTL и ICMP
В основе лежит поле TTL (Time To Live) в заголовке IP-пакета. Каждый маршрутизатор на пути уменьшает TTL на единицу; когда TTL достигает нуля, маршрутизатор отбрасывает пакет и отправляет обратно ICMP-сообщение «Time Exceeded» (Тип 11 по RFC 792).
Traceroute использует это хитро: он отправляет первый пакет с TTL=1 — тот «умирает» на первом маршрутизаторе, и тот раскрывает свой адрес. Затем TTL=2 — ответит второй хоп, и так далее. Наращивая TTL, утилита по очереди «вытаскивает» каждый маршрутизатор на пути. Когда пакет доходит до самой цели, она отвечает уже не «Time Exceeded», а обычным ответом (Echo Reply для ICMP или «Port Unreachable» для UDP) — так утилита понимает, что маршрут закончен. Windows использует ICMP Echo-запросы, классический Unix-traceroute — UDP-пакеты на высокие порты, но принцип истечения TTL одинаков.
Отсюда важное следствие: трассировка показывает путь только в одну сторону — от вас к серверу. Обратный путь ответов может проходить через совсем других операторов (асимметричная маршрутизация), поэтому при сложных проблемах трассировку делают с обеих сторон.
Как сделать трассировку в Windows (tracert), Linux и macOS
Команда почти одинакова во всех системах — отличается только имя утилиты и набор ключей. Вместо example.com подставьте нужный домен или IP-адрес: трассировка до сервера по IP работает так же, как по имени, только без шага DNS-резолвинга.
# Windows
tracert example.com
# Linux / macOS
traceroute example.com
# mtr — traceroute + ping в реальном времени (Linux/macOS)
mtr example.comКоманда трассировки в cmd (Windows)
- Нажмите Win + R, введите
cmdи нажмите Enter — откроется командная строка. Права администратора дляtracertне нужны. - Введите
tracert -d example.com. Ключ-dотключает обратное разрешение имён: трассировка идёт заметно быстрее, в выводе остаются только IP. - Дождитесь строки «Трассировка завершена.» — по умолчанию утилита проходит до 30 хопов и на каждый шлёт три пробы.
- Чтобы отправить результат в поддержку, сохраните его в файл:
tracert -d example.com > %USERPROFILE%\Desktop\trace.txt— файл появится на рабочем столе.
Полезные ключи команды tracert: -h 40 — максимум хопов, -w 2000 — таймаут ожидания ответа в миллисекундах, -4 и -6 — принудительно IPv4 или IPv6. Полный список — в документации Microsoft по tracert.
C:\>tracert -d example.com
Трассировка маршрута к example.com [93.184.216.34]
с максимальным числом прыжков 30:
1 1 ms 1 ms 1 ms 192.168.1.1
2 9 ms 8 ms 9 ms 10.0.0.1
3 12 ms 12 ms 13 ms 91.200.15.1
4 * * * Превышен интервал ожидания для запроса.
5 25 ms 25 ms 24 ms 213.248.65.9
6 88 ms 90 ms 88 ms 152.195.44.1
7 89 ms 88 ms 89 ms 93.184.216.34
Трассировка завершена.Обратите внимание: в Windows три значения RTT стоят перед адресом хопа, а в Linux и macOS — после. Сообщение «Превышен интервал ожидания для запроса.» (в английской Windows — «Request timed out.») — это те же звёздочки: хоп не ответил за таймаут.
В PowerShell есть встроенная альтернатива: Test-NetConnection example.com -TraceRoute выводит список адресов хопов (без RTT по каждому). А pathping example.com в cmd сначала строит маршрут, затем несколько минут опрашивает каждый хоп и показывает процент потерь — это штатный для Windows аналог MTR.
Трассировка в Linux (traceroute)
Во многих минимальных сборках утилиты нет — установите её пакетным менеджером: sudo apt install traceroute (Debian, Ubuntu) или sudo dnf install traceroute (RHEL, AlmaLinux, Fedora). Если ставить ничего нельзя, почти всегда доступна tracepath из пакета iputils: она работает без root и заодно показывает MTU на пути.
traceroute -n example.com # без DNS, только IP
sudo traceroute -I example.com # ICMP, как в Windows
sudo traceroute -T -p 443 example.com # TCP на порт 443
traceroute -6 example.com # по IPv6
tracepath -n example.com # без rootРежим -T особенно полезен для трассировки до сервера за фаерволом: UDP и ICMP часто режутся, а TCP на порт 443 или 80 пропускают, потому что на нём работает сайт. Разбор TCP и UDP — в статье чем TCP отличается от UDP. Все ключи Linux-версии описаны в man-странице traceroute.
Трассировка в macOS
Откройте «Терминал» (Программы → Утилиты → Терминал или поиск Spotlight) и выполните traceroute -n example.com. Утилита уже установлена. Для ICMP-проб добавьте -I, для IPv6 в macOS используется отдельная команда traceroute6. MTR ставится через Homebrew: brew install mtr, запускать его нужно через sudo.
Сравнение ключей tracert и traceroute
| Задача | Windows (tracert) | Linux (traceroute) | macOS (traceroute) |
|---|---|---|---|
| Без разрешения имён | -d | -n | -n |
| Максимум хопов | -h 40 | -m 40 | -m 40 |
| Таймаут ответа | -w 2000 (мс) | -w 2 (с) | -w 2 (с) |
| Протокол по умолчанию | ICMP | UDP | UDP |
| Переключиться на ICMP | — | -I (root) | -I |
| Трассировка по TCP | нет, только сторонние утилиты | -T -p 443 (root) | — |
| IPv6 | -6 | -6 | команда traceroute6 |
| Сохранить в файл | > trace.txt | > trace.txt | > trace.txt |
Как читать вывод трассировки: колонки и звёздочки
Каждая строка вывода — это один хоп. Слева номер хопа, затем имя и/или IP маршрутизатора, а справа три значения времени отклика (RTT) в миллисекундах — traceroute шлёт три пробы на каждый хоп для надёжности. Таблица ниже расшифровывает элементы строки.
| Элемент строки | Что означает |
|---|---|
| Номер хопа (1, 2, 3…) | Порядковый номер маршрутизатора от вас к цели; хоп 1 — обычно ваш роутер/шлюз |
| Имя хоста / IP | Адрес маршрутизатора, ответившего на этом хопе; имя раскрывается через обратный DNS |
| RTT ×3 (мс) | Три замера времени «туда-обратно»; разброс нормален, важна общая тенденция |
* (звёздочка) | Проба не получила ответа за таймаут: пакет потерян ИЛИ хоп не отвечает на traceroute |
* * * | Все три пробы без ответа на этом хопе |
!H, !N, !X (Linux/macOS) | Хост недоступен, сеть недоступна, связь запрещена администратором — маршрутизатор явно отказал |
| «Заданный узел недоступен.» (Windows) | Маршрутизатор на пути сообщил, что до цели нет маршрута |
Пример реального вывода с пояснением
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 — шлюз провайдера; адрес из диапазона 10.0.0.0/8 — частный, это нормально для внутренней сети оператора. Хоп 4 показывает * * *, но хопы 5–7 отвечают нормально — значит, четвёртый маршрутизатор просто не отвечает на пробы (это не потеря связи). Скачок с 25 до 88 мс между хопами 5 и 6 — это дальний магистральный переход (вероятно, межконтинентальный канал), а не поломка: задержка остаётся стабильной до самой цели.
Чтобы понять, какому оператору принадлежит хоп, посмотрите обратное DNS-имя (его покажет запуск без -d/-n) или номер автономной системы по IP. Имена вида xe-1-0-0.msk-core.provider.net часто подсказывают город и тип узла, но это соглашение оператора, а не стандарт.
Что значат звёздочки и высокий RTT
Главная ошибка новичка — паниковать при виде * или большого RTT на промежуточном хопе. В большинстве случаев это нормально. Разберём два сценария.
Звёздочки * * * посередине маршрута
Если хоп не отвечает, но следующие за ним отвечают нормально, проблемы нет. Многие маршрутизаторы намеренно депориоритизируют или блокируют ICMP-ответы «Time Exceeded» ради безопасности и снижения нагрузки — они прекрасно пересылают ваш трафик, но не тратят ресурсы на ответ traceroute. Тревожный признак — только когда звёздочки идут от какого-то хопа и до самого конца: тогда пакеты реально дальше не проходят.
Есть и третий вариант: звёздочки только на последнем хопе, при этом сайт открывается. Так бывает, когда сервер или его фаервол не отвечает на ICMP и UDP. Повторите трассировку по TCP (sudo traceroute -T -p 443) — если цель ответила, маршрут в порядке.
Почему промежуточные хопы «врут» о задержке
Высокий RTT на одном промежуточном хопе, если на последующих хопах задержка снова падает, — не проблема. RTT промежуточного хопа отражает не сквозную задержку, а то, насколько быстро именно этот маршрутизатор нашёл время ответить на служебный ICMP. Обработка транзитного трафика для него приоритетнее, поэтому ответ traceroute может задержаться. Смотрите на RTT последнего хопа (цели) и на общую тенденцию, а не на отдельный «горб» посередине. Подробнее о том, чем задержка отличается от скорости канала, — в статье разница между задержкой и пропускной способностью.
MTR и WinMTR — трассировка с потерями
Одиночная трассировка — это снимок из трёх проб на хоп. Единичная звёздочка в нём может оказаться случайностью, а кратковременный всплеск задержки — не попасть вовсе. MTR (в Linux и macOS) и WinMTR (графическая программа для Windows) шлют пробы непрерывно и считают статистику по каждому хопу: процент потерь, среднюю, лучшую и худшую задержку.
Как запустить mtr в отчётном режиме
Установка: sudo apt install mtr-tiny (Debian, Ubuntu; консольная версия без графики), sudo dnf install mtr (RHEL, Fedora), brew install mtr (macOS). Интерактивный режим удобен для наблюдения, но для поддержки нужен отчёт:
mtr -rwn -c 100 example.com # 100 проб, отчёт, без DNS
sudo mtr -rwn -T -P 443 -c 100 example.com # то же по TCP на порт 443Ключ -r включает режим отчёта, -w не обрезает длинные имена, -n отключает DNS, -c 100 задаёт число проб. Сто проб дают устойчивую картину, а не случайный всплеск.
Как читать Loss% и Avg
HOST: myhost Loss% Snt Last Avg Best Wrst StDev
1.|-- 192.168.1.1 0.0% 100 1.1 1.2 0.9 3.4 0.3
2.|-- 10.0.0.1 0.0% 100 8.6 8.9 8.1 15.2 0.9
3.|-- 91.200.15.1 40.0% 100 12.2 12.5 11.8 20.1 1.1
4.|-- 213.248.65.9 0.0% 100 24.8 25.0 24.3 31.7 0.8
5.|-- 93.184.216.34 0.0% 100 88.9 89.2 88.1 95.0 1.0| Колонка MTR | Колонка WinMTR | Что показывает |
|---|---|---|
| Loss% | Loss % | Доля проб без ответа на этом хопе |
| Snt | Sent / Recv | Сколько проб отправлено (и получено — в WinMTR) |
| Last | Last | RTT последней пробы, мс |
| Avg | Avrg | Средний RTT — главная цифра для оценки задержки |
| Best / Wrst | Best / Worst | Минимальный и максимальный RTT за все пробы |
| StDev | — | Разброс задержки; большой разброс означает нестабильный канал (джиттер) |
В примере на хопе 3 потеряно 40% проб, но на хопах 4 и 5 потерь нет — это ограничение ICMP-ответов на маршрутизаторе, а не потеря вашего трафика. Реальная проблема выглядит иначе: процент потерь появляется на каком-то хопе и сохраняется на всех последующих, включая последний (например, 12%, 11%, 12% до самой цели). То же с задержкой: значим только рост Avg, который держится до конца маршрута.
WinMTR в Windows
WinMTR не требует установки: скачайте архив, запустите исполняемый файл нужной разрядности, введите домен или IP в поле Host и нажмите Start. Дайте программе поработать несколько минут, чтобы набралось 100–200 проб, затем нажмите Stop и выгрузите результат кнопкой Export TEXT или Copy Text to clipboard — этот текст и отправляют провайдеру или хостеру. Читается таблица так же, как отчёт mtr.
Как найти виновника проблемы
Расположение проблемного хопа подсказывает, чья это зона ответственности. Ориентируйтесь по таблице.
| Где растёт задержка / потери | Вероятная причина | Что делать |
|---|---|---|
| Хоп 1–2 (ваш роутер, шлюз) | Ваша локальная сеть, Wi-Fi, кабель | Проверьте роутер, подключитесь по кабелю, перезагрузите |
| Первые хопы провайдера (3–5) | Сеть вашего интернет-провайдера | Зафиксируйте вывод и обратитесь в поддержку провайдера |
| Магистральные/транзитные хопы посередине | Промежуточный оператор связи (обычно вне вашего контроля) | Часто временно; редко решается на вашей стороне |
| Последний хоп (цель) или предпоследний | Целевой сервер или его хостинг/дата-центр | Проблема на стороне сайта; сообщите его владельцу/хостеру |
| Потери с середины и до конца | Обрыв маршрута на этом хопе | Проблема у оператора этого хопа |
Важное правило: потери должны сохраняться до конца маршрута, чтобы считаться реальными. Потеря только на одном хопе с восстановлением на следующем — это депориоритизация ICMP, а не сбой. Запустите traceroute несколько раз или используйте mtr, чтобы увидеть устойчивый процент потерь, а не случайный всплеск. Как устранять высокий пинг и потери, когда источник найден, — в статье как исправить высокий ping и потери пакетов.
Что приложить к обращению в поддержку
- отчёт
mtr -rwn -c 100или экспорт WinMTR, а не скриншот одного прогона tracert; - дату, время и часовой пояс замера — проблемы часто зависят от часа нагрузки;
- ваш внешний IP и IP целевого сервера;
- по возможности — трассировку в обратную сторону, с сервера до вашего IP, чтобы исключить асимметричный маршрут;
- для сравнения — трассировку до того же сервера из другой сети или онлайн-сервиса.
Как проверить маршрут: трассировка онлайн
Не хотите разбираться с командной строкой — воспользуйтесь бесплатной трассировкой маршрута прямо в браузере: она покажет все хопы и RTT в удобной таблице. Онлайн-трассировка идёт не с вашего компьютера, а с сервера сервиса, поэтому её удобно сравнивать с локальной: если из внешней точки маршрут до сайта чистый, а у вас — нет, проблема на участке вашего провайдера или в домашней сети.
Чтобы отделить проблему задержки от потерь пакетов, дополнительно запустите проверку ping до целевого хоста. Если ping стабилен, но сайт медленный, ищите узкое место в traceroute; если ping «прыгает» и теряет пакеты — проблема в канале. Как правильно измерять пинг в разных ОС — в статье как проверить пинг до сервера и сайта. Определить, какому оператору принадлежит подозрительный хоп, поможет поиск ASN по IP-адресу, а узнать, у какого хостера находится сам сайт, — инструкция как узнать хостинг и IP сайта.
Какой инструмент выбрать
| Инструмент | Где работает | Показывает потери по хопам | Когда использовать |
|---|---|---|---|
tracert | Windows | Нет, только 3 пробы | Быстро посмотреть путь до сервера |
traceroute | Linux, macOS | Нет, только 3 пробы | То же, плюс режимы ICMP и TCP |
pathping | Windows | Да, после нескольких минут сбора | Потери по хопам без установки программ |
mtr | Linux, macOS | Да, непрерывно | Поиск нестабильных потерь, отчёт для поддержки |
| WinMTR | Windows | Да, непрерывно | То же, что mtr, в графическом окне |
| Трассировка онлайн | Браузер | Зависит от сервиса | Взгляд на маршрут из внешней точки, без командной строки |
Частые вопросы
Чем tracert отличается от traceroute?
Это одна и та же утилита в разных ОС. tracert — команда в Windows, она использует ICMP Echo-запросы. traceroute — команда в Linux и macOS, по умолчанию она шлёт UDP-пакеты. Логика работы через истечение TTL идентична; отличаются лишь имя команды, протокол по умолчанию и набор ключей.
Почему traceroute показывает звёздочки, но интернет работает?
Звёздочки * * * означают, что конкретный маршрутизатор не ответил на служебную пробу traceroute. Многие роутеры намеренно игнорируют или депориоритизируют такие ответы ради безопасности и производительности, при этом исправно пересылая ваш реальный трафик. Если хопы после звёздочек отвечают нормально — беспокоиться не о чем.
Какой RTT считается нормальным?
Всё зависит от расстояния. До сайтов внутри вашей страны нормой считается 5–40 мс, до других континентов — 100–250 мс из-за физического расстояния и скорости света в оптоволокне. Важнее не абсолютное число, а стабильность: резкие скачки и рост потерь тревожнее, чем стабильно высокая, но ровная задержка. Высокий RTT на одном среднем хопе при нормальной задержке дальше — не проблема.
Как определить, кто виноват — я, провайдер или сайт?
Смотрите, с какого хопа начинаются устойчивые проблемы. Первый-второй хоп — ваша локальная сеть. Ранние хопы с именами вашего провайдера — его сеть. Последний хоп или предпоследний — целевой сервер и его хостинг. Проблемы на магистральных хопах посередине обычно вне зоны вашего контроля.
Почему стоит использовать mtr вместо обычного traceroute?
mtr объединяет traceroute и ping: он непрерывно опрашивает каждый хоп и показывает процент потерь и среднюю задержку в реальном времени. Это надёжнее одиночного прогона traceroute, потому что единичный * может быть случайностью, а устойчивый процент потерь на протяжении десятков проб — уже реальный сигнал о проблеме.
Трассировка остановилась на «Превышен интервал ожидания для запроса» — что делать?
Если эта строка повторяется до 30-го хопа, пакеты дальше не проходят или цель не отвечает на ICMP. Проверьте, открывается ли сайт в браузере: если открывается, сервер просто фильтрует ICMP — повторите трассировку по TCP (sudo traceroute -T -p 443 в Linux) или онлайн. Если не открывается, сохраните вывод и передайте его оператору того хопа, после которого начались сплошные таймауты.
