Диагностика сети в Windows и Linux: проверка IP, DNS, шлюза и маршрута

Чтобы найти причину проблем с подключением, проверяйте сеть по цепочке: состояние адаптера, IP-адрес и маску, шлюз по умолчанию, маршрут до внешнего IP-адреса, затем DNS и конкретный сервис. Такая последовательность быстро отделяет сбой кабеля, Wi-Fi или DHCP от ошибки маршрутизации, DNS, VPN, прокси или внешнего канала.

В Windows для быстрой проверки сети нужны ipconfig, ping, tracert, nslookup и PowerShell. В Linux ту же задачу решают ip, ping, traceroute или tracepath, nslookup, resolvectl, nmcli и ethtool. Начинайте с локальной конфигурации и не меняйте настройки, пока не определите участок отказа.

От чего зависит подключение

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

Как прочитать IP-конфигурацию

IPv4-адрес, маска и шлюз должны согласовываться. Например, адрес 192.168.10.25 с маской 255.255.255.0, или префиксом /24, находится в сети 192.168.10.0/24. Шлюз 192.168.10.1 расположен в той же подсети, поэтому хост может отправить ему кадр напрямую.

Адрес вида 169.254.x.x в IPv4 обычно означает, что клиент не получил аренду DHCP. Проверьте линк, VLAN, доступность DHCP-сервера, настройки relay и фильтрацию DHCP-трафика. Статический адрес из чужой подсети дает схожий результат, но в выводе будет виден вручную заданный IP.

В Windows подробную карточку адаптера, его MAC-адрес, скорость, IPv4, IPv6, шлюз и DNS удобно сверять по шпаргалке по сетевым интерфейсам Windows. Для быстрой локализации важны имя адаптера, его состояние и источник адреса: DHCP или статическая настройка.

Почему тестируют несколько точек

Один успешный ping не подтверждает работу всей сети. Проверка 127.0.0.1 подтверждает локальный TCP/IP-стек. Ответ собственного адреса проверяет назначение IP в системе. Ответ шлюза проверяет путь до локального маршрутизатора. Ответ внешнего IP проверяет маршрут без участия DNS. Успешное разрешение имени проверяет DNS, а соединение с нужным TCP-портом проверяет прикладной уровень.

При Wi-Fi учитывайте качество радиоканала. Диапазон 2,4 ГГц обычно покрывает большую площадь, но чаще страдает от помех. Диапазон 5 ГГц часто дает более высокую скорость на небольшом расстоянии. Сравните ping и скорость возле точки доступа и в рабочей точке, затем повторите замеры несколько раз. Одна удачная попытка не исключает потерю пакетов или скачки задержки.

Что нужно для подключения

Для диагностики подготовьте имя интерфейса, ожидаемую подсеть, адрес шлюза, адреса корпоративных DNS-серверов и один известный внешний IP. Если сеть использует VPN, зафиксируйте, какие маршруты и DNS-серверы должны появиться после подключения. На сервере полезно заранее знать порт целевого сервиса.

Команды диагностики сети в Windows

ipconfig /all
Get-NetAdapter
Get-NetIPConfiguration
route print
ping -n 4 127.0.0.1
ping -n 4 192.168.10.1
ping -n 4 1.1.1.1
tracert -d 1.1.1.1
nslookup example.com
Test-NetConnection example.com -Port 443

ipconfig /all показывает адреса, маски, шлюзы, DNS, DHCP и суффиксы поиска. Get-NetAdapter выводит состояние и скорость адаптера. route print помогает найти маршрут по умолчанию, который выглядит как 0.0.0.0 с маской 0.0.0.0 для IPv4.

tracert -d строит маршрут без обратного DNS-разрешения, поэтому тест завершается быстрее. Test-NetConnection проверяет TCP-подключение, когда ICMP запрещен на целевом узле. Это полезно для HTTPS, WinRM, SSH, RDP и внутренних веб-панелей.

Команды диагностики сети в Linux

ip -br link
ip -br addr
ip route
ip route get 1.1.1.1
nmcli device status
ethtool eth0
ping -c 4 127.0.0.1
ping -c 4 192.168.10.1
ping -c 4 1.1.1.1
traceroute -n 1.1.1.1
tracepath 1.1.1.1
resolvectl status
nslookup example.com
ss -lntup

