Сброс сетевых настроек Windows при ошибках IP-адреса и DNS в 2026 году

Короткий ответ: как сбросить сетевые настройки Windows

При ошибках «Нет допустимой конфигурации IP», сбоях DHCP или проблемах с DNS в Windows 10 и Windows 11 выполните диагностику, сбросьте Winsock и TCP/IP, очистите DNS-кэш, обновите DHCP-аренду и перезагрузите компьютер. После запуска Windows проверьте результат в порядке: ipconfig /all, ping шлюза, ping внешнего IP-адреса, затем nslookup доменного имени.

Откройте Windows Terminal или командную строку от имени администратора и выполняйте команды по одной:

netsh winsock reset
netsh int ip reset
ipconfig /flushdns
ipconfig /release
ipconfig /renew

Команды ipconfig /release и ipconfig /renew предназначены для адаптеров, которые получают настройки через DHCP. Если на компьютере задан статический IP-адрес, маска, шлюз или DNS, сначала запишите эти значения и не рассчитывайте на автоматическое восстановление конфигурации после сброса.

Перезагрузите Windows обычным способом или выполните shutdown /r /t 0. После перезагрузки не ограничивайтесь открытием одного сайта. Сначала убедитесь, что система получила корректный IPv4-адрес и шлюз, затем проверьте локальную связность, внешний маршрут и DNS-разрешение.

Короткий критерий результата: в ipconfig /all есть ожидаемые IPv4, маска, шлюз и DNS-сервер; шлюз отвечает на ping; внешний узел доступен или его ICMP-фильтрация объяснима; nslookup возвращает адрес для проверяемого домена.

Перед сбросом: определите, что именно сломалось

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

До изменений сохраните исходную конфигурацию и определите границу сбоя. Такой подход помогает выбрать минимальное вмешательство. Дополнительный пошаговый сценарий есть в руководстве по восстановлению сетевых настроек Windows без переустановки системы.

Что посмотреть в `ipconfig /all` до изменений

Откройте обычную командную строку и выполните:

ipconfig /all

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

IPv4 Address, текущий адрес интерфейса;
Subnet Mask, маску подсети;
Default Gateway, адрес маршрутизатора для выхода за пределы локальной сети;
DHCP Enabled, признак автоматического получения параметров;
DHCP Server, узел, выдавший аренду, если DHCP используется;
DNS Servers, серверы, которым Windows отправляет запросы имен.

Адрес из диапазона 169.254.0.0/16, например 169.254.18.42, обычно означает, что Windows не получила рабочую DHCP-аренду и назначила себе локальный адрес. Такой адрес не подтверждает доступ к маршрутизатору или интернету.

Отсутствие Default Gateway ограничивает обмен локальной подсетью. Если шлюз пуст, компьютер может видеть соседние узлы, но не сможет отправлять трафик в другие сети. Пустое поле DNS Servers или адрес недоступного DNS-сервера объясняет ошибки разрешения имен, но не отсутствие самого IPv4-адреса.

Какие параметры сохранить перед сбросом

Сделайте снимок текущего состояния командой ipconfig /all и запишите значения в рабочую документацию. Для нестандартной маршрутизации дополнительно выполните:

route print

статический IPv4-адрес и маску подсети;
шлюз по умолчанию и статические маршруты;
адреса внутренних и публичных DNS-серверов;
настройки прокси Windows и браузера;
параметры VPN-профилей, сертификаты и способ авторизации;
SSID и ключ Wi-Fi, если после сброса потребуется повторное подключение;
настройки 802.1X, VLAN и корпоративных виртуальных адаптеров;
конфигурации Hyper-V, Docker Desktop, VirtualBox и других сетевых компонентов.

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

Когда сброс действительно уместен

Сброс TCP/IP и Winsock подходит, когда сетевой стек Windows получил некорректные параметры после обновления, установки VPN-клиента, сетевого фильтра или неудачной смены конфигурации. Метод уместен при таких симптомах:

Windows сообщает об отсутствии допустимой конфигурации IP;
адаптер не получает новую DHCP-аренду после смены сети;
локальный стек TCP/IP работает нестабильно после удаления сетевого ПО;
приложения используют поврежденные записи Winsock;
старый DNS-кэш направляет запросы на неактуальные адреса.

