Коротка відповідь: Міряйте через mtr щонайменше на 100 циклах в обох напрямках. Втрати, що з’являються на одному проміжному хопі, але не на кінцевому — зазвичай нешкідливий ICMP rate-limiting; реальна втрата пакетів видна на фінальному хопі та на кожному хопі після проблемної точки. Зберіть звіти й надішліть підтримці, якщо втрати справжні.

Огляд

Втрата пакетів «підвішує» з’єднання, робить SSH смиканим і рве дзвінки. Але більшість «втрат» у traceroute — артефакт: маршрутизатори знижують пріоритет ICMP-відповідей про самих себе, бездоганно передаючи реальний трафік. Уміння — відділити косметичні втрати від реальних, і коректно запущений MTR робить саме це.

Що потрібно мати

  • Встановіть mtr на обох кінцях, якщо можливо: sudo apt install -y mtr-tiny (Debian/Ubuntu) або sudo dnf install -y mtr (Alma/Rocky). Windows: WinMTR.
  • Занотуйте точні мітки часу та ваш публічний IP-джерело — підтримці треба обидва.

Покрокова інструкція

  1. З вашого боку до сервера: 
    mtr -rwbzc 100 SERVER_IP
    (-r звіт, -w широкий, -b імена+IP, -z номери AS, -c 100 циклів.)
  2. Із сервера назад до вас (зворотний шлях часто інший): 
    mtr -rwbzc 100 YOUR_PUBLIC_IP
    Свій публічний IP дізнайтеся через curl -4 ifconfig.me на робочій машині.
  3. Читайте колонку Loss%: ігноруйте поодинокі втрати на проміжних хопах, якщо подальші чисті; втрати реальні, коли починаються на якомусь хопі і тривають до пункту призначення.
  4. Перевірте сам сервер: насичення CPU чи переповнення conntrack імітують втрати — 
    uptime; ss -s
ip -s link show eth0   # помилки та дропи RX/TX
  5. Якщо реальні втрати тримаються в часі та в обох напрямках — повідомте з обома виводами MTR.

Типові проблеми

  • «50% втрат на хопі 3!», але 0% на призначенні = ICMP-тротлінг маршрутизатора, не проблема.
  • Тест лише під час сплеску: підтвердьте патерн кількома прогонами/годинами — миттєва перегрузка трапляється в будь-якій мережі.
  • Wi-Fi як перший хоп: втрати з хопів 1–2 — це ваша локальна мережа; тестуйте по кабелю чи з іншого підключення.

Коли звертатися в підтримку

Стійкі наскрізні втрати (Loss% призначення > 0 на 100+ циклах, обидва напрямки, кілька разів) — наша справа: відкрийте тикет з обома звітами, мітками часу та вашим IP-джерелом.

Часті запитання

MTR показує втрати на проміжному хопі, але 0% наприкінці — це проблема?

Ні. Маршрутизатори знижують пріоритет ICMP-відповідей про себе, нормально передаючи трафік. Втрати реальні лише тоді, коли тривають до фінального хопа.

Навіщо тестувати в обох напрямках?

Маршрутизація в Інтернеті асиметрична — зворотний шлях може відрізнятися і саме він може нести проблему. Запускайте MTR і з вашого боку, і з сервера.

Скільки циклів MTR достатньо?

Щонайменше 100 циклів (-c 100), це близько двох хвилин — коротші прогони дають статистичний шум, який виглядає як втрата пакетів, але нею не є.

Схожі статті

Потрібна допомога? Звернутися в підтримку Cloud2Y →

Ця відповідь Вам допомогла? 0 Користувачі, які знайшли це корисним (0 Голосів)

Найпопулярніші

Огляд мережі Cloud2Y

Коротка відповідь: Cloud2Y експлуатує власну мережу в Україні (DC2 Київ, DC3 Львів), Європі...
Що означає інфраструктура на базі Cisco?

Коротка відповідь: «На базі Cisco» означає, що маршрутизація та комутація Cloud2Y працюють на...
Як перевірити швидкість мережі

Коротка відповідь: Три стандартні інструменти — speedtest-cli (швидка публічна перевірка), iperf3...
Як перевірити затримку до локацій Cloud2Y

Коротка відповідь: Запустіть ping або mtr звідти, де перебувають ваші користувачі, до сервера (чи...
Як користуватися Looking Glass

Коротка відповідь: Looking Glass (LG) — це веб-інструмент, що дозволяє запускати ping, traceroute...