ip -br link быстро показывает состояние интерфейса. Статус UP без LOWER_UP часто означает, что интерфейс включен программно, но физического линка нет. NO-CARRIER у проводного интерфейса указывает на кабель, порт коммутатора, SFP-модуль или отключенный соседний порт.

ip route get 1.1.1.1 отвечает на практический вопрос: через какой интерфейс, исходный адрес и next hop система отправит пакет к указанной цели. Для хостов с несколькими NIC, Docker, VPN или несколькими default route эта команда полезнее общего просмотра таблицы.

Порядок быстрой проверки сети

1. Проверьте, затронут ли один сервис, один компьютер или несколько устройств. Если сбой виден только в одном приложении, сначала проверьте его прокси, учетную запись и статус сервиса.
2. Убедитесь, что адаптер включен и имеет линк. На проводной сети проверьте кабель и индикаторы порта. На Wi-Fi проверьте SSID, уровень сигнала и отсутствие captive portal.
3. Сверьте IP-адрес, маску или префикс, шлюз и DNS с ожидаемой конфигурацией.
4. Проверьте 127.0.0.1, затем собственный IP, шлюз и соседний хост в той же подсети.
5. Проверьте доступность внешнего IP, например 1.1.1.1. Успех означает, что маршрут наружу работает для ICMP.
6. Проверьте имя через nslookup example.com. При необходимости запросите конкретный DNS-сервер.
7. Проверьте порт целевого сервиса: Test-NetConnection host -Port 443 в Windows или подходящим клиентом в Linux.
8. Если путь обрывается, запустите tracert, traceroute или tracepath, затем изучите маршрут, MTU, firewall и VPN.

Как интерпретировать результат

Вопросы и ответы

Почему ping до шлюза не проходит, хотя IP-адрес получен?

IP-адрес подтверждает только работу DHCP или статической настройки. Причина может быть в неверной маске, другой VLAN, отключенном порту, ARP-проблеме, фильтрации ICMP или недоступном шлюзе. В Windows проверьте arp -a, в Linux - ip neigh show. Отсутствие MAC-адреса шлюза после попытки ping указывает на проблему канального уровня или сегментации сети.

Ping до IP проходит, а сайт по имени не открывается. Что проверять?

Сначала выполните nslookup example.com. Проверьте, какой DNS-сервер использует система и какой адрес он возвращает. При активном VPN корпоративные имена могут разрешаться только через внутренний DNS, а публичный DNS не знает нужную зону. Очистка кэша помогает лишь при устаревшей записи: в Windows используйте ipconfig /flushdns; в Linux порядок зависит от резолвера и дистрибутива.

Почему tracert или traceroute обрывается на одном из хопов?

Промежуточный маршрутизатор может не отвечать на ICMP с истекшим TTL, но продолжать пересылать пользовательский трафик. Оценивайте не отдельную звездочку, а достижимость последнего узла и работу целевого порта. Если обрыв повторяется для всех адресов сразу после локального шлюза, проверьте uplink, правила маршрутизации и провайдера.

Как отличить сбой сетевого адаптера от ошибки шлюза?

Сбой адаптера обычно виден до проверки IP: интерфейс отключен, кабель не подключен, нет carrier, скорость не согласована или Wi-Fi не ассоциирован. При ошибке шлюза интерфейс активен, адрес корректен, но нет ответа от шлюза или отсутствует default route. Проверка соседнего хоста в той же подсети помогает разделить эти случаи.

Почему ping успешен, но веб-интерфейс не открывается?

ICMP и HTTPS используют разные протоколы. Удаленный хост может отвечать на ping при закрытом TCP-порту, остановленном веб-сервисе, неверном reverse proxy или запрете в firewall. Для такого случая подходит системный алгоритм диагностики доступа к веб-интерфейсу.

Что означает потеря пакетов при нормальной скорости?

Высокая пропускная способность не гарантирует стабильный канал. Потери и рост задержки вызывают обрывы VPN, зависания VoIP, повторные передачи TCP и паузы при потоковой передаче. Выполните 20-50 ping подряд к шлюзу и внешнему IP, сравните минимальную, среднюю и максимальную задержку. Сильный разброс до шлюза указывает на локальную сеть или Wi-Fi; проблемы только после шлюза сужают поиск до внешнего канала.

Недавно опубликованные