Сброс не починит отключенный роутер, поврежденный кабель, неверный VLAN, неисправный Wi-Fi, недоступный DHCP-сервер или удаленный сервис. Блокировка ICMP тоже не доказывает повреждение Windows: маршрутизатор или сервер могут намеренно не отвечать на ping.

Windows не получает IP-адрес: как проверить DHCP до сброса

Начните с физического подключения и состояния интерфейса. Убедитесь, что кабель вставлен, Wi-Fi подключен к нужному SSID, адаптер включен, а компьютер находится в правильной VLAN. Затем сопоставьте результат с полями DHCP и Default Gateway в ipconfig /all.

Адрес `169.254.x.x` или отсутствие IPv4-адреса

Windows назначает адрес 169.254.x.x, когда не получает ответ от DHCP и не находит подходящую ручную конфигурацию. Такой результат указывает на проблему адресации, а не на DNS.

Проверьте следующие причины:

сетевой кабель, порт коммутатора и индикаторы линка;
подключение к правильной точке Wi-Fi;
состояние адаптера в списке сетевых подключений;
отсутствие ошибочного статического IP-адреса;
доступность DHCP в роутере или корпоративной сети;
совпадение VLAN и SSID с теми, где разрешена выдача адресов;
работу службы DHCP Client в Windows.

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

Проверка шлюза и маршрута через `ping`

Возьмите адрес шлюза из поля Default Gateway. Например, если там указано 192.168.1.1, выполните:

ping 192.168.1.1

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

После успешного ответа шлюза проверьте внешний IP-адрес:

ping 1.1.1.1

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

Как отличить локальный сбой от внешней проблемы

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

Результат	Вероятная область поиска
Нет IPv4 или выдан адрес 169.254.x.x	Адаптер, кабель, Wi-Fi, VLAN или DHCP
IPv4 есть, шлюз не отвечает	Локальная сеть, порт, точка доступа, VLAN или firewall
Шлюз отвечает, внешний IP не отвечает	Маршрутизатор, провайдер, внешний маршрут или ICMP-фильтрация
Внешний IP доступен, доменное имя не разрешается	DNS-сервер, VPN-политика или локальный DNS-кэш

Такая последовательность отделяет проблему компьютера от сбоя локальной сети и внешней инфраструктуры. Не переходите к смене DNS, пока система не получила корректный адрес и маршрут до шлюза.

Сброс TCP/IP и Winsock Windows через командную строку

Командный способ затрагивает отдельные компоненты сетевого стека и обычно подходит раньше полного Network reset. Он не требует переустановки Windows, но часть изменений применится только после перезагрузки.

Откройте терминал с правами администратора

Откройте меню Пуск.
Введите Windows Terminal или cmd.
Выберите запуск от имени администратора.
Подтвердите запрос контроля учетных записей.

В заголовке окна обычно указано, что терминал запущен с правами администратора. Без повышенных прав netsh может завершиться с отказом в доступе или не изменить нужные параметры.

Не запускайте этот набор на удаленной машине по RDP без согласованного окна работ и резервного канала доступа. Сброс Winsock, TCP/IP и DHCP способен временно оборвать соединение.

Выполните команды для сброса сети в правильном порядке

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

netsh winsock reset
netsh int ip reset
ipconfig /flushdns
ipconfig /release
ipconfig /renew

Запуск всех строк одной длинной командой затрудняет поиск причины, если одна операция завершится ошибкой. Сообщение о необходимости перезагрузки после netsh int ip reset не означает, что остальные проверки уже прошли.

Что делает каждая команда

