> ## Documentation Index > Fetch the complete documentation index at: https://docs.edisglobal.com/llms.txt > Use this file to discover all available pages before exploring further. # Как понимать потери пакетов в traceroute и MTR > Интерпретация потерь пакетов в traceroute и MTR на виртуальном VPS: почему потери на промежуточных узлах часто вызваны ограничением ICMP и не означают неисправность. Клиенты часто сообщают о потерях пакетов, увидев после traceroute или MTR **80% или даже 100% потерь на промежуточных узлах**. Но во многих случаях **на конечном узле потерь нет вообще**. Эта статья объясняет, как правильно читать MTR и отличать реальные проблемы соединения от безвредных особенностей обработки диагностического трафика маршрутизаторами. *** ## Кратко * Потери на **промежуточных узлах** **не означают проблему автоматически**. * Важнее всего **последний узел** — ваш VPS или целевой хост. * Многие маршрутизаторы **снижают приоритет ответов ICMP или ограничивают их частоту**. * Виртуальные среды добавляют уровни, где диагностический ICMP может обрабатываться иначе, чем обычный трафик приложений. **Начните с конечного узла, затем проверьте приложение.** Отсутствие потерь на конечном узле в одной выборке — хороший признак, но оно не исключает периодические проблемы или сбои других протоколов. *** ## Как на самом деле измеряются потери **traceroute** и **MTR** отправляют диагностические пакеты, обычно ICMP или UDP, и измеряют ответы маршрутизаторов. Представьте, что они спрашивают каждый маршрутизатор на пути: > «Можешь ответить мне прямо сейчас?» Некоторые маршрутизаторы не отвечают, **но продолжают нормально передавать реальный трафик приложений**. Маршрутизаторы оптимизированы для **пересылки трафика**, а не ответов на диагностические запросы. Под нагрузкой они могут: * ограничивать частоту ответов ICMP; * отбрасывать диагностические пакеты; * отвечать непостоянно. В MTR это выглядит как потери, даже когда пользовательский трафик проходит нормально. *** ## Как правильно проводить тесты Перед интерпретацией потерь убедитесь, что тест выполнен правильно. ### Использование traceroute и MTR Следуйте пошаговому руководству: 👉 [Руководство по traceroute и MTR](https://docs.edisglobal.com/ru/faq/ip-addresses/debugging-packet-loss-traceroute-mtr-windows.md) Запускайте MTR минимум на **100 циклов** для получения содержательной статистики. ### Использование ping.pe Для внешней проверки из нескольких локаций: 👉 [Проверка подключения через ping.pe](https://docs.edisglobal.com/ru/faq/ip-addresses/ping-pe-connectivity-check.md) Это помогает определить, является ли проблема локальной или глобальной. *** ## Как читать вывод MTR Примеры ниже **иллюстративные** и сокращены до важных столбцов. Каждая строка соответствует **100 запросам**; задержка указана в миллисекундах. Сначала читайте **строку назначения**, затем сравнивайте предыдущие узлы. ### Сценарий 1: потери только на промежуточных узлах > [card] 01 · Потерь на конечном узле не обнаружено > > > [!TIP] > > > > **Конечный узел: 0% потерь.** В этом тесте отсутствие ответов на предыдущих узлах не продолжается до назначения. > > | Узел | Потери | Отправлено | Средняя задержка | > | - | -: | -: | -: | > | Маршрутизатор 1 | 80% | 100 | 2 мс | > | Маршрутизатор 2 | 100% | 100 | — | > | Маршрутизатор 3 | 0% | 100 | 18 мс | > | **Назначение** | **0%** | **100** | **20 мс** | > > **Что заметно:** маршрутизатор 2 совсем не отвечает, но последующие узлы и назначение отвечают. Его молчание не доказывает, что он отбрасывает весь пересылаемый трафик. > > **Что делать:** если приложение тоже работает нормально, одних промежуточных потерь недостаточно для сообщения о сбое. Маршрутизаторы могут фильтровать или ограничивать диагностические ответы. ### Сценарий 2: потери продолжаются до последнего узла > [card] 02 · Потери на конечном узле требуют проверки > > > [!WARNING] > > > > **Конечный узел: 10% потерь.** Ответы теряются и от назначения. Повторите тест и сопоставьте результаты с работой приложения. > > | Узел | Потери | Отправлено | Средняя задержка | > | - | -: | -: | -: | > | Маршрутизатор 1 | 0% | 100 | 2 мс | > | Маршрутизатор 2 | 0% | 100 | 8 мс | > | **Маршрутизатор 3** | **10%** | 100 | 18 мс | > | **Маршрутизатор 4** | **10%** | 100 | 20 мс | > | **Назначение** | **10%** | **100** | **22 мс** | > > **Что заметно:** потери сохраняются до назначения, поэтому их нельзя объяснить только отсутствием ответа одного промежуточного маршрутизатора. > > **Что делать:** сохраните полный отчёт, по возможности повторите проверку из другого источника или в обратном направлении и проверьте протокол и порт приложения. Возможны перегрузка, неисправный канал, проблемы хоста или фильтрация и ограничение диагностических запросов. Одна эта картина не определяет точный неисправный канал и не доказывает такой же процент потерь трафика приложения. ### Сценарий 3: скачки задержки без потерь на конечном узле > [card] 03 · Промежуточный скачок не равен общей задержке > > > [!NOTE] > > > > **Пик маршрутизатора 2 — 250 мс, назначения — 23 мс.** В этой выборке скачок не наблюдается на конечном узле. > > | Узел | Потери | Отправлено | Среднее | Максимум | > | - | -: | -: | -: | -: | > | Маршрутизатор 1 | 0% | 100 | 2 мс | 3 мс | > | **Маршрутизатор 2** | 0% | 100 | 80 мс | **250 мс** | > | Маршрутизатор 3 | 0% | 100 | 18 мс | 21 мс | > | **Назначение** | **0%** | **100** | **20 мс** | **23 мс** | > > **Что заметно:** последующие узлы отвечают быстрее маршрутизатора со скачком. Каждая строка измеряет отдельные ответы; времена узлов не складываются. > > **Что делать:** оценивайте задержку на назначении и в приложении. Маршрутизаторы могут медленно отвечать на запросы, нормально пересылая трафик. Если назначение также замедляется, исследуйте это отдельно. Подробнее об ответах на диагностические запросы и ограничениях маршрутизаторов — в [проекте MTR](https://github.com/traviscross/mtr) и [объяснении MTR от Cloudflare](https://www.cloudflare.com/learning/network-layer/what-is-mtr/). *** ## Потери пакетов в виртуальных средах В виртуальных средах сетевой трафик проходит через: * виртуальные интерфейсы гостевой системы; * сетевые уровни гипервизора; * сетевые стеки хоста. Эти уровни могут обрабатывать диагностический ICMP иначе, чем обычный трафик. Поэтому: * промежуточные потери могут выглядеть завышенными; * реальный трафик приложения может оставаться незатронутым. Всегда оценивайте соединение по **конечному узлу и работе приложения**, а не только промежуточной статистике ICMP. *** ## Когда обращаться в поддержку Обратитесь к нашей команде, если наблюдаете: * потери на **последнем узле**; * постоянно высокую задержку до назначения; * проблемы соединения на уровне приложения. Приложите: * полный вывод MTR; * время тестов (UTC); * исходный и целевой IP; * результаты ping.pe при наличии. Это поможет быстрее диагностировать проблему. *** ## Главное MTR — мощный инструмент, но его часто понимают неправильно. 👉 **Потери только на промежуточных узлах не являются надёжным признаком сетевой проблемы.**\ 👉 Важнее всего статистика конечного узла. Если на назначении стабильная задержка и нет потерь, тест подтверждает отсутствие потерь назначения в этой выборке, **даже если предыдущие узлы выглядят тревожно**. Проверьте работу приложения перед более широкими выводами. ## Related topics - [Как проверить доступность и потери пакетов через ping.pe](https://docs.edisglobal.com/ru/faq/ip-addresses/ping-pe-connectivity-check.md) - [Диагностика потерь пакетов](https://docs.edisglobal.com/ru/faq/ip-addresses/debugging-packet-loss-traceroute-mtr-windows.md) - [Проверка IPv4 с помощью ping](https://docs.edisglobal.com/ru/faq/ip-addresses/ping-test-ip.md) - [IP-адрес недоступен из моей страны](https://docs.edisglobal.com/ru/faq/ip-addresses/ip-can-not-be-reached-from-my-country.md) - [Как настроить OpenVPN поверх Stunnel](https://docs.edisglobal.com/ru/advanced-setup-guides/openvpn-over-stunnel.md) This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.