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 443TcpTestSucceeded: True подтверждает установление TCP-соединения на порт 443, но не проверяет сертификат, HTTP-ответ или авторизацию. Если браузер сообщает об ошибке сертификата, проверьте время устройства и точный адрес сайта. Не игнорируйте предупреждение безопасности.
5. Сравните маршрут и нагрузку
Команда CMD или PowerShell показывает отвечающие промежуточные узлы:
tracert -d example.comЗвёздочки в отдельных строках часто означают фильтрацию или ограничение диагностических ответов, а не потерю пользовательского трафика. Если следующий узел отвечает, предыдущая звёздочка не означает, что путь оборван. Сохраните результат, время проверки и описание симптома для администратора или провайдера.
При жалобе на скорость остановите фоновые загрузки, сравните Ethernet и Wi-Fi, проверьте согласованную скорость сетевого адаптера. Скорость одного удалённого сервиса не равна пропускной способности всей домашней сети.
Короткая карта результата
- Нет линка: кабель, питание, порт, адаптер.
- Есть линк, нет адреса: DHCP, сегмент сети, конфигурация адаптера.
- Есть адрес, не виден шлюз: маска, локальное соединение, ограничения доступа.
- Сеть доступна, имена не находятся: DNS и его доступность.
- Сбой только одного сервиса: его доступность, HTTPS и настройки клиента.
Microsoft: ipconfig · Microsoft: tracert
Если подозреваете физическую линию: проверка кабеля после обжима.