netsh winsock reset пересоздает каталог Winsock. В каталоге хранятся записи, через которые сетевые приложения обращаются к TCP/IP. Поврежденные записи могут появиться после установки или удаления VPN, фильтров безопасности и другого сетевого ПО.
netsh int ip reset сбрасывает параметры стека TCP/IP к стандартному состоянию Windows. После команды проверьте ручные настройки IP, маршрутов и DNS, потому что рабочая конфигурация может потребовать повторной настройки.
ipconfig /flushdns удаляет локальные записи DNS-кэша. Команда полезна, если Windows хранит устаревший ответ, но она не исправляет недоступный DNS-сервер или неправильную DNS-зону.
ipconfig /release освобождает DHCP-аренду на адаптерах с автоматической адресацией. На статическом интерфейсе операция не решает проблему и может завершиться сообщением о неприменимости.
ipconfig /renew запрашивает новую DHCP-аренду. Команда сработает только при доступном DHCP-сервере, активном интерфейсе и корректном подключении к нужной сети.

Команды воздействуют на разные уровни. Winsock отвечает за каталог сетевых провайдеров, TCP/IP хранит базовые параметры протоколов, DNS-кэш содержит локальные ответы, а DHCP выдает адресную конфигурацию. Поэтому один успешный шаг не подтверждает исправность всей цепочки.

Перезагрузите Windows после сброса

Перезагрузите компьютер через меню Пуск или из административного терминала:

shutdown /r /t 0

Закройте рабочие приложения и предупредите пользователей, если компьютер обслуживает общие ресурсы. После запуска Windows снова выполните ipconfig /all. Проверяйте параметры в заданном порядке: IPv4 и шлюз, ответ шлюза, внешний IP, DNS-запрос.

Если команды не показали явных ошибок, перезагрузка все равно нужна. Winsock и часть TCP/IP-параметров применяются полностью после перезапуска системы.

Полный сброс сети Windows 10/11 через параметры

Графический Network reset переустанавливает сетевые адаптеры и возвращает связанные параметры к стандартным. Это более радикальный вариант, чем отдельная очистка DNS-кэша или сброс Winsock. Используйте его, когда адаптеры отображаются некорректно, ручной сброс не помог или требуется переустановить сетевые компоненты Windows.

Путь к Network reset в Windows 11

Откройте Параметры.
Перейдите в раздел Сеть и Интернет.
Откройте Дополнительные сетевые параметры.
Выберите Сброс сети.
Нажмите Сбросить сейчас и подтвердите действие.

Windows предупредит о перезагрузке. Закройте сетевые сессии и подготовьте параметры Wi-Fi, VPN и статического IP до подтверждения операции.

Путь к сбросу сети в Windows 10

Откройте Параметры.
Выберите Сеть и Интернет.
Перейдите в раздел Состояние.
Откройте пункт Сброс сети.
Нажмите Сбросить сейчас.

Названия пунктов могут немного отличаться в отдельных сборках Windows 10. Если нужная команда не отображается, найдите в параметрах фразу Сброс сети.

Последствия полного сброса

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

Wi-Fi-профили и сохраненные беспроводные сети;
статический IP, маску, шлюз и DNS;
VPN-клиенты и виртуальные туннели;
прокси и корпоративные параметры авторизации;
виртуальные адаптеры Hyper-V, Docker Desktop и VirtualBox;
нестандартные маршруты и сетевые фильтры.

Не выполняйте полный сброс на удаленном сервере или рабочей станции, доступной только через текущий сетевой канал. Для нестандартной маршрутизации отдельно сохраните вывод route print. Команды добавления и удаления маршрутов собраны в руководстве по управлению маршрутами Windows.

Проверка после перезагрузки: ipconfig, ping и nslookup

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

Шаг 1. Проверьте IP-конфигурацию через `ipconfig /all`

ipconfig /all

Для DHCP-конфигурации ожидайте такие признаки:

у нужного адаптера есть IPv4-адрес из диапазона вашей сети;
маска соответствует подсети;
поле Default Gateway содержит адрес маршрутизатора;
DHCP Enabled указано как Yes;
присутствует адрес DHCP-сервера или система получает параметры согласно политике сети;
в поле DNS указаны доступные резолверы.

Адрес 169.254.x.x после перезагрузки означает, что DHCP-восстановление не завершилось. Отсутствие шлюза указывает на незавершенную маршрутизацию, даже если IPv4-адрес выглядит корректным.

При статической конфигурации сравните значения с сохраненной записью. DHCP может быть выключен намеренно, поэтому поле DHCP Enabled само по себе не служит ошибкой.

