Пошаговая проверка сетевого подключения встроенными командами Windows

Когда интернет пропадает или сайты перестают открываться, первое желание - перезагрузить роутер и понадеяться на удачу. Способ рабочий, но слепой. Он не отвечает на главный вопрос: где именно оборвалась цепочка. А цепочка длинная. Сигнал проходит сетевой адаптер, шлюз, провайдера, десятки промежуточных маршрутизаторов и только потом достигает нужного сервера. Сбой может прятаться на любом из этих участков, и встроенные средства Windows позволяют пройти весь путь по шагам, не устанавливая ничего лишнего. Командная строка остаётся самым честным инструментом диагностики: она показывает голые факты без красивых оболочек и догадок.

Грамотная проверка строится по принципу от ближнего к дальнему. Сначала убеждаемся, что работает собственный сетевой стек, потом проверяем связь со шлюзом, затем выход в большую сеть и только в конце разрешение имён. Такой порядок экономит время, потому что отсекает целые пласты возможных причин на каждом шаге.

Просмотр текущей конфигурации адаптера как стартовая точка любой диагностики

Любая проверка начинается с того, что система сама о себе сообщает. Команда ipconfig выводит базовые параметры всех сетевых интерфейсов, но для диагностики нужна расширенная версия с ключом /all:

ipconfig /all

В выводе стоит обратить внимание на несколько строк. Поле "IPv4-адрес" показывает, какой адрес получил компьютер. Если там значится что-то из диапазона 169.254.x.x, это тревожный знак: машина не смогла получить адрес от DHCP-сервера и присвоила себе автоматический адрес из служебного диапазона APIPA. Связи с такой настройкой не будет. Поле "Основной шлюз" указывает адрес роутера, через который уходит весь внешний трафик, а "DNS-серверы" перечисляют узлы, отвечающие за превращение имён сайтов в адреса.

Пустое поле шлюза или его отсутствие сразу объясняет, почему пропал интернет при работающей локальной сети. Значение маски подсети тоже важно: типичное домашнее значение 255.255.255.0 означает, что в одной подсети помещается до 254 устройств с адресами вида 192.168.1.1 - 192.168.1.254.

Проверка собственного сетевого стека через обращение к петлевому адресу

Прежде чем винить провайдера, надо убедиться, что протокол TCP/IP вообще работает на самом компьютере. Для этого существует петлевой адрес 127.0.0.1, обращение к которому не выходит за пределы машины:

ping 127.0.0.1

Если ответы приходят с временем меньше 1 миллисекунды, сетевой стек жив. Отсутствие ответа на петлевой адрес встречается редко и почти всегда говорит о серьёзном повреждении системных компонентов или о том, что сетевые драйверы повреждены. По умолчанию утилита ping в Windows отправляет четыре пакета по 32 байта каждый и показывает время прохождения каждого. После четырёх пакетов выводится сводка: сколько отправлено, сколько получено, сколько потеряно и в каком проценте.

Последовательная проверка связи от шлюза до внешнего узла

Дальше движемся наружу. Сначала проверяем связь с собственным роутером, подставив его адрес из вывода ipconfig:

ping 192.168.1.1

Успешные ответы означают, что физическое подключение к роутеру в порядке, кабель цел или Wi-Fi держит соединение. Следующий шаг - проверка выхода во внешнюю сеть по числовому адресу, минуя разрешение имён. Классический выбор - публичный адрес 8.8.8.8:

ping 8.8.8.8

Здесь кроется важный диагностический приём. Если пинг по числовому адресу 8.8.8.8 проходит, а по имени нет, проблема не в канале связи, а в разрешении имён. Канал работает, данные ходят, ломается только перевод буквенных адресов в числовые. Это сужает поиск до настроек DNS и экономит часы бессмысленных проверок кабелей. Завершает связку проверка по имени:

ping ya.ru

Анализ маршрута прохождения пакетов до удалённого ресурса

