1. MTR вместо Ping: увидьте всю цепочку, а не только конец
Ping показывает, жив ли конечный узел. Он не показывает, где теряются пакеты по пути. Если между вами и сервером десять маршрутизаторов, и пакеты теряются на пятом, ping до конечного адреса покажет потери, но вы не узнаете, кто виноват.
Используйте утилиту MTR (My Traceroute). В Windows она называется WinMTR (графическая) или доступна через PowerShell как Test-NetConnection с трассировкой, но лучше установить классический mtr через WSL или Chocolatey. В Linux/macOS просто введите mtr ya.ru.
Утилита совмещает traceroute и ping. Она отправляет пакеты к каждому узлу на пути и показывает статистику потерь и задержек в реальном времени. Если вы видите, что на каком-то промежуточном хоке потери составляют 20-30%, а дальше всё чисто — проблема у провайдера на этом участке. Если потери растут к концу пути — проблема на стороне сервера или вашего последнего шлюза. MTR даёт объективную картину для разговора с техподдержкой провайдера. Не скриншоты «медленного интернета», а конкретные цифры потерь на конкретном узле.
2. DNS-диагностика: когда пинг есть, а сайта нет
Частая ситуация: мессенджеры работают, а сайты не открываются. Или открываются через раз. Проблема почти всегда в DNS. Система не может превратить имя site.ru в IP-адрес.
Не используйте nslookup для глубокой диагностики. Он кэширует ответы и может врать. Используйте dig (в Windows 10/11 он встроен, в старых версиях — через BIND tools или WSL). Команда dig ya.ru @8.8.8.8 запросит запись у конкретного сервера (Google), минуя локальный кэш и провайдерский DNS.
Смотрите на поле Query time. Если оно больше 100-200 мс, ваш DNS-сервер тормозит. Сравните с dig ya.ru @1.1.1.1 (Cloudflare). Если там время 20 мс, меняйте настройки DNS на клиенте или роутере на публичные.
Также проверяйте наличие DNSSEC подписей, если сайт использует защищённые зоны. Команда dig +dnssec site.ru покажет, валидна ли цепочка доверия. Ошибки валидации часто приводят к тихому блокированию сайтов браузером без явных сообщений об ошибке.
3. Анализ насыщенности канала: кто съел весь трафик
«Интернет тормозит у всех». Вы смотрите на график загрузки канала на роутере — он заполнен на 100%. Кто виноват? Обновление Windows? Торренты? Видеонаблюдение?
Если у вас есть доступ к управляемому коммутатору или роутеру с поддержкой NetFlow/sFlow, включите экспорт потоков и направьте их на анализатор (например, бесплатный Ntopng или PRTG в пробном режиме). Вы увидите топ-говорливых хостов и протоколов.
Если доступа к неттофлоу нет, используйте метод исключения. Отключайте сегменты сети по одному (или группы портов на коммутаторе) и смотрите на график загрузки внешнего канала. Когда нагрузка упадёт, вы нашли виновника. Затем подключайте обратно порты по одному, чтобы найти конкретный компьютер.
На самом компьютере используйте утилиту TCPView (от Sysinternals) в Windows или nethogs в Linux. Они показывают, какой процесс и куда передаёт данные прямо сейчас. Часто оказывается, что «тормозит интернет» из-за того, что один ПК синхронизирует облачный диск или качает обновление игры в фоне.
4. Проверка качества кабеля и порта: физические ошибки
Иногда проблема не в настройках, а в физике. Плохой обжим коннектора RJ-45, перебитый кабель, окисленные контакты. Симптомы: периодические обрывы связи, падение скорости с 1 Гбит/с до 100 Мбит/с или 10 Мбит/с, огромные задержки при потере 0% пакетов.
В интерфейсе сетевого адаптера (в Windows: ncpa.cpl → свойства адаптера → состояние → подробности, или через PowerShell Get-NetAdapterStatistics) смотрите на счётчики ошибок: CRC Errors, Frame Errors, Collisions. Если эти значения растут со временем, проблема в кабеле или порту.
Замените патч-корд. Переподключите кабель в другой порт коммутатора. Если ошибки прекратились — вы нашли причину. Не игнорируйте физические ошибки. Они создают ретрансмиссии пакетов, которые незаметны для пинга, но убивают производительность TCP-сессий (веб-браузинг, файловые передачи).
5. Тест реальной пропускной способности: iperf3
Спидтесты в браузере врут. Они зависят от нагрузки на сервер тестирования, от работы JavaScript в браузере, от ограничений самого браузера на количество соединений.
Для честного теста используйте iperf3. Установите серверную часть на одном конце канала (например, на локальном сервере или на удалённом VPS) и клиентскую на другом.
На сервере: iperf3 -s
На клиенте: iperf3 -c <IP_сервера> -t 30 -P 4
Ключ -t 30 задаёт длительность теста 30 секунд. Ключ -P 4 запускает 4 параллельных потока, что позволяет загрузить канал полностью и нивелировать влияние размера окна TCP.
Смотрите на результат Bandwidth. Если он близок к теоретическому максимуму вашего канала (например, 90-95 Мбит/с для тарифа 100 Мбит/с), значит, канал чист. Если скорость ниже, ищите узкое место: перегруженный роутер, старый кабель, ограничения провайдера. Iperf3 измеряет чистую пропускную способность транспортного уровня, без накладных расходов HTTP и шифрования.
Итог
Диагностика сети — это не магия. Это система.
MTR покажет, где теряются пакеты по пути.
Dig проверит, не врёт ли DNS.
Анализ трафика (NetFlow или исключение) найдёт пожирателя канала.
Счётчики ошибок адаптера выявят плохой кабель.
Iperf3 даст честную цифру пропускной способности.
Используйте эти инструменты по очереди. Не гадайте. Собирайте факты. Когда вы приходите к провайдеру или руководству с логами MTR и результатами iperf, разговор переходит из плоскости «у вас всё плохо» в плоскость «на узле Х потери 20%, прошу исправить». Это экономит нервы, время и репутацию.