Для смежных сценариев используйте отдельные инструкции, когда базовая проверка уже указала на конкретный слой проблемы.

• Сетевые интерфейсы Windows: поиск имени адаптера, IP-адреса, MAC, скорости и текущего статуса.
• Диагностика проблем загрузки файлов в браузере: проверка прокси, VPN, антивируса и прикладных ограничений после подтверждения базовой связности.

При проверке виртуальной машины фиксируйте IP, таблицу маршрутов, DNS и результат теста порта до перезагрузки. Снимок этих значений помогает сравнить состояние до и после изменения сети. Для стендов и сервисов в облаке полезно иметь консольный доступ к экземпляру, например в облачной инфраструктуре Timeweb Cloud, чтобы проверить сеть при недоступности публичного интерфейса.

Лучшие мобильные приложения для девушек, занимающихся пилатесом

Проблема с одним мобильным приложением не доказывает сбой всей сети. Проверьте тот же сервис в браузере, затем откройте другой сайт и повторите тест через Wi-Fi и мобильную сеть. Если приложение работает через LTE или 5G, но не работает через Wi-Fi, ищите причину в роутере, DNS, фильтрации, VPN или captive portal.

Для Wi-Fi сравните задержку рядом с точкой доступа и в месте использования устройства. Стены, расстояние и радиопомехи дают нестабильную передачу даже при видимой сети. В диапазоне 2,4 ГГц помех обычно больше; 5 ГГц часто снижает их влияние на короткой дистанции. DNS на Android проверяйте отдельно, если по IP соединение есть, а доменные имена не открываются: поможет инструкция по настройке DNS на Android для Wi-Fi.

Развитие инноваций в современном спорте

Видеотрекинг, онлайн-трансляции, телеметрия и мобильные сервисы чувствительны к задержке, джиттеру и потерям пакетов. Для таких нагрузок измеряйте не только скорость скачивания. Серия из нескольких тестов к одному адресу покажет колебания задержки, а проверка в разное время суток поможет выявить перегрузку канала.

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

По каким ключевым характеристикам выбрать наушники себе по вкусу?

Беспроводные наушники не меняют IP-настройки компьютера, но могут совпасть по времени с ухудшением Wi-Fi в диапазоне 2,4 ГГц. Не связывайте два события без проверки. Отключите Bluetooth-наушники, повторите ping до шлюза, затем переключите Wi-Fi на 5 ГГц или подключите компьютер кабелем. Сравнение трех результатов покажет, есть ли влияние радиосреды.

Для звонков и конференций контролируйте потерю пакетов и задержку до шлюза. Громкий звук, низкий заряд гарнитуры или плохой микрофон создают локальные аудиосимптомы, которые не требуют изменения DNS, маршрутов или firewall. Разделяйте сетевую и периферийную диагностику, чтобы не менять рабочую конфигурацию без причины.

Самое читаемое

Ниже приведен компактный набор команд, который покрывает большинство первичных проверок.

Сохраняйте вывод команд вместе со временем проверки, именем интерфейса и сетью, через которую выполнялся тест. Эти три детали часто объясняют расхождения между результатами на рабочих станциях, сервере и VPN-клиенте.

Эксперты узнали самые популярные запросы в YouTube среди российских детей и подростков

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

Проверка должна быть воспроизводимой: зафиксируйте время, IP-адрес назначения, имя, используемый DNS-сервер, результат ping и TCP-подключения. Не делайте вывод по одному замеру скорости. Повторные тесты в разное время дают более полезную картину при плавающих сбоях.

Вирусологи: коронавирус может передаваться через посылки AliExpress

Заголовки о внешних событиях не заменяют техническую проверку сети. Если доступ к ресурсу пропал после обновления антивируса, прокси-клиента, VPN или корпоративной политики, сначала сравните маршрут, DNS-ответ и доступность порта с заведомо рабочим устройством. Не отключайте защиту целиком ради теста: используйте журналы firewall, прокси и VPN, чтобы найти правило, блокирующее нужный трафик.

Когда имя разрешается в неожиданный адрес, проверьте DNS-сервер, локальный файл hosts, суффиксы поиска и настройки VPN. Когда адрес правильный, но TCP-порт недоступен, проверяйте ACL, reverse proxy, сервис на сервере и обратный маршрут. Такая последовательность локализует проблему без случайного сброса TCP/IP и без потери настроек.