Когда базовая связь есть, но конкретный сайт тормозит или не открывается, нужно увидеть путь, по которому идут пакеты. Команда tracert показывает каждый промежуточный маршрутизатор от компьютера до цели вместе со временем отклика на каждом переходе:

tracert ya.ru

Каждая строка вывода - это один прыжок, hop на языке сетевиков. Видно, на каком именно узле резко вырастает задержка или появляются звёздочки вместо времени. Звёздочки означают, что узел не ответил в отведённое время, хотя это не всегда поломка: многие маршрутизаторы намеренно ограничивают ответы на служебные запросы. Чтобы трассировка шла быстрее и не тратила время на перевод адресов в имена, добавляют ключ -d:

tracert -d ya.ru

Ограничить максимальное число переходов помогает ключ -h, что удобно при проверке близких узлов:

tracert -h 10 192.168.1.1

Объединённый анализ задержек и потерь через расширенную трассировку

Связка ping и tracert хороша, но у каждой свой недостаток. Ping проверяет только конечную точку, tracert показывает путь, но почти не считает потери на каждом узле. Команда pathping объединяет оба подхода: сначала строит маршрут, а потом несколько минут опрашивает каждый промежуточный узел и выдаёт подробную статистику потерь по каждому из них:

pathping ya.ru

Первая фаза похожа на обычную трассировку и занимает секунды. Вторая фаза - сбор статистики, она длится дольше, около 25 секунд на каждый узел маршрута, поэтому полный отчёт по длинной цепочке появляется через несколько минут. Зато результат точнее любого другого встроенного инструмента: видно конкретный маршрутизатор, теряющий пакеты, и процент потерь именно на нём. Это незаменимо, когда связь вроде есть, но качество плавает.

Очистка кэша и сброс параметров при необъяснимых сбоях

Иногда все проверки проходят, а нужный сайт упорно не грузится. Частая причина - устаревшая запись в кэше разрешения имён. Очистка кэша часто решает проблему, когда сайт сменил адрес, а компьютер ломится по старому:

ipconfig /flushdns

Если адрес от DHCP завис или конфликтует, помогает принудительное обновление. Сначала отказ от текущего адреса, потом запрос нового:

ipconfig /release
ipconfig /renew

Эти две команды заставляют машину заново пройти процедуру получения адреса от роутера, что снимает часть проблем с автоматической настройкой.

Проверка активных подключений и открытых портов

Когда связь в целом работает, но конкретное приложение не выходит в сеть, полезно увидеть, какие соединения открыты прямо сейчас и какие порты слушает система. За это отвечает netstat. Расширенный вызов с ключами показывает все подключения вместе с идентификаторами процессов, которые их держат:

netstat -ano

Колонка "Состояние" подсказывает, на каком этапе соединение. Значение ESTABLISHED означает установленную связь, LISTENING - что порт открыт и ждёт входящих, TIME_WAIT - что соединение недавно закрылось и порт ещё освобождается. Последняя колонка с идентификатором процесса позволяет через диспетчер задач найти конкретную программу, занявшую порт. Чтобы сразу увидеть статистику по протоколам и заодно отловить аномалии, добавляют ключ -s:

netstat -s

Резкий рост числа отброшенных или повторно отправленных сегментов в этой сводке намекает на проблемы качества канала задолго до того, как пользователь заметит тормоза.

Просмотр таблицы маршрутизации и соответствия адресов

У каждого компьютера есть внутренняя таблица маршрутов, по которой он решает, куда направить пакет. Если выход в сеть ведёт себя странно, таблицу стоит изучить:

route print

В таблице ищут маршрут по умолчанию, обозначенный адресом 0.0.0.0 с маской 0.0.0.0. Именно через него уходит весь трафик, не относящийся к локальной сети. Если этой строки нет или она указывает на неверный шлюз, внешний интернет работать не будет, сколько ни проверяй кабели. Рядом по смыслу стоит таблица соответствия адресов канального и сетевого уровней, которую показывает arp:

arp -a

Эта таблица хранит связку числовых адресов и аппаратных адресов устройств в локальной сети. Анализ этой таблицы помогает выявить конфликт, когда один адрес внезапно отзывается на чужом аппаратном идентификаторе, что выдаёт второе устройство, занявшее тот же адрес.

