frontpage hub

Практикум 02 · Windows

Есть соединение.
Нет Интернета?

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

1. Зафиксируйте симптом

Не работает один сайт или всё сразу? Проблема только на компьютере или на других устройствах тоже? Возникает по кабелю, по Wi-Fi или в обоих случаях? Запишите ответы и время сбоя. Они помогут отличить проблему одного устройства от неисправности общего подключения.

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

2. Посмотрите адрес и шлюз

Откройте командную строку Windows (CMD) или PowerShell и выполните:

ipconfig /all

Найдите именно используемый Ethernet- или Wi-Fi-адаптер. Запишите IPv4-адрес, маску, основной шлюз и DNS-серверы. При наличии виртуальных адаптеров не путайте их с физическим подключением.

В обычной домашней сети адреса раздаёт DHCP-сервер роутера. Адрес 169.254.x.x часто означает, что Windows назначила себе локальный адрес после неудачного получения DHCP-настроек. Проверьте кабель, доступность роутера и DHCP. Сам по себе такой адрес ещё не объясняет, почему сервер не ответил.

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

3. Проверьте локальный путь

Отправьте несколько запросов на шлюз, найденный в предыдущем шаге. Ниже 192.168.1.1 — только пример; замените его своим адресом.

ping 192.168.1.1

Ответ подтверждает доступность шлюза по ICMP, но не гарантирует, что Интернет работает. Отсутствие ответа тоже не доказывает обрыв: устройство может не отвечать на ICMP. Сравните с доступностью его административного интерфейса и поведением другого устройства в той же сети.

Если шлюз доступен, проверьте внешний узел, о котором известно, что он отвечает. Сравнивайте несколько независимых проверок. Не отключайте брандмауэр ради одного неудачного ping.

4. Отделите DNS от соединения

DNS преобразует имя в адрес. Посмотрите, какой сервер отвечает и какие адреса он возвращает:

nslookup example.com

Если ответ получен, проверяйте соединение с конкретным сервисом. Если запрос завершается тайм-аутом, проверьте доступность настроенного DNS и настройки роутера. Не подменяйте корпоративный DNS публичным без согласования: внутренние имена после этого могут перестать работать.

Проверка HTTPS в PowerShell:

Test-NetConnection example.com -Port 443

TcpTestSucceeded: True подтверждает установление TCP-соединения на порт 443, но не проверяет сертификат, HTTP-ответ или авторизацию. Если браузер сообщает об ошибке сертификата, проверьте время устройства и точный адрес сайта. Не игнорируйте предупреждение безопасности.

5. Сравните маршрут и нагрузку

Команда CMD или PowerShell показывает отвечающие промежуточные узлы:

tracert -d example.com

Звёздочки в отдельных строках часто означают фильтрацию или ограничение диагностических ответов, а не потерю пользовательского трафика. Если следующий узел отвечает, предыдущая звёздочка не означает, что путь оборван. Сохраните результат, время проверки и описание симптома для администратора или провайдера.

При жалобе на скорость остановите фоновые загрузки, сравните Ethernet и Wi-Fi, проверьте согласованную скорость сетевого адаптера. Скорость одного удалённого сервиса не равна пропускной способности всей домашней сети.

Короткая карта результата

  • Нет линка: кабель, питание, порт, адаптер.
  • Есть линк, нет адреса: DHCP, сегмент сети, конфигурация адаптера.
  • Есть адрес, не виден шлюз: маска, локальное соединение, ограничения доступа.
  • Сеть доступна, имена не находятся: DNS и его доступность.
  • Сбой только одного сервиса: его доступность, HTTPS и настройки клиента.
Документация команд

Microsoft: ipconfig · Microsoft: tracert

Если подозреваете физическую линию: проверка кабеля после обжима.