Шаг 2. Проверьте локальную связность через `ping`

Проверьте адрес из поля Default Gateway. Если шлюз равен 192.168.1.1, команда выглядит так:

ping 192.168.1.1

Ответы с небольшим временем и без потерь подтверждают связь компьютера с локальным маршрутизатором. При недоступном шлюзе проверяйте сетевой адаптер, кабель, Wi-Fi, VLAN и локальный брандмауэр. DNS на этом шаге еще не участвует.

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

Шаг 3. Проверьте внешний маршрут через `ping`

После успешного ответа шлюза выполните проверку известного внешнего IP:

ping 1.1.1.1

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

Для диагностики опубликованного сервиса с независимого сетевого сегмента можно временно использовать облачный сервер, например Timeweb Cloud. Такой тест помогает отделить проблему компьютера от недоступности конкретной инфраструктуры.

Шаг 4. Проверьте DNS через `nslookup`

Выполните DNS-запрос из командной строки:

nslookup example.com

Проверьте строки Server и Address, чтобы увидеть использованный DNS-сервер, а затем раздел с именем и возвращенными IP-адресами. Успешный ответ содержит адрес для запрошенного домена. Тайм-аут, сообщение о недоступности сервера или отсутствие адреса указывают на отдельную проблему DNS.

Для сравнения отправьте запрос напрямую к конкретному резолверу:

nslookup example.com 1.1.1.1

Если прямой запрос к указанному серверу работает, а обычный nslookup завершается ошибкой, проверьте DNS-серверы в ipconfig /all, настройки VPN и корпоративную DNS-политику. Очистка кэша командой ipconfig /flushdns не восстановит недоступный резолвер.

PTR-запись относится к обратному DNS, когда IP-адрес преобразуется в имя. Наличие PTR само по себе не подтверждает корректность обычного клиентского DNS. Для проверки FCrDNS имя из PTR должно разрешаться обратно в тот же IP-адрес. Для обычного доступа к сайтам достаточно сначала проверить прямой запрос имени, а обратный DNS использовать для отдельной задачи.

Подробная последовательность проверки DNS и дополнительные варианты сброса описаны в материале о проверке и сбросе DNS в Windows.

Как читать комбинации результатов

Проверка	Результат	Что искать дальше
`ipconfig /all`	Нет IPv4, адрес 169.254.x.x или нет шлюза	Адаптер, кабель, Wi-Fi, DHCP, VLAN и статическую конфигурацию
`ping` шлюза	Ответа нет	Локальную сеть, порт коммутатора, точку доступа, firewall и состояние интерфейса
`ping` шлюза	Ответ есть, внешний IP не отвечает	Маршрутизатор, провайдера, внешний маршрут и фильтрацию ICMP
`ping` внешнего IP	Ответ есть, `nslookup` не работает	DNS-серверы, VPN, корпоративную политику и DNS-кэш
`nslookup`	Имя разрешается, приложение не подключается	Прокси, VPN, firewall, TLS, порт и состояние самого сервиса

Успешный ping подтверждает доступность только проверяемого узла. Успешный nslookup подтверждает конкретный DNS-запрос, но не доступность веб-сервиса по HTTPS, работу прокси или правильность VPN-маршрута.

После сброса DHCP или DNS всё ещё не работает

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

Команда `ipconfig /renew` завершается ошибкой

Проверьте, что адаптер включен и имеет физическое подключение. Для Ethernet проверьте линк и порт, для Wi-Fi, подключение к нужному SSID. В окне служб Windows найдите службу DHCP Client и убедитесь, что она запущена.

Дополнительные проверки в PowerShell:

Get-NetAdapter
Get-NetIPConfiguration
Get-Service Dhcp

Сопоставьте эти данные с ipconfig /all. Ошибка обновления аренды возникает, если адаптер отключен, компьютер подключен к неправильной VLAN, DHCP-сервер недоступен, задан конфликтующий статический IP или на роутере исчерпан пул адресов.

Проверьте DHCP на другом устройстве в той же сети. Если оно тоже не получает адрес, сброс Windows не устранит причину на роутере или корпоративном DHCP-сервере.