Глубокая проверка состояния стека и сброс настроек оболочкой netsh

Когда обычные команды не помогают, в дело вступает мощная оболочка управления сетью. Она умеет показывать и менять почти любой параметр стека. Просмотр глобального состояния протокола делается так:

netsh interface ipv4 show config

При неустранимых сбоях, когда настройки запутались окончательно, помогает полный сброс стека к заводскому состоянию. Две команды возвращают протокол и каталог сокетов в исходный вид:

netsh int ip reset
netsh winsock reset

После такого сброса обязательна перезагрузка, потому что система пересоздаёт сетевые компоненты заново. Этот приём - последний рубеж перед переустановкой драйверов, и он выручает, когда повреждены параметры, которые вручную уже не отыскать. Важно понимать, что сброс стирает ручные настройки прокси и статических адресов, поэтому перед ним стоит сохранить текущую конфигурацию через ipconfig /all в отдельный файл.

Проверка качества беспроводного соединения отдельной командой

Если компьютер подключён по Wi-Fi, к обычной диагностике добавляется отдельный пласт - качество радиоканала. Оболочка netsh умеет показывать состояние беспроводного адаптера со всеми деталями, которые не видны в обычном ipconfig:

netsh wlan show interfaces

В выводе ключевые строки - это "Сигнал" в процентах, "Скорость приёма" и "Скорость передачи" в мегабитах в секунду, а также используемый канал и диапазон. Сигнал ниже 40 процентов почти гарантированно даёт обрывы и просадки скорости, даже когда формально связь есть. Здесь же видно, на каком канале работает сеть, что помогает поймать ситуацию, когда соседние точки доступа толкаются на одной частоте и мешают друг другу. Полный отчёт о беспроводном адаптере с историей подключений и причинами разрывов выводит расширенная команда:

netsh wlan show wlanreport

Она формирует наглядный отчёт за последние три дня, где по временной шкале видно каждое успешное подключение и каждый разрыв с указанием причины. Для блуждающей проблемы, которая возникает раз в сутки и пропадает к приходу администратора, такой отчёт часто оказывается единственной зацепкой.

Чтение результатов и построение диагностической логики

Главная ценность набора команд не в каждой из них по отдельности, а в порядке применения. Логика простая: петлевой адрес проверяет сам компьютер, пинг шлюза проверяет локальное подключение, пинг внешнего числового адреса проверяет канал к провайдеру, пинг по имени проверяет разрешение имён, а трассировка и расширенная трассировка показывают, где именно на длинном пути возникает затык.

Проходя эти шаги один за другим, администратор не гадает, а методично отсекает работающие участки и приближается к настоящему виновнику. Каждый ответ команды - это либо зелёный свет, разрешающий идти дальше по цепочке, либо красный, прямо указывающий на проблемный участок.

Стоит держать в голове ещё одну тонкость. Многие сетевые проблемы плавают по времени: утром связь идеальная, вечером начинаются обрывы. Разовый прогон команд в такой ситуации почти бесполезен, он ловит лишь срез текущего момента. Поэтому для непостоянных сбоев применяют связку из непрерывного пинга шлюза и внешнего узла одновременно, запущенных в двух окнах командной строки на несколько часов. Когда проблема проявится, по двум потокам сразу видно, оборвалась связь до роутера или уже за ним, в сторону провайдера. Этот приём превращает набор статичных команд в живой мониторинг, не требующий никаких дополнительных программ.

В этом и состоит сила встроенной диагностики: набор простых утилит, выстроенных в правильную последовательность, заменяет дорогие программы и долгие догадки. Опытный человек по нескольким строкам вывода понимает картину целиком, тогда как новичок видит лишь набор цифр. Разница только в умении читать эти цифры и задавать команды в нужном порядке, а это умение нарабатывается быстро, стоит лишь несколько раз пройти весь путь от петлевого адреса до удалённого сервера вручную.