IP-связность есть, но доменные имена не разрешаются

Если шлюз и внешний IP отвечают, перейдите к DNS. Выполните оба запроса:

nslookup example.com
nslookup example.com 1.1.1.1

Сверьте DNS-серверы в ipconfig /all с настройками сети. В корпоративной среде внешний DNS может быть запрещен, а внутренние домены будут работать только через DNS компании. VPN-клиент может менять DNS после подключения и возвращать прежние параметры после отключения.

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

Локальная сеть работает, а внешние ресурсы недоступны

Сопоставьте два теста: ответ шлюза и ответ внешнего IP. Затем проверьте тот же ресурс с другого компьютера и через альтернативный канал. Такой тест показывает, связана ли проблема с Windows или с маршрутизатором, провайдером, фильтрацией или удаленным сервером.

Не считайте отсутствие ответа ping достаточным доказательством отказа сервиса. Проверьте DNS, TCP-порт и прикладной протокол. Веб-сервер может блокировать ICMP и продолжать принимать HTTPS-запросы.

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

Сброс не помог: что проверить в самом Windows

Проверьте состояние интерфейса и назначенные адреса:

Get-NetAdapter
Get-NetIPConfiguration

В диспетчере устройств проверьте наличие ошибок драйвера сетевого адаптера.
Убедитесь, что нужный интерфейс не отключен и не имеет статуса Media disconnected.
В параметрах Windows проверьте прокси и исключения для локальных адресов.
Временно сопоставьте результат с отключенным VPN, если это разрешено политикой компании.
Проверьте правила стороннего firewall и сетевого защитного ПО.
Сверьте IP, DNS и маршруты с ожидаемой конфигурацией рабочей станции.

Для готового алгоритма действий после неудачного сброса используйте план диагностики подключения после сброса сети Windows.

Когда сброс сетевых настроек Windows не нужен или опасен

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

Статический IP, DNS и корпоративные параметры

Сохраните статический IP-адрес, маску, шлюз, DNS, статические маршруты, прокси и параметры 802.1X. Уточните, требуется ли ручная регистрация MAC-адреса или компьютера на коммутаторе и DHCP-сервере.

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

VPN и виртуальные сетевые адаптеры

Network reset может удалить или переустановить виртуальные интерфейсы. Заранее сохраните конфигурации VPN-клиента, Hyper-V, Docker Desktop, VirtualBox и других систем, которые создают собственные сети.

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

Почему успешный тест не означает, что исправлено всё

Ответ от шлюза подтверждает локальную связность. Ответ от внешнего IP подтверждает доступность конкретного узла или прохождение ICMP. Успешный nslookup показывает, что конкретное имя разрешилось через конкретный DNS-сервер.

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

Итоговая шпаргалка: безопасный порядок действий

Выполните ipconfig /all и сохраните IPv4, маску, шлюз, DHCP, DNS и состояние адаптера.
Проверьте шлюз командой ping адрес_шлюза, подставив фактический адрес из конфигурации.
Сохраните статический IP, DNS, прокси, VPN, виртуальные адаптеры и маршруты через route print.
Откройте Windows Terminal или командную строку от имени администратора.
Выполните по порядку netsh winsock reset, netsh int ip reset, ipconfig /flushdns, ipconfig /release и ipconfig /renew.
Перезагрузите Windows командой shutdown /r /t 0 или через меню Пуск.
Повторите ipconfig /all и убедитесь, что IPv4, шлюз и DNS соответствуют ожидаемой сети.
Проверьте локальный шлюз через ping.
Проверьте внешний IP-адрес через ping 1.1.1.1 или разрешенный узел инфраструктуры.
Проверьте доменное имя через nslookup example.com, а при необходимости сравните ответ с запросом к конкретному DNS-серверу.

Если после этих шагов Windows снова получает адрес 169.254.x.x, ищите причину в адаптере, подключении, VLAN или DHCP. Если IP-связность восстановилась, а имена не разрешаются, проверяйте DNS и VPN. Если компьютер видит шлюз, но внешний сервис недоступен, сопоставляйте результаты с другим устройством, маршрутизатором, провайдером и удаленной инфраструктурой.